[PATCH] spi: fsi: Remove multiple sequenced ops for restricted chips

[PATCH] spi: fsi: Remove multiple sequenced ops for restricted chips

[Eddie James]

Updated restricted chips have trouble processing multiple sequenced
operations. So remove the capability to sequence multiple operations and
reduce the maximum transfer size to 8 bytes.

Signed-off-by: Eddie James <eajames@linux.ibm.com>
---
 drivers/spi/spi-fsi.c | 27 +++++++--------------------
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/drivers/spi/spi-fsi.c b/drivers/spi/spi-fsi.c
index 3920cd3286d8..de359718e816 100644
--- a/drivers/spi/spi-fsi.c
+++ b/drivers/spi/spi-fsi.c
@@ -26,7 +26,7 @@
 #define SPI_FSI_BASE			0x70000
 #define SPI_FSI_INIT_TIMEOUT_MS		1000
 #define SPI_FSI_MAX_XFR_SIZE		2048
-#define SPI_FSI_MAX_XFR_SIZE_RESTRICTED	32
+#define SPI_FSI_MAX_XFR_SIZE_RESTRICTED	8
 
 #define SPI_FSI_ERROR			0x0
 #define SPI_FSI_COUNTER_CFG		0x1
@@ -265,14 +265,12 @@ static int fsi_spi_sequence_transfer(struct fsi_spi *ctx,
 				     struct fsi_spi_sequence *seq,
 				     struct spi_transfer *transfer)
 {
-	bool docfg = false;
 	int loops;
 	int idx;
 	int rc;
 	u8 val = 0;
 	u8 len = min(transfer->len, 8U);
 	u8 rem = transfer->len % len;
-	u64 cfg = 0ULL;
 
 	loops = transfer->len / len;
 
@@ -292,28 +290,17 @@ static int fsi_spi_sequence_transfer(struct fsi_spi *ctx,
 		return -EINVAL;
 	}
 
-	if (ctx->restricted) {
-		const int eidx = rem ? 5 : 6;
-
-		while (loops > 1 && idx <= eidx) {
-			idx = fsi_spi_sequence_add(seq, val);
-			loops--;
-			docfg = true;
-		}
-
-		if (loops > 1) {
-			dev_warn(ctx->dev, "No sequencer slots; aborting.\n");
-			return -EINVAL;
-		}
+	if (ctx->restricted && loops > 1) {
+		dev_warn(ctx->dev,
+			 "Transfer too large; no branches permitted.\n");
+		return -EINVAL;
 	}
 
 	if (loops > 1) {
+		u64 cfg = SPI_FSI_COUNTER_CFG_LOOPS(loops - 1);
+
 		fsi_spi_sequence_add(seq, SPI_FSI_SEQUENCE_BRANCH(idx));
-		docfg = true;
-	}
 
-	if (docfg) {
-		cfg = SPI_FSI_COUNTER_CFG_LOOPS(loops - 1);
 		if (transfer->rx_buf)
 			cfg |= SPI_FSI_COUNTER_CFG_N2_RX |
 				SPI_FSI_COUNTER_CFG_N2_TX |
-- 
2.27.0

Re: [PATCH] spi: fsi: Remove multiple sequenced ops for restricted chips

[Joel Stanley]

On Wed, 24 Mar 2021 at 22:05, Eddie James <eajames@linux.ibm.com> wrote:
>
> Updated restricted chips have trouble processing multiple sequenced
> operations. So remove the capability to sequence multiple operations and
> reduce the maximum transfer size to 8 bytes.
>
> Signed-off-by: Eddie James <eajames@linux.ibm.com>

Reviewed-by: Joel Stanley <joel@jms.id.au>

> ---
>  drivers/spi/spi-fsi.c | 27 +++++++--------------------
>  1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/spi/spi-fsi.c b/drivers/spi/spi-fsi.c
> index 3920cd3286d8..de359718e816 100644
> --- a/drivers/spi/spi-fsi.c
> +++ b/drivers/spi/spi-fsi.c
> @@ -26,7 +26,7 @@
>  #define SPI_FSI_BASE                   0x70000
>  #define SPI_FSI_INIT_TIMEOUT_MS                1000
>  #define SPI_FSI_MAX_XFR_SIZE           2048
> -#define SPI_FSI_MAX_XFR_SIZE_RESTRICTED        32
> +#define SPI_FSI_MAX_XFR_SIZE_RESTRICTED        8
>
>  #define SPI_FSI_ERROR                  0x0
>  #define SPI_FSI_COUNTER_CFG            0x1
> @@ -265,14 +265,12 @@ static int fsi_spi_sequence_transfer(struct fsi_spi *ctx,
>                                      struct fsi_spi_sequence *seq,
>                                      struct spi_transfer *transfer)
>  {
> -       bool docfg = false;
>         int loops;
>         int idx;
>         int rc;
>         u8 val = 0;
>         u8 len = min(transfer->len, 8U);
>         u8 rem = transfer->len % len;
> -       u64 cfg = 0ULL;
>
>         loops = transfer->len / len;
>
> @@ -292,28 +290,17 @@ static int fsi_spi_sequence_transfer(struct fsi_spi *ctx,
>                 return -EINVAL;
>         }
>
> -       if (ctx->restricted) {
> -               const int eidx = rem ? 5 : 6;
> -
> -               while (loops > 1 && idx <= eidx) {
> -                       idx = fsi_spi_sequence_add(seq, val);
> -                       loops--;
> -                       docfg = true;
> -               }
> -
> -               if (loops > 1) {
> -                       dev_warn(ctx->dev, "No sequencer slots; aborting.\n");
> -                       return -EINVAL;
> -               }
> +       if (ctx->restricted && loops > 1) {
> +               dev_warn(ctx->dev,
> +                        "Transfer too large; no branches permitted.\n");
> +               return -EINVAL;
>         }
>
>         if (loops > 1) {
> +               u64 cfg = SPI_FSI_COUNTER_CFG_LOOPS(loops - 1);
> +
>                 fsi_spi_sequence_add(seq, SPI_FSI_SEQUENCE_BRANCH(idx));
> -               docfg = true;
> -       }
>
> -       if (docfg) {
> -               cfg = SPI_FSI_COUNTER_CFG_LOOPS(loops - 1);
>                 if (transfer->rx_buf)
>                         cfg |= SPI_FSI_COUNTER_CFG_N2_RX |
>                                 SPI_FSI_COUNTER_CFG_N2_TX |
> --
> 2.27.0
>

Re: [PATCH] spi: fsi: Remove multiple sequenced ops for restricted chips

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

On Wed, Mar 24, 2021 at 05:05:16PM -0500, Eddie James wrote:

> Updated restricted chips have trouble processing multiple sequenced
> operations. So remove the capability to sequence multiple operations and
> reduce the maximum transfer size to 8 bytes.

That's a very small limit, it would be nice to be able to identify
devices that can use the larger limit so they don't suffer needlessly.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] spi: fsi: Remove multiple sequenced ops for restricted chips

[Eddie James]

On Thu, 2021-03-25 at 13:50 +0000, Mark Brown wrote:
> On Wed, Mar 24, 2021 at 05:05:16PM -0500, Eddie James wrote:
> 
> > Updated restricted chips have trouble processing multiple sequenced
> > operations. So remove the capability to sequence multiple
> > operations and
> > reduce the maximum transfer size to 8 bytes.
> 
> That's a very small limit, it would be nice to be able to identify
> devices that can use the larger limit so they don't suffer
> needlessly.

Yes, this is only for the "restricted" controllers which are marked by
a different compatible string. I guess the commit message isn't
perfectly clear.

Thanks,
Eddie

Re: [PATCH] spi: fsi: Remove multiple sequenced ops for restricted chips

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On Thu, Mar 25, 2021 at 09:46:50AM -0500, Eddie James wrote:
> On Thu, 2021-03-25 at 13:50 +0000, Mark Brown wrote:
> > On Wed, Mar 24, 2021 at 05:05:16PM -0500, Eddie James wrote:

> > > Updated restricted chips have trouble processing multiple sequenced
> > > operations. So remove the capability to sequence multiple
> > > operations and
> > > reduce the maximum transfer size to 8 bytes.

> > That's a very small limit, it would be nice to be able to identify
> > devices that can use the larger limit so they don't suffer
> > needlessly.

> Yes, this is only for the "restricted" controllers which are marked by
> a different compatible string. I guess the commit message isn't
> perfectly clear.

The commit message reads like there's a new version of the restricted
controllers that have even more limits.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] spi: fsi: Remove multiple sequenced ops for restricted chips

[Mark Brown]

On Wed, 24 Mar 2021 17:05:16 -0500, Eddie James wrote:
> Updated restricted chips have trouble processing multiple sequenced
> operations. So remove the capability to sequence multiple operations and
> reduce the maximum transfer size to 8 bytes.

Applied to

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

Thanks!

[1/1] spi: fsi: Remove multiple sequenced ops for restricted chips
      commit: 3ed4c84cc7ac59dd383f1d77f7b04148ede2548d

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