| Message ID | 20220513105850.310375-3-herve.codina@bootlin.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | Microchip LAN966x USB device support | expand |
On 13/05/2022 12:58, Herve Codina wrote: > The USB device controller available in the Microchip LAN966x SOC > is the same IP as the one present in the SAMA5D3 SOC. > > Add the LAN966x compatible string and set the SAMA5D3 compatible > string as a fallback for the LAN966x. > > Signed-off-by: Herve Codina <herve.codina@bootlin.com> > --- > Documentation/devicetree/bindings/usb/atmel-usb.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt > index f512f0290728..a6fab7d63f37 100644 > --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt > +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt > @@ -87,6 +87,9 @@ Required properties: > "atmel,at91sam9g45-udc" > "atmel,sama5d3-udc" > "microchip,sam9x60-udc" > + "microchip,lan996x-udc" No wildcards please, especially that it closely fits previous wildcard (lan996x includes lan9960 which looks a lot like sam9x60...) Best regards, Krzysztof
On Fri, 13 May 2022 14:57:55 +0200 Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > On 13/05/2022 12:58, Herve Codina wrote: > > The USB device controller available in the Microchip LAN966x SOC > > is the same IP as the one present in the SAMA5D3 SOC. > > > > Add the LAN966x compatible string and set the SAMA5D3 compatible > > string as a fallback for the LAN966x. > > > > Signed-off-by: Herve Codina <herve.codina@bootlin.com> > > --- > > Documentation/devicetree/bindings/usb/atmel-usb.txt | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt > > index f512f0290728..a6fab7d63f37 100644 > > --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt > > +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt > > @@ -87,6 +87,9 @@ Required properties: > > "atmel,at91sam9g45-udc" > > "atmel,sama5d3-udc" > > "microchip,sam9x60-udc" > > + "microchip,lan996x-udc" > > No wildcards please, especially that it closely fits previous wildcard > (lan996x includes lan9960 which looks a lot like sam9x60...) > Well, first, I made a mistake. It should be lan966x instead of lan996x. This family is composed of the LAN9662 and the LAN9668 SOCs. Related to the wilcard, lan966x is used in several bindings for common parts used by both SOCs: - microchip,lan966x-gck - microchip,lan966x-cpu-syscon - microchip,lan966x-switch - microchip,lan966x-miim - microchip,lan966x-serdes - microchip,lan966x-pinctrl 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. Regards, Hervé > > Best regards, > Krzysztof
On 20/05/2022 13:34, Herve Codina wrote: > On Fri, 13 May 2022 14:57:55 +0200 > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > >> On 13/05/2022 12:58, Herve Codina wrote: >>> The USB device controller available in the Microchip LAN966x SOC >>> is the same IP as the one present in the SAMA5D3 SOC. >>> >>> Add the LAN966x compatible string and set the SAMA5D3 compatible >>> string as a fallback for the LAN966x. >>> >>> Signed-off-by: Herve Codina <herve.codina@bootlin.com> >>> --- >>> Documentation/devicetree/bindings/usb/atmel-usb.txt | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt >>> index f512f0290728..a6fab7d63f37 100644 >>> --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt >>> +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt >>> @@ -87,6 +87,9 @@ Required properties: >>> "atmel,at91sam9g45-udc" >>> "atmel,sama5d3-udc" >>> "microchip,sam9x60-udc" >>> + "microchip,lan996x-udc" >> >> No wildcards please, especially that it closely fits previous wildcard >> (lan996x includes lan9960 which looks a lot like sam9x60...) >> > > Well, first, I made a mistake. It should be lan966x instead of lan996x. > > This family is composed of the LAN9662 and the LAN9668 SOCs. > > Related to the wilcard, lan966x is used in several bindings for common > parts used by both SOCs: > - microchip,lan966x-gck > - microchip,lan966x-cpu-syscon > - microchip,lan966x-switch > - microchip,lan966x-miim > - microchip,lan966x-serdes > - microchip,lan966x-pinctrl And for new bindings I pointed that it is not preferred, so already few other started using specific compatible. > > 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... Best regards, Krzysztof
Hi Krzysztof, On Fri, 20 May 2022 13:40:13 +0200 Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > On 20/05/2022 13:34, Herve Codina wrote: > > On Fri, 13 May 2022 14:57:55 +0200 > > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > > >> On 13/05/2022 12:58, Herve Codina wrote: > >>> The USB device controller available in the Microchip LAN966x SOC > >>> is the same IP as the one present in the SAMA5D3 SOC. > >>> > >>> Add the LAN966x compatible string and set the SAMA5D3 compatible > >>> string as a fallback for the LAN966x. > >>> > >>> Signed-off-by: Herve Codina <herve.codina@bootlin.com> > >>> --- > >>> Documentation/devicetree/bindings/usb/atmel-usb.txt | 3 +++ > >>> 1 file changed, 3 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt > >>> index f512f0290728..a6fab7d63f37 100644 > >>> --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt > >>> +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt > >>> @@ -87,6 +87,9 @@ Required properties: > >>> "atmel,at91sam9g45-udc" > >>> "atmel,sama5d3-udc" > >>> "microchip,sam9x60-udc" > >>> + "microchip,lan996x-udc" > >> > >> No wildcards please, especially that it closely fits previous wildcard > >> (lan996x includes lan9960 which looks a lot like sam9x60...) > >> > > > > Well, first, I made a mistake. It should be lan966x instead of lan996x. > > > > This family is composed of the LAN9662 and the LAN9668 SOCs. > > > > Related to the wilcard, lan966x is used in several bindings for common > > parts used by both SOCs: > > - microchip,lan966x-gck > > - microchip,lan966x-cpu-syscon > > - microchip,lan966x-switch > > - microchip,lan966x-miim > > - microchip,lan966x-serdes > > - microchip,lan966x-pinctrl > > And for new bindings I pointed that it is not preferred, so already few > other started using specific compatible. > > > > > 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 (1) https://lore.kernel.org/all/20211004105926.5696-1-kavyasree.kotagiri@microchip.com/ Regards, Herve
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. Best regards, Krzysztof
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". Regards, Hervé
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
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.
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
Hi Alexandre, On Fri, 20 May 2022 15:52:22 +0200 Alexandre Belloni <alexandre.belloni@bootlin.com> 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. > Sounds good. I will do that. Thanks, Hervé
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt index f512f0290728..a6fab7d63f37 100644 --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt @@ -87,6 +87,9 @@ Required properties: "atmel,at91sam9g45-udc" "atmel,sama5d3-udc" "microchip,sam9x60-udc" + "microchip,lan996x-udc" + For "microchip,lan996x-udc", the fallback "atmel,sama5d3-udc" + is required. - reg: Address and length of the register set for the device - interrupts: Should contain usba interrupt - clocks: Should reference the peripheral and host clocks
The USB device controller available in the Microchip LAN966x SOC is the same IP as the one present in the SAMA5D3 SOC. Add the LAN966x compatible string and set the SAMA5D3 compatible string as a fallback for the LAN966x. Signed-off-by: Herve Codina <herve.codina@bootlin.com> --- Documentation/devicetree/bindings/usb/atmel-usb.txt | 3 +++ 1 file changed, 3 insertions(+)