lkml.org 
[lkml]   [2022]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 2/3] dt-bindings: usb: atmel: Add Microchip LAN966x compatible string
    From
    On 20/05/2022 15:02, Herve Codina wrote:
    > On Fri, 20 May 2022 14:50:24 +0200
    > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
    >
    >> On 20/05/2022 14:21, Herve Codina wrote:
    >>>>> I think it makes sense to keep 'microchip,lan966x-udc' for the USB
    >>>>> device controller (same controller on LAN9662 and LAN9668) and so
    >>>>> keeping the same rules as for other common parts.
    >>>>
    >>>> Having wildcard was rather a mistake and we already started correcting
    >>>> it, so keeping the "mistake" neither gives you consistency, nor
    >>>> correctness...
    >>>>
    >>>
    >>> I think that the "family" compatible should be present.
    >>> This one allows to define the common parts in the common
    >>> .dtsi file (lan966x.dtsi in our case).
    >>>
    >>> What do you think about:
    >>> - microchip,lan9662-udc
    >>> - microchip,lan9668-udc
    >>> - microchip,lan966-udc <-- Family
    >>>
    >>> lan966 is defined as the family compatible string since (1) in
    >>> bindings/arm/atmel-at91.yaml and in Documentation/arm/microchip.rst
    >>>
    >>
    >> You can add some family compatible, if it makes sense. I don't get why
    >> do you mention it - we did not discuss family names, but using
    >> wildcards... Just please do not add wildcards.
    >
    > Well, I mentioned it as I will only use the family compatible string
    > and not the SOC (lan9662 or lan9668) compatible string in lan966x.dtsi.
    > In this case, the family compatible string can be seen as a kind of
    > "wildcard".

    I understood as "the "family" compatible should be present" as you want
    to add it as a fallback. It would be okay (assuming devices indeed share
    family design). If you want to use it as the only one, then it is again
    not a recommended approach. Please use specific compatibles.

    I mean, why do we have this discussion? What is the benefit for you to
    implement something not-recommended by Devicetree spec and style?

    Best regards,
    Krzysztof

    \
     
     \ /
      Last update: 2022-05-20 15:39    [W:3.487 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site