<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/spi, branch linux-6.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.12.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.12.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2026-03-04T12:21:29Z</updated>
<entry>
<title>spi: spidev: fix lock inversion between spi_lock and buf_lock</title>
<updated>2026-03-04T12:21:29Z</updated>
<author>
<name>Fabian Godehardt</name>
<email>fg@emlix.com</email>
</author>
<published>2026-02-11T07:26:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f8431b8672231d378b03176fe74c95adfd3522cf'/>
<id>urn:sha1:f8431b8672231d378b03176fe74c95adfd3522cf</id>
<content type='text'>
[ Upstream commit 40534d19ed2afb880ecf202dab26a8e7a5808d16 ]

The spidev driver previously used two mutexes, spi_lock and buf_lock,
but acquired them in different orders depending on the code path:

  write()/read(): buf_lock -&gt; spi_lock
  ioctl():       spi_lock -&gt; buf_lock

This AB-BA locking pattern triggers lockdep warnings and can
cause real deadlocks:

  WARNING: possible circular locking dependency detected
  spidev_ioctl() -&gt; mutex_lock(&amp;spidev-&gt;buf_lock)
  spidev_sync_write() -&gt; mutex_lock(&amp;spidev-&gt;spi_lock)
  *** DEADLOCK ***

The issue is reproducible with a simple userspace program that
performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from
separate threads on the same spidev file descriptor.

Fix this by simplifying the locking model and removing the lock
inversion entirely. spidev_sync() no longer performs any locking,
and all callers serialize access using spi_lock.

buf_lock is removed since its functionality is fully covered by
spi_lock, eliminating the possibility of lock ordering issues.

This removes the lock inversion and prevents deadlocks without
changing userspace ABI or behaviour.

Signed-off-by: Fabian Godehardt &lt;fg@emlix.com&gt;
Link: https://patch.msgid.link/20260211072616.489522-1-fg@emlix.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: Fix abort sequence execution for serial engine errors</title>
<updated>2026-03-04T12:21:09Z</updated>
<author>
<name>Praveen Talari</name>
<email>praveen.talari@oss.qualcomm.com</email>
</author>
<published>2026-02-04T16:28:52Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=21207c003700f226bbe38fb9fe5dd5d640e51f31'/>
<id>urn:sha1:21207c003700f226bbe38fb9fe5dd5d640e51f31</id>
<content type='text'>
[ Upstream commit 96e041647bb0f9d92f95df1d69cb7442d7408b79 ]

The driver currently skips the abort sequence for target mode when serial
engine errors occur. This leads to improper error recovery as the serial
engine may remain in an undefined state without proper cleanup, potentially
causing subsequent operations to fail or behave unpredictably.

Fix this by ensuring the abort sequence and DMA reset always execute during
error recovery, as both are required for proper serial engine error
handling.

Co-developed-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Signed-off-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Signed-off-by: Praveen Talari &lt;praveen.talari@oss.qualcomm.com&gt;
Reviewed-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260204162854.1206323-3-praveen.talari@oss.qualcomm.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: spi-mem: Protect dirmap_create() with spi_mem_access_start/end</title>
<updated>2026-03-04T12:21:08Z</updated>
<author>
<name>Chin-Ting Kuo</name>
<email>chin-ting_kuo@aspeedtech.com</email>
</author>
<published>2026-01-20T12:30:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f1c5fcf80d771bd5635227fb58ebac85e0571265'/>
<id>urn:sha1:f1c5fcf80d771bd5635227fb58ebac85e0571265</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: spi-mem: Limit octal DTR constraints to octal DTR situations</title>
<updated>2026-03-04T12:21:03Z</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2026-01-09T17:18:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=aaced618189a5cf27f05b9449d64ccaeb1580f4d'/>
<id>urn:sha1:aaced618189a5cf27f05b9449d64ccaeb1580f4d</id>
<content type='text'>
[ Upstream commit 8618271887ca10ac5108fe7e1d82ba8f1b152cf9 ]

In this helper, any operation with a single DTR cycle (like 1S-1S-8D) is
considered requiring a duplicated command opcode. This is wrong as this
constraint only applies to octal DTR operations (8D-8D-8D).

Narrow the application of this constraint to the concerned bus
interface.

Note: none of the possible XD-XD-XD pattern, with X being one of {1, 2,
4} would benefit from this check either as there is only in octal DTR
mode that a single clock edge would be enough to transmit the full
opcode.

Make sure the constraint of expecting two bytes for the command is
applied to the relevant bus interface.

Reviewed-by: Tudor Ambarus &lt;tudor.ambarus@linaro.org&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://patch.msgid.link/20260109-winbond-v6-17-rc1-oddr-v2-3-1fff6a2ddb80@bootlin.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:21:00Z</updated>
<author>
<name>Deepak Kumar</name>
<email>deepak.kumar01@st.com</email>
</author>
<published>2025-12-18T10:48:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=86ba653114bafd6acc28ca35e6d03b1696b423ed'/>
<id>urn:sha1:86ba653114bafd6acc28ca35e6d03b1696b423ed</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: use xfer-&gt;bits_per_word for can_dma()</title>
<updated>2026-03-04T12:21:00Z</updated>
<author>
<name>Jonathan Marek</name>
<email>jonathan@marek.ca</email>
</author>
<published>2025-11-20T21:12:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=46e108c702278ef7490c2dde38c3b41e549a0bb3'/>
<id>urn:sha1:46e108c702278ef7490c2dde38c3b41e549a0bb3</id>
<content type='text'>
[ Upstream commit fb2bbe3838728f572485706677590e4fc41eec5c ]

mas-&gt;cur_bits_per_word may not reflect the value of xfer-&gt;bits_per_word
when can_dma() is called. Use the right value instead.

Signed-off-by: Jonathan Marek &lt;jonathan@marek.ca&gt;
Link: https://patch.msgid.link/20251120211204.24078-3-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-geni-qcom: initialize mode related registers to 0</title>
<updated>2026-03-04T12:20:59Z</updated>
<author>
<name>Jonathan Marek</name>
<email>jonathan@marek.ca</email>
</author>
<published>2025-11-20T21:12:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e15d7f3597debca23f015829af4f6a72bf5ec67d'/>
<id>urn:sha1:e15d7f3597debca23f015829af4f6a72bf5ec67d</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: wpcm-fiu: Fix potential NULL pointer dereference in wpcm_fiu_probe()</title>
<updated>2026-03-04T12:20:43Z</updated>
<author>
<name>Felix Gu</name>
<email>ustc.gu@gmail.com</email>
</author>
<published>2026-02-12T12:41:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2c538a0b3472e99c892c26f4940da38b7d87f632'/>
<id>urn:sha1:2c538a0b3472e99c892c26f4940da38b7d87f632</id>
<content type='text'>
[ Upstream commit 888a0a802c467bbe34a42167bdf9d7331333440a ]

platform_get_resource_byname() can return NULL, which would cause a crash
when passed the pointer to resource_size().

Move the fiu-&gt;memory_size assignment after the error check for
devm_ioremap_resource() to prevent the potential NULL pointer dereference.

Fixes: 9838c182471e ("spi: wpcm-fiu: Add direct map support")
Signed-off-by: Felix Gu &lt;ustc.gu@gmail.com&gt;
Reviewed-by: J. Neuschäfer &lt;j.ne@posteo.net&gt;
Link: https://patch.msgid.link/20260212-wpcm-v1-1-5b7c4f526aac@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: tegra114: Preserve SPI mode bits in def_command1_reg</title>
<updated>2026-02-11T12:40:29Z</updated>
<author>
<name>Vishwaroop A</name>
<email>va@nvidia.com</email>
</author>
<published>2026-02-04T14:12:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6d6b23aada49c4cd44d61d83c073e507c2acb8fc'/>
<id>urn:sha1:6d6b23aada49c4cd44d61d83c073e507c2acb8fc</id>
<content type='text'>
[ Upstream commit a0a75b40c919b9f6d3a0b6c978e6ccf344c1be5a ]

The COMMAND1 register bits [29:28] set the SPI mode, which controls
the clock idle level. When a transfer ends, tegra_spi_transfer_end()
writes def_command1_reg back to restore the default state, but this
register value currently lacks the mode bits. This results in the
clock always being configured as idle low, breaking devices that
need it high.

Fix this by storing the mode bits in def_command1_reg during setup,
to prevent this field from always being cleared.

Fixes: f333a331adfa ("spi/tegra114: add spi driver")
Signed-off-by: Vishwaroop A &lt;va@nvidia.com&gt;
Link: https://patch.msgid.link/20260204141212.1540382-1-va@nvidia.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: tegra: Fix a memory leak in tegra_slink_probe()</title>
<updated>2026-02-11T12:40:28Z</updated>
<author>
<name>Felix Gu</name>
<email>ustc.gu@gmail.com</email>
</author>
<published>2026-02-02T15:15:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=075415ae18b5b3e4d0187962d538653154216fe7'/>
<id>urn:sha1:075415ae18b5b3e4d0187962d538653154216fe7</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>
</feed>
