linux-stable.git/drivers, branch v6.6.20

ahci: Extend ASM1061 43-bit DMA address quirk to other ASM106x parts

2024-03-01T12:35:11+00:00

commit 51af8f255bdaca6d501afc0d085b808f67b44d91 upstream.

ASMedia have confirmed that all ASM106x parts currently listed in
ahci_pci_tbl[] suffer from the 43-bit DMA address limitation that we ran
into on the ASM1061, and therefore, we need to apply the quirk added by
commit 20730e9b2778 ("ahci: add 43-bit DMA address quirk for ASMedia
ASM1061 controllers") to the other supported ASM106x parts as well.

Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/linux-ide/ZbopwKZJAKQRA4Xv@x1-carbon/
Signed-off-by: Lennert Buytenhek 
[cassel: add link to ASMedia confirmation email]
Signed-off-by: Niklas Cassel 
Signed-off-by: Greg Kroah-Hartman

ata: ahci: add identifiers for ASM2116 series adapters

2024-03-01T12:35:11+00:00

commit 3bf6141060948e27b62b13beb216887f2e54591e upstream.

Add support for PCIe SATA adapter cards based on Asmedia 2116 controllers.
These cards can provide up to 10 SATA ports on PCIe card.

Signed-off-by: Szuying Chen 
Signed-off-by: Damien Le Moal 
Signed-off-by: Greg Kroah-Hartman

i2c: imx: when being a target, mark the last read as processed

2024-03-01T12:35:10+00:00

[ Upstream commit 87aec499368d488c20292952d6d4be7cb9e49c5e ]

When being a target, NAK from the controller means that all bytes have
been transferred. So, the last byte needs also to be marked as
'processed'. Otherwise index registers of backends may not increase.

Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver")
Signed-off-by: Corey Minyard 
Tested-by: Andrew Manley 
Reviewed-by: Andrew Manley 
Reviewed-by: Oleksij Rempel 
[wsa: fixed comment and commit message to properly describe the case]
Signed-off-by: Wolfram Sang 
Signed-off-by: Andi Shyti 
Signed-off-by: Sasha Levin

drm/amd/display: Fix memory leak in dm_sw_fini()

2024-03-01T12:35:10+00:00

[ Upstream commit bae67893578d608e35691dcdfa90c4957debf1d3 ]

After destroying dmub_srv, the memory associated with it is
not freed, causing a memory leak:

unreferenced object 0xffff896302b45800 (size 1024):
  comm "(udev-worker)", pid 222, jiffies 4294894636
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 6265fd77):
    [] kmalloc_trace+0x29d/0x340
    [] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
    [] dm_sw_init+0x15/0x2b0 [amdgpu]
    [] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
    [] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
    [] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
    [] local_pci_probe+0x3e/0x90
    [] pci_device_probe+0xc3/0x230
    [] really_probe+0xe2/0x480
    [] __driver_probe_device+0x78/0x160
    [] driver_probe_device+0x1f/0x90
    [] __driver_attach+0xce/0x1c0
    [] bus_for_each_dev+0x70/0xc0
    [] bus_add_driver+0x112/0x210
    [] driver_register+0x55/0x100
    [] do_one_initcall+0x41/0x300

Fix this by freeing dmub_srv after destroying it.

Fixes: 743b9786b14a ("drm/amd/display: Hook up the DMUB service in DM")
Signed-off-by: Armin Wolf 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/syncobj: handle NULL fence in syncobj_eventfd_entry_func

2024-03-01T12:35:10+00:00

[ Upstream commit 2aa6f5b0fd052e363bb9d4b547189f0bf6b3d6d3 ]

During syncobj_eventfd_entry_func, dma_fence_chain_find_seqno may set
the fence to NULL if the given seqno is signaled and a later seqno has
already been submitted. In that case, the eventfd should be signaled
immediately which currently does not happen.

This is a similar issue to the one addressed by commit b19926d4f3a6
("drm/syncobj: Deal with signalled fences in drm_syncobj_find_fence.").

As a fix, if the return value of dma_fence_chain_find_seqno indicates
success but it sets the fence to NULL, we will assign a stub fence to
ensure the following code still signals the eventfd.

v1 -> v2: assign a stub fence instead of signaling the eventfd

Signed-off-by: Erik Kurzinger 
Fixes: c7a472297169 ("drm/syncobj: add IOCTL to register an eventfd")
Signed-off-by: Simon Ser 
Link: https://patchwork.freedesktop.org/patch/msgid/20240221184527.37667-1-ekurzinger@nvidia.com
Signed-off-by: Sasha Levin

drm/syncobj: call drm_syncobj_fence_add_wait when WAIT_AVAILABLE flag is set

2024-03-01T12:35:10+00:00

[ Upstream commit 3c43177ffb54ea5be97505eb8e2690e99ac96bc9 ]

When waiting for a syncobj timeline point whose fence has not yet been
submitted with the WAIT_FOR_SUBMIT flag, a callback is registered using
drm_syncobj_fence_add_wait and the thread is put to sleep until the
timeout expires. If the fence is submitted before then,
drm_syncobj_add_point will wake up the sleeping thread immediately which
will proceed to wait for the fence to be signaled.

However, if the WAIT_AVAILABLE flag is used instead,
drm_syncobj_fence_add_wait won't get called, meaning the waiting thread
will always sleep for the full timeout duration, even if the fence gets
submitted earlier. If it turns out that the fence *has* been submitted
by the time it eventually wakes up, it will still indicate to userspace
that the wait completed successfully (it won't return -ETIME), but it
will have taken much longer than it should have.

To fix this, we must call drm_syncobj_fence_add_wait if *either* the
WAIT_FOR_SUBMIT flag or the WAIT_AVAILABLE flag is set. The only
difference being that with WAIT_FOR_SUBMIT we will also wait for the
fence to be signaled after it has been submitted while with
WAIT_AVAILABLE we will return immediately.

IGT test patch: https://lists.freedesktop.org/archives/igt-dev/2024-January/067537.html

v1 -> v2: adjust lockdep_assert_none_held_once condition

(cherry picked from commit 8c44ea81634a4a337df70a32621a5f3791be23df)

Fixes: 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8")
Signed-off-by: Erik Kurzinger 
Signed-off-by: Simon Ser 
Reviewed-by: Daniel Vetter 
Reviewed-by: Simon Ser 
Link: https://patchwork.freedesktop.org/patch/msgid/20240119163208.3723457-1-ekurzinger@nvidia.com
Signed-off-by: Sasha Levin

net: phy: realtek: Fix rtl8211f_config_init() for RTL8211F(D)(I)-VD-CG PHY

2024-03-01T12:35:10+00:00

[ Upstream commit 3489182b11d35f1944c1245fc9c4867cf622c50f ]

Commit bb726b753f75 ("net: phy: realtek: add support for
RTL8211F(D)(I)-VD-CG") extended support of the driver from the existing
support for RTL8211F(D)(I)-CG PHY to the newer RTL8211F(D)(I)-VD-CG PHY.

While that commit indicated that the RTL8211F_PHYCR2 register is not
supported by the "VD-CG" PHY model and therefore updated the corresponding
section in rtl8211f_config_init() to be invoked conditionally, the call to
"genphy_soft_reset()" was left as-is, when it should have also been invoked
conditionally. This is because the call to "genphy_soft_reset()" was first
introduced by the commit 0a4355c2b7f8 ("net: phy: realtek: add dt property
to disable CLKOUT clock") since the RTL8211F guide indicates that a PHY
reset should be issued after setting bits in the PHYCR2 register.

As the PHYCR2 register is not applicable to the "VD-CG" PHY model, fix the
rtl8211f_config_init() function by invoking "genphy_soft_reset()"
conditionally based on the presence of the "PHYCR2" register.

Fixes: bb726b753f75 ("net: phy: realtek: add support for RTL8211F(D)(I)-VD-CG")
Signed-off-by: Siddharth Vadapalli 
Reviewed-by: Simon Horman 
Link: https://lore.kernel.org/r/20240220070007.968762-1-s-vadapalli@ti.com
Signed-off-by: Paolo Abeni 
Signed-off-by: Sasha Levin

net: sparx5: Add spinlock for frame transmission from CPU

2024-03-01T12:35:09+00:00

[ Upstream commit 603ead96582d85903baec2d55f021b8dac5c25d2 ]

Both registers used when doing manual injection or fdma injection are
shared between all the net devices of the switch. It was noticed that
when having two process which each of them trying to inject frames on
different ethernet ports, that the HW started to behave strange, by
sending out more frames then expected. When doing fdma injection it is
required to set the frame in the DCB and then make sure that the next
pointer of the last DCB is invalid. But because there is no locks for
this, then easily this pointer between the DCB can be broken and then it
would create a loop of DCBs. And that means that the HW will
continuously transmit these frames in a loop. Until the SW will break
this loop.
Therefore to fix this issue, add a spin lock for when accessing the
registers for manual or fdma injection.

Signed-off-by: Horatiu Vultur 
Reviewed-by: Daniel Machon 
Fixes: f3cad2611a77 ("net: sparx5: add hostmode with phylink support")
Link: https://lore.kernel.org/r/20240219080043.1561014-1-horatiu.vultur@microchip.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

hwmon: (nct6775) Fix access to temperature configuration registers

2024-03-01T12:35:08+00:00

[ Upstream commit d56e460e19ea8382f813eb489730248ec8d7eb73 ]

The number of temperature configuration registers does
not always match the total number of temperature registers.
This can result in access errors reported if KASAN is enabled.

BUG: KASAN: global-out-of-bounds in nct6775_probe+0x5654/0x6fe9 nct6775_core

Reported-by: Erhard Furtner 
Closes: https://lore.kernel.org/linux-hwmon/d51181d1-d26b-42b2-b002-3f5a4037721f@roeck-us.net/
Fixes: b7f1f7b2523a ("hwmon: (nct6775) Additional TEMP registers for nct6799")
Cc: Ahmad Khalifa 
Tested-by: Ahmad Khalifa 
Signed-off-by: Guenter Roeck 
Signed-off-by: Sasha Levin

cache: ax45mp_cache: Align end size to cache boundary in ax45mp_dma_cache_wback()

2024-03-01T12:35:08+00:00

[ Upstream commit 9bd405c48b0ac4de087c0c4440fd79597201b8a7 ]

Align the end size to cache boundary size in ax45mp_dma_cache_wback()
callback likewise done in ax45mp_dma_cache_inv() callback.

Additionally return early in case of start == end.

Fixes: d34599bcd2e4 ("cache: Add L2 cache management for Andes AX45MP RISC-V core")
Reported-by: Pavel Machek 
Link: https://lore.kernel.org/cip-dev/ZYsdKDiw7G+kxQ3m@duo.ucw.cz/
Signed-off-by: Lad Prabhakar 
Signed-off-by: Conor Dooley 
Signed-off-by: Sasha Levin