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

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

This way, the spi sync path does not need to deal with the idling
transition.
Signed-off-by: NDavid Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-4-david@protonic.nlSigned-off-by: NMark 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: NDavid Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-3-david@protonic.nlSigned-off-by: NMark 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: NDavid Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-2-david@protonic.nlSigned-off-by: NMark 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: NDan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/Yqh6bdNYO2XNhPBa@kiliSigned-off-by: NMark Brown <broonie@kernel.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: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NDavid Jander <david@protonic.nl>
Tested-by: NNícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://lore.kernel.org/r/20220609121334.2984808-1-david@protonic.nlSigned-off-by: NMark 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: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220524091808.2269898-1-david@protonic.nlSigned-off-by: NMark 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: NEddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/20220525165852.33167-3-eajames@linux.ibm.comSigned-off-by: NMark Brown <broonie@kernel.org>

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

Using pm_runtime_resume_and_get is more appropriate
for simplifing code
Reported-by: NZeal Robot <zealci@zte.com.cn>
Signed-off-by: NMinghao Chi <chi.minghao@zte.com.cn>
Link: https://lore.kernel.org/r/20220418110226.2559081-1-chi.minghao@zte.com.cnSigned-off-by: NMark Brown <broonie@kernel.org>

The previous commit that made bits-per-word validation conditional
results in leaving no unconditional affectation of the status variable.

Since the variable is returned at the end of the function, initialize
it to avoid returning an undefined value.
Signed-off-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Fixes: b3fe2e51 ("spi: core: Only check bits_per_word validity when explicitly provided")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20220414084040.975520-1-paul.kocialkowski@bootlin.comSigned-off-by: NMark Brown <broonie@kernel.org>

On SPI device probe, the core will call spi_setup in spi_add_device
before the corresponding driver was probed. When this happens, the
bits_per_word member of the device is not yet set by the driver,
resulting in the default being set to 8 bits-per-word.

However some controllers do not support 8 bits-per-word at all, which
results in a failure when checking the bits-per-word validity.

In order to support these devices, skip the bits-per-word validity
check when it is not explicitly provided by drivers.
Signed-off-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://lore.kernel.org/r/20220412122207.130181-1-paul.kocialkowski@bootlin.comSigned-off-by: NMark Brown <broonie@kernel.org>

Commit b470e10e ("spi: core: add dma_map_dev for dma device") added
dma_map_dev for _spi_map_msg() but missed to add for unmap routine,
__spi_unmap_msg(), so add it now.

Fixes: b470e10e ("spi: core: add dma_map_dev for dma device")
Cc: stable@vger.kernel.org # v5.14+
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20220406132238.1029249-1-vkoul@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Replace the last instance of acpi_bus_get_device(), added recently
by commit 87e59b36 ("spi: Support selection of the index of the
ACPI Spi Resource before alloc"), with acpi_fetch_acpi_dev() and
finally drop acpi_bus_get_device() that has no more users.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NMark Brown <broonie@kernel.org>

While computing sgs in spi_map_buf(), the data type
used in min_t() for max_seg_size is 'unsigned int' where
as that of ctlr->max_dma_len is 'size_t'.

min_t(unsigned int,x,y) gives wrong results if one of x/y is
'size_t'

Consider the below examples on a 64-bit machine (ie size_t is
64-bits, and unsigned int is 32-bit).
    case 1) min_t(unsigned int, 5, 0x100000001);
    case 2) min_t(size_t, 5, 0x100000001);

Case 1 returns '1', where as case 2 returns '5'. As you can see
the result from case 1 is wrong.

This patch fixes the above issue by using the data type of the
parameters that are used in min_t with maximum data length.

Fixes: commit 1a4e53d2 ("spi: Fix invalid sgs value")
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Suggested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NBiju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20220316175317.465-1-biju.das.jz@bp.renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

max_seg_size is unsigned int and it can have a value up to 2^32
(for eg:-RZ_DMAC driver sets dma_set_max_seg_size as U32_MAX)
When this value is used in min_t() as an integer type, it becomes
-1 and the value of sgs becomes 0.

Fix this issue by replacing the 'int' data type with 'unsigned int'
in min_t().
Signed-off-by: NBiju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20220307184843.9994-1-biju.das.jz@bp.renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

Commit d40f0b6f instroduced last_cs_enable to avoid setting
chipselect if it's not necessary, but it also introduces a bug. The
chipselect may not be set correctly on multi-device SPI busses. The
reason is that we can't judge the chipselect by bool last_cs_enable,
since chipselect may be modified after other devices were accessed.

So we should record the specific state of chipselect in case of
confusion.
Signed-off-by: NYun Zhou <yun.zhou@windriver.com>
Link: https://lore.kernel.org/r/20220217141234.72737-1-yun.zhou@windriver.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use dedicated function sysfs_emit() that does some extra checking,
e.g. to ensure that no more than PAGESIZE bytes are written.
In addition add a trailing newline to the output, that makes it
better readable from the console.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/56e1588d-d53b-73e9-fdc8-7fe30bf91f11@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

All drivers using GPIOs as chip select have been rewritten to use
GPIO descriptors passing the ->use_gpio_descriptors flag. Retire
the code and fields used by the legacy GPIO API.

Do not drop the ->use_gpio_descriptors flag: it now only indicates
that we want to use GPIOs in addition to native chip selects.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220210231954.807904-1-linus.walleij@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

The value returned by an spi driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)

So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error to
the upper layer is a good idea. All drivers are adapted accordingly.
There is no intended change of behaviour, all callbacks were prepared to
return 0 before.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NJérôme Pouiller <jerome.pouiller@silabs.com>
Acked-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: NClaudius Heine <ch@denx.de>
Acked-by: NStefan Schmidt <stefan@datenfreihafen.org>
Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Acked-by: NMarcus Folkesson <marcus.folkesson@gmail.com>
Acked-by: NŁukasz Stelmach <l.stelmach@samsung.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20220123175201.34839-6-u.kleine-koenig@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

Replace acpi_bus_get_device() that is going to be dropped with
acpi_fetch_acpi_dev().

No intentional functional impact.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/2231987.ElGaqSPkdT@kreacherSigned-off-by: NMark Brown <broonie@kernel.org>

Some ACPI nodes may have more than one Spi Resource.
To be able to handle these case, its necessary to have
a way of counting these resources.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-5-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

If a node contains more than one SPI resource it may be necessary to
use an index to select which one you want to allocate a spi device for.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-4-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

This can then be used to find a spi resource inside an
ACPI node, and allocate a spi device.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-3-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

This functions were previously made private since they
were not used. However, these functions will be needed
again.

Partial revert of commit da21fde0
("spi: Make several public functions private to spi.c")
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-2-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some ACPI nodes may have more than one Spi Resource.
To be able to handle these case, its necessary to have
a way of counting these resources.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-5-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

If a node contains more than one SPI resource it may be necessary to
use an index to select which one you want to allocate a spi device for.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-4-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

This can then be used to find a spi resource inside an
ACPI node, and allocate a spi device.
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-3-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

This functions were previously made private since they
were not used. However, these functions will be needed
again.

Partial revert of commit da21fde0
("spi: Make several public functions private to spi.c")
Signed-off-by: NStefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220121172431.6876-2-sbinding@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

Commit b42faeee ("spi: Add a PTP system timestamp
to the transfer structure") added an include of ptp_clock_kernel.h
to spi.h for struct ptp_system_timestamp but a forward declaration
is enough. Let's use that to limit the number of objects we have
to rebuild every time we touch networking headers.
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Tested-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20210904013140.2377609-1-kuba@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Move the cs_setup delay to the end of spi_set_cs.

From include/linux/spi/spi.h:

 * @cs_setup: delay to be introduced by the controller after CS is
   asserted

The cs_setup delay needs to happen *after* CS is asserted, that is, at
the end of spi_set_cs, not at the beginning. Otherwise we're just
delaying before the SPI transaction starts at all, which isn't very
useful.

No drivers use this right now, but that is likely to change soon with an
upcoming Apple SPI HID transport driver.

Fixes: 25093bde ("spi: implement SW control for CS times")
Signed-off-by: NHector Martin <marcan@marcan.st>
Link: https://lore.kernel.org/r/20211210170534.177139-1-marcan@marcan.stSigned-off-by: NMark Brown <broonie@kernel.org>

The recent commit 3f076575 ("spi: deduplicate spi_match_id()
in __spi_register_driver()") inadvertently inverted a condition
that provokes a (harmless) warning:

  WARNING KERN SPI driver mtd_dataflash has no spi_device_id for atmel,at45

Restore logic to avoid such warning to be issued.

Fixes: 3f076575 ("spi: deduplicate spi_match_id() in __spi_register_driver()")
Reported-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NJon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20211123170034.41253-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

  /*
   * Fix multi-line comment style as in this short example. Pay attention
   * to the capitalization, period and starting line of the text.
   */

While at it, split the (supposedly short) description of couple of functions
to summary (short description) and (long) description.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211122171721.61553-3-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

krealloc() as any other kernel memory allocation calls accepts GFP flags,
one of which is __GFP_ZERO. Hence, no need to call memset() explicitly on
the reallocated buffer.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211122171721.61553-2-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The same logic is used in spi_match_id() and in the __spi_register_driver().
By switching the former from taking struct spi_device * to const char * as
the second parameter we may deduplicate the code.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211119173718.52938-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Commit 6098475d ("spi: Fix deadlock when adding SPI controllers on
SPI buses") introduced a per-controller mutex. But mutex_unlock() of
said lock is called after the controller is already freed:

  spi_unregister_controller(ctlr)
  -> put_device(&ctlr->dev)
    -> spi_controller_release(dev)
  -> mutex_unlock(&ctrl->add_lock)

Move the put_device() after the mutex_unlock().

Fixes: 6098475d ("spi: Fix deadlock when adding SPI controllers on SPI buses")
Signed-off-by: NMichael Walle <michael@walle.cc>
Reviewed-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NLukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v5.15
Link: https://lore.kernel.org/r/20211111083713.3335171-1-michael@walle.ccSigned-off-by: NMark Brown <broonie@kernel.org>

io_mutex is taken by spi_setup() and spi-mux's .setup() callback calls
spi_setup() which results in a nested lock of io_mutex.

add_lock is taken by spi_add_device(). The device_add() call in there
can result in calling spi-mux's .probe() callback which registers its
own spi controller which in turn results in spi_add_device() being
called again.

To fix this initialize the controller's locks already in
spi_alloc_controller() to give spi_mux_probe() a chance to set the
lockdep subclass.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211013133710.2679703-2-u.kleine-koenig@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>