Hi,
On Tue, Dec 2, 2025 at 1:58 PM Julius Werner jwerner@chromium.org wrote:
Is there really a need to merge the compatible strings in your case?
Well, you could just require duplicating an overlay N times for N bases, but that doesn't scale
I think my question was more along the lines of "is there actually a reason why the combined compatible string needs to be that accurate" (i.e. contain the right "socvendor,mysoc-rev1" or "socvendor,mysoc-rev2"). What is the purpose of having that string in there?
Yes, this matches what I just sent in several of my replies. What exactly is the top-level compatible supposed to represent? I think different people have different ideas. Is it documented somewhere? I guess I could start a new thread to solve just this one question, though I suspect not everyone (not even core DT folks) will agree. If they don't, how do we solve that? Who is "the decider"?
It wouldn't be used for matching which DTB(O) to load in this case because we're already past that step. It's not used by the kernel directly for anything as far as I know.
It has _sometimes_ been used by the Linux kernel. Specifically the fact that the SoC is represented in the top-level compatible is used to "blocklist" the generic cpufreq driver (drivers/cpufreq/cpufreq-dt-platdev.c). I've never loved this, but it is an example.
Occasionally, I have also seen random software workarounds that rely on the top-level string. See Linux commit 127068abe85b ("i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630"), which added:
+ if (!of_machine_is_compatible("lenovo,yoga-c630")) + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
...that's been since removed, but it's one example I can think of where the top-level string was temporarily relied upon.
There are certainly lots of hits for `of_machine_is_compatible()` in Linux today. I don't know if these are all for good reasons, but they are examples of people relying on it. In my experience it's mostly used for things that are a bit hacky, to avoid an unexplained bug, or to work around the fact that someone didn't add a specific enough compatible string somewhere else in the device tree.
Is it used by userspace programs which parse /proc/device-tree/compatible in order to detect which SoC revision they're running on? Because that's the only use case I could think of that really remains, but I'd argue that the compatible string is a pretty poor vehicle for things like that
Agreed. This type of thing has always been broken on Chromebooks which have more than one revision/sku listed since a single device tree works on more than one device. We had long arguments about this in the past and I think DT folks finally threw in the towel and let us land these, though I think they still don't really like it to this day.
(it would be easier to parse and use to just put a `soc-revision = <1>` property somewhere). So if this is the only problem I'd say maybe just don't use the board compatible string for that, don't expect to be able to find such details in there accurately. But if we do think it needs to be that accurate for some reason, then I'd suggest platforms like this (which should be rather few, e.g. only those that really have a socketable SoC with differentiations that are so compatible that other than this identification information itself it doesn't require any device tree differences) should simply have their bootloaders rewrite the compatible string into the right format with all the necessary information manually, rather than expect the overlay application process to create it correctly.
Yeah, trying to stuff the world into the top-level compatible never seemed amazing to me. Given that today's advice is to have a top-level `soc@0` node, IMO SoC-specific details ought to be under that. This is something that Stephen Boyd suggested a while ago but it never gained traction.
I also don't see a sensible way without something like the above for a boot loader to know the filenames of each of the components for a platform - and it would need to be told the order to glue those components together.
I think platform identification and matching which overlays to apply should remain outside the scope of the device tree itself. The main reason is that you usually want to compress DTB(O) files for efficiency, and when you have a large list of overlays in a kernel image you don't want to have to decompress them all just to determine which ones to load for the current platform. So I think it's generally better to let bootloaders come up with their own scheme to store this information inside their file systems or whatever other data structures they use to find these DTB(O) files.
IMO it's still nice to be able to store some of the metadata that the loader will use in the overlay files, just so we don't need a parallel set of files. The current Android way of doing things is that the metadata in the "dtbo" is parsed by the packaging tool (`mktdimg`) and that creates the tables that the bootloader needs. This seems reasonable, even though I'll argue that the metadata needs to be documented under a specific node (one for `mkdtimg`). I wouldn't want to have to maintain a separate file mapping overlays to their metadata.
-Doug