From: Rob Herring <robh@kernel.org>
To: Michael Walle <mwalle@kernel.org>
Cc: Simon Glass <sjg@chromium.org>,
miquel.raynal@bootlin.com, conor+dt@kernel.org,
devicetree@vger.kernel.org, krzysztof.kozlowski+dt@linaro.org,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
ptyadav@amazon.de, rafal@milecki.pl, richard@nod.at,
trini@konsulko.com, u-boot@lists.denx.de, vigneshr@ti.com
Subject: Re: [PATCH v2 1/3] dt-bindings: mtd: fixed-partitions: Add binman compatible
Date: Fri, 6 Oct 2023 11:11:13 -0500 [thread overview]
Message-ID: <20231006161113.GA3983739-robh@kernel.org> (raw)
In-Reply-To: <27d37d4c7cf353d99737a1e7a450f9f7@kernel.org>
On Fri, Oct 06, 2023 at 10:37:41AM +0200, Michael Walle wrote:
> Hi,
>
> > > I'm still not sure why that compatible is needed. Also I'd need to
> > > change
> > > the label which might break user space apps looking for that specific
> > > name.
> > >
> > > Also, our board might have u-boot/spl or u-boot/spl/bl31/bl32, right
> > > now
> > > that's something which depends on an u-boot configuration variable,
> > > which
> > > then enables or disables binman nodes in the -u-boot.dtsi. So in linux
> > > we only have that "bootloader" partition, but there might be either
> > > u-boot+spl or u-boot+spl+bl31+bl32.
> > >
> > > Honestly, I'm really not sure this should go into a device tree.
> >
> > I think we might be getting a bit ahead of ourselves here. I thought
> > that the decision was that the label should indicate the contents.
> > If you have multiple things in a partition then it would become a
> > 'section' in Binman's terminology. Either the label programmatically
> > describes what is inside or it doesn't. We can't have it both ways.
> > What do you suggest?
>
> As Rob pointed out earlier, it's just a user-facing string. I'm a bit
> reluctant to use it programatically.
In general, yes, but the partition stuff has long (and still) uses
label. As long as the values the tools understand are documented (which
we don't normally do for label), I don't care so much. That's my
opinion as long as this is shared with fixed-partitions. If it is not
and there's little reason to use label, then absolutely, I think
'compatible' makes more sense.
> Taking my example again, the string "bootloader" is sufficient for a
> user. He doesn't care if it's u-boot with spl or u-boot with tfa, or
> even coreboot. It just says, "in this partition is the bootloader".
> If you have an "bootloader" image you can flash it there.
These days, there's generally not just 1 bootloader in the boot flow.
Maybe there's 1 image, maybe not. Being more specific is hardly ever a
bad thing. Only when the number of specific things becomes multiple 10s
or 100s of them does it become a problem.
> If it has a label "u-boot" and I want to switch to coreboot, will
> it have to change to "coreboot"? I really don't think this is practical,
> you are really putting software configuration into the device tree.
On the input side (to binman), yes it is config, but on the output side
(to the running system) we are saying what's there.
> > At present it seems you have the image described in two places - one
> > is the binman node and the other is the partitions node. I would like
> > to unify these.
>
> And I'm not sure that will work for all the corner cases :/
>
> If you keep the binman section seperate from the flash partition
> definition you don't have any of these problems, although there is
> some redundancy:
> - you only have compatible = "binman", "fixed-partition", no further
> compatibles are required
> - you don't have any conflicts with the current partition descriptions
> - you could even use the labels, because binman is the (only?) user
>
> But of course you need to find a place where to put your node.
And remove it. We don't need 2 sources of truth in the DTB.
Rob
next prev parent reply other threads:[~2023-10-06 16:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-02 17:49 [PATCH v2 1/3] dt-bindings: mtd: fixed-partitions: Add binman compatible Simon Glass
2023-10-02 17:49 ` [PATCH v2 2/3] dt-bindings: mtd: binman-partition: Add binman labels Simon Glass
2023-10-02 17:49 ` [PATCH v2 3/3] dt-bindings: mtd: binman-partitions: Add alignment properties Simon Glass
2023-10-04 7:36 ` [PATCH v2 1/3] dt-bindings: mtd: fixed-partitions: Add binman compatible Miquel Raynal
2023-10-04 11:34 ` Michael Walle
2023-10-04 16:05 ` Simon Glass
2023-10-04 17:16 ` Michael Walle
2023-10-04 18:08 ` Simon Glass
2023-10-05 8:54 ` Michael Walle
2023-10-05 13:28 ` Simon Glass
2023-10-05 15:01 ` Simon Glass
2023-10-06 8:37 ` Michael Walle
2023-10-06 12:39 ` Simon Glass
2023-10-06 16:11 ` Rob Herring [this message]
2023-10-09 19:52 ` Simon Glass
2023-10-04 16:05 ` Simon Glass
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=20231006161113.GA3983739-robh@kernel.org \
--to=robh@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@kernel.org \
--cc=ptyadav@amazon.de \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).