All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Herve Codina <herve.codina@bootlin.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Claudiu Beznea <claudiu.beznea@microchip.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Horatiu Vultur <horatiu.vultur@microchip.com>,
	linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 2/3] dt-bindings: usb: atmel: Add Microchip LAN966x compatible string
Date: Fri, 20 May 2022 16:05:07 +0200	[thread overview]
Message-ID: <862862a6-afde-234a-ccb1-d3781d867775@linaro.org> (raw)
In-Reply-To: <YoedFkAsTdoOn/3Y@mail.local>

On 20/05/2022 15:52, Alexandre Belloni wrote:
> Hello,
> 
> On 20/05/2022 15:38:36+0200, Krzysztof Kozlowski wrote:
>> 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?
>>
> 
> Honestly, I would just go for microchip,lan9662-udc. There is no
> difference between lan9662 and lan9668 apart from the number of switch
> ports.

Thank you, and maybe that was misunderstanding - I do not propose to add
additional lan9668 compatible, if it is not actually needed.


Best regards,
Krzysztof

WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
	Herve Codina <herve.codina@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Michael Turquette <mturquette@baylibre.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Horatiu Vultur <horatiu.vultur@microchip.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Claudiu Beznea <claudiu.beznea@microchip.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/3] dt-bindings: usb: atmel: Add Microchip LAN966x compatible string
Date: Fri, 20 May 2022 16:05:07 +0200	[thread overview]
Message-ID: <862862a6-afde-234a-ccb1-d3781d867775@linaro.org> (raw)
In-Reply-To: <YoedFkAsTdoOn/3Y@mail.local>

On 20/05/2022 15:52, Alexandre Belloni wrote:
> Hello,
> 
> On 20/05/2022 15:38:36+0200, Krzysztof Kozlowski wrote:
>> 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?
>>
> 
> Honestly, I would just go for microchip,lan9662-udc. There is no
> difference between lan9662 and lan9668 apart from the number of switch
> ports.

Thank you, and maybe that was misunderstanding - I do not propose to add
additional lan9668 compatible, if it is not actually needed.


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-05-20 14:05 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-13 10:58 [PATCH 0/3] Microchip LAN966x USB device support Herve Codina
2022-05-13 10:58 ` Herve Codina
2022-05-13 10:58 ` [PATCH 1/3] clk: lan966x: Fix the lan966x clock gate register address Herve Codina
2022-05-13 10:58   ` Herve Codina
2022-05-13 10:58 ` [PATCH 2/3] dt-bindings: usb: atmel: Add Microchip LAN966x compatible string Herve Codina
2022-05-13 10:58   ` Herve Codina
2022-05-13 12:57   ` Krzysztof Kozlowski
2022-05-13 12:57     ` Krzysztof Kozlowski
2022-05-20 11:34     ` Herve Codina
2022-05-20 11:34       ` Herve Codina
2022-05-20 11:40       ` Krzysztof Kozlowski
2022-05-20 11:40         ` Krzysztof Kozlowski
2022-05-20 12:21         ` Herve Codina
2022-05-20 12:21           ` Herve Codina
2022-05-20 12:50           ` Krzysztof Kozlowski
2022-05-20 12:50             ` Krzysztof Kozlowski
2022-05-20 13:02             ` Herve Codina
2022-05-20 13:02               ` Herve Codina
2022-05-20 13:38               ` Krzysztof Kozlowski
2022-05-20 13:38                 ` Krzysztof Kozlowski
2022-05-20 13:52                 ` Alexandre Belloni
2022-05-20 13:52                   ` Alexandre Belloni
2022-05-20 14:05                   ` Krzysztof Kozlowski [this message]
2022-05-20 14:05                     ` Krzysztof Kozlowski
2022-05-20 14:12                   ` Herve Codina
2022-05-20 14:12                     ` Herve Codina
2022-05-13 10:58 ` [PATCH 3/3] ARM: dts: lan966x: Add UDPHS support Herve Codina
2022-05-13 10:58   ` Herve Codina
2022-05-13 12:54   ` Krzysztof Kozlowski
2022-05-13 12:54     ` Krzysztof Kozlowski
2022-05-20 12:37     ` Herve Codina
2022-05-20 12:37       ` Herve Codina
2022-05-20 12:48       ` Krzysztof Kozlowski
2022-05-20 12:48         ` Krzysztof Kozlowski
2022-05-14  9:35   ` Sergei Shtylyov
2022-05-14  9:35     ` Sergei Shtylyov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=862862a6-afde-234a-ccb1-d3781d867775@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=claudiu.beznea@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=herve.codina@bootlin.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=nicolas.ferre@microchip.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.