Merge series from Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>:
This patch series adds support to the SPI framework for using multiple
chip selects.
AMD-Xilinx GQSPI controller has two advanced mode that allows the
controller to consider two flashes as one single device.
One of these two mode is the parallel mode in which each byte of data is
stored in both devices, the even bits in the lower flash & the odd bits in
the upper flash. The byte split is automatically handled by the QSPI
controller.
The other mode is the stacked mode in which both the flashes share the
same SPI bus but each of the device contain half of the data. In this mode,
the controller does not follow CS requests but instead internally wires the
two CS levels with the value of the most significant address bit.
For supporting both these modes SPI core need to be updated for providing
multiple CS for a single SPI device.
For adding multi CS support the SPI device need to be aware of all the CS
values. So, the "chip_select" member in the spi_device structure is now an
array that holds all the CS values.
spi_device structure now has a "cs_index_mask" member. This acts as an
index to the chip_select array. If nth bit of spi->cs_index_mask is set
then the driver would assert spi->chip_select[n].
In parallel mode all the chip selects are asserted/de-asserted
simultaneously and each byte of data is stored in both devices, the even
bits in one, the odd bits in the other. The split is automatically handled
by the GQSPI controller. The GQSPI controller supports a maximum of two
flashes connected in parallel mode. A SPI_CONTROLLER_MULTI_CS flag bit is
added in the spi controller flags, through ctlr->flags the spi core
will make sure that the controller is capable of handling multiple chip
selects at once.
For supporting multiple CS via GPIO the cs_gpiod member of the spi_device
structure is now an array that holds the gpio descriptor for each
chipselect.
CS GPIO is not tested on our hardware, but it has been tested by @Stefan
https://lore.kernel.org/all/005001da1efc$619ad5a0$24d080e0$@opensource.cirrus.com/
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Tested-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20231125092137.2948-4-amit.kumar-mahapatra@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from David Lechner <dlechner@baylibre.com>:
We are working towards adding support for the offload feature [1] of the
AXI SPI Engine IP core. Before we can do that, we want to make some
general fixes and improvements to the driver. In order to avoid a giant
series with 35+ patches, we are splitting this up into a few smaller
series.
This is a continuation of the work started in [2] which has been applied
to spi/for-6.8 [3]. This series must be applied on top of that series to
apply cleanly.
Once this series is applied, we will follow up with the 3rd series that
implements the offload support. The offload support will also involve
the IIO subsystem (a new IIO driver will depend on the new SPI offload
feature), so I'm mentioning this now in case we want to do anything
ahead of time to prepare for that (e.g. putting all of these changes on
a separate branch).
[1]: https://wiki.analog.com/resources/fpga/peripherals/spi_engine/offload
[2]: https://lore.kernel.org/linux-spi/20231117-axi-spi-engine-series-1-v1-0-cc59db999b87@baylibre.com/
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/log/?h=for-6.8
The commit 855a40cd8c ("spi: cadence: Add SPI transfer delays") adds a
delay after each transfer into the driver's transfer_one(). However,
the delay is already done in SPI core. So this commit unnecessarily
doubles the delay amount. Revert this commit.
Signed-off-by: Nam Cao <namcao@linutronix.de>
Link: https://lore.kernel.org/r/20231206145233.74982-1-namcao@linutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If there is an issue with the AXI SPI Engine hardware a scheduled
transfer might never be completed and spi_sync() will block forever.
This due to the uninterruptible wait for completion waiting for the
spi_finalize_current_message() that never comes.
Add a watchdog timer that will abort a transfer 5 seconds after it has
been started. This will potentially leave the hardware in a broken state
but it allows software to recover and allow to better diagnose the
underlying issue.
Co-developed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20231204-axi-spi-engine-series-2-v1-9-063672323fce@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that the AXI SPI Engine driver has support for the various CS delays
requested through struct spi_message, we don't need to add a separate
delay to the CS assertion instruction. Otherwise, we end up with longer
than requested delays.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20231204-axi-spi-engine-series-2-v1-8-063672323fce@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This modifies the ADI AXI SPI Engine driver to restore the clkdiv
configuration register at the end of a SPI message. Having the clkdiv in
a known state is needed to be able to add a new command in the future
that only performs a delay without any SPI transfers. Furthermore having
that state be the smallest possible divider will allow these delays to
have the highest possible precision.
Changing the initial value of clk_div from -1 to 1 is now possible
because we know the function will always be called with a known clkdiv
config register state. Making this change will also have the effect of
not emitting a clkdiv configuration register instruction in cases where
the maximum sclk rate is used. Having one less instruction to process
reduces delays on the bus which will be beneficial when we implement
offload support to enable reading data from devices at very high rates.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20231204-axi-spi-engine-series-2-v1-7-063672323fce@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds handling of xfer->cs_change_delay to the AXI SPI Engine
driver.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20231204-axi-spi-engine-series-2-v1-6-063672323fce@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This replaces the xfer parameter of spi_engine_gen_sleep() in the AXI
SPI Engine driver with parameters for the delay in nanoseconds and the
SPI SCLK rate. This will allow this function to be used by callers in
the future that do not have a spi_transfer struct.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20231204-axi-spi-engine-series-2-v1-5-063672323fce@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This fixes the sleep ticks calculation when generating sleep
instructions in the AXI SPI Engine driver. The previous calculation
was ignoring delays less than one microsecond and missed a microsecond
to second conversion factor.
This fixes the first issue by not rounding to microseconds. Now that
xfer->effective_speed_hz is guaranteed to be set correctly, we can use
that to simplify the calculation. This new calculation replaces the old
incorrect math.
Also add unit suffix to the delay variable for clarity while we are
touching this.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20231204-axi-spi-engine-series-2-v1-4-063672323fce@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that host->max_speed_hz and xfer->effective_speed_hz are properly
set, we can use them instead of having to do more complex calculations
to get the clock divider for each transfer.
This removes the spi_engine_get_clk_div() function and replaces it with
just dividing the two clock rates. Since the hardware register value is
the divider minus one, we need to subtract one. Subtracting one was
previously done in the spi_engine_get_clk_div() function.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20231204-axi-spi-engine-series-2-v1-3-063672323fce@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds a new spi_engine_precompile_message() function to the ADI AXI
SPI Engine driver to populate the xfer->effective_speed_hz field since
the SPI core doesn't/can't do this for us.
This driver is already using spi_delay_to_ns() which depends on
effective_speed_hz to get an accurate value in some cases.
Having an effective_speed_hz value can also be used in future changes
to simplify other code.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20231204-axi-spi-engine-series-2-v1-2-063672323fce@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the AXI SPI Engine driver, the spi_engine_compile_message() function
does not return any error and none of the callers check the return
value. So we can change the return type to void and drop the return 0.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20231204-axi-spi-engine-series-2-v1-1-063672323fce@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Upstream commit e0205d6203 ("spi: atmel: Prevent false timeouts on
long transfers") has tried to mitigate the problem of getting spi
transfers canceled because they were lasting too long. On slow buses,
transfers in the MiB range can take more than one second and thus a
calculation was added to progressively increment the timeout value. In
order to not be too problematic from a user point of view (waiting dozen
of seconds or even minutes), the wait call was turned interruptible.
Turning the wait interruptible was a mistake as what we really wanted to
do was to be able to kill a transfer. Any signal interrupting our
transfer would not be suitable at all so a second attempt was made at
turning the wait killable instead.
Link: https://lore.kernel.org/linux-spi/20231127095842.389631-1-miquel.raynal@bootlin.com/
All being well, it was reported that JFFS2 was showing a splat when
interrupting a transfer. After some more debate about whether JFFS2
should be fixed and how, it was also pointed out that the whole
consistency of the filesystem in case of parallel I/O would be
compromised. Changing JFFS2 behavior would in theory be possible but
nobody has the energy and time and knowledge to do this now, so better
prevent spi transfers to be interrupted by the user.
Partially revert the blamed commit to no longer use the interruptible
nor the killable variant of wait_for_completion().
Fixes: e0205d6203 ("spi: atmel: Prevent false timeouts on long transfers")
Cc: <stable@vger.kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Ronald Wahl <ronald.wahl@raritan.com>
Link: https://lore.kernel.org/r/20231205083102.16946-1-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
cqspi_jh7110_clk_init() is called after clk_prepare_enable(cqspi->clk),
if it fails, it should goto label 'probe_reset_failed' to disable
cqspi->clk.
In the error path after calling cqspi_jh7110_clk_init(),
cqspi_jh7110_disable_clk() need be called.
Fixes: 33f1ef6d4e ("spi: cadence-quadspi: Add clock configuration for StarFive JH7110 QSPI")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20231129081147.628004-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Nam Cao <namcao@linutronix.de>:
While running the spl022, I got the following warning:
BUG: sleeping function called from invalid context at drivers/spi/spi.c:1428
This is because between spi transfers, spi_transfer_delay_exec() (who
may sleep if the delay is >10us) is called in interrupt context. This is
a problem for anyone who runs this driver and need more than 10us delay.
Patch 1 adds an error reporting mechanism, needed by patch 2 who switch
to use the default spi_transfer_one_message(), which fix the problem.
The series is tested with polling transfer mode and interrupt transfer
mode. I can't test the DMA mode, so some help testing here is very
appreciated.
These defines are leftovers from previous versions of the blamed commit,
they are simply unused so drop them.
Fixes: e0205d6203 ("spi: atmel: Prevent false timeouts on long transfers")
Reported-by: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20231127095842.389631-2-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The intended move from wait_for_completion_*() to
wait_for_completion_interruptible_*() was to allow (very) long spi memory
transfers to be stopped upon user request instead of freezing the
machine forever as the timeout value could now be significantly bigger.
However, depending on the user logic, applications can receive many
signals for their own "internal" purpose and have nothing to do with the
requested kernel operations, hence interrupting spi transfers upon any
signal is probably not a wise choice. Instead, let's switch to
wait_for_completion_killable_*() to only catch the "important"
signals. This was likely the intended behavior anyway.
Fixes: e0205d6203 ("spi: atmel: Prevent false timeouts on long transfers")
Cc: stable@vger.kernel.org
Reported-by: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20231127095842.389631-1-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This commit updates the SPI subsystem, particularly affecting "SPI MEM"
drivers and core parts, by replacing the -ENOTSUPP error code with
-EOPNOTSUPP.
The key motivations for this change are as follows:
1. The spi-nor driver currently uses EOPNOTSUPP, whereas calls to spi-mem
might return ENOTSUPP. This update aims to unify the error reporting
within the SPI subsystem for clarity and consistency.
2. The use of ENOTSUPP has been flagged by checkpatch as inappropriate,
mainly being reserved for NFS-related errors. To align with kernel coding
standards and recommendations, this change is being made.
3. By using EOPNOTSUPP, we provide more specific context to the error,
indicating that a particular operation is not supported. This helps
differentiate from the more generic ENOTSUPP error, allowing drivers to
better handle and respond to different error scenarios.
Risks and Considerations:
While this change is primarily intended as a code cleanup and error code
unification, there is a minor risk of breaking user-space applications
that rely on specific return codes for unsupported operations. However,
this risk is considered low, as such use-cases are unlikely to be common
or critical. Nevertheless, developers and users should be aware of this
change, especially if they have scripts or tools that specifically handle
SPI error codes.
This commit does not introduce any functional changes to the SPI subsystem
or the affected drivers.
Signed-off-by: "Chia-Lin Kao (AceLan)" <acelan.kao@canonical.com>
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20231129064311.272422-1-acelan.kao@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Except for polling mode, this driver's transfer_one_message() makes use
of interrupt handler and tasklet. This is problematic because
spi_transfer_delay_exec(), who may sleep, is called in interrupt handler
and tasklet. This causes the following warning:
BUG: sleeping function called from invalid context at drivers/spi/spi.c:1428
Switch to use the default spi_transfer_one_message() instead, which
calls spi_transfer_delay_exec() appropriately.
Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/ae1940abd6ff6a9e77b4373cff60007c641a0c6c.1701274975.git.namcao@linutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The default message transfer implementation - spi_transfer_one_message -
invokes the specific device driver's transfer_one(), then waits for
completion. However, there is no mechanism for the device driver to
report failure in the middle of the transfer.
Introduce SPI_TRANS_FAIL_IO for drivers to report transfer failure.
Signed-off-by: Nam Cao <namcao@linutronix.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/4b420dac528e60f122adde16851da88e4798c1ea.1701274975.git.namcao@linutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Use device life-cycle managed register function to simplify probe error
path and eliminate need for explicit remove function.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20231117161006.87734-5-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from David Lechner <dlechner@baylibre.com>:
We are working towards adding support for the offload feature[1] of the
AXI SPI Engine IP core. Before we can do that, we want to make some
general fixes and improvements to the driver. In order to avoid a giant
series with 35+ patches, we are splitting this up into a few smaller
series.
This first series mostly doing some housekeeping:
* Convert device tree bindings to yaml.
* Add a MAINTAINERS entry.
* Clean up probe and remove using devm.
* Separate message state from driver state.
* Add support for cs_off and variable word size.
Once this series is applied, we will follow up with a second series of
general improvements, and then finally a 3rd series that implements the
offload support. The offload support will also involve the IIO
subsystem (a new IIO driver will depend on the new SPI offload feature),
so I'm mentioning this now in case we want to do anything ahead of time
to prepare for that (e.g. putting all of these changes on a separate
branch).
[1]: https://wiki.analog.com/resources/fpga/peripherals/spi_engine/offload
The AXI SPI Engine IP supports any word size from 1 to 32 bits. This
adds support for this by setting the bits_per_word_mask and emitting
the appropriate instruction to the SPI Engine each time a transfer
requires a new word size.
The functions that transfer tx/rx buffers from/to the SPI Engine
registers (spi_engine_write_{tx,rx}_fifo()) as well as the function that
creates the transfer instruction (spi_engine_gen_xfer()) also have to be
modified to take into account the word size since xfer->len is the
size of the buffers in bytes rather than words.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-14-cc59db999b87@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the AXI SPI Engine driver, the struct spi_engine::msg member was used
to keep track of the current message being processed. The SPI core is
already keeping track of this, so we don't need to duplicate the effort.
In most cases, we already have a pointer to the current message, so we
can pass it directly to the functions that need it. In the one case
where we don't have a pointer to the current message, we can get it
from struct spi_controller::cur_msg.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-12-cc59db999b87@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the AXI SPI Engine driver, the completed_id field in the driver
state is only used in one function and the value does not need to
persist between function calls. Therefore, it can be removed from the
driver state and made a local variable in the function where it is used.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-11-cc59db999b87@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This modifies the AXI SPI Engine driver to make use of the
message_prepare and message_unprepare callbacks. This separates
the concerns of allocating and freeing the message state from the
transfer_one_message callback.
The main benfit of this is so that future callers of
spi_finalize_current_message() will not have to do manual cleanup
of the state.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-10-cc59db999b87@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This moves the message state in the AXI SPI Engine driver to a new
struct spi_engine_msg_state.
Previously, the driver state contained various pointers that pointed
to memory owned by a struct spi_message. However, it did not set any of
these pointers to NULL when a message was completed. This could lead to
use after free bugs.
Example of how this could happen:
1. SPI core calls into spi_engine_transfer_one_message() with msg1.
2. Assume something was misconfigured and spi_engine_tx_next() is not
called enough times in interrupt callbacks for msg1 such that
spi_engine->tx_xfer is never set to NULL before the msg1 completes.
3. SYNC interrupt is received and spi_finalize_current_message() is
called for msg1. spi_engine->msg is set to NULL but no other
message-specific state is reset.
4. Caller that sent msg1 is notified of the completion and frees msg1
and the associated xfers and tx/rx buffers.
4. SPI core calls into spi_engine_transfer_one_message() with msg2.
5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is
still be pointing to an xfer from msg1, which was already freed.
spi_engine_xfer_next() tries to access xfer->transfer_list of one
of the freed xfers and we get a segfault or undefined behavior.
To avoid issues like this, instead of putting per-message state in the
driver state struct, we can make use of the struct spi_message::state
field to store a pointer to a new struct spi_engine_msg_state. This way,
all of the state that belongs to specific message stays with that
message and we don't have to remember to manually reset all aspects of
the message state when a message is completed. Rather, a new state is
allocated for each message.
Most of the changes are just renames where the state is accessed. One
place where this wasn't straightforward was the sync_id member. This
has been changed to use ida_alloc_range() since we needed to separate
the per-message sync_id from the per-controller next available sync_id.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds a check for a valid SCLK rate in the axi-spi-engine driver
during probe. A valid rate is required to get accurate timing for delays
and by not allowing 0 we can avoid divide by zero errors later without
additional checks.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-8-cc59db999b87@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This replaces spi_register_controller() with
devm_spi_register_controller() in the AXI SPI Engine driver. This
saves us from having to call spi_unregister_controller() in the
remove function.
The remove function is also removed since it is no longer needed.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-7-cc59db999b87@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This replaces request_irq() with devm_request_irq() in the AXI SPI
Engine driver. This simplifies the error path and removes the need to
call free_irq() in the remove function.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-6-cc59db999b87@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This moves the reset of the hardware to a devm action in the AXI SPI
Engine driver. This will allow us to use devm on later calls in the
probe function while preserving the order during cleanup.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-5-cc59db999b87@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This modifies the AXI SPI Engine driver to use devm_spi_alloc_host()
instead of spi_alloc_host() to simplify the code a bit.
In addition to simplifying the error paths in the probe function, we
can also remove spi_controller_get/put() calls in the remove function
since devm_spi_alloc_host() sets a flag to no longer decrement the
controller reference count in the spi_unregister_controller() function.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-4-cc59db999b87@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This simplifies the private data allocation in the AXI SPI Engine driver
by making use of the feature built into the spi_alloc_host() function
instead of doing it manually.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-3-cc59db999b87@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of comparing parameters for every supported mem_ops, only compare
on opcode match, which is relatively more efficient.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20231117144053.24005-1-raag.jadav@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Ben Wolsieffer <ben.wolsieffer@hefring.com>:
This series adds support for SPI on STM32F7 processors. The STM32F7 SPI
peripheral is nearly identical to the STM32F4, with the only significant
differences being that it supports a wider range of word sizes, and the
addition of 32-bit transmit and receive FIFOs.
v2:
- Add missing commit body
Ben Wolsieffer (5):
spi: stm32: rename stm32f4_* to stm32fx_*
spi: stm32: use callbacks for read_rx and write_tx
dt-bindings: spi: add stm32f7-spi compatible
spi: stm32: add STM32F7 support
ARM: dts: stm32: add SPI support on STM32F746
.../devicetree/bindings/spi/st,stm32-spi.yaml | 1 +
arch/arm/boot/dts/st/stm32f746.dtsi | 60 +++
drivers/spi/spi-stm32.c | 455 ++++++++++++------
3 files changed, 367 insertions(+), 149 deletions(-)
--
2.42.0
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Add an error message to the error path that returned an error before to
replace the core's error message with more information. Apart from the
different wording of the error message, this patch doesn't introduce a
semantic difference.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231105172649.3738556-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
ZynqMP GQSPI driver no longer uses spi-master framework. It had been
converted to use spi-mem framework. So remove driver dependency from
spi-master and replace it with spi-mem.
Fixes: 1c26372e5a ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Link: https://lore.kernel.org/r/1699282435-884917-1-git-send-email-radhey.shyam.pandey@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Static structs are initialized with zeros for unspecified fields. So
there is no advantage to explicitly initialize .remove with NULL and the
assignment can be dropped without side effects.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231105143932.3722920-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The STM32F7 SPI peripheral is similar to the STM32F4, except it allows
arbitrary word lengths between 4 and 16 bits, and has a small 32-bit
FIFO that allows two 8-bit or smaller words to be transferred with a
single 16-bit read/write.
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
Link: https://lore.kernel.org/r/20231102193722.3042245-5-ben.wolsieffer@hefring.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The STM32F4 and STM32F7 SPI peripherals are very similar, therefore
most of the driver can be shared between the two. In preparation for
adding support for the F7, change all functions and defines to use a
generic stm32fx prefix, except for code and registers that differ
between the two devices.
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
Link: https://lore.kernel.org/r/20231102193722.3042245-2-ben.wolsieffer@hefring.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A couple of fixes that came in during the merge window, one Kconfig
dependency fix and another fix for a long standing issue where in the
case where a sync transfer races with system suspend.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmVONkAACgkQJNaLcl1U
h9CjXAf+INeTPAMe6N9eR4IQ8Q+92h2ST1P8YlZ7Mr8BUgEieXVrnlk9CCtUqymy
JBG3NmHnoQEnDfQ6AXB5dW9ALtOOwxI4PbCIRaaQ1pV5Xu6LBE/HKIvYdSUOevvx
LTXeUKt60TD+75AoKYx59Eu3SVQVQr+RoK6GFxZOPh0ixgpIBq9sZ03bXBQFyXCA
xvvTjqc/olMK8V35ZUjmERR+/0qi7dv9gLCuPXDcMzyaAMZRcX5IfD4WUhfmIEdD
diqiYEebV3EQ0Qzl72C3gYuANVUJ3mRNpDoa2ITRtpspCk0G2ghe8nuRVCZQ/Qyq
C2F8n2p9UKDMPhay6vbK6LVr/1Fi1A==
=p/JY
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v6.7-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A couple of fixes that came in during the merge window: one Kconfig
dependency fix and another fix for a long standing issue where a sync
transfer races with system suspend"
* tag 'spi-fix-v6.7-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: Fix null dereference on suspend
spi: spi-zynq-qspi: add spi-mem to driver kconfig dependencies
A race condition exists where a synchronous (noqueue) transfer can be
active during a system suspend. This can cause a null pointer
dereference exception to occur when the system resumes.
Example order of events leading to the exception:
1. spi_sync() calls __spi_transfer_message_noqueue() which sets
ctlr->cur_msg
2. Spi transfer begins via spi_transfer_one_message()
3. System is suspended interrupting the transfer context
4. System is resumed
6. spi_controller_resume() calls spi_start_queue() which resets cur_msg
to NULL
7. Spi transfer context resumes and spi_finalize_current_message() is
called which dereferences cur_msg (which is now NULL)
Wait for synchronous transfers to complete before suspending by
acquiring the bus mutex and setting/checking a suspend flag.
Signed-off-by: Mark Hasemeyer <markhas@chromium.org>
Link: https://lore.kernel.org/r/20231107144743.v1.1.I7987f05f61901f567f7661763646cb7d7919b528@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@kernel.org
Zynq QSPI driver has been converted to use spi-mem framework so
add spi-mem to driver kconfig dependencies.
Fixes: 67dca5e580 ("spi: spi-mem: Add support for Zynq QSPI controller")
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Link: https://lore.kernel.org/r/1699037031-702858-1-git-send-email-radhey.shyam.pandey@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Here is the "big" set of USB and Thunderbolt changes for 6.7-rc1.
Nothing really major in here, just lots of constant development for new
hardware. Included in here are:
- Thunderbolt (i.e. USB4) fixes for reported issues and support for
new hardware types and devices
- USB typec additions of new drivers and cleanups for some existing
ones
- xhci cleanups and expanded tracing support and some platform
specific updates
- USB "La Jolla Cove Adapter (LJCA)" support added, and the gpio, spi,
and i2c drivers for that type of device (all acked by the respective
subsystem maintainers.)
- lots of USB gadget driver updates and cleanups
- new USB dwc3 platforms supported, as well as other dwc3 fixes and
cleanups
- USB chipidea driver updates
- other smaller driver cleanups and additions, full details in the
shortlog
All of these have been in the linux-next tree for a while with no
reported problems, EXCEPT for some merge conflicts that you will run
into in your tree. 2 of them are in device-tree files, which will be
trivial to resolve (accept both sides), and the last in the
drivers/gpio/gpio-ljca.c file, in the remove callback, resolution should
be pretty trivial (take the version in this branch), see here:
https://lore.kernel.org/all/20231016134159.11d8f849@canb.auug.org.au/
for details, or I can provide a resolved merge point if needed.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZUStew8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ykxgQCggUyfGo+JVV8XZVu5A9KwT6nr7mUAmwUgFxhZ
khK77t0KqF4hjXryeaHa
=iPd+
-----END PGP SIGNATURE-----
Merge tag 'usb-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB/Thunderbolt updates from Greg KH:
"Here is the "big" set of USB and Thunderbolt changes for 6.7-rc1.
Nothing really major in here, just lots of constant development for
new hardware. Included in here are:
- Thunderbolt (i.e. USB4) fixes for reported issues and support for
new hardware types and devices
- USB typec additions of new drivers and cleanups for some existing
ones
- xhci cleanups and expanded tracing support and some platform
specific updates
- USB "La Jolla Cove Adapter (LJCA)" support added, and the gpio,
spi, and i2c drivers for that type of device (all acked by the
respective subsystem maintainers.)
- lots of USB gadget driver updates and cleanups
- new USB dwc3 platforms supported, as well as other dwc3 fixes and
cleanups
- USB chipidea driver updates
- other smaller driver cleanups and additions, full details in the
shortlog
All of these have been in the linux-next tree for a while with no
reported problems"
* tag 'usb-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (167 commits)
usb: gadget: uvc: Add missing initialization of ssp config descriptor
usb: storage: set 1.50 as the lower bcdDevice for older "Super Top" compatibility
usb: raw-gadget: report suspend, resume, reset, and disconnect events
usb: raw-gadget: don't disable device if usb_ep_queue fails
usb: raw-gadget: properly handle interrupted requests
usb:cdnsp: remove TRB_FLUSH_ENDPOINT command
usb: gadget: aspeed_udc: Convert to platform remove callback returning void
dt-bindings: usb: fsa4480: Add compatible for OCP96011
usb: typec: fsa4480: Add support to swap SBU orientation
dt-bindings: usb: fsa4480: Add data-lanes property to endpoint
usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm()
Revert "dt-bindings: usb: Add bindings for multiport properties on DWC3 controller"
Revert "dt-bindings: usb: qcom,dwc3: Add bindings for SC8280 Multiport"
thunderbolt: Fix one kernel-doc comment
usb: gadget: f_ncm: Always set current gadget in ncm_bind()
usb: core: Remove duplicated check in usb_hub_create_port_device
usb: typec: tcpm: Add additional checks for contaminant
arm64: dts: rockchip: rk3588s: Add USB3 host controller
usb: dwc3: add optional PHY interface clocks
dt-bindings: usb: add rk3588 compatible to rockchip,dwc3
...
Currently, the built-in 64-byte FIFO on the MCSPI controller is not
enabled in PIO mode and is used only when DMA is enabled. Enable the
FIFO in PIO mode by default for transactions larger than the FIFO depth
and fallback only if FIFO is not available. When DMA is not enabled,
it is efficient to enable the RX FIFO almost full and TX FIFO almost
empty events after each FIFO fill instead of each word.
Update omap2_mcspi_set_fifo() to enable the events accordingly and
also rely on OMAP2_MCSPI_CHSTAT_RXS for the last transfer instead of the
FIFO events to handle the case when the transfer size is not a multiple
of FIFO depth.
See J721E Technical Reference Manual (SPRUI1C), section 12.1.5
for further details: http://www.ti.com/lit/pdf/spruil1
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20231013092629.19005-1-vaishnav.a@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Acked-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231017203352.2698326-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Export acpi_spi_find_controller_by_adev() so that ACPI glue code which
wants to dynamically create a spi_device using acpi_spi_device_alloc() or
spi_new_device() on a controller, to which the code does not already have
a reference, can find the controller.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20231014205314.59333-2-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
AHB memory as MMIO should be mapped with ioremap rather than ioremap_wc,
which should have been used initially just to handle unaligned access as
a workaround.
Fixes: d166a73503 ("spi: fspi: dynamically alloc AHB memory")
Signed-off-by: Han Xu <han.xu@nxp.com>
Link: https://lore.kernel.org/r/20231010201524.2021340-1-han.xu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Implements the SPI function of Intel USB-I2C/GPIO/SPI adapter device
named "La Jolla Cove Adapter" (LJCA). It communicate with LJCA SPI
module with specific protocol through interfaces exported by LJCA USB
driver.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/1696833205-16716-4-git-send-email-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge series from Fabrizio Castro <fabrizio.castro.jz@renesas.com>:
The CSI IP found inside the Renesas RZ/V2M SoC supports both SPI host
and target. This series extends the CSI dt-bindings and driver to
add SPI target support.
GPIOLIB expects the array of lookup entries to be terminated with an
empty member. We need to increase the size of the variable length array
in the lookup table by 1.
Fixes: 21f252cd29 ("spi: bcm2835: reduce the abuse of the GPIO API")
Reported-by: Hans de Goede <hdegoede@redhat.com>
Closes: https://lore.kernel.org/lkml/29764d46-8d3d-9794-bbde-d7928a91cbb5@redhat.com/
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231004183906.97845-1-brgl@bgdev.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
The code at unmap_if_dma label doesn't contain unmapping dma anymore but
has only fsm reset.
Rename it to reset_if_dma accordingly.
No functional change.
Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/1696614170-18969-1-git-send-email-quic_vnivarth@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The CSI IP found inside the Renesas RZ/V2M SoC supports
both SPI host and SPI target roles.
When working in target mode, the CSI IP has the option
of using its Slave Selection (SS) pin to enable TX and RX
operations. Since the SPI target cannot control the clock,
when working as target it's best not to stop operations
during a transfer, as by doing so the IP will not send or
receive data, regardless of clock and active level on pin SS.
A side effect from not stopping operations is that the RX
FIFO needs to be flushed, word by word, when RX data needs
to be discarded.
Finally, when in target mode timings are tighter, as missing a
deadline translates to errors being thrown, resulting in
aborting the transfer. In order to speed things up, we can
avoid waiting for the TX FIFO to be empty, we can just wait
for the RX FIFO to contain at least the number of words that
we expect.
Add target support to the currently existing CSI driver.
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Link: https://lore.kernel.org/r/20230927162508.328736-3-fabrizio.castro.jz@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that the driver core allows for struct class to be in read-only
memory, we should make all 'class' structures declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at runtime.
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/2023100639-celtic-herbs-66be@gregkh
Signed-off-by: Mark Brown <broonie@kernel.org>
With W=1:
drivers/spi/spi-mpc52xx-psc.c:178:5: warning: no previous prototype for ‘mpc52xx_psc_spi_transfer_one_message’ [-Wmissing-prototypes]
178 | int mpc52xx_psc_spi_transfer_one_message(struct spi_controller *ctlr,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mpc52xx_psc_spi_transfer_one_message() is only used inside the file that
defines it. Hence fix this by making it static.
Fixes: 145cfc3840 ("spi: mpc52xx-psc: Switch to using core message queue")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202310061815.7Rtyi4hs-lkp@intel.com/
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20231006112945.1491265-1-geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
We don't want to use the value of ilog2(0) as dummy.buswidth is 0 when
dummy.nbytes is 0. Since we have no dummy bytes, we don't need to
configure the dummy byte bits per clock register value anyway.
Signed-off-by: "William A. Kennington III" <william@wkennington.com>
Link: https://lore.kernel.org/r/20230922182812.2728066-1-william@wkennington.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug fix to correct return value of gxp_spi_write function to zero.
Completion of succesful operation should return zero.
Fixes: 730bc8ba5e spi: spi-gxp: Add support for HPE GXP SoCs
Signed-off-by: Charles Kearney <charles.kearney@hpe.com>
Link: https://lore.kernel.org/r/20230920215339.4125856-2-charles.kearney@hpe.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A hardcoded reference clock of 48 MHz is used to calculate the
clock divisor values, but the reference clock frequency can be
different across devices and can be configured which can cause
a mismatch between the reported frequency and actual SPI clock
frequency observed. Fix this by fetching the clock rate from
the clock provider and falling back to hardcoded reference only
if the clock is not supplied.
Fixes: 2cd7d393f4 ("arm64: dts: ti: k3-am654: Add McSPI DT nodes")
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230926113812.30692-1-vaishnav.a@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Stephan Gerhold <stephan.gerhold@kernkonzept.com>:
Make it possible to scale performance states of the power domain and
interconnect of the SPI QUP controller in relation to the selected SPI
speed / core clock. This is done separately by:
- Parsing the OPP table from the device tree for performance state
votes of the power domain
- Voting for the necessary bandwidth on the interconnect path to DRAM
dma_request_chan() does not return NULL. It returns a valid pointer or an
error pointer.
So, some dead code can be removed.
The IS_ERR_OR_NULL() in the error handling path are still needed, because
the error handling path is common to the whole function and the
ctlr->dma_xx are NULL when at91_usart_spi_configure_dma() is called.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/84eb08daf85d203b34af9d8d08abf86804211413.1694961365.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
When the SPI QUP controller is used together with a DMA engine it needs
to vote for the interconnect path to the DRAM. Otherwise it may be
unable to access the memory quickly enough.
The requested peak bandwidth is dependent on the SPI core/bus clock so
that the bandwidth scales together with the selected SPI speed.
To avoid sending votes too often the bandwidth is always requested when
a DMA transfer starts, but dropped only on runtime suspend. Runtime
suspend should only happen if no transfer is active. After resumption we
can defer the next vote until the first DMA transfer actually happens.
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Link: https://lore.kernel.org/r/20230919-spi-qup-dvfs-v2-4-1bac2e9ab8db@kernkonzept.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Parse the OPP table from the device tree and use dev_pm_opp_set_rate()
instead of clk_set_rate() to allow making performance state for power
domains specified in the OPP table.
This is needed to guarantee correct behavior of the clock, especially
with the higher clock/SPI bus frequencies.
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Link: https://lore.kernel.org/r/20230919-spi-qup-dvfs-v2-2-1bac2e9ab8db@kernkonzept.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct pci1xxxx_spi.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230922175322.work.170-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
A pm_runtime_disable was left in when the driver was ported to use
devm_pm_runtime_enable, remove it.
Fixes: ef75e76716 ("spi: cs42l43: Add SPI controller support")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230922090829.1467594-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently the bcm2835 SPI driver uses functions that are available
exclusively to GPIO providers as a way to handle a platform quirk. Let's
use a slightly better alternative that avoids poking around in GPIOLIB's
internals and use GPIO lookup tables.
Link: https://www.spinics.net/lists/linux-gpio/msg36218.html
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230911161553.24313-1-brgl@bgdev.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Both callers of spi_stop_queue() (i.e. spi_destroy_queue() and
spi_controller_suspend()) already emit an error message if
spi_stop_queue() fails. Another warning in this case isn't helpful, so
drop it.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230916161235.1050176-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The IMX spi driver has a hardcoded 8, breaking the driver for word
lengths other than 8.
Signed-off-by: Stefan Moring <stefanmoring@gmail.com>
Reported-by: Sebastian Reichel <sre@kernel.org>
Fixes: 15a6af94a2 ("spi: Increase imx51 ecspi burst length based on transfer length")
Tested-by: Sebastian Reichel <sre@kernel.org>
Link: https://lore.kernel.org/r/20230917164037.29284-1-stefanmoring@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Li Zetao <lizetao1@huawei.com>:
Commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks") provides a new helper function for prepared and
enabled clocks when a driver keeps a clock prepared (or enabled) during
the whole lifetime of the driver. So where drivers get clocks and enable
them immediately, it can be combined into a single function
devm_clk_get_*(). Moreover, the unprepare and disable function
has been registered to devm_clk_state, and before devm_clk_state is
released, the clocks will be unprepareed and disable, so it is unnecessary
to unprepare and disable clocks explicitly when remove drivers or in the
error handling path.
Merge series from Yang Yingliang <yangyingliang@huawei.com>:
I'm trying to rename the legacy name to modern name used in SPI drivers,
this is part3 patchset.
After introducing devm_spi_alloc_host/spi_alloc_host(), the legacy
named function devm_spi_alloc_master/spi_alloc_master() can be replaced.
And also change other legacy name master/slave to modern name host/target
or controller. Each patch compile test passed.
Intel Granite Rapids has a flash controller that is compatible with the
other Cannon Lake derivatives. Add Granite Rapids PCI ID to the driver
list of supported devices.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20230911074616.3473347-1-mika.westerberg@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
A few cleanups to the spidev.c to utilize existing APIs and make it
use less amount of Lines of Code. No functional change intended.
Add runtime pm support to cadence-qspi driver, this allows the driver to
suspend whenever it's is not actively being used thus reducing active
power consumed by the system.
Also, with the use of devm_pm_runtime_enable we no longer need the
fallback probe_pm_failed that used to pm_runtime_disable
Co-developed-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230829062706.786637-1-d-gole@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This func misses checking for platform_get_irq()'s call and may passes the
negative error codes to request_irq(), which takes unsigned IRQ #,
causing it to fail with -EINVAL, overriding an original error code.
Fix this by stop calling request_irq() with invalid IRQ #s.
Fixes: dc4dc36056 ("spi: tegra: add spi driver for SLINK controller")
Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com>
Reviewed-by: Helen Koike <helen.koike@collabora.com>
Link: https://lore.kernel.org/r/tencent_73FCC06A3D1C14EE5175253C6FB46A07B709@qq.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-26-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Moreover, the label "err_no_clk_en" is no used, drop it for clean code.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-25-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-24-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-23-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-22-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-21-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Also, devm_clk_get_optional() and clk_prepare_enable() can now be
replaced by devm_clk_get_optional_enabled().Moreover, the two functions
mtk_snand_enable_clk() and mtk_snand_disable_clk() no longer are used,
drop them for clean code.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-20-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-19-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-18-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Moreover, the lable "out_clk" no longer makes sense, rename it to "out_pm".
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-17-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-16-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-15-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-14-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly. Also,
devm_clk_get_optional() and clk_prepare_enable() can now be replaced by
devm_clk_get_optional_enabled(). Moreover, the lable "out_clk" no longer
makes sense, rename it to "out_reset".
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-13-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-12-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-11-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-10-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-9-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-8-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 7ef9651e97 ("clk: Provide new devm_clk helpers for prepared
and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be
replaced by devm_clk_get_enabled() when driver enables (and possibly
prepares) the clocks for the whole lifetime of the device. Moreover, it is
no longer necessary to unprepare and disable the clocks explicitly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230823133938.1359106-7-lizetao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
