On Tue, Jun 30, 2026 at 11:46 PM Rob Herring [off-list ref] wrote:

On Tue, Jun 30, 2026 at 2:59 PM Loic Poulain
[off-list ref] wrote:

quoted

Hi Rob,

On Tue, Jun 30, 2026 at 8:02 PM Rob Herring [off-list ref] wrote:

quoted

On Mon, Jun 29, 2026 at 10:55:20AM +0200, Loic Poulain wrote:

quoted

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

quoted

          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.

Well, now I think both approaches make sense. We should support a
fixed-layout on the entire hw-part/block, while also allowing it
within individual logical partitions.
Support for the former would only require a small rework/addition in
this series (to have the hw boot partition a fixed-layout) . The
latter could come in a follow-up series, as it would require some
additional fwnode logic.

quoted

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.

quoted

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.

Sure.

Thanks,
Loic