[PATCH 0/2] Uniform way to pass a NAND ID table to the core

Miquel Raynal miquel.raynal at bootlin.com
Sat Apr 21 18:36:00 PDT 2018


Hi Boris,

On Sat, 21 Apr 2018 21:28:53 +0200, Boris Brezillon
<boris.brezillon at bootlin.com> wrote:

> On Sat, 21 Apr 2018 20:19:00 +0200
> Miquel Raynal <miquel.raynal at bootlin.com> wrote:
> 
> > Hi Boris,
> > 
> > On Tue, 27 Mar 2018 09:17:37 +0200, Boris Brezillon
> > <boris.brezillon at bootlin.com> wrote:
> >   
> > > Hi Miquel,
> > > 
> > > On Wed, 21 Mar 2018 14:12:33 +0100
> > > Miquel Raynal <miquel.raynal at bootlin.com> wrote:
> > >     
> > > > Hello,
> > > > 
> > > > As part of the work of migrating all the drivers to nand_scan(), and
> > > > because nand_scan() does not provide a way to pass any ID table, create
> > > > a field in NAND chip so a controller driver can expose its ID table to
> > > > the core through it and stop using the last parameter of
> > > > nand_scan_ident() for that.      
> > > 
> > > I'm not a big fan of adding yet another field to the nand_chip struct.
> > > Could we instead create a nand_scan_with_ids() function that takes an
> > > extra ID table in argument and then make nand_scan() a wrapper around
> > > this new function?
> > > 
> > > int nand_scan_with_ids(struct mtd_info *mtd, int max_chips,
> > > 		       struct nand_flash_dev *ids);
> > > 
> > > static inline int nand_scan(struct mtd_info *mtd, int max_chips)
> > > {
> > > 	return nand_scan_with_ids(mtd, max_chips, NULL);
> > > }    
> > 
> > Sure I can do that, but I found too impacting the fact that we should
> > patch all the drivers to call nand_scan_with_ids() from your example.  
> 
> Nope we don't have to do that, see the nand_scan() wrapper proposed
> above.

Actually I was embarrassed by the 'static' keyword, I'll just drop
it off.

> 
> > 
> > I added another exported function called nand_scan_with_ids() but
> > nand_scan() is still visible so that I only have to patch one driver.
> > 
> > You'll tell me what you think.  
> 
> That's exactly what I suggested, so I think we're good ;-).





More information about the linux-mtd mailing list