Re: [PATCH 1/2] ARM: dts: broadcom: bcm2835-rpi: Move the firmware node down 1 level

[Florian Fainelli]

On 3/19/26 04:19, Marek Szyprowski wrote:
> On 14.01.2026 19:22, Florian Fainelli wrote:
> > On 1/13/2026 5:58 PM, Rob Herring (Arm) wrote:
> > > Commit 32eea985999b ("ARM: dts: broadcom: bcm2835-rpi: Move non
> > > simple-bus nodes to root level") moved the firmware nodes into the
> > > standard /firmware. However, /firmware is intended to be just a
> > > container for firmware nodes as it is possible to have multiple types of
> > > firmware (e.g. SCMI, OP-TEE, etc.). Move the RPi firmware down a level.
> > >
> > > Fixes: 32eea985999b ("ARM: dts: broadcom: bcm2835-rpi: Move non
> > > simple-bus nodes to root level")
> > > Reported-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> > > Signed-off-by: Rob Herring (Arm) <robh@xxxxxxxxxx>
> > > ---
> > > This is only half the fix. Unfortunately, a kernel change[1] is also
> > > needed to make this all work. I do plan for that to go to stable. I'll
> > > leave it up to the Broadcom maintainers whether it's preferred to revert
> > > the fixed patches or apply these fixes. A 3rd option is revert for now
> > > and apply these DT changes some time later to give some time for stable
> > > updates.
> >
> > Let's wait until your fix for the /firmware match table gets applied
> > and then I will pick up your two changes.
>
>
> Florian: I've noticed that the $subject patch has been applied to
> yesterday's linux-next as commit 0603d8af97ff, but the code applied in
> Your tree differs from what has been posted in this thread. See:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi?h=next-20260318&id=0603d8af97fff097daa118faf04d9f439b2227ec
>
> https://lore.kernel.org/all/20260114015810.701076-2-robh@xxxxxxxxxx/
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/broadcom/bcm2835-rpi.dtsi?h=next-20260318
>
>
> The "firmware" node in Your tree is under "soc" node, but without adding
> a "compatible = simple-mfd;" property there it won't be populated, what
> breaks operation of all drivers requiring the firmware driver(s).

Yes I see what happened here, Rob's patch is dependent upon 32eea985999b 
which I had initially applied then dropped, and then I did not (re)apply 
it again as a prerequisite for that one we are replying to and I 
incorrectly resolved the conflict as a result. It should have been clear 
that no conflict resolution should have been necessary, *sigh*.

This is now fixed and pushed out, sorry about that, definitively a 
sloppy move here.

Will let that simmer in linux-next for a day and then sent out the pull 
requests.

Thanks again Marek for catching this, my test rack does not currently 
have a working RPi system, something to address.
--
Florian