On Thu, 9 Jan 2020 19:45:56 +0100 Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > Hi Richard, > > Richard Weinberger <richard@xxxxxx> 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. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/