Re: [PATCH v6 1/9] block: partitions: of: Skip child nodes without reg property
From: Rob Herring
Date: Tue Jun 30 2026 - 17:48:01 EST
On Tue, Jun 30, 2026 at 2:59 PM Loic Poulain
<loic.poulain@xxxxxxxxxxxxxxxx> wrote:
>
> Hi Rob,
>
> On Tue, Jun 30, 2026 at 8:02 PM Rob Herring <robh@xxxxxxxxxx> wrote:
> >
> > On Mon, Jun 29, 2026 at 10:55:20AM +0200, Loic Poulain wrote:
> > > Child nodes of a fixed-partitions node are not necessarily partition
> > > entries, for example an nvmem-layout node has no reg property. The
> > > current code passes a NULL reg pointer and uninitialized len to the
> > > length check, which can result in a kernel panic or silent failure to
> > > register any partitions.
> >
> > That does not sound right to me. A fixed-partitions node should only be
> > defining partitions with address ranges. I would expect a partition node
> > could be nvmem-layout, but not the whole address range. If you wanted
> > the latter, then just do:
> >
> > partitions {
> > ...
> > };
> >
> > nvmem-layout {
> > ...
> > };
>
> In our case, the nvmem-layout needs to be associated with a specific
> eMMC hardware partition, nvmem cells can be a simple sub-range within
> the global eMMC, each hardware partition (boot0, boot1, user...)
> having its own address spaces.
>
> That said, your point about not abusing fixed-partitions is valid. I
> initially dropped the compatible = "fixed-partitions" from the
> partitions-boot1 node when it only carries an nvmem-layout and no
> actual partition entries, making it a plain named container node. But
> it's a bit fragile if we want to support both nvmem-layout and
> fixed-partitions.
>
> Regarding your expectation of a partition node being a nvmem-layout,
> do you mean that the nvmem-layout should live under a fixed-partitions
> node? Something along these lines:
>
> partitions-boot1 {
> compatible = "fixed-partitions";
> #address-cells = <1>;
> #size-cells = <1>;
>
> nvmem@4400 {
partition@4400
> reg = <0x4400 0x1000>;
>
> nvmem-layout {
> compatible = "fixed-layout";
> #address-cells = <1>;
> #size-cells = <1>;
>
> wifi_mac_addr: mac-addr@0 {
> compatible = "mac-base";
> reg = <0x0 0x6>;
> #nvmem-cell-cells = <1>;
> };
> [...]
Either this or replacing "fixed-partitions" with "fixed-layout" if you
want to make the whole boot1 partition nvmem-layout looks like the
right way to me.
> That makes some sense, this would require extra work for the
> emmc/block layer to also associate fwnodes with logical partitions,
> not just the whole disk/hw (hw part), Is that the direction you'd like
> us to go?
Yes.
> Also, Note that regardless of which approach we settle on, this
> specific fix/patch remains necessary to validate the partition node
> and prevent NULL-deref.
Fair enough, though the reasoning for it would be different and
perhaps should give a warning.
Rob