All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Chuanhong Guo <gch981213@gmail.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <bbrezillon@kernel.org>,
	Richard Weinberger <richard@nod.at>,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	Miquel Raynal <miquel.raynal@bootlin.com>
Subject: Re: [PATCH] mtd: nand: spi: rework detect procedure for different read id op
Date: Thu, 9 Jan 2020 20:29:22 +0100	[thread overview]
Message-ID: <20200109202922.744a6739@collabora.com> (raw)
In-Reply-To: <20200109075551.357179-1-gch981213@gmail.com>

On Thu,  9 Jan 2020 15:54:00 +0800
Chuanhong Guo <gch981213@gmail.com> wrote:

> @@ -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
> + * @nchips: number of chips available in spinand_table
>   * @ops: manufacturer operations
>   */
>  struct spinand_manufacturer {
>  	u8 id;
>  	char *name;
> +	u8 devid_len;

IIRC, some manufacturers support more than one scheme which means you
can't really take this decision at the manufacturer level. How about
adding a readid_method field to spinand_info?

enum spinand_readid_method {
	SPINAND_READID_METHOD_OPCODE,
	SPINAND_READID_METHOD_OPCODE_ADDR,
	SPINAND_READID_METHOD_OPCODE_DUMMY,
};

> +	const struct spinand_info *spinand_table;

s/spinand_table/chips/

> +	size_t nchips;
>  	const struct spinand_manufacturer_ops *ops;
>  };


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Chuanhong Guo <gch981213@gmail.com>
Cc: linux-mtd@lists.infradead.org,
	Boris Brezillon <bbrezillon@kernel.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	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 20:29:22 +0100	[thread overview]
Message-ID: <20200109202922.744a6739@collabora.com> (raw)
In-Reply-To: <20200109075551.357179-1-gch981213@gmail.com>

On Thu,  9 Jan 2020 15:54:00 +0800
Chuanhong Guo <gch981213@gmail.com> wrote:

> @@ -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
> + * @nchips: number of chips available in spinand_table
>   * @ops: manufacturer operations
>   */
>  struct spinand_manufacturer {
>  	u8 id;
>  	char *name;
> +	u8 devid_len;

IIRC, some manufacturers support more than one scheme which means you
can't really take this decision at the manufacturer level. How about
adding a readid_method field to spinand_info?

enum spinand_readid_method {
	SPINAND_READID_METHOD_OPCODE,
	SPINAND_READID_METHOD_OPCODE_ADDR,
	SPINAND_READID_METHOD_OPCODE_DUMMY,
};

> +	const struct spinand_info *spinand_table;

s/spinand_table/chips/

> +	size_t nchips;
>  	const struct spinand_manufacturer_ops *ops;
>  };


  parent reply	other threads:[~2020-01-09 19:29 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
2020-01-09 18:08   ` Miquel Raynal
2020-01-09 19:29 ` Boris Brezillon [this message]
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=20200109202922.744a6739@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=bbrezillon@kernel.org \
    --cc=gch981213@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --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.