From: Michael Walle <mwalle@kernel.org>
To: Simon Glass <sjg@chromium.org>
Cc: 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,
robh+dt@kernel.org, robh@kernel.org, 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, 06 Oct 2023 10:37:41 +0200 [thread overview]
Message-ID: <27d37d4c7cf353d99737a1e7a450f9f7@kernel.org> (raw)
In-Reply-To: <CAPnjgZ2PnKD5m0EgTdEAf-gcK3wuBZvWw_AO2iehb1dmfdoz3A@mail.gmail.com>
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.
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.
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.
> 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.
> What does user space do with the partition labels?
I'm not sure. Also I'm not sure if it really matters, I just wanted to
point out, that you'll force users to change it.
-michael
>> >> What if a board uses eMMC to store the firmware binaries? Will that
>> >> then
>> >> be a subnode to the eMMC device?
>> >
>> > I thought there was a way to link the partition nodes and the device
>> > using a property, without having the partition info as a subnode of
>> > the device. But I may have imagined it as I cannot find it now. So
>> > yes, it will be a subnode of the eMMC device.
>>
>> Not sure if that will fly.
>
> I can't find it anyway. There is somelike like that in
> simple-framebuffer with the 'display' property.
>
> Regards,
> SImon
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Michael Walle <mwalle@kernel.org>
To: Simon Glass <sjg@chromium.org>
Cc: 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,
robh+dt@kernel.org, robh@kernel.org, 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, 06 Oct 2023 10:37:41 +0200 [thread overview]
Message-ID: <27d37d4c7cf353d99737a1e7a450f9f7@kernel.org> (raw)
In-Reply-To: <CAPnjgZ2PnKD5m0EgTdEAf-gcK3wuBZvWw_AO2iehb1dmfdoz3A@mail.gmail.com>
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.
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.
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.
> 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.
> What does user space do with the partition labels?
I'm not sure. Also I'm not sure if it really matters, I just wanted to
point out, that you'll force users to change it.
-michael
>> >> What if a board uses eMMC to store the firmware binaries? Will that
>> >> then
>> >> be a subnode to the eMMC device?
>> >
>> > I thought there was a way to link the partition nodes and the device
>> > using a property, without having the partition info as a subnode of
>> > the device. But I may have imagined it as I cannot find it now. So
>> > yes, it will be a subnode of the eMMC device.
>>
>> Not sure if that will fly.
>
> I can't find it anyway. There is somelike like that in
> simple-framebuffer with the 'display' property.
>
> Regards,
> SImon
next prev parent reply other threads:[~2023-10-06 8:38 UTC|newest]
Thread overview: 32+ 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 ` 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 ` Simon Glass
2023-10-02 17:49 ` [PATCH v2 3/3] dt-bindings: mtd: binman-partitions: Add alignment properties Simon Glass
2023-10-02 17:49 ` Simon Glass
2023-10-04 7:36 ` [PATCH v2 1/3] dt-bindings: mtd: fixed-partitions: Add binman compatible Miquel Raynal
2023-10-04 7:36 ` Miquel Raynal
2023-10-04 11:34 ` Michael Walle
2023-10-04 11:34 ` Michael Walle
2023-10-04 16:05 ` Simon Glass
2023-10-04 16:05 ` Simon Glass
2023-10-04 17:16 ` Michael Walle
2023-10-04 17:16 ` Michael Walle
2023-10-04 18:08 ` Simon Glass
2023-10-04 18:08 ` Simon Glass
2023-10-05 8:54 ` Michael Walle
2023-10-05 8:54 ` Michael Walle
2023-10-05 13:28 ` Simon Glass
2023-10-05 13:28 ` Simon Glass
2023-10-05 15:01 ` Simon Glass
2023-10-05 15:01 ` Simon Glass
2023-10-06 8:37 ` Michael Walle [this message]
2023-10-06 8:37 ` Michael Walle
2023-10-06 12:39 ` Simon Glass
2023-10-06 12:39 ` Simon Glass
2023-10-06 16:11 ` Rob Herring
2023-10-06 16:11 ` Rob Herring
2023-10-09 19:52 ` Simon Glass
2023-10-09 19:52 ` Simon Glass
2023-10-04 16:05 ` 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=27d37d4c7cf353d99737a1e7a450f9f7@kernel.org \
--to=mwalle@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=ptyadav@amazon.de \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--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 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.