On 8.06.2024 15:06, Stanislav Jakubek wrote:
To make development for both platforms easier, split out the common
nodes into a separate DTSI, bcm21664-common.dtsi. This only leaves
the device-specific nodes - so, CPU and related things - in the SoC-
specific DTSIs (bcm21664.dtsi and bcm23550.dtsi).
The name "bcm21664-common" makes me think that it's a DTSI for common
properties of multiple BCM21664 *board* DTs, which is obviously not the
case here. IMO something like "bcm21664-bcm23550-common" makes more sense here.
The "bcm21664-common" name sounds fine to me, though I can certainly see
how it could be interpreted as a board DTSI (I was planning to make a
bcm21664-samsung-common.dtsi for Samsung's BCM21664-based phones, funny
enough...)
The idea of just putting together the two model numbers sounded a bit
awkward to me at first, but I've been thinking about it and I'm starting
to warm up to it. There are a handful of examples of a similar double-
naming scheme: e.g. intel-ixp45x-ixp46x.dtsi, sunxi-h3-h5.dtsi, sun8i-
a23-a33.dtsi. The difference is that these DTSIs have a manufacturer
prefix and no "-common" suffix.
I had many ideas for naming the common DTSI. My initial idea was
"bcm216xx.dtsi", but that would cover the BCM21654 (which has a few more
differences); then "bcm2166x.dtsi" which would cover the BCM21663 and
BCM21664 (which AFAIK are largely the same). We could combine it with
the current name and get "bcm2166x-common.dtsi". That already sounds
less like a board file to me, what do you think?
It's worth noting though that some bcm23550 compatibles now go unused,
since the bcm21664-common.dtsi file uses bcm21664 compatibles.
I don't think this is the way to go. While in these cases the Linux drivers
match only on the generic brcm,kona-* fallback compatible (AFAIK anyway),
the compatibles in DT should still be (SoC-)specific.
I think the common DTSI should omit the compatible values altogether
and instead have the compatible be specified in SoC DTSI. You could keep
a note in the common DTSI saying that the compatible is in SoC DTSI or
something similar.
There's plenty of DTSIs in the kernel that have "device-specific"
compatibles in common DTSIs. Off the top of my head I can name the
Exynos 4 DTSIs that do this pretty often[1][2][3] (4210 and 4212
compatibles in DTSIs that are later included from the 4412 DTSI, but
which does not override any of them).
While looking around for examples I stumbled upon some sunxi DTSIs that
actually do *both*: have some compatibles that mention one of the two
models they cover, but leave some compatibles to be set in the child
DTSIs[4][5].
Since as I mentioned the underlying components seem to be the exact
same, the compatibles are really just cosmetic; plus I feel like lots of
such compatible-only nodes could add unnecessary noise to the SoC DTSIs.
With that said, I'm not against the idea, and I suppose it's not too
much extra work. I'm curious what other reviewers will have to say, but
either way I'll try to incorporate this into the next version of this
patchset.
Best regards
Artur
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/samsung/exynos4.dtsi
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/samsung/exynos4x12.dtsi
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/samsung/exynos4412.dtsi
[4]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/allwinner/sunxi-h3-h5.dtsi
[5]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/allwinner/sun8i-a23-a33.dtsi
