[PATCH v2] mtd: implement proper partition handling

Boris Brezillon boris.brezillon at collabora.com
Thu Jan 9 11:13:55 PST 2020


On Thu, 9 Jan 2020 19:45:56 +0100
Miquel Raynal <miquel.raynal at bootlin.com> wrote:

> Hi Richard,
> 
> Richard Weinberger <richard at nod.at> wrote on Thu, 9 Jan 2020 19:43:04
> +0100 (CET):
> 
> > Miquel,
> > 
> > ----- Ursprüngliche Mail -----  
> > >> What problem does this solve?
> > >> ...beside of a nice diffstat which removes more than it adds. :-)    
> > > 
> > > It is much easier to escalade to the top most "master" device when
> > > there are multiple levels of partitioning, which was not cleanly
> > > described IMHO. Also it is already used in the MLC-in-pseudo-SLC-mode
> > > series :)    
> > 
> > Ok. In fact I "found" this patch my looking at the SLC emulation patches.
> >   
> > >> > +static inline struct mtd_info *mtd_get_master(struct mtd_info *mtd)
> > >> > +{
> > >> > +	while (mtd->parent)
> > >> > +		mtd = mtd->parent;
> > >> > +
> > >> > +	return mtd;
> > >> > +}    
> > >> 
> > >> So, parent == master?    
> > > 
> > > top most parent (the one without parent) == master !
> > >     
> > >> 
> > >> When I create a MTD ontop of UBI using gluebi, who will be parent/master?    
> > > 
> > > I don't really understand the issue here?    
> > 
> > Let's say I have mtd0 with an ubi and a volume "xxx". After enabling
> > gluebi a new mtd1 will arrive on the system.
> > The stacking is mtd0 -> ubi (volume xxx) -> mtd1.  
> 
> This is much clearer, thanks!
> 
> > Is now a relationship between mtd1 and mtd0?  
> 
> No there is none. 
> 
> > I'd expect mtd1's parent being mtd0.  
> 
> This would be a new feature, right? I don't think it is the case today.

We definitely don't want mtd1 to appear as a partition of mtd0 in that
case (blocks in mtd1 can't be mapped to blocks in mtd0 without the UBI
layer being involved). Maybe it'd be clearer if we move the parent
field to mtd_part and add an MTD_IS_PARTITION flag. Or maybe we can
just choose a better name.



More information about the linux-mtd mailing list