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

[Florian Fainelli <florian.fainelli@broadcom.com>]

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@samsung.com>
>>> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
>>> ---
>>> 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@kernel.org/
> 
> 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