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

Revert "drm/amd/display: Fix VUpdate offset calculations for dcn401"

2025-06-27T10:13:43+00:00

commit 0fc9635a801f6ba3a03ad2de6d46f4f3e2fdfed6 upstream.

This reverts commit fe45e2af4a22e569b35b7f45eb9f040f6fbef94f.

Reason for revert: it causes stuttering in some usecases.

Reviewed-by: Aric Cyr 
Signed-off-by: Dillon Varone 
Signed-off-by: Roman Li 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

PCI: pciehp: Ignore belated Presence Detect Changed caused by DPC

2025-06-27T10:13:43+00:00

[ Upstream commit bbf10cd686835d5a4b8566dc73a3b00b4cd7932a ]

Commit c3be50f7547c ("PCI: pciehp: Ignore Presence Detect Changed caused by
DPC") sought to ignore Presence Detect Changed events occurring as a side
effect of Downstream Port Containment.

The commit awaits recovery from DPC and then clears events which occurred
in the meantime. However if the first event seen after DPC is Data Link
Layer State Changed, only that event is cleared and not Presence Detect
Changed. The object of the commit is thus defeated.

That's because pciehp_ist() computes the events to clear based on the local
"events" variable instead of "ctrl->pending_events". The former contains
the events that had occurred when pciehp_ist() was entered, whereas the
latter also contains events that have accumulated while awaiting DPC
recovery.

In practice, the order of PDC and DLLSC events is arbitrary and the delay
in-between can be several milliseconds.

So change the logic to always clear PDC events, even if they come after an
initial DLLSC event.

Fixes: c3be50f7547c ("PCI: pciehp: Ignore Presence Detect Changed caused by DPC")
Reported-by: Lương Việt Hoàng
Reported-by: Joel Mathew Thomas
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219765#c165
Signed-off-by: Lukas Wunner
Signed-off-by: Bjorn Helgaas
Tested-by: Lương Việt Hoàng
Tested-by: Joel Mathew Thomas
Link: https://patch.msgid.link/d9c4286a16253af7e93eaf12e076e3ef3546367a.1750257164.git.lukas@wunner.de
Signed-off-by: Sasha Levin

gpio: mlxbf3: only get IRQ for device instance 0

2025-06-27T10:13:43+00:00

[ Upstream commit 10af0273a35ab4513ca1546644b8c853044da134 ]

The gpio-mlxbf3 driver interfaces with two GPIO controllers,
device instance 0 and 1. There is a single IRQ resource shared
between the two controllers, and it is found in the ACPI table for
device instance 0.  The driver should not attempt to get an IRQ
resource when probing device instance 1, otherwise the following
error is logged:
  mlxbf3_gpio MLNXBF33:01: error -ENXIO: IRQ index 0 not found

Signed-off-by: David Thompson 
Reviewed-by: Shravan Kumar Ramani 
Fixes: cd33f216d241 ("gpio: mlxbf3: Add gpio driver support")
Link: https://lore.kernel.org/r/20250613163443.1065217-1-davthompson@nvidia.com
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Sasha Levin

mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants

2025-06-27T10:13:43+00:00

[ Upstream commit dba90f5a79c13936de4273a19e67908a0c296afe ]

Dual and quad capable chips natively support dual and quad I/O variants
at up to 104MHz (1-2-2 and 1-4-4 operations). Reaching the maximum speed
of 166MHz is theoretically possible (while still unsupported in the
field) by adding a few more dummy cycles. Let's be accurate and clearly
state this limit.

Setting a maximum frequency implies adding the frequency parameter to
the macro, which is done using a variadic argument to avoid impacting
all the other drivers which already make use of this macro.

Fixes: 1ea808b4d15b ("mtd: spinand: winbond: Update the *JW chip definitions")
Signed-off-by: Miquel Raynal 
Signed-off-by: Sasha Levin

mtd: spinand: Use more specific naming for the (quad IO) read from cache ops

2025-06-27T10:13:42+00:00

[ Upstream commit 9c6911072c6e8b128ccdb7dd00efa13c47513074 ]

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really mean by describing the expected bus
topology in the (quad IO) read from cache macro names.

Acked-by: Tudor Ambarus 
Signed-off-by: Miquel Raynal 
Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants")
Signed-off-by: Sasha Levin

mtd: spinand: Use more specific naming for the (quad output) read from cache ops

2025-06-27T10:13:42+00:00

[ Upstream commit 1deae734cc1c7e976d588e7d8f46af2bb9ef5656 ]

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really mean by describing the expected bus
topology in the (quad output) read from cache macro names.

Acked-by: Tudor Ambarus 
Signed-off-by: Miquel Raynal 
Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants")
Signed-off-by: Sasha Levin

mtd: spinand: Use more specific naming for the (dual IO) read from cache ops

2025-06-27T10:13:42+00:00

[ Upstream commit d9de177996d74c0cc44220003953ba2d2bece0ac ]

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really mean by describing the expected bus
topology in the (dual IO) read from cache macro names. While at
modifying them, better reordering the macros to group them all by bus
topology which now feels more intuitive.

Acked-by: Tudor Ambarus 
Signed-off-by: Miquel Raynal 
Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants")
Signed-off-by: Sasha Levin

mtd: spinand: Use more specific naming for the (dual output) read from cache ops

2025-06-27T10:13:42+00:00

[ Upstream commit 684f7105e8534f6500de389c089ba204cb1c8058 ]

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really mean by describing the expected bus
topology in the (dual output) read from cache macro names.

Acked-by: Tudor Ambarus 
Signed-off-by: Miquel Raynal 
Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants")
Signed-off-by: Sasha Levin

mtd: spinand: Use more specific naming for the (single) read from cache ops

2025-06-27T10:13:42+00:00

[ Upstream commit ea2087d4e66d0b927918cc9048576aca6a0446ad ]

SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).

Let's clarify what the macro really mean by describing the expected bus
topology in the (single) read from cache macro names.

Acked-by: Tudor Ambarus 
Signed-off-by: Miquel Raynal 
Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants")
Signed-off-by: Sasha Levin

gpio: pca953x: fix wrong error probe return value

2025-06-27T10:13:42+00:00

[ Upstream commit 0a1db19f66c0960eb00e1f2ccd40708b6747f5b1 ]

The second argument to dev_err_probe() is the error value. Pass the
return value of devm_request_threaded_irq() there instead of the irq
number.

Signed-off-by: Sascha Hauer 
Fixes: c47f7ff0fe61 ("gpio: pca953x: Utilise dev_err_probe() where it makes sense")
Link: https://lore.kernel.org/r/20250616134503.1201138-1-s.hauer@pengutronix.de
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Sasha Levin