Commits · 1a435466b0d470eb9095da0efefea5f7f69acf9c · Kirill Smelkov / linux

01 Jun, 2021 2 commits

Merge branch 'for-5.13' of... · 1a435466

Mark Brown authored Jun 01, 2021

Merge branch 'for-5.13' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.14

1a435466

spi: Cleanup on failure of initial setup · 2ec6f20b

Lukas Wunner authored May 27, 2021

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: Lukas 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: Mark Brown <broonie@kernel.org>

2ec6f20b

26 May, 2021 1 commit

spi: Enable tracing of the SPI setup CS selection · 5cb4e1f3

Andy Shevchenko authored May 26, 2021

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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Message-Id: <20210526195655.75691-1-andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

5cb4e1f3

24 May, 2021 3 commits

spi: ath79: set number of chipselect lines · ab053f48

David Bauer authored May 22, 2021

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: David Bauer <mail@david-bauer.net>
Link: https://lore.kernel.org/r/20210522074453.39299-2-mail@david-bauer.netSigned-off-by: Mark Brown <broonie@kernel.org>

ab053f48

spi: ath79: drop platform data · 42a7dfa2

David Bauer authored May 22, 2021

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

42a7dfa2

spi: bcm2835: Fix out-of-bounds access with more than 4 slaves · 13817d46

Lukas Wunner authored May 22, 2021

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: Joe Burmeister <joe.burmeister@devtank.co.uk>
Signed-off-by: Lukas 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: Mark Brown <broonie@kernel.org>

13817d46

21 May, 2021 3 commits

spi: pxa2xx: Fix inconsistent indenting · dbfac814

Jiapeng Chong authored May 21, 2021

Eliminate the follow smatch warning:

drivers/spi/spi-pxa2xx-pci.c:260 pxa2xx_spi_pci_probe() warn:
inconsistent indenting.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng 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: Mark Brown <broonie@kernel.org>

dbfac814

spi: sc18is602: implement .max_{transfer,message}_size() for the controller · b4e46c99

Vladimir Oltean authored May 20, 2021

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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20210520131238.2903024-3-olteanv@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

b4e46c99

spi: sc18is602: don't consider the chip select byte in sc18is602_check_transfer · bda7db1d

Vladimir Oltean authored May 20, 2021

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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20210520131238.2903024-2-olteanv@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

bda7db1d

20 May, 2021 9 commits

Merge series "drivers: spi - add parenthesis for sizeof" from Zhiqi Song <songzhiqi1@huawei.com>: · b8b0da83

Mark Brown authored May 20, 2021

This patchset fixes missing parentheses of sizeof reported by checkpatch.pl
under drivers/spi/.

Zhiqi Song (7):
  spi: lm70llp: add parenthesis for sizeof
  spi: mpc512x-psc: add parenthesis for sizeof
  spi: mpc52xx: add parenthesis for sizeof
  spi: mpc52xx-psc: add parenthesis for sizeof
  spi: omap2-mcspi: add parenthesis for sizeof
  spi: omap-uwire: add parenthesis for sizeof
  spi: ppc4xx: add parenthesis for sizeof

 drivers/spi/spi-lm70llp.c     | 2 +-
 drivers/spi/spi-mpc512x-psc.c | 4 ++--
 drivers/spi/spi-mpc52xx-psc.c | 4 ++--
 drivers/spi/spi-mpc52xx.c     | 2 +-
 drivers/spi/spi-omap-uwire.c  | 2 +-
 drivers/spi/spi-omap2-mcspi.c | 2 +-
 drivers/spi/spi-ppc4xx.c      | 4 ++--
 7 files changed, 10 insertions(+), 10 deletions(-)

--
2.7.4

b8b0da83