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

[Gregor Herburger]

On Mon, Aug 10, 2026 at 09:19:35AM +0200, Krzysztof Kozlowski wrote:
> On Wed, Aug 05, 2026 at 02:52:44PM +0200, Gregor Herburger wrote:
> > 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
> 
> Different SoC means different SoC-compatible. If the soc is soldered to
> the board, then it also means board is different. Otherwise how can it
> be the same board if it comes with different elements?
That makes perfect sense. Thanks for the explanation. I will add a board
compatible and a SoC compatible.
> 
> Of course boards can share schematics and everything except some
> component so you could have common compatible.
> 
> 1. Rpi 5b d0
> 2. Rpi 5b
> 3. bcm2712-d0
> 

But I don't think that should be done here. As you explained in the previous
iteration [0] we shouldn't add a non-compatible fallback.

> > 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].
> 
> 
> If systemd-boot is not following established for 10 years DT practices
> that systemd-boot's fault, not something to be fixed in DT.

I don't think systemd-boot isn't following these practices. I just wanted to
explain what was the problem for me, and why I wanted to solve it.
> 
> But anyway I did not hear anyone adding/using wrong or fake compatibles
> to satisfy systemd-boot for other hardware.
> 
> Best regards,
> Krzysztof
> 
Best regards,
Gregor

[0] https://lore.kernel.org/all/20260804-unbeatable-fluffy-galago-bfe282@quoll/