All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: linux-block@vger.kernel.org, linux-efi@vger.kernel.org,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	Tom Rini <trini@konsulko.com>, Jens Axboe <axboe@kernel.dk>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Masahiro Yamada <masahiroy@kernel.org>
Subject: Re: [PATCH v3 4/5] mtd_blkdevs: add option to enable scanning for partitions
Date: Tue, 7 Jun 2022 01:42:01 +0100	[thread overview]
Message-ID: <Yp6e2XXJ7SlkdX+B@makrotopia.org> (raw)
In-Reply-To: <20220603154804.2705bcb6@xps-13>

On Fri, Jun 03, 2022 at 03:48:04PM +0200, Miquel Raynal wrote:
> Hi Daniel,
> 
> daniel@makrotopia.org wrote on Thu, 12 May 2022 20:39:27 +0100:
> 
> > Add Kconfig boolean CONFIG_MTD_BLOCK_PARTITIONS and enable block
> > partition parsers on non-NAND mtdblock devices in case it is selected.
> > 
> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> > ---
> >  drivers/mtd/Kconfig       | 11 +++++++++++
> >  drivers/mtd/mtd_blkdevs.c |  4 +++-
> >  2 files changed, 14 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> > index 796a2eccbef0b8..12874dec15692a 100644
> > --- a/drivers/mtd/Kconfig
> > +++ b/drivers/mtd/Kconfig
> > @@ -69,6 +69,17 @@ config MTD_BLOCK_RO
> >  	  You do not need this option for use with the DiskOnChip devices. For
> >  	  those, enable NFTL support (CONFIG_NFTL) instead.
> >  
> > +config MTD_BLOCK_PARTITIONS
> > +	bool "Scan for partitions on MTD block devices"
> > +	depends on MTD_BLOCK || MTD_BLOCK_RO
> > +	default y if FIT_PARTITION
> > +	help
> > +	  Scan MTD block devices for partitions (ie. MBR, GPT, uImage.FIT, ...).
> > +	  (NAND devices are omitted, ubiblock should be used instead when)
> > +
> > +	  Unless your MTD partitions contain sub-partitions mapped using a
> > +	  partition table, say no.
> > +
> >  comment "Note that in some cases UBI block is preferred. See MTD_UBI_BLOCK."
> >  	depends on MTD_BLOCK || MTD_BLOCK_RO
> >  
> > diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
> > index f7317211146550..c67ce2e6fbeb0a 100644
> > --- a/drivers/mtd/mtd_blkdevs.c
> > +++ b/drivers/mtd/mtd_blkdevs.c
> > @@ -359,7 +359,9 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
> >  	} else {
> >  		snprintf(gd->disk_name, sizeof(gd->disk_name),
> >  			 "%s%d", tr->name, new->devnum);
> > -		gd->flags |= GENHD_FL_NO_PART;
> > +
> > +		if (!IS_ENABLED(CONFIG_MTD_BLOCK_PARTITIONS) || mtd_type_is_nand(new->mtd))
> > +			gd->flags |= GENHD_FL_NO_PART;
> 
> I really wonder if we need this in mtdblock ? Isn't ubiblock enough?

One of the ideas behind this series is to be able to use the exact same
image (which includes a rootfs filesystem sub-image) on devices with
different boot storage options instead of having to write kernel and
root filesystems separately in a storage-type specific manner.

So the very same uImage.FIT on devices with block-based storage can be
written into a GPT partition (see 3/5), on devices with NAND flash
where UBI is used into a UBI volume (see 5/5) and on devices with NOR
flash into an MTD partition (this patch).

> 
> Anyhow,
> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>

Thank you for the review!


> 
> I'll let Richard ack the ubiblock patch.
> 
> Thanks,
> Miquèl
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Golle <daniel@makrotopia.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: linux-block@vger.kernel.org, linux-efi@vger.kernel.org,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	Tom Rini <trini@konsulko.com>, Jens Axboe <axboe@kernel.dk>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Masahiro Yamada <masahiroy@kernel.org>
Subject: Re: [PATCH v3 4/5] mtd_blkdevs: add option to enable scanning for partitions
Date: Tue, 7 Jun 2022 01:42:01 +0100	[thread overview]
Message-ID: <Yp6e2XXJ7SlkdX+B@makrotopia.org> (raw)
In-Reply-To: <20220603154804.2705bcb6@xps-13>

On Fri, Jun 03, 2022 at 03:48:04PM +0200, Miquel Raynal wrote:
> Hi Daniel,
> 
> daniel@makrotopia.org wrote on Thu, 12 May 2022 20:39:27 +0100:
> 
> > Add Kconfig boolean CONFIG_MTD_BLOCK_PARTITIONS and enable block
> > partition parsers on non-NAND mtdblock devices in case it is selected.
> > 
> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> > ---
> >  drivers/mtd/Kconfig       | 11 +++++++++++
> >  drivers/mtd/mtd_blkdevs.c |  4 +++-
> >  2 files changed, 14 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> > index 796a2eccbef0b8..12874dec15692a 100644
> > --- a/drivers/mtd/Kconfig
> > +++ b/drivers/mtd/Kconfig
> > @@ -69,6 +69,17 @@ config MTD_BLOCK_RO
> >  	  You do not need this option for use with the DiskOnChip devices. For
> >  	  those, enable NFTL support (CONFIG_NFTL) instead.
> >  
> > +config MTD_BLOCK_PARTITIONS
> > +	bool "Scan for partitions on MTD block devices"
> > +	depends on MTD_BLOCK || MTD_BLOCK_RO
> > +	default y if FIT_PARTITION
> > +	help
> > +	  Scan MTD block devices for partitions (ie. MBR, GPT, uImage.FIT, ...).
> > +	  (NAND devices are omitted, ubiblock should be used instead when)
> > +
> > +	  Unless your MTD partitions contain sub-partitions mapped using a
> > +	  partition table, say no.
> > +
> >  comment "Note that in some cases UBI block is preferred. See MTD_UBI_BLOCK."
> >  	depends on MTD_BLOCK || MTD_BLOCK_RO
> >  
> > diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
> > index f7317211146550..c67ce2e6fbeb0a 100644
> > --- a/drivers/mtd/mtd_blkdevs.c
> > +++ b/drivers/mtd/mtd_blkdevs.c
> > @@ -359,7 +359,9 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
> >  	} else {
> >  		snprintf(gd->disk_name, sizeof(gd->disk_name),
> >  			 "%s%d", tr->name, new->devnum);
> > -		gd->flags |= GENHD_FL_NO_PART;
> > +
> > +		if (!IS_ENABLED(CONFIG_MTD_BLOCK_PARTITIONS) || mtd_type_is_nand(new->mtd))
> > +			gd->flags |= GENHD_FL_NO_PART;
> 
> I really wonder if we need this in mtdblock ? Isn't ubiblock enough?

One of the ideas behind this series is to be able to use the exact same
image (which includes a rootfs filesystem sub-image) on devices with
different boot storage options instead of having to write kernel and
root filesystems separately in a storage-type specific manner.

So the very same uImage.FIT on devices with block-based storage can be
written into a GPT partition (see 3/5), on devices with NAND flash
where UBI is used into a UBI volume (see 5/5) and on devices with NOR
flash into an MTD partition (this patch).

> 
> Anyhow,
> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>

Thank you for the review!


> 
> I'll let Richard ack the ubiblock patch.
> 
> Thanks,
> Miquèl
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2022-06-07  0:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12 19:39 [PATCH v3 4/5] mtd_blkdevs: add option to enable scanning for partitions Daniel Golle
2022-05-12 19:39 ` Daniel Golle
2022-06-03 13:48 ` Miquel Raynal
2022-06-03 13:48   ` Miquel Raynal
2022-06-07  0:42   ` Daniel Golle [this message]
2022-06-07  0:42     ` Daniel Golle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yp6e2XXJ7SlkdX+B@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=axboe@kernel.dk \
    --cc=dave@stgolabs.net \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=masahiroy@kernel.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=trini@konsulko.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.