> Wait, we agreed that you don't consider them identical, didn't we? If > they are identical, you do not need rev4 at all. So they are not > identical... Well, they are identical until they're not. We intend them to be identical. But for practical purposes it does sometimes happen that two board revisions which were meant to be indistinguishable by software end up needing to be distinguished at a later point, when both the hardware and firmware can no longer be changed. We need to allow an escape hatch for that case. It does not happen often, so just treating them all as separate boards from the start is not a scalable solution. DTBs are not free when they all need to be packaged in the same kernel image. > Right now it's not possible to validate QCOM DTSes against DT bindings > because they throw big fat warnings about undocumented top compatibles. > This is a downside for us. But that's a solvable problem, right? As I understand, what Doug was initially just asking was whether it made _sense_ to document all of these... not that we couldn't do it. Then this whole thread went down a rabbit hole of whether our compatible assignments are allowed in the first place. If we can compromise on this discussion by just doing whatever needs to be done to make the tool happy, I think(?) we can provide that. > Remember, you do not have to use Devicetree or Linux at all if it causes > you some downsides... No one is forced. :) If you choose to use it, > sorry, it comes with some requirements like being following Devicetree > specification or the binding guidelines. Woah... that is maybe a bit extreme, don't you think? My understanding was that Linux tries to support a wide variety of platforms and devices and can make the necessary compromises where needed to stay practical. I'm sure you are aware of the numerous hacks, workarounds and special cases throughout the kernel that enthusiasts put in there to get their favorite platform working, even if the original manufacturer never bothered to test with anything but Windows and blatantly violates common standards. Or how the USB stack has a file listing custom quirks for hundreds of individual device IDs just to make hardware work that didn't put any effort into following the spec. We're not even asking for any of that -- we're here, engaging with you and trying to find the best way for our platforms to fit cleanly into your model. All we're asking is to please offer some way that makes accommodations for the necessary practical concerns that come up when building devices at our scale. We're open for new suggestions, but they need to stay within the realm of what we can practically do (e.g. not ship a wholly separate DTB for each board revision, because that would grow the kernel image beyond what can fit in the kernel partitions on our platforms, and would create a notable extra cost in boot time for our users). Besides, I don't actually see how this violates the Device Tree specification? All I see it say about the toplevel compatible property is that it > Specifies a list of platform architectures with which this platform is compatible. This property can be used by operating systems in selecting platform specific code. It doesn't say anything about having to uniquely identify the platform architecture even if a more generic identifier is good enough to make all necessary platform-specific code choices for the operating system. In fact, about compatible properties in general the specification says > The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. Which implies that using a more generic string to cover multiple cases at once is an intentionally allowed use case.
