All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.