Hi Pintu, pintu.ping@xxxxxxxxx wrote on Wed, 12 Jul 2023 19:29:39 +0530: > Hi, > > We are getting below warning messages in dmesg logs on a NAND device > for every raw partition. > Kernel: 5.15 ; arm64 ; NAND + ubi + squashfs > We have some RAW partitions and one UBI partition (with ubifs/squashfs volumes). > > We are seeing large numbers of these logs on the serial console that > impact the boot time. > [....] > [ 9.667240][ T9] Creating 58 MTD partitions on "1c98000.nand": > [....] > [ 39.975707][ T519] mtdblock: MTD device 'uefi_a' is NAND, please > consider using UBI block devices instead. > [ 39.975707][ T519] mtdblock: MTD device 'uefi_b' is NAND, please > consider using UBI block devices instead. > [....] > > This was added as part of this commit: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mtd/mtdblock.c?h=v5.15.120&id=f41c9418c5898c01634675150696da290fb86796 > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mtd/mtdblock.c?h=v5.15.120&id=e07403a8c6be01857ff75060b2df9a1aa8320fe5 > > I think this warning was decided after my last year's discussion about > mtdblock vs ubiblock for squashfs. > > But these are raw NAND partitions and not mounted by us. > > What is the exact meaning of these warnings ? mtdblock is legacy, ubiblock is better (on NAND devices). > We have both these configs enabled: > CONFIG_MTD_BLOCK=y > CONFIG_MTD_UBI_BLOCK=y > > Through this warning, are we telling that only one of the above config > should be enabled ? If you don't need both, then yes. > And the recommendation is to use ubi_block and disable mtd_block ? Yes. > We are already using ubiblock for mounting squashfs volumes. > But how to get rid of these warnings for raw NAND partitions ? > > Is there a way to avoid or we are missing something which we are not aware of? > In theory the warning should only appear if you open the device (IOW, only if you use it). For this to happen, you need: 96a3295c351d ("mtdblock: warn if opened on NAND") This commit was maybe not backported to stable kernels, you can send it to stable@xxxxxxxxxxxxxxx in order to ask for that. I also see that the mtdblock_ro path was not corrected, maybe that's also a problem in your case? Same, you can adapt the above patch and send it upstream. Thanks, Miquèl
