From: Tom Rini <trini@konsulko.com>
To: "Marek Behún" <marek.behun@nic.cz>
Cc: u-boot@lists.denx.de,
"Masami Hiramatsu" <masami.hiramatsu@linaro.org>,
"Jagan Teki" <jagan@amarulasolutions.com>,
"Patrice CHOTARD" <patrice.chotard@foss.st.com>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Pali Rohár" <pali@kernel.org>, "Simon Glass" <sjg@chromium.org>
Subject: Re: u-boot and mtdparts
Date: Thu, 15 Jul 2021 16:50:08 -0400 [thread overview]
Message-ID: <20210715205008.GD9379@bill-the-cat> (raw)
In-Reply-To: <20210715201355.5f571f27@dellmb>
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
On Thu, Jul 15, 2021 at 08:13:55PM +0200, Marek Behún wrote:
> Hello Tom and others,
>
> many boards still use the obsolete mtdparts command.
> What is the plan with this command? Do we still want to support it?
>
> Recently as discovered by Masami, my patch
> mtd: spi-nor: allow registering multiple MTDs when DM is enabled
> caused that mtds may have different name than that defined in
> CONFIG_MTDPARTS_DEFAULT.
> Masami fixed his board by putting the partition definitions into
> devicetree, but there are still many boards that may be broken.
>
> The easy fix here is to make mtd_device_matches_name() in
> drivers/mtd/mtdcore.c to support the old names. Most of them are in
> format "type.id", for example "nor.1", "nand.1", but some are different.
>
> The problem is that I do not know how exactly to match these names with
> the devices. Does the number represent the bus, or chip select or
> something else?
>
> There are also multiple parsers of the mtdparts string (at least two,
> one in cmd/mtdparts.c and the other in drivers/mtd/mtd_uboot.c).
>
> IMO the proper solution would be to get rid of the mtdparts entirely,
> move it to devicetree, and add code that generates the mtdparts string
> for Linux' command line from devicetree.
>
> What do you think?
I think there's a few parts to this. Checking the help for
CMD_MTDPARTS, it's been saying it's deprecated since:
commit 938db6fe5da3581ed2c17d64c7e016a7a8df5237
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date: Sat Sep 29 12:58:30 2018 +0200
cmd: mtdparts: describe as legacy
So yes, lets kill off cmd/mtdparts.c. Linux has taken the partition
layout from the device tree itself, one way or another, for seemingly
forever. I don't think we need to have logic to construct the cmdline
option for the kernel at this point. If platforms need it still, for
legacy kernels, they can still of course construct and pass it in
manually.
Now, what to do about parsing of CONFIG_MTDPARTS_DEFAULT /
CONFIG_MTDIDS_DEFAULT? Well, I think at this point we what we care
about in terms of "U-Boot wants to know how MTD is partitioned"
everything should come in from the device tree. Or, we can parse
CONFIG_MTD{PARTS,IDS}_DEFAULT and assume it describes what we need
perhaps?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
prev parent reply other threads:[~2021-07-15 20:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-15 18:13 u-boot and mtdparts Marek Behún
2021-07-15 18:26 ` Simon Glass
2021-07-15 20:50 ` Tom Rini [this message]
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=20210715205008.GD9379@bill-the-cat \
--to=trini@konsulko.com \
--cc=jagan@amarulasolutions.com \
--cc=marek.behun@nic.cz \
--cc=masami.hiramatsu@linaro.org \
--cc=miquel.raynal@bootlin.com \
--cc=pali@kernel.org \
--cc=patrice.chotard@foss.st.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox