From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Chuanhong Guo <gch981213@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
linux-mtd@lists.infradead.org,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-kernel@vger.kernel.org,
Boris Brezillon <bbrezillon@kernel.org>
Subject: Re: [PATCH] mtd: nand: spi: rework detect procedure for different read id op
Date: Thu, 9 Jan 2020 19:08:38 +0100 [thread overview]
Message-ID: <20200109190838.7028c8d9@xps13> (raw)
In-Reply-To: <20200109075551.357179-1-gch981213@gmail.com>
Hi Chuanhong,
Chuanhong Guo <gch981213@gmail.com> wrote on Thu, 9 Jan 2020 15:54:00
+0800:
> Currently there are 3 different variants of read_id implementation:
> 1. opcode only. Found in GD5FxGQ4xF.
> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
> 3. opcode + 1 dummy byte. Found in other currently supported chips.
>
> Original implementation was for variant 1 and let detect function
> of chips with variant 2 and 3 to ignore the first byte. This isn't
> robust:
>
> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
> during read, chip will get a random id offset, and the entire id
> buffer will shift by that offset, causing detect failure.
>
> 2. For chips of variant 1, if it happens to get a devid that equals
> to manufacture id of variant 2 or 3 chips, it'll get incorrectly
> detected.
>
> This patch reworks detect procedure to address problems above. New
> logic do detection for all variants separatedly, in 1-2-3 order.
> Since all current detect methods do exactly the same id matching
> procedure, unify them into core.c and remove detect method from
> manufacture_ops.
>
> Tested on GD5F1GQ4UAYIG and W25N01GVZEIG.
>
> Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
> ---
> drivers/mtd/nand/spi/core.c | 89 +++++++++++++++++++++++--------
> drivers/mtd/nand/spi/gigadevice.c | 46 ++++++----------
> drivers/mtd/nand/spi/macronix.c | 25 ++-------
> drivers/mtd/nand/spi/micron.c | 24 ++-------
> drivers/mtd/nand/spi/paragon.c | 23 ++------
> drivers/mtd/nand/spi/toshiba.c | 25 ++-------
> drivers/mtd/nand/spi/winbond.c | 29 ++--------
> include/linux/mtd/spinand.h | 24 ++++-----
> 8 files changed, 110 insertions(+), 175 deletions(-)
Nice diffstat, and nice implementation IMHO.
I'm fine with the patch but I would love to hear Boris' voice on this.
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
One minor nit below.
> @@ -215,15 +204,22 @@ struct spinand_manufacturer_ops {
> * struct spinand_manufacturer - SPI NAND manufacturer instance
> * @id: manufacturer ID
> * @name: manufacturer name
> + * @devid_len: number of bytes in device ID
> + * @spinand_table: array with info for spi nands under current manufacturer
This description is not very clear to me.
And also s/spi nands/SPI-NANDs/
> + * @nchips: number of chips available in spinand_table
> * @ops: manufacturer operations
> */
> struct spinand_manufacturer {
> u8 id;
> char *name;
> + u8 devid_len;
> + const struct spinand_info *spinand_table;
> + size_t nchips;
> const struct spinand_manufacturer_ops *ops;
> };
>
> /* SPI NAND manufacturers */
> +extern const struct spinand_manufacturer gigadevice_spinand_manufacturer_1a_id;
> extern const struct spinand_manufacturer gigadevice_spinand_manufacturer;
> extern const struct spinand_manufacturer macronix_spinand_manufacturer;
> extern const struct spinand_manufacturer micron_spinand_manufacturer;
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: Chuanhong Guo <gch981213@gmail.com>
Cc: linux-mtd@lists.infradead.org,
Boris Brezillon <bbrezillon@kernel.org>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: nand: spi: rework detect procedure for different read id op
Date: Thu, 9 Jan 2020 19:08:38 +0100 [thread overview]
Message-ID: <20200109190838.7028c8d9@xps13> (raw)
In-Reply-To: <20200109075551.357179-1-gch981213@gmail.com>
Hi Chuanhong,
Chuanhong Guo <gch981213@gmail.com> wrote on Thu, 9 Jan 2020 15:54:00
+0800:
> Currently there are 3 different variants of read_id implementation:
> 1. opcode only. Found in GD5FxGQ4xF.
> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
> 3. opcode + 1 dummy byte. Found in other currently supported chips.
>
> Original implementation was for variant 1 and let detect function
> of chips with variant 2 and 3 to ignore the first byte. This isn't
> robust:
>
> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
> during read, chip will get a random id offset, and the entire id
> buffer will shift by that offset, causing detect failure.
>
> 2. For chips of variant 1, if it happens to get a devid that equals
> to manufacture id of variant 2 or 3 chips, it'll get incorrectly
> detected.
>
> This patch reworks detect procedure to address problems above. New
> logic do detection for all variants separatedly, in 1-2-3 order.
> Since all current detect methods do exactly the same id matching
> procedure, unify them into core.c and remove detect method from
> manufacture_ops.
>
> Tested on GD5F1GQ4UAYIG and W25N01GVZEIG.
>
> Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
> ---
> drivers/mtd/nand/spi/core.c | 89 +++++++++++++++++++++++--------
> drivers/mtd/nand/spi/gigadevice.c | 46 ++++++----------
> drivers/mtd/nand/spi/macronix.c | 25 ++-------
> drivers/mtd/nand/spi/micron.c | 24 ++-------
> drivers/mtd/nand/spi/paragon.c | 23 ++------
> drivers/mtd/nand/spi/toshiba.c | 25 ++-------
> drivers/mtd/nand/spi/winbond.c | 29 ++--------
> include/linux/mtd/spinand.h | 24 ++++-----
> 8 files changed, 110 insertions(+), 175 deletions(-)
Nice diffstat, and nice implementation IMHO.
I'm fine with the patch but I would love to hear Boris' voice on this.
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
One minor nit below.
> @@ -215,15 +204,22 @@ struct spinand_manufacturer_ops {
> * struct spinand_manufacturer - SPI NAND manufacturer instance
> * @id: manufacturer ID
> * @name: manufacturer name
> + * @devid_len: number of bytes in device ID
> + * @spinand_table: array with info for spi nands under current manufacturer
This description is not very clear to me.
And also s/spi nands/SPI-NANDs/
> + * @nchips: number of chips available in spinand_table
> * @ops: manufacturer operations
> */
> struct spinand_manufacturer {
> u8 id;
> char *name;
> + u8 devid_len;
> + const struct spinand_info *spinand_table;
> + size_t nchips;
> const struct spinand_manufacturer_ops *ops;
> };
>
> /* SPI NAND manufacturers */
> +extern const struct spinand_manufacturer gigadevice_spinand_manufacturer_1a_id;
> extern const struct spinand_manufacturer gigadevice_spinand_manufacturer;
> extern const struct spinand_manufacturer macronix_spinand_manufacturer;
> extern const struct spinand_manufacturer micron_spinand_manufacturer;
Thanks,
Miquèl
next prev parent reply other threads:[~2020-01-09 18:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-09 7:54 [PATCH] mtd: nand: spi: rework detect procedure for different read id op Chuanhong Guo
2020-01-09 7:54 ` Chuanhong Guo
2020-01-09 18:08 ` Miquel Raynal [this message]
2020-01-09 18:08 ` Miquel Raynal
2020-01-09 19:29 ` Boris Brezillon
2020-01-09 19:29 ` Boris Brezillon
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=20200109190838.7028c8d9@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=bbrezillon@kernel.org \
--cc=gch981213@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--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.