Re: [PATCH v2] arm64: dts: broadcom: bcm2712: rpi-5: Add ethernet0 alias

[Andrea della Porta <andrea.porta@suse.com>]

Hi Laurent, Rob,

On 11:37 Fri 12 Dec     , Laurent Pinchart wrote:
> Hi Rob,
> 
> On Thu, Dec 11, 2025 at 12:42:40PM -0600, Rob Herring wrote:
> > On Sun, Nov 2, 2025 at 5:15 AM Laurent Pinchart wrote:
> > >
> > > The RP1 ethernet controller DT node contains a local-mac-address
> > > property to pass the MAC address from the boot loader to the kernel. The
> > > boot loader does not fill the MAC address as the ethernet0 alias is
> > > missing. Add it.
> > 
> > My change here[1] is going to effectively revert this.
> 
> :-(
> 
> > The RP1 stuff
> > needs to either be an overlay or not. We don't need both ways.
> > /aliases don't work for overlays. I suppose that could be added as a
> > fixup when applying. The kernel also assumes aliases are not dynamic
> > and uses indexes which aren't present, so even if it did work there
> > would still be problems. OTOH, if the bootloader might use the
> > ethernet controller, then why would this ever be an overlay in the
> > first place?
> > 
> > Turns out digging into RP1 stuff, it is a mess and needs reworking[2].

I'm currently working on it.

> 
> I don't have a strong opinion personally. As far as I understand from
> https://lore.kernel.org/all/cover.1748526284.git.andrea.porta@suse.com/,
> non-overlay support was added for compatibility with downstream. I don't
> know why the overlay option was considered better for upstream. Andrea,
> could you comment on this ?

The overlay support was initially conceived for three main reasons:

- it was mildly asked for the driver to work also on ACPI based system. It was
  not clear if the ACPI tables would also include entries for the RP1 so I
  assumeed they did not (which would be most probably the case). I'm not aware
  of any hw which complies with these scenario.

- there was a non zero (even though close to zero) chance that RP1 could be used
  on other appliances (i.e. some PCI cards), which makes teh overlay approach 
  appealing. Again, I'm not aware of any real existing hw, if ever.

- paving the way already opened by Bootlin's LAN driver seemed IMHO a good thing
  to pursue (I would say that drivers for FPGA peripherals could benefit the most
  from this approach but there could be others), so why not kicking it off with
  this driver.

Unfortunately, the overlay support is not fully working for all but the simplest
peripherals that requires referencing their nodes from the main DTB, for reasons
debated starting from this thread [1].

This is why the full DT has been provided as the default. Now that I see that the
overlay support is causing a lot of pain and concerns, I'm planning to evict it
in favor of the full DT only, overlay is not used anyway and will not be functional
until we solve all those issues which could be in a very long time, if ever feasible.

> 
> > Right now, I just want the warning gone so I don't get further complaints[3].

I'm also on this. Please provide a priority between fixing this warning (I need to
do a round of tests) and fixing the RP1 DT hierarchy (there will be changes in
both DT and driver code).

Many thanks,
Andrea

[1] - https://lore.kernel.org/all/CAMEGJJ3=W8_R0xBvm8r+Q7iExZx8xPBHEWWGAT9ngpGWDSKCaQ@mail.gmail.com/

> > 
> > Rob
> > 
> > [1] https://lore.kernel.org/all/20251117211503.728354-2-robh@kernel.org/
> > [2] https://lore.kernel.org/all/CAL_JsqJUzB71QdMcxJtNZ7raoPcK+SfTh7EVzGmk=syo8xLKQw@mail.gmail.com/
> > [3] https://lore.kernel.org/all/CAHk-=wi+ge-gtCg+iLd6dgjisGchjtsKY8AXG9tXGOxqVv8Fkw@mail.gmail.com/
> 
> -- 
> Regards,
> 
> Laurent Pinchart