On Thu, Nov 10, 2022 at 09:12:35PM +0100, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- > > On Thu, Nov 10, 2022 at 08:44:53PM +0100, Richard Weinberger wrote: > >> ----- Ursprüngliche Mail ----- > >> > Von: "Daniel Golle" <daniel@xxxxxxxxxxxxxx> > >> > + > >> > + if (!IS_ENABLED(CONFIG_MTD_BLOCK_PARTITIONS) || mtd_type_is_nand(new->mtd)) > >> > + gd->flags |= GENHD_FL_NO_PART; > >> > >> I know that NAND should not get used with mtdblock because lack of wearleveling > >> and > >> in general too many writes. But what exactly is the rationale to deny part > >> scanning for NAND? > > > > As UBI should be used on NAND, partition scanning should be enabled for > > ubiblock devices to have uImage.FIT filesystem subimages mapped by the > > partition parser. > > > > If not skipping partition scanning on NAND-backed mtdblock devices the > > scanning itself will already trigger multiple warnings which now happen > > every time when a NAND-backed mtdblock device is being opened since > > commit 96a3295c ("mtdblock: warn if opened on NAND"). > > I see, you want to promote UBI. Makes sense. > In case you do a v5 series, please add a comment to the code. Will do, I'm planning to send v5 early next week. If we are going to have only CONFIG_MTD_BLOCK_PARTITIONS and no other config symbol for ubiblock devices I'd also merge the two patches for mtdblock and ubiblock partition scanning into a single one. Thank you for reviewing! Daniel