| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"The bulk of the changes in this release are driver work, as well as
new device support we have some important work on performance over
several drivers, and big overhauls for maintainability on a couple
too. Highlights include:
- Big cleanups of the sh-msiof driver from Geert Uytterhoeven, and of
the NXP FSPI driver from Haibo Chen
- Performance improvements for the AXI SPI engine
- Support for writes to memory mapped flashes on Renesas devices
- Integrated DMA support for Tegra210 QSPI, used by the Tegra234
- DMA support for Amlogic SPI controllers
- Support for AMD HID2, Qualcomm IPQ5018, Renesas RZ/G3E, Rockchip
RK3528 and Samsung Exynos Autov920
An update to fix some issues with the Atmel QSPI driver runtime PM
pulled in a new API from the PM core, and the Renesas memory mapped
write changes pull in some code that's shared in drivers/memory"
* tag 'spi-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (90 commits)
spi: spi-qpic-snand: return early on error from qcom_spi_io_op()
spi: loopback-test: fix up const pointer issue in rx_ranges_cmp()
spi: gpio: fix const issue in spi_to_spi_gpio()
spi: spi-qpic-snand: remove superfluous parameters of qcom_spi_check_error()
dt-bindings: spi: samsung: add exynosautov920-spi compatible
spi: spi-qpic-snand: reuse qcom_spi_check_raw_flash_errors()
spi: dt-bindings: Add rk3528-spi compatible
spi: spi_amd: Update Kconfig dependencies
spi: spi_amd: Add HIDDMA basic write support
spi: spi_amd: Remove read{q,b} usage on DMA buffer
spi: sh-msiof: Move register definitions to <linux/spi/sh_msiof.h>
spi: sh-msiof: Document frame start sync pulse mode
spi: sh-msiof: Double maximum DMA transfer size using two groups
spi: sh-msiof: Simplify BRG's Division Ratio
spi: sh-msiof: Increase TX FIFO size for R-Car V4H/V4M
spi: sh-msiof: Correct RX FIFO size for R-Car Gen3
spi: sh-msiof: Correct RX FIFO size for R-Car Gen2
spi: sh-msiof: Add core support for dual-group transfers
spi: sh-msiof: Correct SIMDR2_GRPMASK
spi: sh-msiof: SIFCTR bitfield conversion
...
|
|
Some places in the spi core pass in a const pointer to a device and the
default container_of() casts that away, which is not a good idea.
Preserve the proper const attribute by using container_of_const() for
to_spi_device() instead, which is what it was designed for.
Note, this removes the NULL check for a device pointer in the call, but
no one was ever checking for that return value, and a device pointer
should never be NULL overall anyway, so this should be a safe change.
Cc: Mark Brown <broonie@kernel.org>
Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/2025052230-fidgeting-stooge-66f5@gregkh
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Move the MSIOF register and register bit definitions from the MSIOF SPI
driver to the existing header file <linux/spi/sh_msiof.h>, so they can
be shared with the MSIOF I2S driver.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/066d1086973eb309006258484e9fe8138807e565.1747401908.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
Recently in the discussion with David the idea of having
a common helper popped up. The helper converts the given
bits per word to bytes. The result will always be power-of-two
(e.g. for 37 bits it returns 8 bytes) or 0 for 0 input.
More details are in the respective code comment.
This mini-series introduces it and replaces current users
under drivers/spi and we expect more (and possibly some
lurking in other subsystems).
|
|
This helper converts the given bits per word to bytes. The result
will always be power-of-two, e.g.,
=============== =================
Input (in bits) Output (in bytes)
=============== =================
5 1
9 2
21 4
37 8
=============== =================
It will return 0 for the 0 input.
There are a couple of cases in SPI that are using the same approach
and at least one more (in IIO) would benefit of it. Add a helper
for everyone.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250417152529.490582-2-andriy.shevchenko@linux.intel.com
Acked-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Introduce support for protocol drivers to specify whether a transfer
should use single or dual transfer mode. Currently, the SPI controller
cannot determine this information from the user, leading to potential
limitations in transfer capabilities.
Add a new field `dtr_mode` in the `spi_transfer` structure. The `dtr_mode`
field allows protocol drivers to indicate if Double Transfer Rate (DTR)
mode is supported for a given transfer. When `dtr_mode` is set to true,
the SPI controller will use DTR mode; otherwise, it will default to single
transfer mode.
Introduce another field `dtr_caps` to indicate if the QSPI controller is
capable of supporting DTR mode (SDR and DDR). By default, both `dtr_caps`
and `dtr_mode` will be false. These flags manage the QSPI controller's DTR
mode capabilities within the SPI framework.
The QSPI controller driver uses these flags to configure single or double
transfer rates using the controller register.
The existing spi-mem driver helps configure the DTR mode but is limited to
memory devices. There is no support available to set DTR mode for non-memory
devices, e.g., touch or any generic SPI sensor. This change is backward
compatible and doesn't break existing SPI or QSPI drivers.
Changes include:
- Addition of `dtr_mode` and `dtr_caps` fields in the `spi_transfer`
structure.
- Documentation updates to reflect the new `dtr_mode` and `dtr_caps` fields.
Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
Link: https://patch.msgid.link/20250404135427.313825-1-quic_msavaliy@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The CS related fields are sparse in the struct spi_device. Group them.
While at it, fix the comment style of cs_index_mask.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250331103609.4160281-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Replace "master" by "[host] controller" in the SPI core code and comments.
All the similar to the "slave" by "target [device]" changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250313140340.380359-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add offload_flags to the documentation comment for struct spi_transfer.
This was missed when adding the field.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/linux-next/20250212154356.784944ea@canb.auug.org.au/
Fixes: 700a281905f2 ("spi: add offload TX/RX streaming APIs")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250212-spi-offload-fixes-v1-1-e192c69e3bb3@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add #include <linux/bits.h> to linux/spi/offload/types.h since this
file uses the BIT macro.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250210-spi-offload-extra-headers-v1-1-0f3356362254@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Most configuration of SPI offloads is handled opaquely using the offload
pointer that is passed to the various offload functions. However, there
are some offload features that need to be controlled on a per transfer
basis.
This patch adds a flag field to struct spi_transfer to allow specifying
such features. The first feature to be added is the ability to stream
data to/from a hardware sink/source rather than using a tx or rx buffer.
Additional flags can be added in the future as needed.
A flags field is also added to the offload struct for providers to
indicate which flags are supported. This allows for generic checking of
offload capabilities during __spi_validate() so that each offload
provider doesn't have to implement their own validation.
As a first users of this streaming capability, getter functions are
added to get a DMA channel that is directly connected to the offload.
Peripheral drivers will use this to get a DMA channel and configure it
to suit their needs.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250207-dlech-mainline-spi-engine-offload-2-v8-5-e48a489be48c@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Extend SPI offloading to support hardware triggers.
This allows an arbitrary hardware trigger to be used to start a SPI
transfer that was previously set up with spi_optimize_message().
A new struct spi_offload_trigger is introduced that can be used to
configure any type of trigger. It has a type discriminator and a union
to allow it to be extended in the future. Two trigger types are defined
to start with. One is a trigger that indicates that the SPI peripheral
is ready to read or write data. The other is a periodic trigger to
repeat a SPI message at a fixed rate.
There is also a spi_offload_hw_trigger_validate() function that works
similar to clk_round_rate(). It basically asks the question of if we
enabled the hardware trigger what would the actual parameters be. This
can be used to test if the requested trigger type is actually supported
by the hardware and for periodic triggers, it can be used to find the
actual rate that the hardware is capable of.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250207-dlech-mainline-spi-engine-offload-2-v8-2-e48a489be48c@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add the basic infrastructure to support SPI offload providers and
consumers.
SPI offloading is a feature that allows the SPI controller to perform
transfers without any CPU intervention. This is useful, e.g. for
high-speed data acquisition.
SPI controllers with offload support need to implement the get_offload
and put_offload callbacks and can use the devm_spi_offload_alloc() to
allocate offload instances.
SPI peripheral drivers will call devm_spi_offload_get() to get a
reference to the matching offload instance. This offload instance can
then be attached to a SPI message to request offloading that message.
It is expected that SPI controllers with offload support will check for
the offload instance in the SPI message in the ctlr->optimize_message()
callback and handle it accordingly.
CONFIG_SPI_OFFLOAD is intended to be a select-only option. Both
consumer and provider drivers should `select SPI_OFFLOAD` in their
Kconfig to ensure that the SPI core is built with offload support.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250207-dlech-mainline-spi-engine-offload-2-v8-1-e48a489be48c@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In the SPI-NAND layer, we currently make list of operation variants from
the fastest one to the slowest and there is a bit of logic in the core
to go over them and pick the first one that is supported by the
controller, ie. the fastest one among the supported ops.
This kind of logic only works if all operations run at the same
frequency, but as soon as we introduce per operation max frequencies it
is not longer as obvious which operation will be faster, especially
since it also depends on the PCB/controller frequency limitation.
One way to make this choice more clever is to go over all the
variants and for each of them derive an indicator which will help derive
the theoretical best. In this case, we derive a theoretical duration for
the entire operation and we take the smallest one.
Add a helper that parses the spi-mem operation and returns this value.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20250110-winbond-6-11-rc1-quad-support-v3-20-7ab4bd56cf6e@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We do have macros for defining command, address, dummy and data
cycles. We also have a .dtr flag that implies sampling the bus on both
edges, but there are currently no macros enabling it. We might make use
of such macros, so let's create:
- SPI_MEM_DTR_OP_CMD
- SPI_MEM_DTR_OP_ADDR
- SPI_MEM_DTR_OP_DUMMY
- SPI_MEM_DTR_OP_DATA_OUT
- SPI_MEM_DTR_OP_DATA_OUT
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-19-ad218dbc406f@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Follow the order in which all the `struct spi_mem_op` members are
defined.
This is purely aesthetics, there is no functional change.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-18-ad218dbc406f@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
There are spi devices with multiple frequency limitations depending on
the invoked command. We probably do not want to afford running at the
lowest supported frequency all the time, so if we want to get the most
of our hardware, we need to allow per-operation frequency limitations.
Among all the SPI memory controllers, I believe all are capable of
changing the spi frequency on the fly. Some of the drivers do not make
any frequency setup though. And some others will derive a per chip
prescaler value which will be used forever.
Actually changing the frequency on the fly is something new in Linux, so
we need to carefully flag the drivers which do and do not support it. A
controller capability is created for that, and the presence for this
capability will always be checked before accepting such pattern.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-2-ad218dbc406f@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In the spi subsystem, the bus frequency is derived as follows:
- the controller may expose a minimum and maximum operating frequency
- the hardware description, through the spi peripheral properties,
advise what is the maximum acceptable frequency from a device/wiring
point of view.
Transfers must be observed at a frequency which fits both (so in
practice, the lowest maximum).
Actually, this second point mixes two information and already takes the
lowest frequency among:
- what the spi device is capable of (what is written in the component
datasheet)
- what the wiring allows (electromagnetic sensibility, crossovers,
terminations, antenna effect, etc).
This logic works until spi devices are no longer capable of sustaining
their highest frequency regardless of the operation. Spi memories are
typically subject to such variation. Some devices are capable of
spitting their internally stored data (essentially in read mode) at a
very fast rate, typically up to 166MHz on Winbond SPI-NAND chips, using
"fast" commands. However, some of the low-end operations, such as
regular page read-from-cache commands, are more limited and can only be
executed at 54MHz at most. This is currently a problem in the SPI-NAND
subsystem. Another situation, even if not yet supported, will be with
DTR commands, when the data is latched on both edges of the clock. The
same chips as mentioned previously are in this case limited to
80MHz. Yet another example might be continuous reads, which, under
certain circumstances, can also run at most at 104 or 120MHz.
As a matter of fact, the "one frequency per chip" policy is outdated and
more fine grain configuration is needed: we need to allow per-operation
frequency limitations. So far, all datasheets I encountered advertise a
maximum default frequency, which need to be lowered for certain specific
operations. So based on the current infrastructure, we can still expect
firmware (device trees in general) to continued advertising the same
maximum speed which is a mix between the PCB limitations and the chip
maximum capability, and expect per-operation lower frequencies when this
is relevant.
Add a `struct spi_mem_op` member to carry this information. Not
providing this field explicitly from upper layers means that there is no
further constraint and the default spi device maximum speed will be
carried instead. The SPI_MEM_OP() macro is also expanded with an
optional frequency argument, because virtually all operations can be
subject to such a limitation, and this will allow for a smooth and
discrete transition.
For controller drivers which do not implement the spi-mem interface, the
per-transfer speed is also set acordingly to a lower (than the maximum
default) speed when relevant.
Acked-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-1-ad218dbc406f@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull MTD updates from Miquel Raynal:
"MTD device changes:
- switch platform_driver back to remove()
- misc fixes
SPI-NAND changes:
- a load of fixes to Winbond manufacturer driver
- structure constification
Raw NAND changes:
- improve the power management of the GPMI driver
- Davinci driver clean-ups
- fix leak in the Atmel driver
- fix some typos in the core
SPI NOR changes:
- Introduce byte swap support for 8D-8D-8D mode and a user for it:
macronix.
SPI NOR flashes may swap the bytes on a 16-bit boundary when
configured in Octal DTR mode. For such cases the byte order is
propagated through SPI MEM to the SPI controllers so that the
controllers swap the bytes back at runtime. This avoids breaking
the boot sequence because of the endianness problems that appear
when the bootloaders use 1-1-1 and the kernel uses 8D-8D-8D with
byte swap support. Along with the SPI MEM byte swap support we
queue a patch for the SPI MXIC controller that swaps the bytes back
at runtime"
* tag 'mtd/for-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (25 commits)
mtd: spi-nor: core: replace dummy buswidth from addr to data
mtd: spi-nor: winbond: add "w/ and w/o SFDP" comment
mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in RD_ANY_REG_OP
mtd: Switch back to struct platform_driver::remove()
mtd: cfi_cmdset_0002: remove redundant assignment to variable ret
mtd: spinand: Constify struct nand_ecc_engine_ops
MAINTAINERS: add mailing list for GPMI NAND driver
mtd: spinand: winbond: Sort the devices
mtd: spinand: winbond: Ignore the last ID characters
mtd: spinand: winbond: Fix 512GW, 01GW, 01JW and 02JW ECC information
mtd: spinand: winbond: Fix 512GW and 02JW OOB layout
mtd: nand: raw: gpmi: improve power management handling
mtd: nand: raw: gpmi: switch to SYSTEM_SLEEP_PM_OPS
mtd: rawnand: davinci: use generic device property helpers
mtd: rawnand: davinci: break the line correctly
mtd: rawnand: davinci: order headers alphabetically
mtd: rawnand: atmel: Fix possible memory leak
mtd: rawnand: Correct multiple typos in comments
mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE
mtd: spi-nor: add support for Macronix Octal flash
...
|
|
There are NOR flashes (Macronix) that swap the bytes on a 16-bit
boundary when configured in Octal DTR mode. The byte order of
16-bit words is swapped when read or written in Octal Double
Transfer Rate (DTR) mode compared to Single Transfer Rate (STR)
modes. If one writes D0 D1 D2 D3 bytes using 1-1-1 mode, and uses
8D-8D-8D SPI mode for reading, it will read back D1 D0 D3 D2.
Swapping the bytes may introduce some endianness problems. It can
affect the boot sequence if the entire boot sequence is not handled
in either 8D-8D-8D mode or 1-1-1 mode. Therefore, it is necessary
to swap the bytes back to ensure the same byte order as in STR modes.
Fortunately there are controllers that could swap the bytes back at
runtime, addressing the flash's endianness requirements. Provide a
way for the upper layers to specify the byte order in Octal DTR mode.
Merge Tudor's patch and add modifications for suiting newer version
of Linux kernel.
Suggested-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Signed-off-by: AlvinZhou <alvinzhou@mxic.com.tw>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20240926141956.2386374-3-alvinzhou.tw@gmail.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
|
All the {devm_}spi_alloc_master/slave() have been replaced,
so they can be removed and replaced in doc and comment.
No functional changed.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://patch.msgid.link/20240902125947.1368-8-yangyingliang@huaweicloud.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
spi_controller_is_slave() and spi_slave_abort() are all replaced,
so they can be removed.
No functional changed.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://patch.msgid.link/20240910022618.1397-8-yangyingliang@huaweicloud.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:
Provide empty versions of acpi_spi_count_resources(),
acpi_spi_device_alloc() and acpi_spi_find_controller_by_adev()
if the real functions are not being built.
This commit fixes two problems with the original definitions:
1) There wasn't an empty version of these functions
2) The #if only depended on CONFIG_ACPI. But the functions are implemented
in the core spi.c so CONFIG_SPI_MASTER must also be enabled for the real
functions to exist.
|
|
Provide empty versions of acpi_spi_count_resources(),
acpi_spi_device_alloc() and acpi_spi_find_controller_by_adev()
if the real functions are not being built.
This commit fixes two problems with the original definitions:
1) There wasn't an empty version of these functions
2) The #if only depended on CONFIG_ACPI. But the functions are implemented
in the core spi.c so CONFIG_SPI_MASTER must also be enabled for the real
functions to exist.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20240802152215.20831-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Some SPI peripherals may require strict MOSI line state when the controller
is not clocking out data. Implement support for MOSI idle state
configuration (low or high) by setting the data output line level on
controller setup and after transfers. Bitbang operations now call
controller specific set_mosi_idle() callback to set MOSI to its idle state.
The MOSI line is kept at its idle state if no tx buffer is provided.
Acked-by: Nuno Sa <nuno.sa@analog.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Link: https://patch.msgid.link/de61a600b56ed9cb714d5ea87afa88948e70041e.1720810545.git.marcelo.schmitt@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here is the big set of driver core changes for 6.11-rc1.
Lots of stuff in here, with not a huge diffstat, but apis are evolving
which required lots of files to be touched. Highlights of the changes
in here are:
- platform remove callback api final fixups (Uwe took many releases
to get here, finally!)
- Rust bindings for basic firmware apis and initial driver-core
interactions.
It's not all that useful for a "write a whole driver in rust" type
of thing, but the firmware bindings do help out the phy rust
drivers, and the driver core bindings give a solid base on which
others can start their work.
There is still a long way to go here before we have a multitude of
rust drivers being added, but it's a great first step.
- driver core const api changes.
This reached across all bus types, and there are some fix-ups for
some not-common bus types that linux-next and 0-day testing shook
out.
This work is being done to help make the rust bindings more safe,
as well as the C code, moving toward the end-goal of allowing us to
put driver structures into read-only memory. We aren't there yet,
but are getting closer.
- minor devres cleanups and fixes found by code inspection
- arch_topology minor changes
- other minor driver core cleanups
All of these have been in linux-next for a very long time with no
reported problems"
* tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (55 commits)
ARM: sa1100: make match function take a const pointer
sysfs/cpu: Make crash_hotplug attribute world-readable
dio: Have dio_bus_match() callback take a const *
zorro: make match function take a const pointer
driver core: module: make module_[add|remove]_driver take a const *
driver core: make driver_find_device() take a const *
driver core: make driver_[create|remove]_file take a const *
firmware_loader: fix soundness issue in `request_internal`
firmware_loader: annotate doctests as `no_run`
devres: Correct code style for functions that return a pointer type
devres: Initialize an uninitialized struct member
devres: Fix memory leakage caused by driver API devm_free_percpu()
devres: Fix devm_krealloc() wasting memory
driver core: platform: Switch to use kmemdup_array()
driver core: have match() callback in struct bus_type take a const *
MAINTAINERS: add Rust device abstractions to DRIVER CORE
device: rust: improve safety comments
MAINTAINERS: add Danilo as FIRMWARE LOADER maintainer
MAINTAINERS: add Rust FW abstractions to FIRMWARE LOADER
firmware: rust: improve safety comments
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"There's some quite exciting core work in this release, we've got the
beginnings of support for hardware initiated transfers which is itself
independently useful for optimising fast paths in existing drivers.
We also have a rework of the DMA mapping which allows finer grained
decisions about DMA mapping messages and also helps remove some bodges
that we'd had.
Otherwise it's a fairly quiet release, a few new drivers and features
for existing drivers, together with various cleanups and DT binding
conversions.
One regmap SPI fix made it's way in here too which I should probably
have sent as a regmap fix instead.
Summary:
- Support for pre-optimising messages, reducing the overhead for
messages that are repeatedly used (eg, reading the interrupt status
from a device). This will also be used for hardware initiated
transfers in future.
- A reworking of how DMA mapping is done, introducing a new helper
and allowing the DMA mapping decision to be done per transfer
instead of per message.
- Support for Atmel SAMA7D64, Freescale LX2160A DSPI and WCH CH341A"
* tag 'spi-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (72 commits)
spi: dt-bindings: at91: Add sama7d65 compatible string
spi: add ch341a usb2spi driver
spi: dt-bindings: fsl-dspi: add compatible string 'fsl,lx2160a-dspi'
spi: dt-bindings: fsl-dspi: add dmas and dma-names properties
spi: spi: Remove unnecessary ‘0’ values from status
spi: spi: Remove unnecessary ‘0’ values from rc
spi: xcomm: fix coding style
spi: xcomm: remove i2c_set_clientdata()
spi: xcomm: make use of devm_spi_alloc_host()
spi: xcomm: add gpiochip support
spi: dt-bindings: snps,dw-apb-ssi.yaml: update compatible property
spi: dt-bindings: fsl-dspi: Convert to yaml format
spi: fsl-dspi: use common proptery 'spi-cs-setup(hold)-delay-ns'
spi: axi-spi-engine: remove platform_set_drvdata()
spi: spi-fsl-lpspi: Pass pm_ptr()
spi: spi-imx: Pass pm_ptr()
spi: spi-fsl-lpspi: Switch to SYSTEM_SLEEP_PM_OPS()
spi: spi-imx: Switch to RUNTIME_PM_OPS/SYSTEM_SLEEP_PM_OPS()
spi: add EXPORT_SYMBOL_GPL(devm_spi_optimize_message)
spi: add devm_spi_optimize_message() helper
...
|
|
Adding spi_optimize_message() broke the spi-mux driver because it
calls spi_async() from it's transfer_one_message() callback. This
resulted in passing an incorrectly optimized message to the controller.
For example, if the underlying controller has an optimize_message()
callback, this would have not been called and can cause a crash when
the underlying controller driver tries to transfer the message.
Also, since the spi-mux driver swaps out the controller pointer by
replacing msg->spi, __spi_unoptimize_message() was being called with a
different controller than the one used in __spi_optimize_message(). This
could cause a crash when attempting to free the message resources when
__spi_unoptimize_message() is called in spi_finalize_current_message()
since it is being called with a controller that did not allocate the
resources.
This is fixed by adding a defer_optimize_message flag for controllers.
This flag causes all of the spi_[maybe_][un]optimize_message() calls to
be a no-op (other than attaching a pointer to the spi device to the
message).
This allows the spi-mux driver to pass an unmodified message to
spi_async() in spi_mux_transfer_one_message() after the spi device has
been swapped out. This causes __spi_optimize_message() and
__spi_unoptimize_message() to be called only once per message and with
the correct/same controller in each case.
Reported-by: Oleksij Rempel <o.rempel@pengutronix.de>
Closes: https://lore.kernel.org/linux-spi/Zn6HMrYG2b7epUxT@pengutronix.de/
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Closes: https://lore.kernel.org/linux-spi/20240628-awesome-discerning-bear-1621f9-mkl@pengutronix.de/
Fixes: 7b1d87af14d9 ("spi: add spi_optimize_message() APIs")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20240708-spi-mux-fix-v1-2-6c8845193128@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In the match() callback, the struct device_driver * should not be
changed, so change the function callback to be a const *. This is one
step of many towards making the driver core safe to have struct
device_driver in read-only memory.
Because the match() callback is in all busses, all busses are modified
to handle this properly. This does entail switching some container_of()
calls to container_of_const() to properly handle the constant *.
For some busses, like PCI and USB and HV, the const * is cast away in
the match callback as those busses do want to modify those structures at
this point in time (they have a local lock in the driver structure.)
That will have to be changed in the future if they wish to have their
struct device * in read-only-memory.
Cc: Rafael J. Wysocki <rafael@kernel.org>
Reviewed-by: Alex Elder <elder@kernel.org>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Merge series from David Lechner <dlechner@baylibre.com>:
In the IIO subsystem, we are finding that it is common to call
spi_optimize_message() during driver probe since the SPI message
doesn't change for the lifetime of the driver. This patch adds a
devm_spi_optimize_message() helper to simplify this common pattern.
|
|
This adds a new helper function devm_spi_optimize_message() that
automatically registers spi_unoptimize_message() to be called
when the device is removed.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20240621-devm_spi_optimize_message-v1-2-3f9dcba6e95e@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We need the fixes to apply new changes to the Cirrus drivers.
|
|
Add OCTAL mode support.
Issue detected using "--octal" spidev_test's option.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Link: https://msgid.link/r/20240618132951.2743935-4-patrice.chotard@foss.st.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The granularity of DMA mappings is transfer and moreover,
the direction is also important as it can be unidirect.
The current cur_msg_mapped flag doesn't fit well the DMA mapping
and syncing calls and we have tons of checks around on top of it.
So, instead of doing that rework the code to use per transfer per
direction flag to show if it's DMA mapped or not.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
Link: https://lore.kernel.org/r/20240531194723.1761567-9-andriy.shevchenko@linux.intel.com
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Instead of using hard coded number of modes, replace it with
SPI_MODE_X_MASK + 1 to show relation to the SPI modes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240517194104.747328-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
With a typedef for the txrx_*() callbacks the code looks neater.
Note that typedef for a function is okay to have.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240517194104.747328-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
There is no user of the linux/spi/pxa2xx_spi.h. Move its contents
to the drivers/spi/spi-pxa2xx.h.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240417110334.2671228-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
kernel-doc complains about last_cs_index_mask not described, so add its
description.
spi.h:778: warning: Function parameter or struct member 'last_cs_index_mask' not described in 'spi_controller'
Fixes: 4d8ff6b0991d ("spi: Add multi-cs memories support in SPI core")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240328223340.17159-1-rdunlap@infradead.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
Fix kernel documentation and inclusion block, and dropping the size
of the num_chipselect.
|
|
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
A couple of cleanups against linux/spi/pxa2xx_spi.h.
I'm sending this as v3 to land in the SPI subsystem. Meanwhile I'm
preparing an update to make linux/spi/pxa2xx_spi.h private to the
subsystem (PXA2xx driver). But the second part will be presented later
on (likely after v6.9-rc1). That said, this can be routed either via
SoC tree or SPI, up to respective maintainers.
|
|
There are no more users of the deprecated is_dma_mapped in struct
spi_message so it can be removed.
References in documentation and comments are also removed.
A few similar checks if xfer->tx_dma or xfer->rx_dma are not NULL are
also removed since these are now guaranteed to be NULL because they
were previously set only if is_dma_mapped was true.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://msgid.link/r/20240325-spi-remove-is_dma_mapped-v2-1-d08d62b61f1c@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
No in-kernel users of struct rspi_plat_data. If required,
the software nodes should be used for such users. For now
just get rid of it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240325142118.3210915-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
There is no use for whole 16-bit for the number of chip select pins.
Drop it to 8 bits.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240307195056.4059864-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
There is the only one user of the pxa2xx_set_spi_info(). Unexport it
and inline to the actual user.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://msgid.link/r/20240307195056.4059864-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
There is no use for whole 16-bit for the number of chip select pins.
Drop it to 8 bits and reshuffle the data structure layout to avoid
unnecessary paddings.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Link: https://msgid.link/r/20240308162920.46816-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
xilinx_spi.h is mnissing inclusion and forward declaration, add them.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://msgid.link/r/20240308162920.46816-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
While updating the data structure layout the kernel documentation
became outdated. Synchronize kernel documentation with the actual
data structure layout.
Fixes: 1dd46599f83a ("spi: xilinx: add force_irq for QSPI mode")
Fixes: 082339bc63cc ("spi: spi-xilinx: Add run run-time endian detection")
Reviewed-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240308162920.46816-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"This was a relatively calm development cycle. Most of changes are
rather small device-specific fixes and enhancements. The only
significant changes in ALSA core are code refactoring with the recent
cleanup infrastructure, which should bring no functionality changes.
Some highlights below:
Core:
- Lots of cleanups in ALSA core code with automatic kfree cleanup and
locking guard macros
- New ALSA core kunit test
ASoC:
- SoundWire support for AMD ACP 6.3 systems
- Support for reporting version information for AVS firmware
- Support DSPless mode for Intel Soundwire systems
- Support for configuring CS35L56 amplifiers using EFI calibration
data
- Log which component is being operated on as part of power
management trace events.
- Support for Microchip SAM9x7, NXP i.MX95 and Qualcomm WCD939x
HD- and USB-audio:
- More Cirrus HD-audio codec support
- TAS2781 HD-audio codec fixes
- Scarlett2 mixer fixes
Others:
- Enhancement of virtio driver for audio control supports
- Cleanups of legacy PM code with new macros
- Firewire sound updates"
* tag 'sound-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (307 commits)
ALSA: usb-audio: Stop parsing channels bits when all channels are found.
ALSA: hda/tas2781: remove unnecessary runtime_pm calls
ALSA: hda/realtek - ALC236 fix volume mute & mic mute LED on some HP models
ALSA: aaci: Delete unused variable in aaci_do_suspend
ALSA: scarlett2: Fix Scarlett 4th Gen input gain range again
ALSA: scarlett2: Fix Scarlett 4th Gen input gain range
ALSA: scarlett2: Fix Scarlett 4th Gen autogain status values
ALSA: scarlett2: Fix Scarlett 4th Gen 4i4 low-voltage detection
ALSA: hda/tas2781: restore power state after system_resume
ALSA: hda/tas2781: do not call pm_runtime_force_* in system_resume/suspend
ALSA: hda/tas2781: do not reset cur_* values in runtime_suspend
ALSA: hda/tas2781: add lock to system_suspend
ALSA: hda/tas2781: use dev_dbg in system_resume
ALSA: hda/realtek: fix ALC285 issues on HP Envy x360 laptops
platform/x86: serial-multi-instantiate: Add support for CS35L54 and CS35L57
ALSA: hda: cs35l56: Add support for CS35L54 and CS35L57
ASoC: cs35l56: Add support for CS35L54 and CS35L57
ASoC: Intel: catpt: Carefully use PCI bitwise constants
ALSA: hda: hda_component: Include sound/hda_codec.h
ALSA: hda: hda_component: Add missing #include guards
...
|
|
First of all, last_cs_index_mask should be aligned with the original
cs_index_mask, which is 16-bit (for now) wide. Use the same pattern
for the last_cs_index_mask.
Second, last_cs can be negative and since 'char' is equal to 'unsigned
char' in the kernel, it's incorrect, strictly speaking, to assign
signed number to it. Use s8 type as it's done for *_native_cs ones.
With this change, regroup a bit the ordering to avoid too much memory
space to be wasted due to paddings. Shuffle kernel documentation
accordignly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240307150256.3789138-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This adds a new spi_optimize_message() function that can be used to
optimize SPI messages that are used more than once. Peripheral drivers
that use the same message multiple times can use this API to perform SPI
message validation and controller-specific optimizations once and then
reuse the message while avoiding the overhead of revalidating the
message on each spi_(a)sync() call.
Internally, the SPI core will also call this function for each message
if the peripheral driver did not explicitly call it. This is done to so
that controller drivers don't have to have multiple code paths for
optimized and non-optimized messages.
A hook is provided for controller drivers to perform controller-specific
optimizations.
Suggested-by: Martin Sperl <kernel@martin.sperl.org>
Link: https://lore.kernel.org/linux-spi/39DEC004-10A1-47EF-9D77-276188D2580C@martin.sperl.org/
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://msgid.link/r/20240219-mainline-spi-precook-message-v2-1-4a762c6701b9@baylibre.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
