Trying to chime in here from the firmware development side of this issue to help clarify what Doug is asking for. We have the fundamental problem that we have several different board revisions that we _think_ should be 100% compatible for kernel and userspace, so for various practical reasons (easier to maintain in the source, limiting kernel image size by not having to bundle the same DTB multiple times under a different name), we want to use the same DTB for all of them. Just saying "well, you should treat each revision as incompatible to all the others from the start then" doesn't scale (we have a lot of revisions, and in the vast majority of cases they are just as compatible as we initially expect them to be). However, we also can't just exhaustively enumerate all revision numbers that are compatible with this DTB, because we don't know in advance how many we'll build. For again various practical reasons (bundling, signing, testing), it would cost a lot of extra effort and friction to rebuild a new kernel image just to add a new compatible string to the list every time the factory updates the revision number. An earlier hacky solution we had for this is to just define a bunch of extra revision compatible strings in advance even though they don't exist yet (e.g. you can still see this in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/tegra124-nyan-blaze.dts -- I believe there were only actually ever 3 or 4 Blaze revisions, the other compatible strings defined there never existed as physical boards). This is cumbersome and hacky and also doesn't really scale (particularly when we need to add SKU as another dimension into the string), so we needed to come up with something more manageable. Our solution is to use "google,lazor" as the stand-in compatible string for "all Lazor boards compatible with the latest revision". When a compatibility break happens at some point in the Lazor series (say between rev3 and rev4), we'll change the compatible string in the old rev3 DTB to no longer include "google,lazor" but to instead list all specific revision numbers ("google,lazor-rev0", ..., "google-lazor-rev3") exhaustively (at this point we can do it, because at this point we know we're not going to build any new boards compatible with that old layout in the future). The new rev4 DTB will then list "google,lazor" and again remain valid for all future revisions we build, until the next compatibility break. You are correct that this ends up changing the meaning of "google,lazor" at some point, but it's really the only good way I can see how to solve this within our practical constraints. I also don't really see a practical concern with that, since our firmware matching algorithm (and I believe this is the standard other bootloaders like U-Boot also follow) will look for the more specific string with the explicit revision number first, before falling back to the generic one. So whenever we decide to change the meaning of the latter in the kernel, we also make sure to provide matches for all the specific revisions that previously used the generic match, so that they will pick up those instead and there's no chance of them getting confused by the change in meaning. While it is perhaps a bit unorthodox, I think it is practical, safe, and I don't really see a practical alternative for our use case.
