From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Pratyush Yadav <p.yadav@ti.com>
Cc: Mark Brown <broonie@kernel.org>, <linux-spi@vger.kernel.org>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tudor Ambarus <Tudor.Ambarus@microchip.com>,
Michael Walle <michael@walle.cc>, <linux-mtd@lists.infradead.org>,
Julien Su <juliensu@mxic.com.tw>,
Jaime Liao <jaimeliao@mxic.com.tw>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Boris Brezillon <boris.brezillon@collabora.com>
Subject: Re: [PATCH v7 01/14] spi: spi-mem: Fix a DTR related check in spi_mem_dtr_supports_op()
Date: Tue, 21 Dec 2021 10:50:58 +0100 [thread overview]
Message-ID: <20211221105058.69822ac5@xps13> (raw)
In-Reply-To: <20211220183917.m3mywavgxsgq7yar@ti.com>
Hi Pratyush,
p.yadav@ti.com wrote on Tue, 21 Dec 2021 00:09:19 +0530:
> On 17/12/21 05:16PM, Miquel Raynal wrote:
> > It seems that the number of command bytes must be "2" only when the
> > command itself is sent in DTR mode. The current logic checks if the
> > number of command bytes is "2" when any of the cycles is a DTR cycle. It
> > is likely that so far no device was actually mixing DTR/non-DTR cycles
> > in the same operation, explaining why this was left undetected until
> > now.
>
> This was intentional. spi_mem_dtr_supports_op() must only be called when
> the operation is DTR in all phases so I did not add any sanity checks if
> someone was using it for non-DTR ops.
Maybe that was the original intention but since then the Macronix
driver has been merged and supports (at lest does not reject) these
modes.
> In fact, I added on to this
> function in [0] to check nbytes for other phases as well. The patch fell
> off my radar unfortunately, and it didn't get merged.
>
> I would like to keep this as it is since we have no user of mixed
> DTR/non-DTR modes yet.
I don't know if the Macronix driver really supports it or if it is the
driver that is doing the wrong checks but in appearance such mixed mode
could be used.
> But if you really want to support it, please
> apply my patch first to make sure we check for every phase, not just
> command.
>
> [0] https://lore.kernel.org/all/20210531181757.19458-5-p.yadav@ti.com/
Nice, I might take that as well indeed in order to make the checks a
little bit more robust.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Pratyush Yadav <p.yadav@ti.com>
Cc: Mark Brown <broonie@kernel.org>, <linux-spi@vger.kernel.org>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tudor Ambarus <Tudor.Ambarus@microchip.com>,
Michael Walle <michael@walle.cc>, <linux-mtd@lists.infradead.org>,
Julien Su <juliensu@mxic.com.tw>,
Jaime Liao <jaimeliao@mxic.com.tw>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Boris Brezillon <boris.brezillon@collabora.com>
Subject: Re: [PATCH v7 01/14] spi: spi-mem: Fix a DTR related check in spi_mem_dtr_supports_op()
Date: Tue, 21 Dec 2021 10:50:58 +0100 [thread overview]
Message-ID: <20211221105058.69822ac5@xps13> (raw)
In-Reply-To: <20211220183917.m3mywavgxsgq7yar@ti.com>
Hi Pratyush,
p.yadav@ti.com wrote on Tue, 21 Dec 2021 00:09:19 +0530:
> On 17/12/21 05:16PM, Miquel Raynal wrote:
> > It seems that the number of command bytes must be "2" only when the
> > command itself is sent in DTR mode. The current logic checks if the
> > number of command bytes is "2" when any of the cycles is a DTR cycle. It
> > is likely that so far no device was actually mixing DTR/non-DTR cycles
> > in the same operation, explaining why this was left undetected until
> > now.
>
> This was intentional. spi_mem_dtr_supports_op() must only be called when
> the operation is DTR in all phases so I did not add any sanity checks if
> someone was using it for non-DTR ops.
Maybe that was the original intention but since then the Macronix
driver has been merged and supports (at lest does not reject) these
modes.
> In fact, I added on to this
> function in [0] to check nbytes for other phases as well. The patch fell
> off my radar unfortunately, and it didn't get merged.
>
> I would like to keep this as it is since we have no user of mixed
> DTR/non-DTR modes yet.
I don't know if the Macronix driver really supports it or if it is the
driver that is doing the wrong checks but in appearance such mixed mode
could be used.
> But if you really want to support it, please
> apply my patch first to make sure we check for every phase, not just
> command.
>
> [0] https://lore.kernel.org/all/20210531181757.19458-5-p.yadav@ti.com/
Nice, I might take that as well indeed in order to make the checks a
little bit more robust.
Thanks,
Miquèl
next prev parent reply other threads:[~2021-12-21 9:52 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-17 16:16 [PATCH v7 00/14] External ECC engines & Macronix support Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 01/14] spi: spi-mem: Fix a DTR related check in spi_mem_dtr_supports_op() Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-20 18:39 ` Pratyush Yadav
2021-12-20 18:39 ` Pratyush Yadav
2021-12-21 9:50 ` Miquel Raynal [this message]
2021-12-21 9:50 ` Miquel Raynal
2021-12-21 10:15 ` Pratyush Yadav
2021-12-21 10:15 ` Pratyush Yadav
2021-12-17 16:16 ` [PATCH v7 02/14] spi: spi-mem: Introduce a capability structure Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-20 18:43 ` Pratyush Yadav
2021-12-20 18:43 ` Pratyush Yadav
2021-12-21 9:35 ` Miquel Raynal
2021-12-21 9:35 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 03/14] spi: spi-mem: Check the controller extra capabilities Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-20 18:48 ` Pratyush Yadav
2021-12-20 18:48 ` Pratyush Yadav
2021-12-17 16:16 ` [PATCH v7 04/14] spi: cadence: Provide a capability structure Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-20 18:55 ` Pratyush Yadav
2021-12-20 18:55 ` Pratyush Yadav
2021-12-21 10:16 ` Miquel Raynal
2021-12-21 10:16 ` Miquel Raynal
2021-12-21 10:41 ` Pratyush Yadav
2021-12-21 10:41 ` Pratyush Yadav
2021-12-21 11:19 ` Miquel Raynal
2021-12-21 11:19 ` Miquel Raynal
2021-12-21 12:05 ` Pratyush Yadav
2021-12-21 12:05 ` Pratyush Yadav
2022-01-03 8:38 ` Boris Brezillon
2022-01-03 8:38 ` Boris Brezillon
2022-01-03 9:18 ` Miquel Raynal
2022-01-03 9:18 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 05/14] spi: mxic: " Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 06/14] spi: spi-mem: Kill the spi_mem_dtr_supports_op() helper Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-20 18:58 ` Pratyush Yadav
2021-12-20 18:58 ` Pratyush Yadav
2021-12-21 9:58 ` Miquel Raynal
2021-12-21 9:58 ` Miquel Raynal
2021-12-21 10:10 ` Pratyush Yadav
2021-12-21 10:10 ` Pratyush Yadav
2021-12-21 10:25 ` Miquel Raynal
2021-12-21 10:25 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 07/14] spi: spi-mem: Add an ecc_en parameter to the spi_mem_op structure Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-20 19:02 ` Pratyush Yadav
2021-12-20 19:02 ` Pratyush Yadav
2021-12-21 17:37 ` Miquel Raynal
2021-12-21 17:37 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 08/14] mtd: spinand: Delay a little bit the dirmap creation Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 09/14] mtd: spinand: Create direct mapping descriptors for ECC operations Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 10/14] spi: mxic: Fix the transmit path Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 11/14] spi: mxic: Create a helper to configure the controller before an operation Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 12/14] spi: mxic: Create a helper to ease the start of " Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 13/14] spi: mxic: Add support for direct mapping Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
2021-12-17 16:16 ` [PATCH v7 14/14] spi: mxic: Add support for pipelined ECC operations Miquel Raynal
2021-12-17 16:16 ` Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211221105058.69822ac5@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=boris.brezillon@collabora.com \
--cc=broonie@kernel.org \
--cc=jaimeliao@mxic.com.tw \
--cc=juliensu@mxic.com.tw \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=michael@walle.cc \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--cc=thomas.petazzoni@bootlin.com \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.