<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/spi, branch v7.2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>spi: virtio: mark device ready before registering the controller</title>
<updated>2026-08-13T16:34:01+00:00</updated>
<author>
<name>Jasper Wise</name>
<email>jaspwise@amazon.co.uk</email>
</author>
<published>2026-08-13T08:46:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=11058bd3d47d57eb3473935feae53868d6d168b7'/>
<id>11058bd3d47d57eb3473935feae53868d6d168b7</id>
<content type='text'>
virtio_spi_probe() registers the SPI controller with
devm_spi_register_controller(). spi_register_controller() binds a child
inline unless its driver has asked for asynchronous probing, so a
peripheral that performs a transfer during its own probe reaches
virtio_spi_transfer_one(), which kicks the virtqueue before probe has
returned.

The driver never calls virtio_device_ready(), so DRIVER_OK is set on its
behalf by virtio_dev_probe(), only once probe has returned. The virtio
spec is explicit about that ordering in 3.1 Device Initialization:
  |  The driver MUST NOT send any buffer available notifications to the
  |  device before setting DRIVER_OK.

A device that waits for DRIVER_OK before servicing the queue therefore
leaves the transfer unanswered, and virtio_spi_transfer_one() waits for its
completion with no timeout, so probe never returns.

Mark the device ready before registering the controller, as done for the
same reason in commit f5866db64f34 ("virtio_console: enable VQs early") and
commit 1d774589f924 ("i2c: virtio: mark device ready before registering the
adapter").

Fixes: f98cabe3f6cf ("SPI: Add virtio SPI driver")
Signed-off-by: Jasper Wise &lt;jaspwise@amazon.co.uk&gt;
Link: https://patch.msgid.link/20260813084618.613172-1-jaspwise@amazon.co.uk
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
virtio_spi_probe() registers the SPI controller with
devm_spi_register_controller(). spi_register_controller() binds a child
inline unless its driver has asked for asynchronous probing, so a
peripheral that performs a transfer during its own probe reaches
virtio_spi_transfer_one(), which kicks the virtqueue before probe has
returned.

The driver never calls virtio_device_ready(), so DRIVER_OK is set on its
behalf by virtio_dev_probe(), only once probe has returned. The virtio
spec is explicit about that ordering in 3.1 Device Initialization:
  |  The driver MUST NOT send any buffer available notifications to the
  |  device before setting DRIVER_OK.

A device that waits for DRIVER_OK before servicing the queue therefore
leaves the transfer unanswered, and virtio_spi_transfer_one() waits for its
completion with no timeout, so probe never returns.

Mark the device ready before registering the controller, as done for the
same reason in commit f5866db64f34 ("virtio_console: enable VQs early") and
commit 1d774589f924 ("i2c: virtio: mark device ready before registering the
adapter").

Fixes: f98cabe3f6cf ("SPI: Add virtio SPI driver")
Signed-off-by: Jasper Wise &lt;jaspwise@amazon.co.uk&gt;
Link: https://patch.msgid.link/20260813084618.613172-1-jaspwise@amazon.co.uk
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: dw: fix wrong RX_SAMPLE_DLY setting after resume</title>
<updated>2026-08-11T14:15:46+00:00</updated>
<author>
<name>Jisheng Zhang</name>
<email>jszhang@kernel.org</email>
</author>
<published>2026-08-03T13:59:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=133c71b2c0bc976a4751f9e05ef7cdea67f964e5'/>
<id>133c71b2c0bc976a4751f9e05ef7cdea67f964e5</id>
<content type='text'>
On platforms which need a non-zero rx sample delay, the RX_SAMPLE_DLY
reg setting is lost after resume. The reason is that the reg may be
reset to 0 after resuming, but dws-&gt;cur_rx_sample_dly doesn't know
this fact. Fix this issue by clearing dws-&gt;cur_rx_sample_dly in
dw_spi_shutdown_chip().

Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Suggested-by: Mark Brown &lt;broonie@kernel.org&gt;
Link: https://patch.msgid.link/20260803135925.12622-1-jszhang@kernel.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On platforms which need a non-zero rx sample delay, the RX_SAMPLE_DLY
reg setting is lost after resume. The reason is that the reg may be
reset to 0 after resuming, but dws-&gt;cur_rx_sample_dly doesn't know
this fact. Fix this issue by clearing dws-&gt;cur_rx_sample_dly in
dw_spi_shutdown_chip().

Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Suggested-by: Mark Brown &lt;broonie@kernel.org&gt;
Link: https://patch.msgid.link/20260803135925.12622-1-jszhang@kernel.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: Few fix/improvement for spi-nxp-fspi</title>
<updated>2026-07-30T12:13:51+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2026-07-30T12:13:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9513b642d233bedb0b703ea75b5f3230eb6293a0'/>
<id>9513b642d233bedb0b703ea75b5f3230eb6293a0</id>
<content type='text'>
haibo.chen@oss.nxp.com &lt;haibo.chen@oss.nxp.com&gt; says:

Patch 1 introduce per-SoC clock rate limits for both SDR and DTR modes
        by adding max_sdr_rate and max_dtr_rate to nxp_fspi_devtype_data.
Patch 2 enter stop mode before reconfiguring MCR0 and DLL to follow
	FlexSPI reference manual initialization sequence
Patch 3 propagate clock reconfig failures in nxp_fspi_select_mem()

Link: https://patch.msgid.link/20260728-fspi-clock-v2-0-dbe786a4a6eb@nxp.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
haibo.chen@oss.nxp.com &lt;haibo.chen@oss.nxp.com&gt; says:

Patch 1 introduce per-SoC clock rate limits for both SDR and DTR modes
        by adding max_sdr_rate and max_dtr_rate to nxp_fspi_devtype_data.
Patch 2 enter stop mode before reconfiguring MCR0 and DLL to follow
	FlexSPI reference manual initialization sequence
Patch 3 propagate clock reconfig failures in nxp_fspi_select_mem()

Link: https://patch.msgid.link/20260728-fspi-clock-v2-0-dbe786a4a6eb@nxp.com
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: spi-nxp-fspi: propagate clock reconfig failures in nxp_fspi_select_mem()</title>
<updated>2026-07-30T12:13:50+00:00</updated>
<author>
<name>Haibo Chen</name>
<email>haibo.chen@nxp.com</email>
</author>
<published>2026-07-28T10:18:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b5902b9779796d515b7d65eb9205994b7a8d00cb'/>
<id>b5902b9779796d515b7d65eb9205994b7a8d00cb</id>
<content type='text'>
nxp_fspi_select_mem() disables the FlexSPI clocks before calling
clk_set_rate() and re-enabling them. If clk_set_rate() or the clock
re-enable fails, the function returned early (as void) leaving both the
serial root clock and the register interface clock disabled.

As the function returned void, nxp_fspi_exec_op() had no way to know
about the failure and continued to access FlexSPI registers (LUT setup,
data transfer, AHB buffer invalidation). Accessing the controller
registers while its clock is gated off results in a synchronous external
abort.

Make nxp_fspi_select_mem() return an error code and have
nxp_fspi_exec_op() bail out on failure before any further register
access, including nxp_fspi_invalid().

Signed-off-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Link: https://patch.msgid.link/20260728-fspi-clock-v2-3-dbe786a4a6eb@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>
nxp_fspi_select_mem() disables the FlexSPI clocks before calling
clk_set_rate() and re-enabling them. If clk_set_rate() or the clock
re-enable fails, the function returned early (as void) leaving both the
serial root clock and the register interface clock disabled.

As the function returned void, nxp_fspi_exec_op() had no way to know
about the failure and continued to access FlexSPI registers (LUT setup,
data transfer, AHB buffer invalidation). Accessing the controller
registers while its clock is gated off results in a synchronous external
abort.

Make nxp_fspi_select_mem() return an error code and have
nxp_fspi_exec_op() bail out on failure before any further register
access, including nxp_fspi_invalid().

Signed-off-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Link: https://patch.msgid.link/20260728-fspi-clock-v2-3-dbe786a4a6eb@nxp.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: spi-nxp-fspi: enter stop mode before reconfiguring MCR0 and DLL</title>
<updated>2026-07-30T12:13:49+00:00</updated>
<author>
<name>Haibo Chen</name>
<email>haibo.chen@nxp.com</email>
</author>
<published>2026-07-28T10:18:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b4bde5cfff8e43e948219f0a598e4bf057ecfba4'/>
<id>b4bde5cfff8e43e948219f0a598e4bf057ecfba4</id>
<content type='text'>
In nxp_fspi_select_mem() the RX sample clock source (MCR0[RXCLKSRC])
and the DLL control registers (DLLxCR) are reconfigured while the
FlexSPI module is still enabled. According to the FlexSPI reference
manual initialization sequence, MCR0 and the DLL control registers
should be programmed while the module is in stop mode, i.e. with
MCR0[MDIS] set to 1, and the module re-enabled (MCR0[MDIS] = 0)
afterwards.

Wrap the RX sample clock source selection and the DLL calibration/
override reconfiguration in a stop-mode window to align with the RM
and avoid reconfiguring timing-critical registers while the module is
active.

Signed-off-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Reviewed-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Link: https://patch.msgid.link/20260728-fspi-clock-v2-2-dbe786a4a6eb@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>
In nxp_fspi_select_mem() the RX sample clock source (MCR0[RXCLKSRC])
and the DLL control registers (DLLxCR) are reconfigured while the
FlexSPI module is still enabled. According to the FlexSPI reference
manual initialization sequence, MCR0 and the DLL control registers
should be programmed while the module is in stop mode, i.e. with
MCR0[MDIS] set to 1, and the module re-enabled (MCR0[MDIS] = 0)
afterwards.

Wrap the RX sample clock source selection and the DLL calibration/
override reconfiguration in a stop-mode window to align with the RM
and avoid reconfiguring timing-critical registers while the module is
active.

Signed-off-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Reviewed-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Link: https://patch.msgid.link/20260728-fspi-clock-v2-2-dbe786a4a6eb@nxp.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: spi-nxp-fspi: add per-SoC SDR/DTR clock rate limits for all supported SoCs</title>
<updated>2026-07-30T12:13:48+00:00</updated>
<author>
<name>Haibo Chen</name>
<email>haibo.chen@nxp.com</email>
</author>
<published>2026-07-28T10:18:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9c19d60fea9f46ed0c3394653ef4941f1a459968'/>
<id>9c19d60fea9f46ed0c3394653ef4941f1a459968</id>
<content type='text'>
The commit f43579ef3500 ("spi: spi-nxp-fspi: limit the clock rate for
different sample clock source selection") introduced a global 166MHz
cap for DTR mode (RXCLKSRC=3), based on the i.MX8MN datasheet timing
specification (Section 3.9.9, page 65).

After reviewing the FlexSPI timing parameters in the datasheets for all
supported SoCs, the following corrections and additions are needed:

1. SDR mode (RXCLKSRC=0) limits vary per SoC:
   - i.MX8MN/MM/MP/95: 66MHz  (IMX8MNCEC §3.9.9, IMX8MMCEC §3.9.10,
                                IMX8MPCEC, IMX95CEC Rev.8 §4.11.7)
   - i.MX8QXP/QM/DXL/ULP: 60MHz (IMX8QXPCEC, IMX8QMCEC, IMX8DXLCEC,
                                   IMX8ULPCEC §7.3.1 ND mode)
   - LX2160A: 100MHz            (LX2160ACEC FlexSPI timing parameters)

2. DTR mode (RXCLKSRC=3) limits vary per SoC:
   - i.MX8MN/MM/MP/ULP: 166MHz
   - i.MX8QXP/QM/DXL: 200MHz   (same FlexSPI IP across this family)
   - i.MX95: 200MHz             (IMX95CEC §4.11.7.3.2.3 Table 106)
   - LX2160A: DTR disabled      (FSPI_QUIRK_DISABLE_DTR)

Update related platform data with correct speed limation according
to datasheet.

Fixes: f43579ef3500 ("spi: spi-nxp-fspi: limit the clock rate for different sample clock source selection")
Signed-off-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Link: https://patch.msgid.link/20260728-fspi-clock-v2-1-dbe786a4a6eb@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>
The commit f43579ef3500 ("spi: spi-nxp-fspi: limit the clock rate for
different sample clock source selection") introduced a global 166MHz
cap for DTR mode (RXCLKSRC=3), based on the i.MX8MN datasheet timing
specification (Section 3.9.9, page 65).

After reviewing the FlexSPI timing parameters in the datasheets for all
supported SoCs, the following corrections and additions are needed:

1. SDR mode (RXCLKSRC=0) limits vary per SoC:
   - i.MX8MN/MM/MP/95: 66MHz  (IMX8MNCEC §3.9.9, IMX8MMCEC §3.9.10,
                                IMX8MPCEC, IMX95CEC Rev.8 §4.11.7)
   - i.MX8QXP/QM/DXL/ULP: 60MHz (IMX8QXPCEC, IMX8QMCEC, IMX8DXLCEC,
                                   IMX8ULPCEC §7.3.1 ND mode)
   - LX2160A: 100MHz            (LX2160ACEC FlexSPI timing parameters)

2. DTR mode (RXCLKSRC=3) limits vary per SoC:
   - i.MX8MN/MM/MP/ULP: 166MHz
   - i.MX8QXP/QM/DXL: 200MHz   (same FlexSPI IP across this family)
   - i.MX95: 200MHz             (IMX95CEC §4.11.7.3.2.3 Table 106)
   - LX2160A: DTR disabled      (FSPI_QUIRK_DISABLE_DTR)

Update related platform data with correct speed limation according
to datasheet.

Fixes: f43579ef3500 ("spi: spi-nxp-fspi: limit the clock rate for different sample clock source selection")
Signed-off-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Link: https://patch.msgid.link/20260728-fspi-clock-v2-1-dbe786a4a6eb@nxp.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: spi-qpic-snand: write the feature value before executing SET_FEATURE</title>
<updated>2026-07-28T17:09:43+00:00</updated>
<author>
<name>Stanislaw Pal</name>
<email>kuncy7@gmail.com</email>
</author>
<published>2026-07-27T16:32:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8fd62901d6bf03f274a49dd0060793cc07dd51b0'/>
<id>8fd62901d6bf03f274a49dd0060793cc07dd51b0</id>
<content type='text'>
qcom_spi_send_cmdaddr() programs NAND_FLASH_CMD/NAND_EXEC_CMD and submits
the descriptors, which makes the controller execute the command
immediately. For SPINAND_SET_FEATURE the value to be written is only
placed into NAND_FLASH_FEATURES afterwards, by qcom_spi_io_op(), in a
second submission - so the chip is programmed with whatever that register
happened to hold from a previous operation, and the intended value is only
applied by the *next* SET_FEATURE.

Measured on a TP-Link Archer AX55 v1 (IPQ5018, ESMT F50L1G41LB): writing
0x40 to the configuration register (0xb0) leaves the chip at 0x00, and the
subsequent write of 0x00 leaves it at 0x40 - every write lands one
operation late.

This stayed unnoticed until v6.18 added SPI-NAND OTP support together
with OTP entries for ESMT chips. spinand_otp_rw() enables OTP mode,
reads, and disables it again, and mtd_otp_nvmem_add() does this during
MTD registration. With the off-by-one, the "disable" write actually
applies the previously requested value, so CFG_OTP_ENABLE ends up set:
the chip stays in OTP mode, every subsequent array read returns the OTP
area instead of the array (UBI reports an empty device) and all writes
fail with -EIO because the OTP area is write protected. On this board
that makes the whole flash unusable and the device unbootable.

Write the feature value into NAND_FLASH_FEATURES as part of the same
transaction, before NAND_EXEC_CMD. While at it, copy only the bytes the
operation actually carries - the previous code dereferenced a 4-byte
pointer on a one-byte buffer (spinand-&gt;scratchbuf).

With this patch the flash contents read back bit-identical to a
known-good dump of the same board taken under the vendor firmware
(md5-verified across partitions), and writes work.

Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface")
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Pal &lt;kuncy7@gmail.com&gt;
Reviewed-by: Md Sadre Alam &lt;md.alam@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260727163216.109938-1-kuncy7@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
qcom_spi_send_cmdaddr() programs NAND_FLASH_CMD/NAND_EXEC_CMD and submits
the descriptors, which makes the controller execute the command
immediately. For SPINAND_SET_FEATURE the value to be written is only
placed into NAND_FLASH_FEATURES afterwards, by qcom_spi_io_op(), in a
second submission - so the chip is programmed with whatever that register
happened to hold from a previous operation, and the intended value is only
applied by the *next* SET_FEATURE.

Measured on a TP-Link Archer AX55 v1 (IPQ5018, ESMT F50L1G41LB): writing
0x40 to the configuration register (0xb0) leaves the chip at 0x00, and the
subsequent write of 0x00 leaves it at 0x40 - every write lands one
operation late.

This stayed unnoticed until v6.18 added SPI-NAND OTP support together
with OTP entries for ESMT chips. spinand_otp_rw() enables OTP mode,
reads, and disables it again, and mtd_otp_nvmem_add() does this during
MTD registration. With the off-by-one, the "disable" write actually
applies the previously requested value, so CFG_OTP_ENABLE ends up set:
the chip stays in OTP mode, every subsequent array read returns the OTP
area instead of the array (UBI reports an empty device) and all writes
fail with -EIO because the OTP area is write protected. On this board
that makes the whole flash unusable and the device unbootable.

Write the feature value into NAND_FLASH_FEATURES as part of the same
transaction, before NAND_EXEC_CMD. While at it, copy only the bytes the
operation actually carries - the previous code dereferenced a 4-byte
pointer on a one-byte buffer (spinand-&gt;scratchbuf).

With this patch the flash contents read back bit-identical to a
known-good dump of the same board taken under the vendor firmware
(md5-verified across partitions), and writes work.

Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface")
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Pal &lt;kuncy7@gmail.com&gt;
Reviewed-by: Md Sadre Alam &lt;md.alam@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260727163216.109938-1-kuncy7@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: spi-cadence: Move TX FIFO full busy-wait into FIFO</title>
<updated>2026-07-27T17:51:47+00:00</updated>
<author>
<name>Srikanth Boyapally</name>
<email>srikanth.boyapally@amd.com</email>
</author>
<published>2026-07-20T12:55:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d9eadfce2fac49445db40808fe4d8259f20a9d2b'/>
<id>d9eadfce2fac49445db40808fe4d8259f20a9d2b</id>
<content type='text'>
SPI host transfers could intermittently stall with spi_transfer timeouts.
The TXFULL condition was checked only once in cdns_transfer_one() before
cdns_spi_process_fifo(), so if the FIFO became full again during refill,
writes could be dropped and the transfer would never complete.

Move the TXFULL busy-wait into the TX path of cdns_spi_process_fifo() so
the 10µs back-off is applied per FIFO entry during filling, ensuring
forward progress and eliminating spurious timeouts.

Restrict the delay to host mode using spi_controller_is_target(), the
controller is passed into cdns_spi_process_fifo() so the check is made at
the point of use. In target mode this delay must not run as it causes the
target to miss its transfer window and corrupt data.

Fixes: 49530e641178 ("spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo()")
Signed-off-by: Srikanth Boyapally &lt;srikanth.boyapally@amd.com&gt;
Reviewed-by: Radhey Shyam Pandey &lt;radhey.shyam.pandey@amd.com&gt;
Link: https://patch.msgid.link/20260720125510.60166-1-srikanth.boyapally@amd.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SPI host transfers could intermittently stall with spi_transfer timeouts.
The TXFULL condition was checked only once in cdns_transfer_one() before
cdns_spi_process_fifo(), so if the FIFO became full again during refill,
writes could be dropped and the transfer would never complete.

Move the TXFULL busy-wait into the TX path of cdns_spi_process_fifo() so
the 10µs back-off is applied per FIFO entry during filling, ensuring
forward progress and eliminating spurious timeouts.

Restrict the delay to host mode using spi_controller_is_target(), the
controller is passed into cdns_spi_process_fifo() so the check is made at
the point of use. In target mode this delay must not run as it causes the
target to miss its transfer window and corrupt data.

Fixes: 49530e641178 ("spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo()")
Signed-off-by: Srikanth Boyapally &lt;srikanth.boyapally@amd.com&gt;
Reviewed-by: Radhey Shyam Pandey &lt;radhey.shyam.pandey@amd.com&gt;
Link: https://patch.msgid.link/20260720125510.60166-1-srikanth.boyapally@amd.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: qcom-qspi: Correct max DMA length to avoid 64K boundary failure</title>
<updated>2026-07-23T18:03:04+00:00</updated>
<author>
<name>Vijaya Krishna Nivarthi</name>
<email>vijaya.nivarthi@oss.qualcomm.com</email>
</author>
<published>2026-07-22T09:23:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=90ef2f2961c2dc55957dafe2f53b3efdb4675efc'/>
<id>90ef2f2961c2dc55957dafe2f53b3efdb4675efc</id>
<content type='text'>
The maximum size for a DMA data descriptor is 64KB-1 because the size
field in HW is 16 bits wide. For this reason, transfers fail at 64KB
and beyond.

Lower max_dma_len to 60KB so larger transfers are split into multiple
DMA blocks and do not hit the failing 64KB boundary. 60KB is chosen as
a safe round number below the 64KB-1 hardware limit while satisfying
alignment requirements.

Tested on x1e80100 (Hamoa) with SPI-NOR flash (/dev/mtd0):

Without patch:
  dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=32768 count=2  # works
  dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=65536 count=1  # fails

With patch:
  dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=65536 count=1  # works

Fixes: b5762d95607e ("spi: spi-qcom-qspi: Add DMA mode support")
Cc: stable@vger.kernel.org
Signed-off-by: Vijaya Krishna Nivarthi &lt;vijaya.nivarthi@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260722092358.459943-1-vnivarth@qti.qualcomm.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The maximum size for a DMA data descriptor is 64KB-1 because the size
field in HW is 16 bits wide. For this reason, transfers fail at 64KB
and beyond.

Lower max_dma_len to 60KB so larger transfers are split into multiple
DMA blocks and do not hit the failing 64KB boundary. 60KB is chosen as
a safe round number below the 64KB-1 hardware limit while satisfying
alignment requirements.

Tested on x1e80100 (Hamoa) with SPI-NOR flash (/dev/mtd0):

Without patch:
  dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=32768 count=2  # works
  dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=65536 count=1  # fails

With patch:
  dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=65536 count=1  # works

Fixes: b5762d95607e ("spi: spi-qcom-qspi: Add DMA mode support")
Cc: stable@vger.kernel.org
Signed-off-by: Vijaya Krishna Nivarthi &lt;vijaya.nivarthi@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260722092358.459943-1-vnivarth@qti.qualcomm.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: spacemit: prepare both DMA descriptors before submitting</title>
<updated>2026-07-22T21:05:55+00:00</updated>
<author>
<name>Surendra Singh Chouhan</name>
<email>kr494167@gmail.com</email>
</author>
<published>2026-07-22T16:24:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d3c87e71539cb183ea6173a99dc0e6f84fa0bc4f'/>
<id>d3c87e71539cb183ea6173a99dc0e6f84fa0bc4f</id>
<content type='text'>
k1_spi_dma_one() currently submits the TX DMA descriptor to the DMA engine
before preparing the RX DMA descriptor. If preparing the RX descriptor
subsequently fails, the function jumps to the fallback error path without
canceling or aborting the already submitted TX DMA descriptor.

Fix this by preparing both the TX and RX descriptors before submitting
either of them to the DMA engine.

Fixes: efcd8b9d1111 ("spi: spacemit: introduce SpacemiT K1 SPI controller driver")
Reviewed-by: Alex Elder &lt;elder@riscstar.com&gt;
Signed-off-by: Surendra Singh Chouhan &lt;kr494167@gmail.com&gt;
Link: https://patch.msgid.link/20260722162444.11415-1-kr494167@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
k1_spi_dma_one() currently submits the TX DMA descriptor to the DMA engine
before preparing the RX DMA descriptor. If preparing the RX descriptor
subsequently fails, the function jumps to the fallback error path without
canceling or aborting the already submitted TX DMA descriptor.

Fix this by preparing both the TX and RX descriptors before submitting
either of them to the DMA engine.

Fixes: efcd8b9d1111 ("spi: spacemit: introduce SpacemiT K1 SPI controller driver")
Reviewed-by: Alex Elder &lt;elder@riscstar.com&gt;
Signed-off-by: Surendra Singh Chouhan &lt;kr494167@gmail.com&gt;
Link: https://patch.msgid.link/20260722162444.11415-1-kr494167@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
