[PATCH v3 2/2] arm64: dts: broadcom: bcm2712-d-rpi-5-b: add compatible

[Gregor Herburger]

Hi Stefan,
On Wed, Aug 05, 2026 at 01:55:50PM +0200, Stefan Wahren wrote:
> Hi Gregor,
> 
> drop Eric and add Peter.
> 
> Am 05.08.26 um 09:27 schrieb Gregor Herburger:
> > On Tue, Aug 04, 2026 at 04:57:09PM +0200, Stefan Wahren wrote:
> > > Hi Gregor,
> > > 
> > > sorry for my late reply.
> > > 
> > > Am 04.08.26 um 15:13 schrieb Gregor Herburger:
> > > > The bcm2712 found on the Raspberry Pi 5 is available in the d Stepping
> > > > and in a c Stepping. There are two separate dts files. The
> > > > bcm2712-rpi-5-b.dts for the c Stepping and the bcm2712-d-rpi-5-b.dts for
> > > > the d Stepping. The d stepping does not set its own compatible/model
> > > > string but uses "raspberrypi,5-model-b".
> > > In case the SoC and not the board has a D stepping, why do just change the
> > > board compatible without the SoC compatible like "brcm,bcm2712-d0"?
> > You mean changing both compatible strings? Like this:
> > 	compatible = "raspberrypi,5-model-b-d0", "brcm,bcm2712-d0";
> I just want to mention that your explanation doesn't match to your changes.
> The first compatible represent the whole board (RPi 5) and the second one
> represent only the SoC (BCM2712). Since the SoC is different according your
> explanation, i would expect the SoC compatible needs to be changed. And in
> case the SoC changes, also the board won't be compatible anymore, correct?
Yes the SoC differs in these two versions and the board is maybe the same (but
not compatible). Compatible strings should go from most specific to most general
[0]. If we would have the same first string for both steppings it wouldn't be
distinguishable. So at least the first string must be unique.

E.g systemd-boot only matches the first compatible string [1].

The only example I found for SoC steppings in the tree is the
'marvell,rd88f6281-a' and 'marvell,rd88f6281-z0'.
Although these dts are from 2014 and I don't know if this is still the current
best practice.
> 
> Usually we try to avoid to model different SoC steppings in the device tree,
> because this introduce a lot of redundancy. But it seems that the
> differences are signifcant here.
Yes but here we are with two devicetrees which are not compatible.
> 
> In case this suggestion break something, this needs further explanation in
> the patch.
I can update the commit message if it is not clear enough.
> 
> Best regards


[0] https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter2-devicetree-basics.rst#compatible
[1] https://github.com/systemd/systemd/blob/main/src/boot/devicetree.c#L182

-- 
Gregor Herburger
Linutronix GmbH | Bahnhofstrasse 3 | D-88690 Uhldingen-Mühlhofen
Phone: +49 7556 25 999 35; Fax.: +49 7556 25 999 99

Hinweise zum Datenschutz finden Sie hier (Informations on data privacy 
can be found here): https://linutronix.de/legal/data-protection.php

Linutronix GmbH | Firmensitz (Registered Office): Uhldingen-Mühlhofen | 
Registergericht (Registration Court): Amtsgericht Freiburg i.Br., HRB700 
806 | Geschäftsführer (Managing Directors): Dr. Wilfried Wessner, 
Katharina Kopp, Alexander Gieringer