Howdy, On 11/22/2023 10:56 AM, Krzysztof Kozlowski wrote:
What is xx? Wildcard? I mean... ehhh...OK, it's not worth my time. Neither Rafał's.
Let me start of that I do get your point, but I also get William's.If you are going to use this email thread as proof that people should not use wildcards or families in compatible strings, this is very much worth everyone's time so we can actually detail better why that is an issue. So far it has been described as an inadequate description of the hardware which is somewhat fair, but subjective as well.
The point of the fallback is precisely to express that the various HW IP versions have a similar programming model and that unless specified otherwise by a more descriptive compatible string, the driver can make that assumption. This is entirely within the spirit of the DT spec:
"""The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. 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 """we simply differ from the recommendation, which is a recommendation, meaning deviation is allowed, and even that is entirely subjective:
"""The recommended format is "manufacturer,model", where manufacturer is a string describing the name of the manufacturer (such as a stock ticker symbol), and model specifies the model number.
""that kind of fits in. I suppose that if we like to paint ourselves in a corner that allows us to simplify the logistics of maintaining our platforms' DTS and drivers without bending the specification we should be allowed to. How does that make your job as a DT maintainer any harder?
I do not disagree that identifying the oldest SoC that featured the specific block is best, but it may not always be that simple or that descriptive either.
There are a lot more properties and compatibles that are IMHO bending the Device Tree to describe how they *intend* to get the HW configured by the client program, and fall backs are really not amongst them IMHO.
Anyway.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
Thanks. -- Florian
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
