<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/spi, branch linux-6.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.1.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.1.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2026-03-04T12:20:24Z</updated>
<entry>
<title>spi: spi-mem: Protect dirmap_create() with spi_mem_access_start/end</title>
<updated>2026-03-04T12:20:24Z</updated>
<author>
<name>Chin-Ting Kuo</name>
</author>
<published>2026-01-20T12:30:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=138138329a0a60e2509c8346ca11778808cb7baf'/>
<id>urn:sha1:138138329a0a60e2509c8346ca11778808cb7baf</id>
<content type='text'>
[ Upstream commit 53f826ff5e0e3ecb279862ca7cce1491b94bb017 ]

spi_mem_dirmap_create() may reconfigure controller-wide settings,
which can interfere with concurrent transfers to other devices
sharing the same SPI controller but using different chip selects.

Wrap the -&gt;dirmap_create() callback with spi_mem_access_start() and
spi_mem_access_end() to serialize access and prevent cross-CS
interference during dirmap creation.

This patch has been verified on a setup where a SPI TPM is connected
to CS0 of a SPI controller, while a SPI NOR flash is connected to CS1
of the same controller. Without this patch, spi_mem_dirmap_create()
for the SPI NOR flash interferes with ongoing SPI TPM data transfers,
resulting in failure to create the TPM device. This was tested on an
ASPEED AST2700 EVB.

Signed-off-by: Chin-Ting Kuo &lt;chin-ting_kuo@aspeedtech.com&gt;
Reviewed-by: Paul Menzel &lt;pmenzel@molgen.mpg.de&gt;
Link: https://patch.msgid.link/20260120123005.1392071-2-chin-ting_kuo@aspeedtech.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: stm32: fix Overrun issue at &lt; 8bpw</title>
<updated>2026-03-04T12:20:18Z</updated>
<author>
<name>Deepak Kumar</name>
</author>
<published>2025-12-18T10:48:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4baf0ec2b0f4761b5a3233842fd04de8fdd011f2'/>
<id>urn:sha1:4baf0ec2b0f4761b5a3233842fd04de8fdd011f2</id>
<content type='text'>
[ Upstream commit 1ac3be217c01d5df55ec5052f81e4f1708f46552 ]

When SPI communication is suspended by hardware automatically, it could
happen that few bits of next frame are already clocked out due to
internal synchronization delay.

To achieve a safe suspension, we need to ensure that each word must be
at least 8 SPI clock cycles long. That's why, if bpw is less than 8
bits, we need to use midi to reach 8 SPI clock cycles at least.

This will ensure that each word achieve safe suspension and prevent
overrun condition.

Signed-off-by: Deepak Kumar &lt;deepak.kumar01@st.com&gt;
Signed-off-by: Alain Volmat &lt;alain.volmat@foss.st.com&gt;
Link: https://patch.msgid.link/20251218-stm32-spi-enhancements-v2-2-3b69901ca9fe@foss.st.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi-geni-qcom: initialize mode related registers to 0</title>
<updated>2026-03-04T12:20:18Z</updated>
<author>
<name>Jonathan Marek</name>
</author>
<published>2025-11-20T21:12:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f05efcc54e72f9772750f7e69b1f2e6a532e0c38'/>
<id>urn:sha1:f05efcc54e72f9772750f7e69b1f2e6a532e0c38</id>
<content type='text'>
[ Upstream commit 739062a9f1e9a77a9687c8fd30f8e5dd12ec70be ]

setup_fifo_params assumes these will be zero, it won't write these
registers if the initial mode is zero.

Signed-off-by: Jonathan Marek &lt;jonathan@marek.ca&gt;
Link: https://patch.msgid.link/20251120211204.24078-4-jonathan@marek.ca
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: tegra: Fix a memory leak in tegra_slink_probe()</title>
<updated>2026-02-11T12:37:27Z</updated>
<author>
<name>Felix Gu</name>
</author>
<published>2026-02-02T15:15:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=327b71326cc1834bc031e8f52a470a18dfd9caa6'/>
<id>urn:sha1:327b71326cc1834bc031e8f52a470a18dfd9caa6</id>
<content type='text'>
[ Upstream commit 41d9a6795b95d6ea28439ac1e9ce8c95bbca20fc ]

In tegra_slink_probe(), when platform_get_irq() fails, it directly
returns from the function with an error code, which causes a memory leak.

Replace it with a goto label to ensure proper cleanup.

Fixes: eb9913b511f1 ("spi: tegra: Fix missing IRQ check in tegra_slink_probe()")
Signed-off-by: Felix Gu &lt;ustc.gu@gmail.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://patch.msgid.link/20260202-slink-v1-1-eac50433a6f9@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: tegra210-quad: Protect curr_xfer clearing in tegra_qspi_non_combined_seq_xfer</title>
<updated>2026-02-11T12:37:27Z</updated>
<author>
<name>Breno Leitao</name>
</author>
<published>2026-01-26T17:50:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a655be4a4d411faec0452a6fa23c9a7bf9a686a0'/>
<id>urn:sha1:a655be4a4d411faec0452a6fa23c9a7bf9a686a0</id>
<content type='text'>
[ Upstream commit 6d7723e8161f3c3f14125557e19dd080e9d882be ]

Protect the curr_xfer clearing in tegra_qspi_non_combined_seq_xfer()
with the spinlock to prevent a race with the interrupt handler that
reads this field to check if a transfer is in progress.

Fixes: b4e002d8a7ce ("spi: tegra210-quad: Fix timeout handling")
Signed-off-by: Breno Leitao &lt;leitao@debian.org&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Acked-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Link: https://patch.msgid.link/20260126-tegra_xfer-v2-5-6d2115e4f387@debian.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: tegra210-quad: Protect curr_xfer in tegra_qspi_combined_seq_xfer</title>
<updated>2026-02-11T12:37:26Z</updated>
<author>
<name>Breno Leitao</name>
</author>
<published>2026-01-26T17:50:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=762e2ce71c8f0238e9eaf05d14da803d9a24422f'/>
<id>urn:sha1:762e2ce71c8f0238e9eaf05d14da803d9a24422f</id>
<content type='text'>
[ Upstream commit bf4528ab28e2bf112c3a2cdef44fd13f007781cd ]

The curr_xfer field is read by the IRQ handler without holding the lock
to check if a transfer is in progress. When clearing curr_xfer in the
combined sequence transfer loop, protect it with the spinlock to prevent
a race with the interrupt handler.

Protect the curr_xfer clearing at the exit path of
tegra_qspi_combined_seq_xfer() with the spinlock to prevent a race
with the interrupt handler that reads this field.

Without this protection, the IRQ handler could read a partially updated
curr_xfer value, leading to NULL pointer dereference or use-after-free.

Fixes: b4e002d8a7ce ("spi: tegra210-quad: Fix timeout handling")
Signed-off-by: Breno Leitao &lt;leitao@debian.org&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Acked-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Link: https://patch.msgid.link/20260126-tegra_xfer-v2-4-6d2115e4f387@debian.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: tegra210-quad: Protect curr_xfer assignment in tegra_qspi_setup_transfer_one</title>
<updated>2026-02-11T12:37:26Z</updated>
<author>
<name>Breno Leitao</name>
</author>
<published>2026-01-26T17:50:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=87376a2fa4b9ecbd8983f6feafba6945475b730d'/>
<id>urn:sha1:87376a2fa4b9ecbd8983f6feafba6945475b730d</id>
<content type='text'>
[ Upstream commit f5a4d7f5e32ba163cff893493ec1cbb0fd2fb0d5 ]

When the timeout handler processes a completed transfer and signals
completion, the transfer thread can immediately set up the next transfer
and assign curr_xfer to point to it.

If a delayed ISR from the previous transfer then runs, it checks if
(!tqspi-&gt;curr_xfer) (currently without the lock also -- to be fixed
soon) to detect stale interrupts, but this check passes because
curr_xfer now points to the new transfer. The ISR then incorrectly
processes the new transfer's context.

Protect the curr_xfer assignment with the spinlock to ensure the ISR
either sees NULL (and bails out) or sees the new value only after the
assignment is complete.

Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller")
Signed-off-by: Breno Leitao &lt;leitao@debian.org&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Acked-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Link: https://patch.msgid.link/20260126-tegra_xfer-v2-3-6d2115e4f387@debian.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: tegra210-quad: Move curr_xfer read inside spinlock</title>
<updated>2026-02-11T12:37:26Z</updated>
<author>
<name>Breno Leitao</name>
</author>
<published>2026-01-26T17:50:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=af1dfdcbea7c8d9cec530f6480e15d7512415233'/>
<id>urn:sha1:af1dfdcbea7c8d9cec530f6480e15d7512415233</id>
<content type='text'>
[ Upstream commit ef13ba357656451d6371940d8414e3e271df97e3 ]

Move the assignment of the transfer pointer from curr_xfer inside the
spinlock critical section in both handle_cpu_based_xfer() and
handle_dma_based_xfer().

Previously, curr_xfer was read before acquiring the lock, creating a
window where the timeout path could clear curr_xfer between reading it
and using it. By moving the read inside the lock, the handlers are
guaranteed to see a consistent value that cannot be modified by the
timeout path.

Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller")
Signed-off-by: Breno Leitao &lt;leitao@debian.org&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Acked-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://patch.msgid.link/20260126-tegra_xfer-v2-2-6d2115e4f387@debian.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: tegra210-quad: Return IRQ_HANDLED when timeout already processed transfer</title>
<updated>2026-02-11T12:37:26Z</updated>
<author>
<name>Breno Leitao</name>
</author>
<published>2026-01-26T17:50:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7464978180b750df1723cdb74da4b72db86c0a2f'/>
<id>urn:sha1:7464978180b750df1723cdb74da4b72db86c0a2f</id>
<content type='text'>
[ Upstream commit aabd8ea0aa253d40cf5f20a609fc3d6f61e38299 ]

When the ISR thread wakes up late and finds that the timeout handler
has already processed the transfer (curr_xfer is NULL), return
IRQ_HANDLED instead of IRQ_NONE.

Use a similar approach to tegra_qspi_handle_timeout() by reading
QSPI_TRANS_STATUS and checking the QSPI_RDY bit to determine if the
hardware actually completed the transfer. If QSPI_RDY is set, the
interrupt was legitimate and triggered by real hardware activity.
The fact that the timeout path handled it first doesn't make it
spurious. Returning IRQ_NONE incorrectly suggests the interrupt
wasn't for this device, which can cause issues with shared interrupt
lines and interrupt accounting.

Fixes: b4e002d8a7ce ("spi: tegra210-quad: Fix timeout handling")
Signed-off-by: Breno Leitao &lt;leitao@debian.org&gt;
Signed-off-by: Usama Arif &lt;usamaarif642@gmail.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Acked-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Link: https://patch.msgid.link/20260126-tegra_xfer-v2-1-6d2115e4f387@debian.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: spi-sprd-adi: Fix double free in probe error path</title>
<updated>2026-02-06T15:44:08Z</updated>
<author>
<name>Felix Gu</name>
</author>
<published>2026-01-09T12:49:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bddd3d10d039729b81cfb0804520c8832a701a0e'/>
<id>urn:sha1:bddd3d10d039729b81cfb0804520c8832a701a0e</id>
<content type='text'>
[ Upstream commit 383d4f5cffcc8df930d95b06518a9d25a6d74aac ]

The driver currently uses spi_alloc_host() to allocate the controller
but registers it using devm_spi_register_controller().

If devm_register_restart_handler() fails, the code jumps to the
put_ctlr label and calls spi_controller_put(). However, since the
controller was registered via a devm function, the device core will
automatically call spi_controller_put() again when the probe fails.
This results in a double-free of the spi_controller structure.

Fix this by switching to devm_spi_alloc_host() and removing the
manual spi_controller_put() call.

Fixes: ac17750 ("spi: sprd: Add the support of restarting the system")
Signed-off-by: Felix Gu &lt;gu_0233@qq.com&gt;
Reviewed-by: Baolin Wang &lt;baolin.wang@linux.alibaba.com&gt;
Link: https://patch.msgid.link/tencent_AC7D389CE7E24318445E226F7CDCCC2F0D07@qq.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
