As mentioned in the corresponding DT binding commit, the naming scheme
for delay properties includes "delay" in the name, so let's keep that
consistent.

Fixes: 33a2fde5 ("spi: Introduce spi-cs-setup-ns property")
Signed-off-by: Hector Martin <marcan@marcan.st>
Link: https://lore.kernel.org/r/20230104093631.15611-3-marcan@marcan.stSigned-off-by: Mark Brown <broonie@kernel.org>

commit 4ccf3598 ("spi: remove spi_set_cs_timing()"), removed the
method as noboby used it. Nobody used it probably because some SPI
controllers use some default large cs-setup time that covers the usual
cs-setup time required by the spi devices. There are though SPI controllers
that have a smaller granularity for the cs-setup time and their default
value can't fulfill the spi device requirements. That's the case for the
at91 QSPI IPs where the default cs-setup time is half of the QSPI clock
period. This was observed when using an sst26vf064b SPI NOR flash which
needs a spi-cs-setup-ns = <7>; in order to be operated close to its maximum
104 MHz frequency.

Call spi_set_cs_timing() in spi_setup() just before calling spi_set_cs(),
as the latter needs the CS timings already set.
If spi->controller->set_cs_timing is not set, the method will return 0.
There's no functional impact expected for the existing drivers. Even if the
spi-mt65xx.c and spi-tegra114.c drivers set the set_cs_timing method,
there's no user for them as of now. The only tested user of this support
will be a SPI NOR flash that comunicates with the Atmel QSPI controller for
which the support follows in the next patches.

One will notice that this support is a bit different from the one that was
removed in commit 4ccf3598 ("spi: remove spi_set_cs_timing()"),
because this patch adapts to the changes done after the removal: the move
of the cs delays to the spi device, the retirement of the lelgacy GPIO
handling. The mutex handling was removed from spi_set_cs_timing() because
we now always call spi_set_cs_timing() in spi_setup(), which already
handles the spi->controller->io_mutex, so use the mutex handling from
spi_setup().
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20221117105249.115649-4-tudor.ambarus@microchip.comSigned-off-by: Mark Brown <broonie@kernel.org>

SPI NOR flashes have specific cs-setup time requirements without which
they can't work at frequencies close to their maximum supported frequency,
as they miss the first bits of the instruction command. Unrecognized
commands are ignored, thus the flash will be unresponsive. Introduce the
spi-cs-setup-ns property to allow spi devices to specify their cs setup
time.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20221117105249.115649-3-tudor.ambarus@microchip.comSigned-off-by: Mark Brown <broonie@kernel.org>

For using modern names host/target to instead of all the legacy names,
I think it takes 3 steps:
  - step1: introduce new helpers with modern naming.
  - step2: switch to use these new helpers in all drivers.
  - step3: remove all legacy helpers and update all legacy names.

This patch is for step1, it introduces new helpers with host/target
naming for drivers using.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221011092204.950288-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now that the 32bit UP oddity is gone and 32bit uses always a sequence
count, there is no need for the fetch_irq() variants anymore.

Convert to the regular interface.

Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20221026122951.331638-1-bigeasy@linutronix.deSigned-off-by: Mark Brown <broonie@kernel.org>

The proposed spi_get_device_match_data() helper is for retrieving
a driver data associated with the ID in an ID table. First, it tries
to get driver data of the device enumerated by firmware interface
(usually Device Tree or ACPI). If none is found it falls back to
the SPI ID table matching.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20221020195421.10482-1-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

SPI code checks for non-zero sgt->orig_nents to determine if the buffer
has been DMA-mapped. Ensure that sg_table is really zeroed after free to
avoid potential NULL pointer dereference if the given SPI xfer object is
reused again without being DMA-mapped.

Fixes: 0c17ba73 ("spi: Fix cache corruption due to DMA/PIO overlap")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20220930113408.19720-1-m.szyprowski@samsung.comSigned-off-by: Mark Brown <broonie@kernel.org>

A couple of drivers call spi_split_transfers_maxsize() from their
->prepare_message() callbacks to split transfers which are too big for
them to handle.  Add support in the core to do this based on
->max_transfer_size() to avoid code duplication.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20220927112117.77599-4-vincent.whitchurch@axis.comSigned-off-by: Mark Brown <broonie@kernel.org>

The SPI core DMA mapping support performs cache management once for the
entire message and not between transfers, and this leads to cache
corruption if a message has two or more RX transfers with both
transfers targeting the same cache line, and the controller driver
decides to handle one using DMA and the other using PIO (for example,
because one is much larger than the other).

Fix it by syncing before/after the actual transfers.  This also means
that we can skip the sync during the map/unmap of the message.

Fixes: 99adef31 ("spi: Provide core support for DMA mapping transfers")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20220927112117.77599-3-vincent.whitchurch@axis.comSigned-off-by: Mark Brown <broonie@kernel.org>

Save the current RX and TX DMA devices to avoid having to duplicate the
logic to pick them, since we'll need access to them in some more
functions to fix a bug in the cache handling.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20220927112117.77599-2-vincent.whitchurch@axis.comSigned-off-by: Mark Brown <broonie@kernel.org>

Some components require a few clock cycles with chipselect off before
or/and after the data transfer done with CS on.

Typically IDT 801034 QUAD PCM CODEC datasheet states "Note *: CCLK
should have one cycle before CS goes low, and two cycles after
CS goes high".

The cycles "before" are implicitely provided by all previous activity
on the SPI bus. But the cycles "after" must be provided in order to
terminate the SPI transfer.

In order to use that kind of component, add a cs_off flag to
spi_transfer struct. When this flag is set, the transfer is performed
with chipselect off. This allows consummer to add a dummy transfer
at the end of the transfer list which is performed with chipselect
OFF, providing the required additional clock cycles.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/434165c46f06d802690208a11e7ea2500e8da4c7.1662558898.git.christophe.leroy@csgroup.euSigned-off-by: Mark Brown <broonie@kernel.org>

The queue worker always needs to be kicked one final time after a transfer
is done in order to transition to idle (ctlr->busy = false).

Commit 69fa9590 ("spi: Ensure the io_mutex is held until
spi_finalize_current_message()") moved this code into
__spi_pump_messages(), but it was executed only if the transfer was
successful. This condition check causes ctlr-busy to stay true in case of
a failed transfer.
This in turn causes that no new work is ever scheduled to the work queue.

Fixes: 69fa9590 ("spi: Ensure the io_mutex is held until spi_finalize_current_message()")
Reported-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220901123630.1098433-1-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

The spi-mux driver is rather too clever and attempts to resubmit any
message that is submitted to it to the parent controller with some
adjusted callbacks.  This does not play at all nicely with the fast
path which now sets flags on the message indicating that it's being
handled through the fast path, we see async messages flagged as being on
the fast path.  Ideally the spi-mux code would duplicate the message but
that's rather invasive and a bit fragile in that it relies on the mux
knowing which fields in the message to copy.  Instead teach the core
that there are controllers which can't cope with the fast path and have
the mux flag itself as being such a controller, ensuring that messages
going via the mux don't get partially handled via the fast path.

This will reduce the performance of any spi-mux connected device since
we'll now always use the thread for both the actual controller and the
mux controller instead of just the actual controller but given that we
were always hitting the slow path anyway it's hopefully not too much of
an additional cost and it allows us to keep the fast path.

Fixes: ae7d2346 ("spi: Don't use the message queue if possible in spi_sync")
Reported-by: Casper Andersson <casper.casan@gmail.com>
Tested-by: Casper Andersson <casper.casan@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220901120732.49245-1-broonie@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The parent field in struct acpi_device is, in fact, redundant,
because the dev.parent field in it effectively points to the same
object and it is used by the driver core.

Accordingly, the parent field can be dropped from struct acpi_device
and for this purpose define acpi_dev_parent() to retrieve a parent
struct acpi_device pointer from the dev.parent field in struct
acpi_device.  Next, update all of the users of the parent field
in struct acpi_device to use acpi_dev_parent() instead of it and
drop it.

While at it, drop the ACPI_IS_ROOT_DEVICE() macro that is only used
in one place in a confusing way.

No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>

Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.

Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20220818210107.7373-1-wsa+renesas@sang-engineering.comSigned-off-by: Mark Brown <broonie@kernel.org>

Fixes sparse warnings of this kind:
drivers/spi/spi.c:117:16: sparse:     expected struct spi_statistics *
drivers/spi/spi.c:117:16: sparse:     got struct spi_statistics [noderef]
 __percpu *[assigned] pcpu_stats
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220805084458.1602277-1-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

This reverts commit 59ebbe40 ("spi: simplify
devm_spi_register_controller").

If devm_add_action() fails in devm_add_action_or_reset(),
devm_spi_unregister() will be called, it decreases the
refcount of 'ctlr->dev' to 0, then it will cause uaf in
the drivers that calling spi_put_controller() in error path.

Fixes: 59ebbe40 ("spi: simplify devm_spi_register_controller")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20220712135504.1055688-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

The acpi_spi_add_resource() is never called with ctrl == NULL and
index == -1. The only caller already performs the check. Hence
remove the duplication from the acpi_spi_add_resource().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220709000709.35622-2-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Since acpi_spi_device_alloc() has been designed to return an error
pointer we may now properly propagate error codes to the caller of
it. It helps debugging a lot.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220709000709.35622-1-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

If the controller is not available, it might be in the future and
we would like to re-probe the peripheral again. For that purpose
return deferred probe.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215993
Fixes: 87e59b36 ("spi: Support selection of the index of the ACPI Spi Resource before alloc")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220709212956.25530-1-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220629142519.3985486-4-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

Capitalize first word in comment where appropriate and add
parentheses to function names.
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220629142519.3985486-3-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220629142519.3985486-2-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

There are only a few drivers that do not call
spi_finalize_current_message() in the context of transfer_one_message(),
and even for those cases the completion ctlr->cur_msg_completion is not
needed always. The calls to complete() and wait_for_completion() each
take a spin-lock, which is costly. This patch makes it possible to avoid
those calls in the big majority of cases, by introducing two flags that
with the help of ordering via barriers can avoid using the completion
safely. In case of a race with the context calling
spi_finalize_current_message(), the scheme errs on the safe side and takes
the completion.
The impact of this patch is worth the effort: On a i.MX8MM SoC, the time
the SPI bus is idle between two consecutive calls to spi_sync(), is
reduced from 19.6us to 16.8us... roughly 15%.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-12-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

This patch introduces a completion that is completed in
spi_finalize_current_message() and waited for in
__spi_pump_transfer_message(). This way all manipulation of ctlr->cur_msg
is done with the io_mutex held and strictly ordered:
__spi_pump_transfer_message() will not return until
spi_finalize_current_message() is done using ctlr->cur_msg, and its
calling context is only touching ctlr->cur_msg after returning.
Due to this, we can safely drop the spin-locks around ctlr->cur_msg.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-11-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

Some drivers rely on this to point to the currently processed message, so
set this here also.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-10-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

Now this flag is written entirely in the mutex, so no need for READ_ONCE
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-9-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

The ctlr->idling flag is never checked now, so we don't need to set it
either.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-8-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

Since the whole idling transition is locked by the io_mutex now, there is
no need to check this flag anymore.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-7-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

Now that the idling flag is wholly behind the io_mutex, this broken piece
of code can be safely removed.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-6-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-5-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

This way, the spi sync path does not need to deal with the idling
transition.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-4-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

The interaction with the controller message queue and its corresponding
auxiliary flags and variables requires the use of the queue_lock which is
costly. Since spi_sync will transfer the complete message anyway, and not
return until it is finished, there is no need to put the message into the
queue if the queue is empty. This can save a lot of overhead.

As an example of how significant this is, when using the MCP2518FD SPI CAN
controller on a i.MX8MM SoC, the time during which the interrupt line
stays active (during 3 relatively short spi_sync messages), is reduced
from 98us to 72us by this patch.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-3-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

This enables the possibility to transfer a message that is not at the
current tip of the async message queue.
This is in preparation of the next patch(es) which enable spi_sync messages
to skip the queue altogether.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-2-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

Return -ENOMEM if the allocation fails.  Don't return success.

Fixes: 6598b91b ("spi: spi.c: Convert statistics to per-cpu u64_stats_t")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/Yqh6bdNYO2XNhPBa@kiliSigned-off-by: Mark Brown <broonie@kernel.org>

We have already a helper to get the first child device, use it and
drop custom approach.
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220610120219.18988-2-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

On 32 bit systems, the following kernel BUG is hit:

BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
caller is debug_smp_processor_id+0x18/0x24
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc1-00001-g6ae0aec8a366 #181
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
 dump_backtrace from show_stack+0x20/0x24
 r7:81024ffd r6:00000000 r5:81024ffd r4:60000013
 show_stack from dump_stack_lvl+0x60/0x78
 dump_stack_lvl from dump_stack+0x14/0x1c
 r7:81024ffd r6:80f652de r5:80bec180 r4:819a2500
 dump_stack from check_preemption_disabled+0xc8/0xf0
 check_preemption_disabled from debug_smp_processor_id+0x18/0x24
 r8:8119b7e0 r7:81205534 r6:819f5c00 r5:819f4c00 r4:c083d724
 debug_smp_processor_id from __spi_sync+0x78/0x220
 __spi_sync from spi_sync+0x34/0x4c
 r10:bb7bf4e0 r9:c083d724 r8:00000007 r7:81a068c0 r6:822a83c0 r5:c083d724
 r4:819f4c00
 spi_sync from spi_mem_exec_op+0x338/0x370
 r5:000000b4 r4:c083d910
 spi_mem_exec_op from spi_nor_read_id+0x98/0xdc
 r10:bb7bf4e0 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:82358040
 r4:819f7c40
 spi_nor_read_id from spi_nor_detect+0x38/0x114
 r7:82358040 r6:00000000 r5:819f7c40 r4:819f7c40
 spi_nor_detect from spi_nor_scan+0x11c/0xbec
 r10:bb7bf4e0 r9:00000000 r8:00000000 r7:c083da4c r6:00000000 r5:00010101
 r4:819f7c40
 spi_nor_scan from spi_nor_probe+0x10c/0x2d0
 r10:bb7bf4e0 r9:bb7bf4d0 r8:00000000 r7:819f4c00 r6:00000000 r5:00000000
 r4:819f7c40

per-cpu access needs to be guarded against preemption.

Fixes: 6598b91b ("spi: spi.c: Convert statistics to per-cpu u64_stats_t")
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: David Jander <david@protonic.nl>
Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://lore.kernel.org/r/20220609121334.2984808-1-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

This change gives a dramatic performance improvement in the hot path,
since many costly spin_lock_irqsave() calls can be avoided.

On an i.MX8MM system with a MCP2518FD CAN controller connected via SPI,
the time the driver takes to handle interrupts, or in other words the time
the IRQ line of the CAN controller stays low is mainly dominated by the
time it takes to do 3 relatively short sync SPI transfers. The effect of
this patch is a reduction of this time from 136us down to only 98us.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220524091808.2269898-1-david@protonic.nlSigned-off-by: Mark Brown <broonie@kernel.org>

All the other calls to the controller driver display the error
return code. The return code is helpful to understand what went
wrong, so include it when failing to transfer one message.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/20220525165852.33167-3-eajames@linux.ibm.comSigned-off-by: Mark Brown <broonie@kernel.org>

Use a helper to set driver_override to the reduce amount of duplicated
code.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220419113435.246203-8-krzysztof.kozlowski@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>