[PATCH V2 1/2] dt-bindings: serial: add Broadcom's BCMBCA family High Speed UART
Florian Fainelli
florian.fainelli at broadcom.com
Wed Nov 22 11:28:10 PST 2023
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 at linaro.org>
>
Thanks.
--
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231122/a1eae5bb/attachment.p7s>
More information about the linux-arm-kernel
mailing list