summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2023-05-25net: phy: Fix genphy_config_advert to advertise PAUSE and 10M Full duplex modeGenevieve Chan1-2/+1
This patch ensure that only 10M Full Duplex and PAUSE are enabled for StarFive Dubhe FPGA Platform Signed-off-by: Genevieve Chan <genevieve.chan@starfivetech.com>
2023-05-25Revert "net: phy: marvell: Set autonegotiation to OFF by default upon init"Genevieve Chan1-2/+0
This reverts commit 057202b6b0f0e9265d6e374f959f715bc3232227. Signed-off-by: Genevieve Chan <genevieve.chan@starfivetech.com>
2023-05-25Revert "net: phylink: Assign link config in phylink_create()"Genevieve Chan1-4/+4
This reverts commit dbe28bc438226acf5b9523bf0a156433470e417d. Signed-off-by: Genevieve Chan <genevieve.chan@starfivetech.com>
2023-03-20random: Cater for low CONFIG_HZ when evaluating cycle counter for jitter ↵Tan En De1-1/+1
entropy generation MAX_SAMPLES_PER_BIT is defined as HZ / 15. However, because of the use of integer division, when HZ < 15, MAX_SAMPLES_BIT_PER_BIT becomes 0. On Linux with CONFIG_HZ < 15, this causes kernel to always assume cycle counter is not suitable for generating jitter entropy. Empirically, this assumption is not true on Dubhe FPGA with CONFIG_HZ_10, because regardless of the low CONFIG_HZ, Dubhe’s cycle counter is still able to produce entropy very fast, such that stack.samples_per_bit = 1. Thus, this commit uses round-up when computing MAX_SAMPLES_PER_BIT: MAX_SAMPLES_PER_BIT = DIV_ROUND_UP(HZ, 15) instead of simply HZ / 15. This way, on Dubhe FPGA with CONFIG_HZ_10, we get MAX_SAMPLES_PER_BIT = 1, and the speed check in try_to_generate_entropy() will pass, which then allows the use of cycle counter to generate jitter entropy. With this commit, Dubhe is now able to reach “crng init done” quickly whenever entropy is needed by a program during boot (ssh-keygen used by Buildroot's sshd). Signed-off-by: Tan En De <ende.tan@starfivetech.com>
2023-03-20net: phylink: Assign link config in phylink_create()Genevieve Chan1-4/+4
This patch parse the following config to a struct phylink: * speed = 10Mbps * duplex = full * pause = RX on, TX on Signed-off-by: Genevieve Chan <genevieve.chan@starfivetech.com>
2023-03-20net: phy: marvell: Set autonegotiation to OFF by default upon initGenevieve Chan1-0/+2
This patch set AUTONEG_DISABLE during init to disable autonegotiation by default. Signed-off-by: Genevieve Chan <genevieve.chan@starfivetech.com>
2023-03-20net: Revert: "net: stmmac: use GFP_DMA32"Ley Foon Tan1-2/+2
This reverts commit 4a75f8889870a8b461c4f0afb6588a3729017490. GMAC supports 64-bit DMA addressing in Dubhe, revert this commit. Signed-off-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
2023-03-20net: stmmac: Add StarFive dwmac supportLey Foon Tan3-0/+162
Add StarFive dwmac support. Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com> Signed-off-by: Ley Foon Tan <leyfoon.tan@linux.starfivetech.com>
2023-03-20mtd: spi-nor: macronix: Add support for MX66U1G45GLey Foon Tan1-0/+3
The Macronix MX66U1G45G is a 1.8V, 1Gbit (128MB) flash device that supports x1, x2, or x4 operation. The MX66U1G45G is the smaller sibling of the mx66u2g45g that is already supported. Tested on StarFive Dubhe hardware on FPGA with a SiFive SPI controller. Validated by erase, read back, write and read back. Signed-off-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
2023-03-20RISC-V: Support CPUID for risc-v in perfJoão Mário Domingos1-0/+18
This patch creates the header.c file for the risc-v architecture and introduces support for PMU identification through sysfs. It is now possible to configure pmu-events in risc-v. Depends on patch [1], that introduces the id sysfs file. Signed-off-by: João Mário Domingos <joao.mario@tecnico.ulisboa.pt>
2023-03-20RISC-V: Create unique identification for SoC PMUJoão Mário Domingos1-0/+47
The SBI PMU platform driver did not provide any identification for perf events matching. This patch introduces a new sysfs file inside the platform device (soc:pmu/id) for pmu identification. The identification is a 64-bit value generated as: [63-32]: mvendorid; [31]: marchid[MSB]; [30-16]: marchid[15-0]; [15-0]: mimpid[15MSBs]; The CSRs are detailed in the RISC-V privileged spec [1]. The marchid is split in MSB + 15LSBs, due to the MSB being used for open-source architecture identification. [1] https://github.com/riscv/riscv-isa-manual Signed-off-by: João Mário Domingos <joao.mario@tecnico.ulisboa.pt>
2023-03-20spi: cadence-quadspi: Allow compilation on RISC-VEmil Renner Berthing1-1/+1
This IP is also used on the StarFive JH7100 riscv64 SoC and presumably also the upcoming JH7110 SoC. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20nvdla: add NVDLA driverFarzad Farshchi33-0/+32588
Additional update from Prashant Gaikwad <pgaikwad@nvidia.com> Adapted for Linux 5.13 and the BeagleV Starlight board by <cybergaszcz@gmail.com> kernel test robot: fix platform_no_drv_owner.cocci warnings Geert: Use div_u64() in dla_get_time_us() Signed-off-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20220119060057.GA1143@7f39e361da8f Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2203090905560.780932@ramsan.of.borg Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20drm/i2c/tda998x: Hardcode register values for Starlightsw.multimedia1-2/+5
A proper solution to this hack should be found. Signed-off-by: jack.zhu <jack.zhu@starfivetech.com> Signed-off-by: keith.zhao <keith.zhao@starfivetech.com>
2023-03-20[WIP] drm/starfive: Support DRM_FORMAT_XRGB8888Emil Renner Berthing2-0/+2
When creating dumb buffers with 32bpp and 24bit colour depth this is default mode return by drm_mode_legacy_fb_format. So we need to support this for common dumb buffers to just work. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20drm/starfive: Add StarFive drm driversw.multimedia19-0/+3427
Add starfive DRM Display driver framework Signed-off-by: jack.zhu <jack.zhu@starfivetech.com> Signed-off-by: keith.zhao <keith.zhao@starfivetech.com> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/a8ca722539672d6369d6e4092e1e08cb6b58c546.1645535955.git.geert@linux-m68k.org Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20net: stmmac: use GFP_DMA32Matteo Croce1-2/+2
Signed-off-by: Matteo Croce <mcroce@microsoft.com>
2023-03-20net: stmmac: Add glue layer for StarFive JH71x0 SoCsEmil Renner Berthing3-0/+171
This adds a glue layer for the Synopsys DesignWare MAC IP core on the StarFive JH71x0 SoCs. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20net: stmmac: platform: Add snps,dwmac-5.20 IP compatible stringEmil Renner Berthing1-1/+2
Add "snps,dwmac-5.20" compatible string for 5.20 version that can avoid to define some platform data in the glue layer. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20net: phy: motorcomm: Disable rgmii rx delayEmil Renner Berthing1-0/+7
Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
2023-03-20dmaengine: dw-axi-dmac: Add StarFive JH7100 supportSamin Guo2-1/+14
Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20dmaengine: dw-axi-dmac: Handle xfer start while non-idleSamin Guo2-1/+4
Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Signed-off-by: Curry Zhang <curry.zhang@starfivetech.com>
2023-03-20pwm: sifive-ptc: Add SiFive PWM PTC driverChenjieqin3-0/+270
yiming.li: clear CNTR of PWM after setting period & duty_cycle Emil: cleanups, clock, reset and div_u64 Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20drivers/tty/serial/8250: update driver for JH7100Samin Guo1-0/+8
2023-03-20power: reset: tps65086: Allow building as a moduleEmil Renner Berthing1-1/+1
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20soc: sifive: ccache: Add non-coherent DMA handlingEmil Renner Berthing1-1/+59
Add functions to flush the caches and handle non-coherent DMA. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20soc: sifive: ccache: Add StarFive JH71x0 supportEmil Renner Berthing3-3/+13
This adds support for the StarFive JH7100 and JH7110 SoCs which also feature this SiFive cache controller. Unfortunately the interrupt for uncorrected data is broken on the JH7100 and fires continuously, so add a quirk to not register a handler for it. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20hwrng: Add StarFive JH7100 Random Number Generator driverHuan Feng4-0/+437
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20watchdog: Add StarFive SI5 watchdog driverSamin Guo3-0/+773
Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Signed-off-by: Walker Chen <walker.chen@starfivetech.com> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20hwmon: (sfctemp) Add StarFive JH71x0 temperature sensorEmil Renner Berthing3-0/+361
Register definitions and conversion constants based on sfctemp driver by Samin in the StarFive 5.10 kernel. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
2023-03-20serial: 8250_dw: Add starfive,jh7100-hsuart compatibleEmil Renner Berthing1-0/+1
This adds a compatible for the high speed UARTs on the StarFive JH7100 RISC-V SoC. Just like the regular uarts we also need to keep the input clocks at their default rate and rely only on the divisor in the UART. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20pinctrl: starfive: Reset pinmux settingsEmil Renner Berthing1-0/+66
Current u-boot doesn't seem to take into account that some GPIOs are configured as inputs/outputs of certain peripherals on power-up. This means it ends up configuring some GPIOs as inputs to more than one peripheral which the documentation explicitly says is illegal. Similarly it also ends up configuring more than one GPIO as output of the same peripheral. While not explicitly mentioned by the documentation this also seems like a bad idea. The easiest way to remedy this mess is to just disconnect all GPIOs from peripherals and have our pinmux configuration set everything up properly. This, however, means that we'd disconnect the serial console from its pins for a while, so add a device tree property to keep certain GPIOs from being reset. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20clk: starfive: jh7100: Keep more clocks aliveEmil Renner Berthing1-18/+18
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20reset: starfive: Add JH7100 audio reset driverEmil Renner Berthing5-11/+108
The audio resets are almost identical to the system resets, there are just fewer of them. So factor out and export a generic probe function, so most of the reset controller implementation can be shared. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20reset: starfive: Use 32bit I/O on 32bit registersEmil Renner Berthing1-20/+20
The driver currently uses 64bit I/O on the 32bit registers. This works because there are 4 assert registers and 4 status register, so they're only ever accessed on 64bit boundaries. There are however other reset controllers for audio and video on the SoC with only one status register that isn't 64bit aligned so 64bit I/O would result in an unaligned access exception. Switch to 32bit I/O in preparation for supporting these resets too. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20reset: Create subdirectory for StarFive driversEmil Renner Berthing5-8/+12
This moves the StarFive JH7100 reset driver to a new subdirectory in preparation for adding more StarFive reset drivers. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2023-03-20net: phy: Add driver for Motorcomm yt8521 gigabit ethernet phyFrank2-3/+1634
Add a driver for the motorcomm yt8521 gigabit ethernet phy. We have verified the driver on StarFive VisionFive development board, which is developed by Shanghai StarFive Technology Co., Ltd.. On the board, yt8521 gigabit ethernet phy works in utp mode, RGMII interface, supports 1000M/100M/10M speeds, and wol(magic package). Signed-off-by: Frank <Frank.Sae@motor-comm.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-03-17drm/amd/display: adjust MALL size available for DCN32 and DCN321Samson Tam5-5/+78
commit 235fef6c7fd341026eee90cc546e6e8ff8b2c315 upstream. [Why] MALL size available can vary for different SKUs. Use num_chans read from VBIOS to determine the available MALL size we can use [How] Define max_chans for DCN32 and DCN321. If num_chans is max_chans, then return max_chans as we can access the entire MALL space. Otherwise, define avail_chans as the number of available channels we are allowed instead. Return corresponding number of channels back and use this to calculate available MALL size. Reviewed-by: Nevenko Stupar <Nevenko.Stupar@amd.com> Acked-by: Alan Liu <HaoPing.Liu@amd.com> Signed-off-by: Samson Tam <Samson.Tam@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-17drm/amd/display: Allow subvp on vactive pipes that are 2560x1440@60Alvin Lee2-1/+32
commit 2ebd1036209c2e7b61e6bc6e5bee4b67c1684ac6 upstream. Enable subvp on specifically 1440p@60hz displays even though it can switch in vactive. Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-17media: rc: gpio-ir-recv: add remove functionLi Jun1-0/+18
[ Upstream commit 30040818b338b8ebc956ce0ebd198f8d593586a6 ] In case runtime PM is enabled, do runtime PM clean up to remove cpu latency qos request, otherwise driver removal may have below kernel dump: [ 19.463299] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000048 [ 19.472161] Mem abort info: [ 19.474985] ESR = 0x0000000096000004 [ 19.478754] EC = 0x25: DABT (current EL), IL = 32 bits [ 19.484081] SET = 0, FnV = 0 [ 19.487149] EA = 0, S1PTW = 0 [ 19.490361] FSC = 0x04: level 0 translation fault [ 19.495256] Data abort info: [ 19.498149] ISV = 0, ISS = 0x00000004 [ 19.501997] CM = 0, WnR = 0 [ 19.504977] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000049f81000 [ 19.511432] [0000000000000048] pgd=0000000000000000, p4d=0000000000000000 [ 19.518245] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 19.524520] Modules linked in: gpio_ir_recv(+) rc_core [last unloaded: rc_core] [ 19.531845] CPU: 0 PID: 445 Comm: insmod Not tainted 6.2.0-rc1-00028-g2c397a46d47c #72 [ 19.531854] Hardware name: FSL i.MX8MM EVK board (DT) [ 19.531859] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.551777] pc : cpu_latency_qos_remove_request+0x20/0x110 [ 19.557277] lr : gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.557294] sp : ffff800008ce3740 [ 19.557297] x29: ffff800008ce3740 x28: 0000000000000000 x27: ffff800008ce3d50 [ 19.574270] x26: ffffc7e3e9cea100 x25: 00000000000f4240 x24: ffffc7e3f9ef0e30 [ 19.574284] x23: 0000000000000000 x22: ffff0061803820f4 x21: 0000000000000008 [ 19.574296] x20: ffffc7e3fa75df30 x19: 0000000000000020 x18: ffffffffffffffff [ 19.588570] x17: 0000000000000000 x16: ffffc7e3f9efab70 x15: ffffffffffffffff [ 19.595712] x14: ffff800008ce37b8 x13: ffff800008ce37aa x12: 0000000000000001 [ 19.602853] x11: 0000000000000001 x10: ffffcbe3ec0dff87 x9 : 0000000000000008 [ 19.609991] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 000000000f0bfe9f [ 19.624261] x5 : 00ffffffffffffff x4 : 0025ab8e00000000 x3 : ffff006180382010 [ 19.631405] x2 : ffffc7e3e9ce8030 x1 : ffffc7e3fc3eb810 x0 : 0000000000000020 [ 19.638548] Call trace: [ 19.640995] cpu_latency_qos_remove_request+0x20/0x110 [ 19.646142] gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.652339] pm_generic_runtime_suspend+0x2c/0x44 [ 19.657055] __rpm_callback+0x48/0x1dc [ 19.660807] rpm_callback+0x6c/0x80 [ 19.664301] rpm_suspend+0x10c/0x640 [ 19.667880] rpm_idle+0x250/0x2d0 [ 19.671198] update_autosuspend+0x38/0xe0 [ 19.675213] pm_runtime_set_autosuspend_delay+0x40/0x60 [ 19.680442] gpio_ir_recv_probe+0x1b4/0x21c [gpio_ir_recv] [ 19.685941] platform_probe+0x68/0xc0 [ 19.689610] really_probe+0xc0/0x3dc [ 19.693189] __driver_probe_device+0x7c/0x190 [ 19.697550] driver_probe_device+0x3c/0x110 [ 19.701739] __driver_attach+0xf4/0x200 [ 19.705578] bus_for_each_dev+0x70/0xd0 [ 19.709417] driver_attach+0x24/0x30 [ 19.712998] bus_add_driver+0x17c/0x240 [ 19.716834] driver_register+0x78/0x130 [ 19.720676] __platform_driver_register+0x28/0x34 [ 19.725386] gpio_ir_recv_driver_init+0x20/0x1000 [gpio_ir_recv] [ 19.731404] do_one_initcall+0x44/0x2ac [ 19.735243] do_init_module+0x48/0x1d0 [ 19.739003] load_module+0x19fc/0x2034 [ 19.742759] __do_sys_finit_module+0xac/0x12c [ 19.747124] __arm64_sys_finit_module+0x20/0x30 [ 19.751664] invoke_syscall+0x48/0x114 [ 19.755420] el0_svc_common.constprop.0+0xcc/0xec [ 19.760132] do_el0_svc+0x38/0xb0 [ 19.763456] el0_svc+0x2c/0x84 [ 19.766516] el0t_64_sync_handler+0xf4/0x120 [ 19.770789] el0t_64_sync+0x190/0x194 [ 19.774460] Code: 910003fd a90153f3 aa0003f3 91204021 (f9401400) [ 19.780556] ---[ end trace 0000000000000000 ]--- Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17media: ov5640: Fix analogue gain controlPaul Elder1-1/+1
[ Upstream commit afa4805799c1d332980ad23339fdb07b5e0cf7e0 ] Gain control is badly documented in publicly available (including leaked) documentation. There is an AGC pre-gain in register 0x3a13, expressed as a 6-bit value (plus an enable bit in bit 6). The driver hardcodes it to 0x43, which one application note states is equal to x1.047. The documentation also states that 0x40 is equel to x1.000. The pre-gain thus seems to be expressed as in 1/64 increments, and thus ranges from x1.00 to x1.984. What the pre-gain does is however unspecified. There is then an AGC gain limit, in registers 0x3a18 and 0x3a19, expressed as a 10-bit "real gain format" value. One application note sets it to 0x00f8 and states it is equal to x15.5, so it appears to be expressed in 1/16 increments, up to x63.9375. The manual gain is stored in registers 0x350a and 0x350b, also as a 10-bit "real gain format" value. It is documented in the application note as a Q6.4 values, up to x63.9375. One version of the datasheet indicates that the sensor supports a digital gain: The OV5640 supports 1/2/4 digital gain. Normally, the gain is controlled automatically by the automatic gain control (AGC) block. It isn't clear how that would be controlled manually. There appears to be no indication regarding whether the gain controlled through registers 0x350a and 0x350b is an analogue gain only or also includes digital gain. The words "real gain" don't necessarily mean "combined analogue and digital gains". Some OmniVision sensors (such as the OV8858) are documented as supoprting different formats for the gain values, selectable through a register bit, and they are called "real gain format" and "sensor gain format". For that sensor, we have (one of) the gain registers documented as 0x3503[2]=0, gain[7:0] is real gain format, where low 4 bits are fraction bits, for example, 0x10 is 1x gain, 0x28 is 2.5x gain If 0x3503[2]=1, gain[7:0] is sensor gain format, gain[7:4] is coarse gain, 00000: 1x, 00001: 2x, 00011: 4x, 00111: 8x, gain[7] is 1, gain[3:0] is fine gain. For example, 0x10 is 1x gain, 0x30 is 2x gain, 0x70 is 4x gain (The second part of the text makes little sense) "Real gain" may thus refer to the combination of the coarse and fine analogue gains as a single value. The OV5640 0x350a and 0x350b registers thus appear to control analogue gain. The driver incorrectly uses V4L2_CID_GAIN as V4L2 has a specific control for analogue gain, V4L2_CID_ANALOGUE_GAIN. Use it. If registers 0x350a and 0x350b are later found to control digital gain as well, the driver could then restrict the range of the analogue gain control value to lower than x64 and add a separate digital gain control. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17macintosh: windfarm: Use unsigned type for 1-bit bitfieldsNathan Chancellor2-4/+4
[ Upstream commit 748ea32d2dbd813d3bd958117bde5191182f909a ] Clang warns: drivers/macintosh/windfarm_lm75_sensor.c:63:14: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] lm->inited = 1; ^ ~ drivers/macintosh/windfarm_smu_sensors.c:356:19: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] pow->fake_volts = 1; ^ ~ drivers/macintosh/windfarm_smu_sensors.c:368:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] pow->quadratic = 1; ^ ~ There is no bug here since no code checks the actual value of these fields, just whether or not they are zero (boolean context), but this can be easily fixed by switching to an unsigned type. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20230215-windfarm-wsingle-bit-bitfield-constant-conversion-v1-1-26415072e855@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17clk: renesas: rcar-gen3: Disable R-Car H3 ES1.*Wolfram Sang5-173/+13
[ Upstream commit b1dec4e78599a2ce5bf8557056cd6dd72e1096b0 ] R-Car H3 ES1.* was only available to an internal development group and needed a lot of quirks and workarounds. These become a maintenance burden now, so our development group decided to remove upstream support for this SoC. Public users only have ES2 onwards. In addition to the ES1 specific removals, a check for it was added preventing the machine to boot further. It may otherwise inherit wrong clock settings from ES2 which could damage the hardware. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230202092332.2504-1-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17tpm/eventlog: Don't abort tpm_read_log on faulty ACPI addressMorten Linderud1-1/+5
[ Upstream commit 80a6c216b16d7f5c584d2148c2e4345ea4eb06ce ] tpm_read_log_acpi() should return -ENODEV when no eventlog from the ACPI table is found. If the firmware vendor includes an invalid log address we are unable to map from the ACPI memory and tpm_read_log() returns -EIO which would abort discovery of the eventlog. Change the return value from -EIO to -ENODEV when acpi_os_map_iomem() fails to map the event log. The following hardware was used to test this issue: Framework Laptop (Pre-production) BIOS: INSYDE Corp, Revision: 3.2 TPM Device: NTC, Firmware Revision: 7.2 Dump of the faulty ACPI TPM2 table: [000h 0000 4] Signature : "TPM2" [Trusted Platform Module hardware interface Table] [004h 0004 4] Table Length : 0000004C [008h 0008 1] Revision : 04 [009h 0009 1] Checksum : 2B [00Ah 0010 6] Oem ID : "INSYDE" [010h 0016 8] Oem Table ID : "TGL-ULT" [018h 0024 4] Oem Revision : 00000002 [01Ch 0028 4] Asl Compiler ID : "ACPI" [020h 0032 4] Asl Compiler Revision : 00040000 [024h 0036 2] Platform Class : 0000 [026h 0038 2] Reserved : 0000 [028h 0040 8] Control Address : 0000000000000000 [030h 0048 4] Start Method : 06 [Memory Mapped I/O] [034h 0052 12] Method Parameters : 00 00 00 00 00 00 00 00 00 00 00 00 [040h 0064 4] Minimum Log Length : 00010000 [044h 0068 8] Log Address : 000000004053D000 Fixes: 0cf577a03f21 ("tpm: Fix handling of missing event log") Tested-by: Erkki Eilonen <erkki@bearmetal.eu> Signed-off-by: Morten Linderud <morten@linderud.pw> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17drm/msm/adreno: fix runtime PM imbalance at unbindJohan Hovold1-1/+2
[ Upstream commit 6153c44392b04ff2da1e9aa82ba87da9ab9a0fc1 ] A recent commit moved enabling of runtime PM from adreno_gpu_init() to adreno_load_gpu() (called on first open()), which means that unbind() may now be called with runtime PM disabled in case the device was never opened in between. Make sure to only forcibly suspend and disable runtime PM at unbind() in case runtime PM has been enabled to prevent a disable count imbalance. This specifically avoids leaving runtime PM disabled when the device is later opened after a successful bind: msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* Couldn't power up the GPU: -13 Fixes: 4b18299b3365 ("drm/msm/adreno: Defer enabling runpm until hw_init()") Reported-by: Bjorn Andersson <quic_bjorande@quicinc.com> Link: https://lore.kernel.org/lkml/20230203181245.3523937-1-quic_bjorande@quicinc.com Cc: stable@vger.kernel.org # 6.0 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/523549/ Link: https://lore.kernel.org/r/20230221101430.14546-2-johan+linaro@kernel.org Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17adreno: Shutdown the GPU properlyJoel Fernandes (Google)1-2/+3
[ Upstream commit e752e5454e6417da3f40ec1306a041ea96c56423 ] During kexec on ARM device, we notice that device_shutdown() only calls pm_runtime_force_suspend() while shutting down the GPU. This means the GPU kthread is still running and further, there maybe active submits. This causes all kinds of issues during a kexec reboot: Warning from shutdown path: [ 292.509662] WARNING: CPU: 0 PID: 6304 at [...] adreno_runtime_suspend+0x3c/0x44 [ 292.509863] Hardware name: Google Lazor (rev3 - 8) with LTE (DT) [ 292.509872] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 292.509881] pc : adreno_runtime_suspend+0x3c/0x44 [ 292.509891] lr : pm_generic_runtime_suspend+0x30/0x44 [ 292.509905] sp : ffffffc014473bf0 [...] [ 292.510043] Call trace: [ 292.510051] adreno_runtime_suspend+0x3c/0x44 [ 292.510061] pm_generic_runtime_suspend+0x30/0x44 [ 292.510071] pm_runtime_force_suspend+0x54/0xc8 [ 292.510081] adreno_shutdown+0x1c/0x28 [ 292.510090] platform_shutdown+0x2c/0x38 [ 292.510104] device_shutdown+0x158/0x210 [ 292.510119] kernel_restart_prepare+0x40/0x4c And here from GPU kthread, an SError OOPs: [ 192.648789] el1h_64_error+0x7c/0x80 [ 192.648812] el1_interrupt+0x20/0x58 [ 192.648833] el1h_64_irq_handler+0x18/0x24 [ 192.648854] el1h_64_irq+0x7c/0x80 [ 192.648873] local_daif_inherit+0x10/0x18 [ 192.648900] el1h_64_sync_handler+0x48/0xb4 [ 192.648921] el1h_64_sync+0x7c/0x80 [ 192.648941] a6xx_gmu_set_oob+0xbc/0x1fc [ 192.648968] a6xx_hw_init+0x44/0xe38 [ 192.648991] msm_gpu_hw_init+0x48/0x80 [ 192.649013] msm_gpu_submit+0x5c/0x1a8 [ 192.649034] msm_job_run+0xb0/0x11c [ 192.649058] drm_sched_main+0x170/0x434 [ 192.649086] kthread+0x134/0x300 [ 192.649114] ret_from_fork+0x10/0x20 Fix by calling adreno_system_suspend() in the device_shutdown() path. [ Applied Rob Clark feedback on fixing adreno_unbind() similarly, also tested as above. ] Cc: Rob Clark <robdclark@chromium.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Ricardo Ribalda <ribalda@chromium.org> Cc: Ross Zwisler <zwisler@kernel.org> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Rob Clark <robdclark@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/517633/ Link: https://lore.kernel.org/r/20230109222547.1368644-1-joel@joelfernandes.org Signed-off-by: Rob Clark <robdclark@chromium.org> Stable-dep-of: 6153c44392b0 ("drm/msm/adreno: fix runtime PM imbalance at unbind") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4Veerabadhran Gopalakrishnan1-0/+1
[ Upstream commit 6ce2ea07c5ff0a8188eab0e5cd1f0e4899b36835 ] Added the video capability query support for VCN version 4_0_4 Signed-off-by: Veerabadhran Gopalakrishnan <veerabadhran.gopalakrishnan@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17drm/amdgpu/soc21: don't expose AV1 if VCN0 is harvestedAlex Deucher1-13/+48
[ Upstream commit a6de636eb04f146d23644dbbb7173e142452a9b7 ] Only VCN0 supports AV1. Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Stable-dep-of: 6ce2ea07c5ff ("drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17drm/amdgpu: fix return value check in kfdShashank Sharma1-1/+1
[ Upstream commit 20534dbcc7b7bfb447279cdcfb0d88ee3b779a18 ] This patch fixes a return value check in kfd doorbell handling. This function should return 0(error) only when the ida_simple_get returns < 0(error), return > 0 is a success case. Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Fixes: 16f0013157bf ("drm/amdkfd: Allocate doorbells only when needed") Acked-by: Christian Koenig <chriatian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Shashank Sharma <shashank.sharma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17net: dsa: mt7530: permit port 5 to work without port 6 on MT7621 SoCVladimir Oltean1-15/+20
[ Upstream commit c8b8a3c601f2cfad25ab5ce5b04df700048aef6e ] The MT7530 switch from the MT7621 SoC has 2 ports which can be set up as internal: port 5 and 6. Arınç reports that the GMAC1 attached to port 5 receives corrupted frames, unless port 6 (attached to GMAC0) has been brought up by the driver. This is true regardless of whether port 5 is used as a user port or as a CPU port (carrying DSA tags). Offline debugging (blind for me) which began in the linked thread showed experimentally that the configuration done by the driver for port 6 contains a step which is needed by port 5 as well - the write to CORE_GSWPLL_GRP2 (note that I've no idea as to what it does, apart from the comment "Set core clock into 500Mhz"). Prints put by Arınç show that the reset value of CORE_GSWPLL_GRP2 is RG_GSWPLL_POSDIV_500M(1) | RG_GSWPLL_FBKDIV_500M(40) (0x128), both on the MCM MT7530 from the MT7621 SoC, as well as on the standalone MT7530 from MT7623NI Bananapi BPI-R2. Apparently, port 5 on the standalone MT7530 can work under both values of the register, while on the MT7621 SoC it cannot. The call path that triggers the register write is: mt753x_phylink_mac_config() for port 6 -> mt753x_pad_setup() -> mt7530_pad_clk_setup() so this fully explains the behavior noticed by Arınç, that bringing port 6 up is necessary. The simplest fix for the problem is to extract the register writes which are needed for both port 5 and 6 into a common mt7530_pll_setup() function, which is called at mt7530_setup() time, immediately after switch reset. We can argue that this mirrors the code layout introduced in mt7531_setup() by commit 42bc4fafe359 ("net: mt7531: only do PLL once after the reset"), in that the PLL setup has the exact same positioning, and further work to consolidate the separate setup() functions is not hindered. Testing confirms that: - the slight reordering of writes to MT7530_P6ECR and to CORE_GSWPLL_GRP1 / CORE_GSWPLL_GRP2 introduced by this change does not appear to cause problems for the operation of port 6 on MT7621 and on MT7623 (where port 5 also always worked) - packets sent through port 5 are not corrupted anymore, regardless of whether port 6 is enabled by phylink or not (or even present in the device tree) My algorithm for determining the Fixes: tag is as follows. Testing shows that some logic from mt7530_pad_clk_setup() is needed even for port 5. Prior to commit ca366d6c889b ("net: dsa: mt7530: Convert to PHYLINK API"), a call did exist for all phy_is_pseudo_fixed_link() ports - so port 5 included. That commit replaced it with a temporary "Port 5 is not supported!" comment, and the following commit 38f790a80560 ("net: dsa: mt7530: Add support for port 5") replaced that comment with a configuration procedure in mt7530_setup_port5() which was insufficient for port 5 to work. I'm laying the blame on the patch that claimed support for port 5, although one would have also needed the change from commit c3b8e07909db ("net: dsa: mt7530: setup core clock even in TRGMII mode") for the write to be performed completely independently from port 6's configuration. Thanks go to Arınç for describing the problem, for debugging and for testing. Reported-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/netdev/f297c2c4-6e7c-57ac-2394-f6025d309b9d@arinc9.com/ Fixes: 38f790a80560 ("net: dsa: mt7530: Add support for port 5") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230307155411.868573-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-28 16:30:16 +0300