[PATCH v1 0/2] Export the spi-sc18is602's max transfer len limit to SPI slave drivers

[PATCH v1 0/2] Export the spi-sc18is602's max transfer len limit to SPI slave drivers

[Vladimir Oltean]

From: Vladimir Oltean <vladimir.oltean@nxp.com>

These 2 patches make it possible for a SPI device driver which uses
large transfer sizes (256 bytes) to limit itself to the maximum length
supported by the spi-sc18is602 hardware.

Tested with 200 byte buffers on the SC18IS602B.

Vladimir Oltean (2):
  spi: sc18is602: don't consider the chip select byte in
    sc18is602_check_transfer
  spi: sc18is602: implement .max_{transfer,message}_size() for the
    controller

 drivers/spi/spi-sc18is602.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

-- 
2.25.1

[PATCH v1 1/2] spi: sc18is602: don't consider the chip select byte in sc18is602_check_transfer

[Vladimir Oltean]

From: Vladimir Oltean <vladimir.oltean@nxp.com>

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>
---
 drivers/spi/spi-sc18is602.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sc18is602.c b/drivers/spi/spi-sc18is602.c
index 297c512069a5..37871edc7962 100644
--- a/drivers/spi/spi-sc18is602.c
+++ b/drivers/spi/spi-sc18is602.c
@@ -174,7 +174,7 @@ static int sc18is602_setup_transfer(struct sc18is602 *hw, u32 hz, u8 mode)
 static int sc18is602_check_transfer(struct spi_device *spi,
 				    struct spi_transfer *t, int tlen)
 {
-	if (t && t->len + tlen > SC18IS602_BUFSIZ)
+	if (t && t->len + tlen > SC18IS602_BUFSIZ + 1)
 		return -EINVAL;
 
 	return 0;
-- 
2.25.1

[PATCH v1 2/2] spi: sc18is602: implement .max_{transfer,message}_size() for the controller

[Vladimir Oltean]

From: Vladimir Oltean <vladimir.oltean@nxp.com>

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>
---
 drivers/spi/spi-sc18is602.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/spi/spi-sc18is602.c b/drivers/spi/spi-sc18is602.c
index 37871edc7962..5d27ee482237 100644
--- a/drivers/spi/spi-sc18is602.c
+++ b/drivers/spi/spi-sc18is602.c
@@ -219,6 +219,11 @@ static int sc18is602_transfer_one(struct spi_master *master,
 	return status;
 }
 
+static size_t sc18is602_max_transfer_size(struct spi_device *spi)
+{
+	return SC18IS602_BUFSIZ;
+}
+
 static int sc18is602_setup(struct spi_device *spi)
 {
 	struct sc18is602 *hw = spi_master_get_devdata(spi->master);
@@ -293,6 +298,8 @@ static int sc18is602_probe(struct i2c_client *client,
 	master->bits_per_word_mask = SPI_BPW_MASK(8);
 	master->setup = sc18is602_setup;
 	master->transfer_one_message = sc18is602_transfer_one;
+	master->max_transfer_size = sc18is602_max_transfer_size;
+	master->max_message_size = sc18is602_max_transfer_size;
 	master->dev.of_node = np;
 	master->min_speed_hz = hw->freq / 128;
 	master->max_speed_hz = hw->freq / 4;
-- 
2.25.1

Re: [PATCH v1 0/2] Export the spi-sc18is602's max transfer len limit to SPI slave drivers

[Mark Brown]

On Thu, 20 May 2021 16:12:36 +0300, Vladimir Oltean wrote:
> These 2 patches make it possible for a SPI device driver which uses
> large transfer sizes (256 bytes) to limit itself to the maximum length
> supported by the spi-sc18is602 hardware.
> 
> Tested with 200 byte buffers on the SC18IS602B.
> 
> Vladimir Oltean (2):
>   spi: sc18is602: don't consider the chip select byte in
>     sc18is602_check_transfer
>   spi: sc18is602: implement .max_{transfer,message}_size() for the
>     controller
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/2] spi: sc18is602: don't consider the chip select byte in sc18is602_check_transfer
      commit: bda7db1d952c3ff7c24c11bc295aa72aaeb98451
[2/2] spi: sc18is602: implement .max_{transfer,message}_size() for the controller
      commit: b4e46c9954ad55092502e1e8c44ceb9b6744bade

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark