Re: [PATCH V2 1/2] dt-bindings: serial: add Broadcom's BCMBCA family High Speed UART

[Florian Fainelli <florian.fainelli@broadcom.com>]

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

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@linaro.org>
> 

Thanks.
-- 
Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]