<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/spi, branch v6.18.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>spi: ch341: fix out-of-bounds memory access in ch341_transfer_one</title>
<updated>2025-12-18T13:03:26+00:00</updated>
<author>
<name>Tianchu Chen</name>
<email>flynnnchen@tencent.com</email>
</author>
<published>2025-11-28T08:06:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=81841da1f30f66a850cc8796d99ba330aad9d696'/>
<id>81841da1f30f66a850cc8796d99ba330aad9d696</id>
<content type='text'>
[ Upstream commit 545d1287e40a55242f6ab68bcc1ba3b74088b1bc ]

Discovered by Atuin - Automated Vulnerability Discovery Engine.

The 'len' variable is calculated as 'min(32, trans-&gt;len + 1)',
which includes the 1-byte command header.

When copying data from 'trans-&gt;tx_buf' to 'ch341-&gt;tx_buf + 1', using 'len'
as the length is incorrect because:

1. It causes an out-of-bounds read from 'trans-&gt;tx_buf' (which has size
   'trans-&gt;len', i.e., 'len - 1' in this context).
2. It can cause an out-of-bounds write to 'ch341-&gt;tx_buf' if 'len' is
   CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341-&gt;tx_buf + 1
   overflows the buffer.

Fix this by copying 'len - 1' bytes.

Fixes: 8846739f52af ("spi: add ch341a usb2spi driver")
Signed-off-by: Tianchu Chen &lt;flynnnchen@tencent.com&gt;
Link: https://patch.msgid.link/20251128160630.0f922c45ec6084a46fb57099@linux.dev
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 545d1287e40a55242f6ab68bcc1ba3b74088b1bc ]

Discovered by Atuin - Automated Vulnerability Discovery Engine.

The 'len' variable is calculated as 'min(32, trans-&gt;len + 1)',
which includes the 1-byte command header.

When copying data from 'trans-&gt;tx_buf' to 'ch341-&gt;tx_buf + 1', using 'len'
as the length is incorrect because:

1. It causes an out-of-bounds read from 'trans-&gt;tx_buf' (which has size
   'trans-&gt;len', i.e., 'len - 1' in this context).
2. It can cause an out-of-bounds write to 'ch341-&gt;tx_buf' if 'len' is
   CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341-&gt;tx_buf + 1
   overflows the buffer.

Fix this by copying 'len - 1' bytes.

Fixes: 8846739f52af ("spi: add ch341a usb2spi driver")
Signed-off-by: Tianchu Chen &lt;flynnnchen@tencent.com&gt;
Link: https://patch.msgid.link/20251128160630.0f922c45ec6084a46fb57099@linux.dev
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was short to GND</title>
<updated>2025-12-18T13:03:24+00:00</updated>
<author>
<name>Mikhail Kshevetskiy</name>
<email>mikhail.kshevetskiy@iopsys.eu</email>
</author>
<published>2025-11-25T23:40:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=749c2b72a2baebf023cbcdffc4c1bc50c4e6442a'/>
<id>749c2b72a2baebf023cbcdffc4c1bc50c4e6442a</id>
<content type='text'>
[ Upstream commit 061795b345aff371df8f71d54ae7c7dc8ae630d0 ]

Airoha EN7523 specific bug
--------------------------
We found that some serial console may pull TX line to GROUND during board
boot time. Airoha uses TX line as one of its bootstrap pins. On the EN7523
SoC this may lead to booting in RESERVED boot mode.

It was found that some flashes operates incorrectly in RESERVED mode.
Micron and Skyhigh flashes are definitely affected by the issue,
Winbond flashes are not affected.

Details:
--------
DMA reading of odd pages on affected flashes operates incorrectly. Page
reading offset (start of the page) on hardware level is replaced by 0x10.
Thus results in incorrect data reading. As result OS loading becomes
impossible.

Usage of UBI make things even worse. On attaching, UBI will detects
corruptions (because of wrong reading of odd pages) and will try to
recover. For recovering UBI will erase and write 'damaged' blocks with
a valid information. This will destroy all UBI data.

Non-DMA reading is OK.

This patch detects booting in reserved mode, turn off DMA and print big
fat warning.

It's worth noting that the boot configuration is preserved across reboots.
Therefore, to boot normally, you should do the following:
- disconnect the serial console from the board,
- power cycle the board.

Fixes: a403997c12019 ("spi: airoha: add SPI-NAND Flash controller driver")
Signed-off-by: Mikhail Kshevetskiy &lt;mikhail.kshevetskiy@iopsys.eu&gt;
Reviewed-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@intel.com&gt;
Link: https://patch.msgid.link/20251125234047.1101985-2-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 061795b345aff371df8f71d54ae7c7dc8ae630d0 ]

Airoha EN7523 specific bug
--------------------------
We found that some serial console may pull TX line to GROUND during board
boot time. Airoha uses TX line as one of its bootstrap pins. On the EN7523
SoC this may lead to booting in RESERVED boot mode.

It was found that some flashes operates incorrectly in RESERVED mode.
Micron and Skyhigh flashes are definitely affected by the issue,
Winbond flashes are not affected.

Details:
--------
DMA reading of odd pages on affected flashes operates incorrectly. Page
reading offset (start of the page) on hardware level is replaced by 0x10.
Thus results in incorrect data reading. As result OS loading becomes
impossible.

Usage of UBI make things even worse. On attaching, UBI will detects
corruptions (because of wrong reading of odd pages) and will try to
recover. For recovering UBI will erase and write 'damaged' blocks with
a valid information. This will destroy all UBI data.

Non-DMA reading is OK.

This patch detects booting in reserved mode, turn off DMA and print big
fat warning.

It's worth noting that the boot configuration is preserved across reboots.
Therefore, to boot normally, you should do the following:
- disconnect the serial console from the board,
- power cycle the board.

Fixes: a403997c12019 ("spi: airoha: add SPI-NAND Flash controller driver")
Signed-off-by: Mikhail Kshevetskiy &lt;mikhail.kshevetskiy@iopsys.eu&gt;
Reviewed-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@intel.com&gt;
Link: https://patch.msgid.link/20251125234047.1101985-2-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: sophgo: Fix incorrect use of bus width value macros</title>
<updated>2025-12-18T13:03:05+00:00</updated>
<author>
<name>Longbin Li</name>
<email>looong.bin@gmail.com</email>
</author>
<published>2025-11-17T09:05:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=77d179867bcc1f8f48bcfc5cdbcf40ba3ab86ead'/>
<id>77d179867bcc1f8f48bcfc5cdbcf40ba3ab86ead</id>
<content type='text'>
[ Upstream commit d9813cd23d5a7b254cc1b1c1ea042634d8da62e6 ]

The previous code initialized the 'reg' value with specific bus-width
values (BUS_WIDTH_2_BIT and BUS_WIDTH_4_BIT), which introduces ambiguity.
Replace them with BUS_WIDTH_MASK to express the intention clearly.

Fixes: de16c322eefb ("spi: sophgo: add SG2044 SPI NOR controller driver")
Signed-off-by: Longbin Li &lt;looong.bin@gmail.com&gt;
Link: https://patch.msgid.link/20251117090559.78288-1-looong.bin@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d9813cd23d5a7b254cc1b1c1ea042634d8da62e6 ]

The previous code initialized the 'reg' value with specific bus-width
values (BUS_WIDTH_2_BIT and BUS_WIDTH_4_BIT), which introduces ambiguity.
Replace them with BUS_WIDTH_MASK to express the intention clearly.

Fixes: de16c322eefb ("spi: sophgo: add SG2044 SPI NOR controller driver")
Signed-off-by: Longbin Li &lt;looong.bin@gmail.com&gt;
Link: https://patch.msgid.link/20251117090559.78288-1-looong.bin@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: tegra210-quad: Fix timeout handling</title>
<updated>2025-12-18T13:02:50+00:00</updated>
<author>
<name>Vishwaroop A</name>
<email>va@nvidia.com</email>
</author>
<published>2025-10-28T15:57:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=01bbf25c767219b14c3235bfa85906b8d2cb8fbc'/>
<id>01bbf25c767219b14c3235bfa85906b8d2cb8fbc</id>
<content type='text'>
[ Upstream commit b4e002d8a7cee3b1d70efad0e222567f92a73000 ]

When the CPU that the QSPI interrupt handler runs on (typically CPU 0)
is excessively busy, it can lead to rare cases of the IRQ thread not
running before the transfer timeout is reached.

While handling the timeouts, any pending transfers are cleaned up and
the message that they correspond to is marked as failed, which leaves
the curr_xfer field pointing at stale memory.

To avoid this, clear curr_xfer to NULL upon timeout and check for this
condition when the IRQ thread is finally run.

While at it, also make sure to clear interrupts on failure so that new
interrupts can be run.

A better, more involved, fix would move the interrupt clearing into a
hard IRQ handler. Ideally we would also want to signal that the IRQ
thread no longer needs to be run after the timeout is hit to avoid the
extra check for a valid transfer.

Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller")
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Vishwaroop A &lt;va@nvidia.com&gt;
Link: https://patch.msgid.link/20251028155703.4151791-2-va@nvidia.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b4e002d8a7cee3b1d70efad0e222567f92a73000 ]

When the CPU that the QSPI interrupt handler runs on (typically CPU 0)
is excessively busy, it can lead to rare cases of the IRQ thread not
running before the transfer timeout is reached.

While handling the timeouts, any pending transfers are cleaned up and
the message that they correspond to is marked as failed, which leaves
the curr_xfer field pointing at stale memory.

To avoid this, clear curr_xfer to NULL upon timeout and check for this
condition when the IRQ thread is finally run.

While at it, also make sure to clear interrupts on failure so that new
interrupts can be run.

A better, more involved, fix would move the interrupt clearing into a
hard IRQ handler. Ideally we would also want to signal that the IRQ
thread no longer needs to be run after the timeout is hit to avoid the
extra check for a valid transfer.

Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller")
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Vishwaroop A &lt;va@nvidia.com&gt;
Link: https://patch.msgid.link/20251028155703.4151791-2-va@nvidia.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: nxp-fspi: Propagate fwnode in ACPI case as well</title>
<updated>2025-11-27T11:41:06+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2025-11-26T20:25:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=40ad64ac25bb736740f895d99a4aebbda9b80991'/>
<id>40ad64ac25bb736740f895d99a4aebbda9b80991</id>
<content type='text'>
Propagate fwnode of the ACPI device to the SPI controller Linux device.
Currently only OF case propagates fwnode to the controller.

While at it, replace several calls to dev_fwnode() with a single one
cached in a local variable, and unify checks for fwnode type by using
is_*_node() APIs.

Fixes: 55ab8487e01d ("spi: spi-nxp-fspi: Add ACPI support")
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Link: https://patch.msgid.link/20251126202501.2319679-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Propagate fwnode of the ACPI device to the SPI controller Linux device.
Currently only OF case propagates fwnode to the controller.

While at it, replace several calls to dev_fwnode() with a single one
cached in a local variable, and unify checks for fwnode type by using
is_*_node() APIs.

Fixes: 55ab8487e01d ("spi: spi-nxp-fspi: Add ACPI support")
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Link: https://patch.msgid.link/20251126202501.2319679-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA</title>
<updated>2025-11-26T12:30:15+00:00</updated>
<author>
<name>Francesco Lavra</name>
<email>flavra@baylibre.com</email>
</author>
<published>2025-11-26T09:50:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3dcf44ab56e1d3ca3532083c0d5390b758e45b45'/>
<id>3dcf44ab56e1d3ca3532083c0d5390b758e45b45</id>
<content type='text'>
This driver runs also on Tegra SoCs without a Tegra20 APB DMA controller
(e.g. Tegra234).
Remove the Kconfig dependency on TEGRA20_APB_DMA; in addition, amend the
help text to reflect the fact that this driver works on SoCs different from
Tegra114.

Fixes: bb9667d8187b ("arm64: tegra: Add SPI device tree nodes for Tegra234")
Signed-off-by: Francesco Lavra &lt;flavra@baylibre.com&gt;
Link: https://patch.msgid.link/20251126095027.4102004-1-flavra@baylibre.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This driver runs also on Tegra SoCs without a Tegra20 APB DMA controller
(e.g. Tegra234).
Remove the Kconfig dependency on TEGRA20_APB_DMA; in addition, amend the
help text to reflect the fact that this driver works on SoCs different from
Tegra114.

Fixes: bb9667d8187b ("arm64: tegra: Add SPI device tree nodes for Tegra234")
Signed-off-by: Francesco Lavra &lt;flavra@baylibre.com&gt;
Link: https://patch.msgid.link/20251126095027.4102004-1-flavra@baylibre.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors</title>
<updated>2025-11-24T11:31:27+00:00</updated>
<author>
<name>Haotian Zhang</name>
<email>vulab@iscas.ac.cn</email>
</author>
<published>2025-11-24T01:58:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a90903c2a3c38bce475f46ea3f93dbf6a9971553'/>
<id>a90903c2a3c38bce475f46ea3f93dbf6a9971553</id>
<content type='text'>
devm_pm_runtime_enable() can fail due to memory allocation. The current
code ignores its return value, potentially causing runtime PM operations
to fail silently after autosuspend configuration.

Check the return value of devm_pm_runtime_enable() and return on failure.

Fixes: 909fac05b926 ("spi: add support for Amlogic A1 SPI Flash Controller")
Signed-off-by: Haotian Zhang &lt;vulab@iscas.ac.cn&gt;
Link: https://patch.msgid.link/20251124015852.937-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
devm_pm_runtime_enable() can fail due to memory allocation. The current
code ignores its return value, potentially causing runtime PM operations
to fail silently after autosuspend configuration.

Check the return value of devm_pm_runtime_enable() and return on failure.

Fixes: 909fac05b926 ("spi: add support for Amlogic A1 SPI Flash Controller")
Signed-off-by: Haotian Zhang &lt;vulab@iscas.ac.cn&gt;
Link: https://patch.msgid.link/20251124015852.937-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: spi-fsl-lpspi: fix watermark truncation caused by type cast</title>
<updated>2025-11-21T14:23:45+00:00</updated>
<author>
<name>Carlos Song</name>
<email>carlos.song@nxp.com</email>
</author>
<published>2025-11-17T03:03:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9f0c21bac5a8089e74b21d007e26fb4594b10d73'/>
<id>9f0c21bac5a8089e74b21d007e26fb4594b10d73</id>
<content type='text'>
't-&gt;len' is an unsigned integer, while 'watermark' and 'txfifosize' are
u8. Using min_t with typeof(watermark) forces both values to be cast to
u8, which truncates len when it exceeds 255. For example, len = 4096
becomes 0 after casting, resulting in an incorrect watermark value.

Use a wider type in min_t to avoid truncation and ensure the correct
minimum value is applied.

Fixes: a750050349ea ("spi: spi-fsl-lpspi: use min_t() to improve code")
Signed-off-by: Carlos Song &lt;carlos.song@nxp.com&gt;
Reviewed-by: Daniel Baluta &lt;daniel.baluta@nxp.com&gt;
Link: https://patch.msgid.link/20251117030355.1359081-1-carlos.song@nxp.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
't-&gt;len' is an unsigned integer, while 'watermark' and 'txfifosize' are
u8. Using min_t with typeof(watermark) forces both values to be cast to
u8, which truncates len when it exceeds 255. For example, len = 4096
becomes 0 after casting, resulting in an incorrect watermark value.

Use a wider type in min_t to avoid truncation and ensure the correct
minimum value is applied.

Fixes: a750050349ea ("spi: spi-fsl-lpspi: use min_t() to improve code")
Signed-off-by: Carlos Song &lt;carlos.song@nxp.com&gt;
Reviewed-by: Daniel Baluta &lt;daniel.baluta@nxp.com&gt;
Link: https://patch.msgid.link/20251117030355.1359081-1-carlos.song@nxp.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm</title>
<updated>2025-11-20T00:10:51+00:00</updated>
<author>
<name>Siddharth Vadapalli</name>
<email>s-vadapalli@ti.com</email>
</author>
<published>2025-11-19T15:23:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=295fe8406a357bc0abb901a21d1a554fd4dd1d05'/>
<id>295fe8406a357bc0abb901a21d1a554fd4dd1d05</id>
<content type='text'>
Commit f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier
to avoid imbalance") relocated code but missed updating the error handling
path associated with it.

Prior to the relocation, runtime pm was enabled after the code-block
associated with 'cqspi_request_mmap_dma()', due to which, the error
handling for the same didn't require invoking 'pm_runtime_disable()'.

Post refactoring, runtime pm has been enabled before the code-block and
when an error is encountered, jumping to 'probe_dma_failed' doesn't
invoke 'pm_runtime_disable()'. This leads to a race condition wherein
'cqspi_runtime_suspend()' is invoked while the error handling path executes
in parallel. The resulting error is the following:

  clk:103:0 already disabled
  WARNING: drivers/clk/clk.c:1188 at clk_core_disable+0x80/0xa0, CPU#1: kworker/u8:0/12
  [TRIMMED]
  pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : clk_core_disable+0x80/0xa0
  lr : clk_core_disable+0x80/0xa0
  [TRIMMED]
  Call trace:
   clk_core_disable+0x80/0xa0 (P)
   clk_core_disable_lock+0x88/0x10c
   clk_disable+0x24/0x30
   cqspi_probe+0xa3c/0xae8
  [TRIMMED]

The error is due to the second invocation of 'clk_disable_unprepare()' on
'cqspi-&gt;clk' in the error handling within 'cqspi_probe()', with the first
invocation being within 'cqspi_runtime_suspend()'.

Fix this by correcting the error handling.

Fixes: f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance")
Signed-off-by: Siddharth Vadapalli &lt;s-vadapalli@ti.com&gt;
Link: https://patch.msgid.link/20251119152545.2591651-1-s-vadapalli@ti.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier
to avoid imbalance") relocated code but missed updating the error handling
path associated with it.

Prior to the relocation, runtime pm was enabled after the code-block
associated with 'cqspi_request_mmap_dma()', due to which, the error
handling for the same didn't require invoking 'pm_runtime_disable()'.

Post refactoring, runtime pm has been enabled before the code-block and
when an error is encountered, jumping to 'probe_dma_failed' doesn't
invoke 'pm_runtime_disable()'. This leads to a race condition wherein
'cqspi_runtime_suspend()' is invoked while the error handling path executes
in parallel. The resulting error is the following:

  clk:103:0 already disabled
  WARNING: drivers/clk/clk.c:1188 at clk_core_disable+0x80/0xa0, CPU#1: kworker/u8:0/12
  [TRIMMED]
  pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : clk_core_disable+0x80/0xa0
  lr : clk_core_disable+0x80/0xa0
  [TRIMMED]
  Call trace:
   clk_core_disable+0x80/0xa0 (P)
   clk_core_disable_lock+0x88/0x10c
   clk_disable+0x24/0x30
   cqspi_probe+0xa3c/0xae8
  [TRIMMED]

The error is due to the second invocation of 'clk_disable_unprepare()' on
'cqspi-&gt;clk' in the error handling within 'cqspi_probe()', with the first
invocation being within 'cqspi_runtime_suspend()'.

Fix this by correcting the error handling.

Fixes: f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance")
Signed-off-by: Siddharth Vadapalli &lt;s-vadapalli@ti.com&gt;
Link: https://patch.msgid.link/20251119152545.2591651-1-s-vadapalli@ti.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: bcm63xx: fix premature CS deassertion on RX-only transactions</title>
<updated>2025-11-17T17:29:50+00:00</updated>
<author>
<name>Hang Zhou</name>
<email>929513338@qq.com</email>
</author>
<published>2025-11-16T14:08:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fd9862f726aedbc2f29a29916cabed7bcf5cadb6'/>
<id>fd9862f726aedbc2f29a29916cabed7bcf5cadb6</id>
<content type='text'>
On BCM6358 (and also observed on BCM6368) the controller appears to
only generate as many SPI clocks as bytes that have been written into
the TX FIFO. For RX-only transfers the driver programs the transfer
length in SPI_MSG_CTL but does not write anything into the FIFO, so
chip select is deasserted early and the RX transfer segment is never
fully clocked in.

A concrete failing case is a three-transfer MAC address read from
SPI-NOR:
  - TX 0x03 (read command)
  - TX 3-byte address
  - RX 6 bytes (MAC)

In contrast, a two-transfer JEDEC-ID read (0x9f + 6-byte RX) works
because the driver uses prepend_len and writes dummy bytes into the
TX FIFO for the RX part.

Fix this by writing 0xff dummy bytes into the TX FIFO for RX-only
segments so that the number of bytes written to the FIFO matches the
total message length seen by the controller.

Fixes: b17de076062a ("spi/bcm63xx: work around inability to keep CS up")

Signed-off-by: Hang Zhou &lt;929513338@qq.com&gt;
Link: https://patch.msgid.link/tencent_7AC88FCB3076489A4A7E6C2163DF1ACF8D06@qq.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On BCM6358 (and also observed on BCM6368) the controller appears to
only generate as many SPI clocks as bytes that have been written into
the TX FIFO. For RX-only transfers the driver programs the transfer
length in SPI_MSG_CTL but does not write anything into the FIFO, so
chip select is deasserted early and the RX transfer segment is never
fully clocked in.

A concrete failing case is a three-transfer MAC address read from
SPI-NOR:
  - TX 0x03 (read command)
  - TX 3-byte address
  - RX 6 bytes (MAC)

In contrast, a two-transfer JEDEC-ID read (0x9f + 6-byte RX) works
because the driver uses prepend_len and writes dummy bytes into the
TX FIFO for the RX part.

Fix this by writing 0xff dummy bytes into the TX FIFO for RX-only
segments so that the number of bytes written to the FIFO matches the
total message length seen by the controller.

Fixes: b17de076062a ("spi/bcm63xx: work around inability to keep CS up")

Signed-off-by: Hang Zhou &lt;929513338@qq.com&gt;
Link: https://patch.msgid.link/tencent_7AC88FCB3076489A4A7E6C2163DF1ACF8D06@qq.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
