The current implementation of the driver holds a spin lock for the
duration of the transfer, releasing it only to enable interrupts for
short periods of time.  As this would prevent any interrupt from
happening, this could cause system performance issues every time a SPI
message is sent.  Since the spi core now handles message syncronization
we can reduce the amount of time the spin-lock is held to the regions
where both the calling thread and the interrupt might interract.
Signed-off-by: NDan Sneddon <dan.sneddon@microchip.com>
Link: https://lore.kernel.org/r/20210602160816.4890-2-dan.sneddon@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>

Switch from using our own transfer_one_message routine to using the one
provided by the SPI core.
Signed-off-by: NDan Sneddon <dan.sneddon@microchip.com>
Link: https://lore.kernel.org/r/20210602160816.4890-1-dan.sneddon@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>

STM32 QSPI is able to automatically poll a specified register inside the
memory and relieve the CPU from this task.

As example, when erasing a large memory area, we got cpu load
equal to 50%. This patch allows to perform the same operation
with a cpu load around 2%.
Signed-off-by: NChristophe Kerello <christophe.kerello@foss.st.com>
Signed-off-by: NPatrice Chotard <patrice.chotard@foss.st.com>
Link: https://lore.kernel.org/r/20210518162754.15940-4-patrice.chotard@foss.st.comSigned-off-by: NMark Brown <broonie@kernel.org>

With STM32 QSPI, it is possible to poll the status register of the device.
This could be done to offload the CPU during an operation (erase or
program a SPI NAND for example).

spi_mem_poll_status API has been added to handle this feature.
This new function take care of the offload/non-offload cases.

For the non-offload case, use read_poll_timeout() to poll the status in
order to release CPU during this phase.
For example, previously, when erasing large area, in non-offload case,
CPU load can reach ~50%, now it decrease to ~35%.
Signed-off-by: NPatrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: NChristophe Kerello <christophe.kerello@foss.st.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/r/20210518162754.15940-2-patrice.chotard@foss.st.comSigned-off-by: NMark Brown <broonie@kernel.org>

Since commit 571e31fa ("spi: bcm2835: Cache CS register value for
->prepare_message()"), the number of slaves has been limited by a
compile-time constant.  This was necessitated by statically-sized
arrays in the driver private data which contain per-slave register
values.

As suggested by Mark, move those register values to a per-slave
controller_state which is allocated on ->setup and freed on ->cleanup.
The limitation on the number of slaves is thus lifted.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Joe Burmeister <joe.burmeister@devtank.co.uk>
Cc: Phil Elwell <phil@raspberrypi.com>
Link: https://lore.kernel.org/r/a847c01f09400801e74e0630bf5a0197591554da.1622150204.git.lukas@wunner.deSigned-off-by: NMark Brown <broonie@kernel.org>

Commit c7299fea ("spi: Fix spi device unregister flow") changed the
SPI core's behavior if the ->setup() hook returns an error upon adding
an spi_device:  Before, the ->cleanup() hook was invoked to free any
allocations that were made by ->setup().  With the commit, that's no
longer the case, so the ->setup() hook is expected to free the
allocations itself.

I've identified 5 drivers which depend on the old behavior and am fixing
them up hereinafter: spi-bitbang.c spi-fsl-spi.c spi-omap-uwire.c
spi-omap2-mcspi.c spi-pxa2xx.c

Importantly, ->setup() is not only invoked on spi_device *addition*:
It may subsequently be called to *change* SPI parameters.  If changing
these SPI parameters fails, freeing memory allocations would be wrong.
That should only be done if the spi_device is finally destroyed.
I am therefore using a bool "initial_setup" in 4 of the affected drivers
to differentiate between the invocation on *adding* the spi_device and
any subsequent invocations: spi-bitbang.c spi-fsl-spi.c spi-omap-uwire.c
spi-omap2-mcspi.c

In spi-pxa2xx.c, it seems the ->setup() hook can only fail on spi_device
addition, not any subsequent calls.  It therefore doesn't need the bool.

It's worth noting that 5 other drivers already perform a cleanup if the
->setup() hook fails.  Before c7299fea, they caused a double-free
if ->setup() failed on spi_device addition.  Since the commit, they're
fine.  These drivers are: spi-mpc512x-psc.c spi-pl022.c spi-s3c64xx.c
spi-st-ssc4.c spi-tegra114.c

(spi-pxa2xx.c also already performs a cleanup, but only in one of
several error paths.)

Fixes: c7299fea ("spi: Fix spi device unregister flow")
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: Saravana Kannan <saravanak@google.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # pxa2xx
Link: https://lore.kernel.org/r/f76a0599469f265b69c371538794101fa37b5536.1622149321.git.lukas@wunner.deSigned-off-by: NMark Brown <broonie@kernel.org>

It is helpful to see what state of CS signal was during one
or another SPI operation. All the same for SPI setup.

Enable tracing of the SPI setup and CS selection.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Message-Id: <20210526195655.75691-1-andriy.shevchenko@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

All chipsets from AR7100 up to QCA9563 have three dedicated chipselect
lines for the integrated SPI controller. Set the number of chipselect
lines available on the controller to this value.
Signed-off-by: NDavid Bauer <mail@david-bauer.net>
Link: https://lore.kernel.org/r/20210522074453.39299-2-mail@david-bauer.netSigned-off-by: NMark Brown <broonie@kernel.org>

The ath79 platform has been converted to pure OF. The platform data is
not needed anymore because of this.
Signed-off-by: NDavid Bauer <mail@david-bauer.net>
Link: https://lore.kernel.org/r/20210522074453.39299-1-mail@david-bauer.netSigned-off-by: NMark Brown <broonie@kernel.org>

Commit 571e31fa ("spi: bcm2835: Cache CS register value for
->prepare_message()") limited the number of slaves to 3 at compile-time.
The limitation was necessitated by a statically-sized array prepare_cs[]
in the driver private data which contains a per-slave register value.

The commit sought to enforce the limitation at run-time by setting the
controller's num_chipselect to 3:  Slaves with a higher chipselect are
rejected by spi_add_device().

However the commit neglected that num_chipselect only limits the number
of *native* chipselects.  If GPIO chipselects are specified in the
device tree for more than 3 slaves, num_chipselect is silently raised by
of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to
the statically-sized array prepare_cs[].

As a bandaid fix which is backportable to stable, raise the number of
allowed slaves to 24 (which "ought to be enough for anybody"), enforce
the limitation on slave ->setup and revert num_chipselect to 3 (which is
the number of native chipselects supported by the controller).
An upcoming for-next commit will allow an arbitrary number of slaves.

Fixes: 571e31fa ("spi: bcm2835: Cache CS register value for ->prepare_message()")
Reported-by: NJoe Burmeister <joe.burmeister@devtank.co.uk>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v5.4+
Cc: Phil Elwell <phil@raspberrypi.com>
Link: https://lore.kernel.org/r/75854affc1923309fde05e47494263bde73e5592.1621703210.git.lukas@wunner.deSigned-off-by: NMark Brown <broonie@kernel.org>

Eliminate the follow smatch warning:

drivers/spi/spi-pxa2xx-pci.c:260 pxa2xx_spi_pci_probe() warn:
inconsistent indenting.
Reported-by: NAbaci Robot <abaci@linux.alibaba.com>
Signed-off-by: NJiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/1621590465-73594-1-git-send-email-jiapeng.chong@linux.alibaba.comSigned-off-by: NMark Brown <broonie@kernel.org>

Allow SPI peripherals attached to this controller to know what is the
maximum transfer size and message size, so they can limit their transfer
lengths properly in case they are otherwise capable of larger transfer
sizes. For the sc18is602, this is 200 bytes in both cases, since as far
as I understand, it isn't possible to tell the controller to keep the
chip select asserted after the STOP command is sent.

The controller can support SPI messages larger than 200 bytes if
cs_change is set for individual transfers such that the portions with
chip select asserted are never longer than 200 bytes. What is not
supported is just SPI messages with a continuous chip select larger than
200. I don't think it is possible to express this using the current API,
so drivers which do send SPI messages with cs_change can safely just
look at the max_transfer_size limit.

An example of user for this is sja1105_xfer() in
drivers/net/dsa/sja1105/sja1105_spi.c which sends by default 64 * 4 =
256 byte transfers.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20210520131238.2903024-3-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

For each spi_message, the sc18is602 I2C-to-SPI bridge driver checks the
length of each spi_transfer against 200 (the size of the chip's internal
buffer) minus hw->tlen (the number of bytes transferred so far).

The first byte of the transferred data is the Function ID (the SPI
slave's chip select) and as per the documentation of the chip:
https://www.nxp.com/docs/en/data-sheet/SC18IS602B.pdf
the data buffer is up to 200 bytes deep _without_ accounting for the
Function ID byte.

However, in sc18is602_txrx(), the driver keeps the Function ID as part
of the buffer, and increments hw->tlen from 0 to 1. Combined with the
check in sc18is602_check_transfer, this prevents us from issuing a
transfer that has exactly 200 bytes in size, but only 199.

Adjust the check function to reflect that the Function ID is not part of
the 200 byte deep data buffer.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20210520131238.2903024-2-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix missing parenthesis of sizeof reported by checkpatch.pl:
 WARNING: sizeof *pp should be sizeof(*pp).

The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: NZhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-8-git-send-email-songzhiqi1@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix missing parenthesis of sizeof reported by checkpatch.pl:
 WARNING: sizeof *pp should be sizeof(*pp).

The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: NZhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-7-git-send-email-songzhiqi1@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix missing parenthesis of sizeof reported by checkpatch.pl:
 WARNING: sizeof *pp should be sizeof(*pp).

The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: NZhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-6-git-send-email-songzhiqi1@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix missing parenthesis of sizeof reported by checkpatch.pl:
 WARNING: sizeof *pp should be sizeof(*pp).

The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: NZhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-5-git-send-email-songzhiqi1@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix missing parenthesis of sizeof reported by checkpatch.pl:
 WARNING: sizeof *pp should be sizeof(*pp).

The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: NZhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-4-git-send-email-songzhiqi1@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix missing parenthesis of sizeof reported by checkpatch.pl:
 WARNING: sizeof *pp should be sizeof(*pp).

The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: NZhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-3-git-send-email-songzhiqi1@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix missing parenthesis of sizeof reported by checkpatch.pl:
 WARNING: sizeof *pp should be sizeof(*pp).

The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.

Cc: Kaiwan N Billimoria <kaiwan@designergraphix.com>
Signed-off-by: NZhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-2-git-send-email-songzhiqi1@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

One of the author names got an invalid char, probably due to
a bad charset conversion, being replaced by the
REPLACEMENT CHARACTER U+fffd ('�').

Use the author's e-mail has the characters without accents,
as also used at the .mailmap file.
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/ff8d296e1fdcc4f1c6df94434a5720bcedcd0ecf.1621412009.git.mchehab+huawei@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

The predefined mask for threshold modification can be used
in case of Intel Merrifield SPI. Replace open-coded value
with predefined mask when programming FIFO thresholds.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-10-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix style of the comments and messages along with typos in them.

While at it, update Intel Copyright year.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-8-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Instead of explicit casting use proper specifier in one case,
and fix specifier signness in another.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-7-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

In the few places it's redundant to compare against 0.
Drop the unneeded comparisons.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-6-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The struct chip_data had been introduced in order to keep the parameters
that may be provided on stack during device allocation. There is no need
to duplicate parameters there, which are carried on by SPI device itself.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-5-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

SPI core has been already providing the GPIO CS handling. Use it.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-4-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

SPI core has been already providing the GPIO CS handling. Use it.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-3-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

SPI core may utilize properties and resources provided by the parent device.
Propagate firmware node to the child SPI controller device for that.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-2-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

When a spi device is unregistered and triggers a driver unbind, the
driver might need to access the spi device. So, don't have the
controller clean up the spi device before the driver is unbound. Clean
up the spi device after the driver is unbound.

Fixes: c7299fea ("spi: Fix spi device unregister flow")
Reported-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Tested-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210505164734.175546-1-saravanak@google.comSigned-off-by: NMark Brown <broonie@kernel.org>

Currently GPIO CS handling, when descriptors are in use, doesn't
take into consideration that in ACPI case the default polarity
is Active High and can't be altered. Instead we have to use the
per-chip definition provided by SPISerialBus() resource.

Fixes: 766c6b63 ("spi: fix client driver breakages when using GPIO descriptors")
Cc: Liguang Zhang <zhangliguang@linux.alibaba.com>
Cc: Jay Fang <f.fangjian@huawei.com>
Cc: Sven Van Asbroeck <thesven73@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NXin Hao <xhao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20210511140912.30757-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

MODULE_DEVICE_TABLE is used to extract the device information out of the
driver and builds a table when being compiled. If using this macro,
kernel can find the driver if available when the device is plugged in,
and then loads that driver and initializes the device.
Signed-off-by: NChunyan Zhang <chunyan.zhang@unisoc.com>
Link: https://lore.kernel.org/r/20210512093534.243040-1-zhang.lyra@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-7-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-6-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-5-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-4-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-3-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-2-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use SPI_MODE_X_MASK instead of open coded variant.

While at it, fix format specifier and drop explicit casting.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZou Wei <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1620716922-108572-1-git-send-email-zou_wei@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>