quoted
So if the silicon and the DT disagree, you get -ENODEV or similar?
That is what i would recommend, so that broken DT blobs get found by
the developer.
I'm personally not a big fan of this kind of thing, as it prevents using
fallbacks for new devices when done strictly. I only really like it
being done this way if the driver does not produce errors for unknown
part numbers, only if (using this case as an example) a b device is
labeled as a non-b, or vice-versa. IOW, if the driver doesn't recognise
the ID, believe what's in DT.
The issue we have seen in the past when not strictly checking the
compatible against the hardware, is that a number of DT blob ship with
the wrong compatible. Then sometime later you find you need to key
some feature off the compatible, but you cannot without breaking all
those devices which have the wrong compatible.
In order to be able to use the compatible, it has to be correct.
Andrew