2021-05-06 19:59:23

by Pratyush Yadav

[permalink] [raw]
Subject: [PATCH 4/6] spi: spi-mem: reject partial cycle transfers in 8D-8D-8D mode

In 8D-8D-8D mode two bytes are transferred per cycle. So an odd number
of bytes cannot be transferred because it would leave a residual half
cycle at the end. Consider such a transfer invalid and reject it.

Signed-off-by: Pratyush Yadav <[email protected]>

---
This patch should go through the SPI tree but I have included it in this
series because if it goes in before patches 1-3, Micron MT35XU and
Cypress S28HS flashes will stop working correctly.

drivers/spi/spi-mem.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 1513553e4080..ab9eefbaa1d9 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -162,7 +162,17 @@ static bool spi_mem_check_buswidth(struct spi_mem *mem,
bool spi_mem_dtr_supports_op(struct spi_mem *mem,
const struct spi_mem_op *op)
{
- if (op->cmd.nbytes != 2)
+ if (op->cmd.buswidth == 8 && op->cmd.nbytes % 2)
+ return false;
+
+ if (op->addr.nbytes && op->addr.buswidth == 8 && op->addr.nbytes % 2)
+ return false;
+
+ if (op->dummy.nbytes && op->dummy.buswidth == 8 && op->dummy.nbytes % 2)
+ return false;
+
+ if (op->data.dir != SPI_MEM_NO_DATA &&
+ op->dummy.buswidth == 8 && op->data.nbytes % 2)
return false;

return spi_mem_check_buswidth(mem, op);
--
2.30.0


2021-05-07 17:17:45

by Pratyush Yadav

[permalink] [raw]
Subject: Re: [PATCH 4/6] spi: spi-mem: reject partial cycle transfers in 8D-8D-8D mode

On 07/05/21 01:55PM, Mark Brown wrote:
> On Fri, May 07, 2021 at 12:48:27AM +0530, Pratyush Yadav wrote:
> > In 8D-8D-8D mode two bytes are transferred per cycle. So an odd number
> > of bytes cannot be transferred because it would leave a residual half
> > cycle at the end. Consider such a transfer invalid and reject it.
> >
> > Signed-off-by: Pratyush Yadav <[email protected]>
> >
> > ---
> > This patch should go through the SPI tree but I have included it in this
> > series because if it goes in before patches 1-3, Micron MT35XU and
> > Cypress S28HS flashes will stop working correctly.
>
> It seems like this should probably even go in as a fix even if nothing
> is broken with mainline right now, it's the sort of thing some out of
> tree patch could easily trigger. Unless anyone objects I'll do that.

If it does get backported to stable branches, patches 1-3 would have to
go in _before_ this one. Otherwise it will break the two 8D-8D-8D
flashes: Micron MT35XU512ABA and Cypress S28HS512T. Without patch 1
8D-8D-8D mode will not be selected correctly on these two flashes. The
supports_op() will reject it because of 1 data byte. This is a
relatively safe patch for backporting to a stable branch.

Patches 2 and 3 are a slightly different matter. They add an extra
register write. But most controllers I've come across don't support
1-byte writes in 8D mode. It is likely that they are sending
bogus/undefined values in the second byte and deasserting CS only after
the cycle is done. So they should _in theory_ change undefined behaviour
to defined behaviour.

Still, they introduce an extra register write. I'm not sure how
risk-tolerant you want to be for stable backports. I will leave the
judgement to you or Tudor or Vignesh.

--
Regards,
Pratyush Yadav
Texas Instruments Inc.

2021-05-07 17:31:22

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 4/6] spi: spi-mem: reject partial cycle transfers in 8D-8D-8D mode

On Fri, May 07, 2021 at 07:26:33PM +0530, Pratyush Yadav wrote:

> Patches 2 and 3 are a slightly different matter. They add an extra
> register write. But most controllers I've come across don't support
> 1-byte writes in 8D mode. It is likely that they are sending
> bogus/undefined values in the second byte and deasserting CS only after
> the cycle is done. So they should _in theory_ change undefined behaviour
> to defined behaviour.

> Still, they introduce an extra register write. I'm not sure how
> risk-tolerant you want to be for stable backports. I will leave the
> judgement to you or Tudor or Vignesh.

Ah, given that if nobody's seeing any issues I'd probably just hold off
there TBH.


Attachments:
(No filename) (723.00 B)
signature.asc (499.00 B)
Download all attachments

2021-05-07 17:33:07

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 4/6] spi: spi-mem: reject partial cycle transfers in 8D-8D-8D mode

On Fri, May 07, 2021 at 12:48:27AM +0530, Pratyush Yadav wrote:
> In 8D-8D-8D mode two bytes are transferred per cycle. So an odd number
> of bytes cannot be transferred because it would leave a residual half
> cycle at the end. Consider such a transfer invalid and reject it.

Reviwed-by: Mark Brown <[email protected]>


Attachments:
(No filename) (328.00 B)
signature.asc (499.00 B)
Download all attachments

2021-05-07 17:38:19

by Pratyush Yadav

[permalink] [raw]
Subject: Re: [PATCH 4/6] spi: spi-mem: reject partial cycle transfers in 8D-8D-8D mode

On 07/05/21 04:48PM, Mark Brown wrote:
> On Fri, May 07, 2021 at 12:48:27AM +0530, Pratyush Yadav wrote:
> > In 8D-8D-8D mode two bytes are transferred per cycle. So an odd number
> > of bytes cannot be transferred because it would leave a residual half
> > cycle at the end. Consider such a transfer invalid and reject it.
>
> Reviwed-by: Mark Brown <[email protected]>

Thanks. BTW, s/Reviwed/Reviewed/.

--
Regards,
Pratyush Yadav
Texas Instruments Inc.

2021-05-07 17:50:26

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 4/6] spi: spi-mem: reject partial cycle transfers in 8D-8D-8D mode

On Fri, May 07, 2021 at 12:48:27AM +0530, Pratyush Yadav wrote:
> In 8D-8D-8D mode two bytes are transferred per cycle. So an odd number
> of bytes cannot be transferred because it would leave a residual half
> cycle at the end. Consider such a transfer invalid and reject it.
>
> Signed-off-by: Pratyush Yadav <[email protected]>
>
> ---
> This patch should go through the SPI tree but I have included it in this
> series because if it goes in before patches 1-3, Micron MT35XU and
> Cypress S28HS flashes will stop working correctly.

It seems like this should probably even go in as a fix even if nothing
is broken with mainline right now, it's the sort of thing some out of
tree patch could easily trigger. Unless anyone objects I'll do that.


Attachments:
(No filename) (762.00 B)
signature.asc (499.00 B)
Download all attachments