DQS is a typical SPI memory signal used to help with reading the data on the bus at high speeds (especially in DTR mode) by avoiding clock skews. The chip generates a clock signal synchronized with its data output fronts, also called data strobe. SPI NOR and SPI NAND cores must set this flag in order to indicate to other layers that DQS is available. Create a getter and a setter to reach this capability. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20260810-winbond-nand-next-phy-tuning-v3-1-a97c3a61e675@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
Development boards such as the Jetson AGX Orin expose SPI buses
on expansion headers (e.g. the 40-pin header) so that users can
connect and interact with SPI peripherals from userspace. The
standard way to get /dev/spidevB.C character device nodes for
this purpose is to register spi_device instances backed by the
spidev driver.
Today there is no viable way to do this on upstream kernels:
- The spidev driver rejects the bare "spidev" compatible
string in DT, since spidev is a Linux software interface
and not a description of real hardware.
- Vendor-specific compatible strings (e.g. "nvidia,tegra-spidev")
have been rejected by DT maintainers for the same reason.
The I2C subsystem solved an analogous problem by exposing
new_device/delete_device sysfs attributes on each adapter. Add
the same interface to SPI host controllers, so that userspace
(e.g. a systemd unit at boot) can instantiate SPI devices at
runtime without needing anything in device-tree.
The new_device file accepts:
<modalias> <chip_select> [<max_speed_hz> [<mode>]]
where chip_select is required, while max_speed_hz and mode are
optional and default to 0 if omitted. max_speed_hz == 0 is
clamped to the controller's maximum by spi_setup(); mode == 0
selects SPI mode 0 (CPOL=0, CPHA=0).
The modalias is used both as the device identifier and as a
driver_override, so that the device binds to the named driver
directly. This is necessary because some drivers like spidev
deliberately exclude generic names from their id_table.
Devices created this way are limited compared to those declared
via DT or board files:
- No IRQ is assigned (the device gets IRQ 0 / no interrupt).
- No platform_data or device properties are attached.
- No OF node is associated with the device.
These limitations are acceptable for spidev, which only needs a
registered spi_device to expose a character device to userspace.
Only devices created via new_device can be removed through
delete_device; DT and platform devices are unaffected.
The sysfs attributes are gated behind CONFIG_SPI_DYNAMIC since
this feature adds a new way of dynamically instantiating and
removing SPI devices, and the add_lock locking in
spi_unregister_controller() is already conditional on
CONFIG_SPI_DYNAMIC.
The userspace sysfs group is created manually as the last step
of spi_register_controller() and removed as the first step of
spi_unregister_controller(). Removing the group before taking
add_lock means kernfs_drain() completes any in-flight
new_device_store()/delete_device_store() calls before
add_lock is acquired, so unregister never blocks on a store
that is itself waiting for add_lock and no store can be
touching an spi_device that is about to be torn down.
Non-sysfs callers of __spi_add_device() (DT/ACPI dynamic add,
ancillary registration) continue to be protected by the
pre-existing !device_is_registered(&ctlr->dev) check added in
commit ddf75be47ca7 ("spi: Prevent adding devices below an
unregistering controller"): device_del(&ctlr->dev) runs inside
add_lock in spi_unregister_controller() so state_in_sysfs flips
to 0 before add_lock is released.
Link: https://lore.kernel.org/linux-tegra/909f0c92-d110-4253-903e-5c81e21e12c9@nvidia.com/
Signed-off-by: Vishwaroop A <va@nvidia.com>
Link: https://patch.msgid.link/20260803104614.2548375-2-va@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
<linux/mod_devicetable.h> is included in a many files: $ git grep '<linux/mod_devicetable.h>' ef0c9f75a195 | wc -l 1598 ; some of them are widely used headers. To stop mixing up different and unrelated driver( type)s let the subsystem headers only use the subset of the recently split <linux/mod_devicetable.h> that are relevant for them. The fallout (I hope) is addressed in the previous commits that handle sources relying on e.g. <linux/i2c.h> pulling in the full legacy header and thus providing pci_device_id. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://patch.msgid.link/199fe46b624ba07fb9bd3e0cd6ff13757932cb5f.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
The secondary_op_tmpl kdoc line has been removed accidentally, add it
back.
Reported-by: Michael Walle <mwalle@kernel.org>
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 <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260612-perso-fix-no-cs-assertion-kdoc-v1-1-626b2d6d0d9b@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <miquel.raynal@bootlin.com> 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.
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 <johan@kernel.org>
Link: https://patch.msgid.link/20260521073816.766596-1-johan@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <broonie@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
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 <broonie@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
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 <broonie@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Johan Hovold <johan@kernel.org> says: Make sure to call controller cleanup() if spi_setup() fails while registering a device to avoid leaking any resources allocated by setup().