Message ID | 20211221174844.56385-2-miquel.raynal@bootlin.com (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | External ECC engines & Macronix support | expand |
Hi, On 21/12/21 06:48PM, Miquel Raynal wrote: > From: Pratyush Yadav <p.yadav@ti.com> > > 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 <p.yadav@ti.com> > Reviewed-by: Mark Brown <broonie@kernel.org> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Sorry, I didn't realize this before. This patch would break a couple of SPI NOR flashes. You need patch 1, 2, and 3 from my series as well to make sure this does not happen. Since those patches have some pending comments, can you just drop this patch and I will re-roll it on top of your series later when I can find some time for it? Again, sorry for not noticing this before.
Hi Pratyush, p.yadav@ti.com wrote on Wed, 22 Dec 2021 00:11:50 +0530: > Hi, > > On 21/12/21 06:48PM, Miquel Raynal wrote: > > From: Pratyush Yadav <p.yadav@ti.com> > > > > 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 <p.yadav@ti.com> > > Reviewed-by: Mark Brown <broonie@kernel.org> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > > Sorry, I didn't realize this before. This patch would break a couple of > SPI NOR flashes. You need patch 1, 2, and 3 from my series as well to > make sure this does not happen. Since those patches have some pending > comments, can you just drop this patch and I will re-roll it on top of > your series later when I can find some time for it? Again, sorry for not > noticing this before. Yes no problem, I might as well drop it when applying. Thanks, Miquèl
On 22/12/21 09:12AM, Miquel Raynal wrote: > Hi Pratyush, > > p.yadav@ti.com wrote on Wed, 22 Dec 2021 00:11:50 +0530: > > > Hi, > > > > On 21/12/21 06:48PM, Miquel Raynal wrote: > > > From: Pratyush Yadav <p.yadav@ti.com> > > > > > > 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 <p.yadav@ti.com> > > > Reviewed-by: Mark Brown <broonie@kernel.org> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > > > > Sorry, I didn't realize this before. This patch would break a couple of > > SPI NOR flashes. You need patch 1, 2, and 3 from my series as well to > > make sure this does not happen. Since those patches have some pending > > comments, can you just drop this patch and I will re-roll it on top of > > your series later when I can find some time for it? Again, sorry for not > > noticing this before. > > Yes no problem, I might as well drop it when applying. And drop the changes from patch 3 as well. > > Thanks, > Miquèl
Hi Pratyush, p.yadav@ti.com wrote on Wed, 22 Dec 2021 14:01:52 +0530: > On 22/12/21 09:12AM, Miquel Raynal wrote: > > Hi Pratyush, > > > > p.yadav@ti.com wrote on Wed, 22 Dec 2021 00:11:50 +0530: > > > > > Hi, > > > > > > On 21/12/21 06:48PM, Miquel Raynal wrote: > > > > From: Pratyush Yadav <p.yadav@ti.com> > > > > > > > > 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 <p.yadav@ti.com> > > > > Reviewed-by: Mark Brown <broonie@kernel.org> > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > > > > > > Sorry, I didn't realize this before. This patch would break a couple of > > > SPI NOR flashes. You need patch 1, 2, and 3 from my series as well to > > > make sure this does not happen. Since those patches have some pending > > > comments, can you just drop this patch and I will re-roll it on top of > > > your series later when I can find some time for it? Again, sorry for not > > > noticing this before. > > > > Yes no problem, I might as well drop it when applying. > > And drop the changes from patch 3 as well. Yes of course, I'll keep the "cmd.nbytes != 2" check as it was to keep the behavior exactly as it was, and on top of that we can fine tune these checks. Thanks, Miquèl
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c index 37f4443ce9a0..1dfd38d82607 100644 --- a/drivers/spi/spi-mem.c +++ b/drivers/spi/spi-mem.c @@ -163,7 +163,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);