<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/spi, branch v7.2-rc6</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<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>
<entry>
<title>spi: spacemit: Correct TX FIFO slot calculation</title>
<updated>2026-07-19T21:12:52+00:00</updated>
<author>
<name>Zhengyu He</name>
<email>hezhy472013@gmail.com</email>
</author>
<published>2026-07-15T12:52:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a88df1d92fcf23d848e5fa6d7d2a1c38fd0174ed'/>
<id>a88df1d92fcf23d848e5fa6d7d2a1c38fd0174ed</id>
<content type='text'>
In k1_spi_write, the count variable is intended to represent the number
of slots available for writing into the TX FIFO.

The current implementation uses FIELD_GET(SSP_STATUS_TFL, val) in an
attempt to determine this count, but this register field returns the
number of occupied slots, not the available space. The previous
implementation attempted to handle this via a ternary operator (? :
K1_SPI_FIFO_SIZE), which incorrectly assumed that the hardware returned
0 when the FIFO was empty (meaning all slots were available), leading to
incorrect accounting of the buffer space.

Fix this by calculating the free slots: count = K1_SPI_FIFO_SIZE -
FIELD_GET(SSP_STATUS_TFL, val);

The associated comment has been updated to reflect the logic change: The
old comment reflected an incorrect assumption about the hardware
behavior, which was the root cause of the previous buggy logic.

This patch accurately and concisely describes the purpose of the new
calculation.

Signed-off-by: Peixin Xie &lt;peixin.xie@spacemit.com&gt;
Signed-off-by: Zhengyu He &lt;hezhy472013@gmail.com&gt;
Link: https://patch.msgid.link/20260715-k1-spi-tx-fifo-fix-v1-for-next-v1-1-02024223b08a@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>
In k1_spi_write, the count variable is intended to represent the number
of slots available for writing into the TX FIFO.

The current implementation uses FIELD_GET(SSP_STATUS_TFL, val) in an
attempt to determine this count, but this register field returns the
number of occupied slots, not the available space. The previous
implementation attempted to handle this via a ternary operator (? :
K1_SPI_FIFO_SIZE), which incorrectly assumed that the hardware returned
0 when the FIFO was empty (meaning all slots were available), leading to
incorrect accounting of the buffer space.

Fix this by calculating the free slots: count = K1_SPI_FIFO_SIZE -
FIELD_GET(SSP_STATUS_TFL, val);

The associated comment has been updated to reflect the logic change: The
old comment reflected an incorrect assumption about the hardware
behavior, which was the root cause of the previous buggy logic.

This patch accurately and concisely describes the purpose of the new
calculation.

Signed-off-by: Peixin Xie &lt;peixin.xie@spacemit.com&gt;
Signed-off-by: Zhengyu He &lt;hezhy472013@gmail.com&gt;
Link: https://patch.msgid.link/20260715-k1-spi-tx-fifo-fix-v1-for-next-v1-1-02024223b08a@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: cadence-quadspi: Fix indirect write timeout when DMA read mode is enabled</title>
<updated>2026-07-14T11:54:50+00:00</updated>
<author>
<name>Srikanth Boyapally</name>
<email>srikanth.boyapally@amd.com</email>
</author>
<published>2026-07-08T04:51:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e919ca35a6e84b5adf085da9ffa1544c01d4ce1e'/>
<id>e919ca35a6e84b5adf085da9ffa1544c01d4ce1e</id>
<content type='text'>
When use_dma_read is enabled, the IRQ handler unconditionally overwrites
irq_status with the return value of get_dma_status(). For write operations,
DMA status returns 0 since no DMA read is in progress, causing irq_status
to become 0. The subsequent completion signal is never triggered and the
write operation times out with -ETIMEDOUT:

  cadence-qspi f1010000.spi: Indirect write timeout
  spi-nor spi0.1: operation failed with -110

Fix this by separating the DMA completion path from the write interrupt
path. If get_dma_status() indicates DMA read completion, signal completion
and return immediately. Otherwise, preserve the original irq_status so that
write completion interrupts are correctly recognized and signalled.

Fixes: aac733a96636 ("spi: cadence-qspi: Fix style and improve readability")
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/20260708045148.2993313-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>
When use_dma_read is enabled, the IRQ handler unconditionally overwrites
irq_status with the return value of get_dma_status(). For write operations,
DMA status returns 0 since no DMA read is in progress, causing irq_status
to become 0. The subsequent completion signal is never triggered and the
write operation times out with -ETIMEDOUT:

  cadence-qspi f1010000.spi: Indirect write timeout
  spi-nor spi0.1: operation failed with -110

Fix this by separating the DMA completion path from the write interrupt
path. If get_dma_status() indicates DMA read completion, signal completion
and return immediately. Otherwise, preserve the original irq_status so that
write completion interrupts are correctly recognized and signalled.

Fixes: aac733a96636 ("spi: cadence-qspi: Fix style and improve readability")
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/20260708045148.2993313-1-srikanth.boyapally@amd.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
