linux-toradex.git/include/linux/spi, branch master

spi: spi-mem: Fix spi_controller_mem_ops kdoc

2026-06-12T13:10:22+00:00

The secondary_op_tmpl kdoc line has been removed accidentally, add it
back.

Reported-by: Michael Walle 
Closes: https://lore.kernel.org/linux-mtd/DJ56CDMRVFQ6.FOZRIQTF3VDW@kernel.org/T/#u
Fixes: 38fbe4b3f66e ("spi: spi-mem: Add a no_cs_assertion capability")
Signed-off-by: Miquel Raynal 
Link: https://patch.msgid.link/20260612-perso-fix-no-cs-assertion-kdoc-v1-1-626b2d6d0d9b@bootlin.com
Signed-off-by: Mark Brown

spi: spi-mem: Add a no_cs_assertion capability

2026-06-12T13:00:51+00:00

Merge tag 'mtd/spi-mem-cont-read-for-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux into spi-7.2

Miquel Raynal  says:

Aside from preparation changes in the SPI NAND core, the changes carried
here focus on the shared spi-mem layer which is enhanced in order to
bring two new features:

- The possibility to fill a primary and a secondary operation template
  in the direct mapping structure in order to support continuous reads
  in SPI NAND, which may require two different read operations.

- SPI controllers may indicate possible CS instabilities over long
  transfers by setting a boolean. This capability is related to the
  previous one, the need for it has arised while testing SPI NAND
  continuous reads with the Cadence QSPI controller which cannot, under
  certain conditions, keep the CS asserted for the length of
  an eraseblock-large transfer.

spi: fix controller registration API inconsistency

2026-05-21T11:25:55+00:00

The SPI controller API is asymmetric in that a controller is allocated
and registered in two step, while it is freed as part of deregistration.
[1]

This is especially unfortunate as any driver data is freed along with
the controller, something which has lead to use-after-free bugs during
deregistration when drivers tear down resources after deregistering the
controller (or tear down resources that may still be in use before
deregistering the controller in an attempt to work around the API).

To reduce the risk of such bugs being introduced a device managed
allocation interface was added, but this arguably made things even less
consistent as now whether the controller gets freed as part of
deregistration depends on how it was allocated. [2][3]

With most drivers converted to use managed allocation in preparation for
fixing the API, the remaining 16 drivers can be converted in one
tree-wide change. Ten of those drivers use the bitbang interface and can
be converted by simply removing the extra reference already taken by
spi_bitbang_start() (and updating the two bitbang drivers that use
managed allocation). [4]

Fix the API inconsistency by no longer dropping a reference when
deregistering non-devres allocated controllers.

[1] 68b892f1fdc4 ("spi: document odd controller reference handling")
[2] 5e844cc37a5c ("spi: Introduce device-managed SPI controller allocation")
[3] 3f174274d224 ("spi: fix misleading controller deregistration kernel-doc")
[4] 702a4879ec33 ("spi: bitbang: Let spi_bitbang_start() take a reference to master")

Signed-off-by: Johan Hovold 
Link: https://patch.msgid.link/20260521073816.766596-1-johan@kernel.org
Signed-off-by: Mark Brown

spi: spi-mem: Add a no_cs_assertion capability

2026-05-04T13:07:37+00:00

Some controllers are 'smart', and that's a problem.

For instance, the Cadence quadspi controller is capable of deasserting
the CS automatically whenever a too long period of time without any data
to transfer elapses.

This 'feature' combined with a loaded interconnect with arbitration, a
"long" transfer may be split into smaller DMA transfers. In this case
the controller may allow itself to deassert the CS between chunks.

Deasserting the CS stops any ongoing continuous read. Reasserting it
later to continue the reading will only result in the host getting
garbage.

In this case, the host controller driver has no control over the CS
state, so we cannot reliably enable continuous reads. Flag this
limitation through a spi-mem controller capability.

The inversion in the flag name (starting with 'no_') is voluntary, in
order to avoid the need to set this flag in all controller drivers. Only
the broken controllers shall set this bit, the default being that the
controller masters its CS fully.

Reviewed-by: Mark Brown 
Signed-off-by: Miquel Raynal

spi: spi-mem: Create a secondary read operation

2026-05-04T13:02:07+00:00

In some situations, direct mappings may need to use different
operation templates.

For instance, when enabling continuous reads, Winbond SPI NANDs no
longer expect address cycles because they would be ignoring them
otherwise. Hence, right after the command opcode, they start counting
dummy cycles, followed by the data cycles as usual.

This breaks the assumptions of "reads from cache" always being done
identically once the best variant has been picked up, across the
lifetime of the system.

In order to support this feature, we must give direct mapping more than
a single operation template to use, in order to switch to using
secondary operations upon request by the upper layer.

Create the concept of optional secondary operation template, which may
or may not be fulfilled by the SPI NAND and SPI NOR cores. If the
underlying SPI controller does not leverage any kind of direct mapping
acceleration, the feature has no impact and can be freely
used. Otherwise, the controller driver needs to opt-in for using this
feature, if supported.

The condition checked to know whether a secondary operation has been
provided or not is to look for a non zero opcode to limit the creation
of extra variables. In practice, the opcode 0x00 exist, but is not
related to any cache related operation.

Acked-by: Mark Brown 
Signed-off-by: Miquel Raynal

spi: spi-mem: Transform the read operation template

2026-05-04T13:02:07+00:00

As of now, we only use a single operation template when creating SPI
memory direct mappings. With the idea to extend this possibility to 2,
rename the template to reflect that we are currently setting the
"primary" operation, and create a pointer in the same structure to point
to it.

From a user point of view, the op_tmpl name remains but becomes a
pointer, leading to minor changes in both the SPI NAND and SPI NOR
cores.

There is no functional change.

Acked-by: Mark Brown 
Signed-off-by: Miquel Raynal

spi: fix resource leaks on device setup failure

2026-04-22T14:10:22+00:00

Johan Hovold  says:

Make sure to call controller cleanup() if spi_setup() fails while
registering a device to avoid leaking any resources allocated by
setup().

spi: fix controller cleanup() documentation

2026-04-22T14:10:18+00:00

The controller cleanup() callback is no longer called when releasing a
device, but rather when deregistering it (and on registration failures).

Fixes: c7299fea6769 ("spi: Fix spi device unregister flow")
Cc: Saravana Kannan 
Signed-off-by: Johan Hovold 
Link: https://patch.msgid.link/20260410154907.129248-3-johan@kernel.org
Signed-off-by: Mark Brown

spi: Fix the error description in the `ptp_sts_word_post` comment

2026-04-21T15:02:45+00:00

Based on the comment information, the description within the
`ptp_sts_word_post` section should be changed to "See @ptp_sts_word_pre".

Signed-off-by: Dewei Meng 
Link: https://patch.msgid.link/20260421025808.6572-1-mengdewei@cqsoftware.com.cn
Signed-off-by: Mark Brown

spi: spi-mem: Add a packed command operation

2026-04-11T10:53:54+00:00

Instead of repeating the command opcode twice, some flash devices try to
pack command and address bits. In this case, the second opcode byte
being sent (LSB) is free to be used. The input data must be ANDed to
only provide the relevant bits.

Signed-off-by: Miquel Raynal 
Link: https://patch.msgid.link/20260410-winbond-6-19-rc1-oddr-v1-2-2ac4827a3868@bootlin.com
Signed-off-by: Mark Brown