linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Shivamurthy Shastri (sshivamurthy)" <sshivamurthy@micron.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	Chuanhong Guo <gch981213@gmail.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <bbrezillon@kernel.org>,
	Marcel Ziswiler <marcel.ziswiler@toradex.com>,
	Richard Weinberger <richard@nod.at>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	liaoweixiong <liaoweixiong@allwinnertech.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Jeff Kletsky <git-commits@allycomm.com>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [EXT] Re: [PATCH 6/8] mtd: spinand: micron: Turn driver implementation generic
Date: Mon, 7 Oct 2019 10:13:37 +0200	[thread overview]
Message-ID: <20191007101337.647300e2@dhcp-172-31-174-146.wireless.concordia.ca> (raw)
In-Reply-To: <MN2PR08MB5951F13BC1D1D111681CCB4BB8A80@MN2PR08MB5951.namprd08.prod.outlook.com>

On Mon, 19 Aug 2019 09:03:38 +0000
"Shivamurthy Shastri (sshivamurthy)" <sshivamurthy@micron.com> wrote:

> >   
> > >  static int micron_spinand_detect(struct spinand_device *spinand)
> > >  {
> > > +	const struct spi_mem_op *op;
> > >  	u8 *id = spinand->id.data;
> > > -	int ret;
> > >
> > >  	/*
> > >  	 * Micron SPI NAND read ID need a dummy byte,
> > > @@ -114,16 +102,55 @@ static int micron_spinand_detect(struct  
> > spinand_device *spinand)  
> > >  	if (id[1] != SPINAND_MFR_MICRON)
> > >  		return 0;
> > >
> > > -	ret = spinand_match_and_init(spinand, micron_spinand_table,
> > > -				     ARRAY_SIZE(micron_spinand_table),  
> > id[2]);
> > 
> > I am not sure this is the right solution. I would keep this call and
> > overwrite what you need to overwrite with the fixup hook.
> >   

I'm definitely not comfortable with this whole "rely on ONFi
param-page" thing. Vendors have proven to get it wrong from time to
time, so before we do that, I'd like to make sure all currently
supported Micron NANDs (looks like we only support MT29F2G01ABAGD, so
that shouldn't be hard) expose the right thing there. For instance, are
we sure the ECC layout is always the same, and if not, do we have a
reliable way to extract that?

> 
> Then, I will have dummy structure like below.
> 
> static const struct spinand_info micron_spinand_table[] = {                      
>         SPINAND_INFO(NULL, 0,                                                                    
>                      NAND_MEMORG(0, 0, 0, 0, 0, 0, 0, 0, 0),           
>                      NAND_ECCREQ(0, 0),                                                                       
>                      SPINAND_INFO_OP_VARIANTS(&read_cache_variants,              
>                                               &write_cache_variants,             
>                                               &update_cache_variants),           
>                      0,                                                                                         
>                      SPINAND_ECCINFO(&micron_ooblayout_ops,                      
>                                      micron_ecc_get_status)),                    
> };   

> 
> Let me know if you are thinking for different approach.

Exposing dummy entries is useless. If you're entirely sure all Micron
SPI NANDs have a valid ONFi param page, then no need to use the
ID-based detection. But as I said above, I feel param-page-based
detection is going to be as messy as SFDP-based detection is for SPI
NORs. Vendors tend to make mistakes which we have to fix to make
things work. ID-based detection is much more reliable in this regard,
as long as we don't have ID collisions :P.
Plus, it looks like only a few manufacturers decided to use ONFi param
pages to expose SPI NAND info (AFAICT, only Micron and Macronix do
that), which is not surprising since the ONFi param page has been
created to describe parallel NANDs not SPI NANDs (if you look closely
enough, you'll notice that some fields are meaningless for SPI NANDs).

  parent reply	other threads:[~2019-10-07  8:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22  5:56 [PATCH 0/8] Introduce generic ONFI support shiva.linuxworks
2019-07-22  5:56 ` [PATCH 1/8] mtd: nand: move ONFI related functions to onfi.h shiva.linuxworks
2019-08-07  8:34   ` Miquel Raynal
2019-08-19  8:35     ` [EXT] " Shivamurthy Shastri (sshivamurthy)
2019-07-22  5:56 ` [PATCH 2/8] mtd: nand: move support functions for ONFI to nand/onfi.c shiva.linuxworks
2019-08-07  9:03   ` Miquel Raynal
2019-08-19  8:36     ` [EXT] " Shivamurthy Shastri (sshivamurthy)
2019-07-22  5:56 ` [PATCH 3/8] mtd: nand: create ONFI table parsing instance shiva.linuxworks
2019-08-07  9:09   ` Miquel Raynal
2019-07-22  5:56 ` [PATCH 4/8] mtd: spinand: enabled parameter page support shiva.linuxworks
2019-08-07  9:48   ` Miquel Raynal
2019-08-19  8:51     ` [EXT] " Shivamurthy Shastri (sshivamurthy)
2019-08-19  9:21       ` Miquel Raynal
2019-09-30 13:23         ` Shivamurthy Shastri (sshivamurthy)
2019-10-07  7:52         ` Boris Brezillon
2019-07-22  5:56 ` [PATCH 5/8] mtd: spinand: micron: prepare for generalizing driver shiva.linuxworks
2019-08-07  9:51   ` Miquel Raynal
2019-07-22  5:56 ` [PATCH 6/8] mtd: spinand: micron: Turn driver implementation generic shiva.linuxworks
2019-08-07 10:04   ` Miquel Raynal
2019-08-19  9:03     ` [EXT] " Shivamurthy Shastri (sshivamurthy)
2019-08-19  9:19       ` Miquel Raynal
2019-09-16 10:41         ` Shivamurthy Shastri (sshivamurthy)
2019-10-07  8:13       ` Boris Brezillon [this message]
2019-10-14 12:49         ` Shivamurthy Shastri (sshivamurthy)
2019-07-22  5:56 ` [PATCH 7/8] mtd: spinand: micron: Fix read failure in Micron M70A flashes shiva.linuxworks
2019-08-07 10:05   ` Miquel Raynal
2019-07-22  5:56 ` [PATCH 8/8] mtd: spinand: micron: Enable micron flashes with multi-die shiva.linuxworks
2019-08-07 10:08   ` 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=20191007101337.647300e2@dhcp-172-31-174-146.wireless.concordia.ca \
    --to=boris.brezillon@collabora.com \
    --cc=bbrezillon@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=frieder.schrempf@kontron.de \
    --cc=gch981213@gmail.com \
    --cc=git-commits@allycomm.com \
    --cc=liaoweixiong@allwinnertech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marcel.ziswiler@toradex.com \
    --cc=marek.vasut@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=sshivamurthy@micron.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).