| Message ID | 20230222183932.33267-8-arinc.unal@arinc9.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | pinctrl: ralink: fix ABI, improve driver, move to mediatek, improve dt-bindings | expand |
On Wed, Feb 22, 2023 at 09:39:23PM +0300, arinc9.unal@gmail.com wrote: > From: Arınç ÜNAL <arinc.unal@arinc9.com> > > Add the ralink,rt2880-pinmux compatible string. It had been removed from > the driver which broke the ABI. > > Add the mediatek compatible strings. Change the compatible string on the > examples with the mediatek compatible strings. > > Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> > --- > .../devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml | 7 +++++-- > .../devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml | 7 +++++-- > .../devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml | 7 +++++-- > .../devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml | 7 +++++-- > .../devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml | 7 +++++-- > 5 files changed, 25 insertions(+), 10 deletions(-) > > diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml > index 1e63ea34146a..531b5f616c3d 100644 > --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml > +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml > @@ -17,7 +17,10 @@ description: > > properties: > compatible: > - const: ralink,mt7620-pinctrl > + enum: > + - mediatek,mt7620-pinctrl > + - ralink,mt7620-pinctrl We don't update compatible strings based on acquistions nor marketing whims. If you want to use 'mediatek' for new things, then fine. Rob
On 27/02/2023 20:33, Rob Herring wrote: > On Wed, Feb 22, 2023 at 09:39:23PM +0300, arinc9.unal@gmail.com wrote: >> From: Arınç ÜNAL <arinc.unal@arinc9.com> >> >> Add the ralink,rt2880-pinmux compatible string. It had been removed from >> the driver which broke the ABI. >> >> Add the mediatek compatible strings. Change the compatible string on the >> examples with the mediatek compatible strings. >> >> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> >> --- >> .../devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml | 7 +++++-- >> .../devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml | 7 +++++-- >> .../devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml | 7 +++++-- >> .../devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml | 7 +++++-- >> .../devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml | 7 +++++-- >> 5 files changed, 25 insertions(+), 10 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >> index 1e63ea34146a..531b5f616c3d 100644 >> --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >> +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >> @@ -17,7 +17,10 @@ description: >> >> properties: >> compatible: >> - const: ralink,mt7620-pinctrl >> + enum: >> + - mediatek,mt7620-pinctrl >> + - ralink,mt7620-pinctrl > > We don't update compatible strings based on acquistions nor marketing > whims. If you want to use 'mediatek' for new things, then fine. Understood. Only the SoCs with rtXXXX were rebranded, the mtXXXX SoCs share the same architecture from Ralink, so they were incorrectly called Ralink SoCs. I can remove the new strings from Ralink SoCs and add them only for MediaTek SoCs. Or you could make an exception for this one, regarding the situation. Whatever you think is best. Arınç
On Tue, Feb 28, 2023 at 07:46:36PM +0300, Arınç ÜNAL wrote: > On 27/02/2023 20:33, Rob Herring wrote: > > On Wed, Feb 22, 2023 at 09:39:23PM +0300, arinc9.unal@gmail.com wrote: > > > From: Arınç ÜNAL <arinc.unal@arinc9.com> > > > > > > Add the ralink,rt2880-pinmux compatible string. It had been removed from > > > the driver which broke the ABI. > > > > > > Add the mediatek compatible strings. Change the compatible string on the > > > examples with the mediatek compatible strings. > > > > > > Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> > > > --- > > > .../devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml | 7 +++++-- > > > .../devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml | 7 +++++-- > > > .../devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml | 7 +++++-- > > > .../devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml | 7 +++++-- > > > .../devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml | 7 +++++-- > > > 5 files changed, 25 insertions(+), 10 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml > > > index 1e63ea34146a..531b5f616c3d 100644 > > > --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml > > > +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml > > > @@ -17,7 +17,10 @@ description: > > > properties: > > > compatible: > > > - const: ralink,mt7620-pinctrl > > > + enum: > > > + - mediatek,mt7620-pinctrl > > > + - ralink,mt7620-pinctrl > > > > We don't update compatible strings based on acquistions nor marketing > > whims. If you want to use 'mediatek' for new things, then fine. > > Understood. Only the SoCs with rtXXXX were rebranded, the mtXXXX SoCs share > the same architecture from Ralink, so they were incorrectly called Ralink > SoCs. > > I can remove the new strings from Ralink SoCs and add them only for MediaTek > SoCs. Or you could make an exception for this one, regarding the situation. > Whatever you think is best. I'm not in a position to make an exception as I know little about this platform. Carrying both strings is a NAK. Either you (and everyone using these platforms) care about the ABI and are stuck with the "wrong" string. In the end, they are just unique identifiers. Or you don't care and break the ABI and rename everything. If you do that, do just that in your patches and make it crystal clear in the commit msg that is your intention and why that is okay. Rob
On 1.03.2023 05:44, Rob Herring wrote: > On Tue, Feb 28, 2023 at 07:46:36PM +0300, Arınç ÜNAL wrote: >> On 27/02/2023 20:33, Rob Herring wrote: >>> On Wed, Feb 22, 2023 at 09:39:23PM +0300, arinc9.unal@gmail.com wrote: >>>> From: Arınç ÜNAL <arinc.unal@arinc9.com> >>>> >>>> Add the ralink,rt2880-pinmux compatible string. It had been removed from >>>> the driver which broke the ABI. >>>> >>>> Add the mediatek compatible strings. Change the compatible string on the >>>> examples with the mediatek compatible strings. >>>> >>>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> >>>> --- >>>> .../devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml | 7 +++++-- >>>> .../devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml | 7 +++++-- >>>> .../devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml | 7 +++++-- >>>> .../devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml | 7 +++++-- >>>> .../devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml | 7 +++++-- >>>> 5 files changed, 25 insertions(+), 10 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>> index 1e63ea34146a..531b5f616c3d 100644 >>>> --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>> +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>> @@ -17,7 +17,10 @@ description: >>>> properties: >>>> compatible: >>>> - const: ralink,mt7620-pinctrl >>>> + enum: >>>> + - mediatek,mt7620-pinctrl >>>> + - ralink,mt7620-pinctrl >>> >>> We don't update compatible strings based on acquistions nor marketing >>> whims. If you want to use 'mediatek' for new things, then fine. >> >> Understood. Only the SoCs with rtXXXX were rebranded, the mtXXXX SoCs share >> the same architecture from Ralink, so they were incorrectly called Ralink >> SoCs. >> >> I can remove the new strings from Ralink SoCs and add them only for MediaTek >> SoCs. Or you could make an exception for this one, regarding the situation. >> Whatever you think is best. > > I'm not in a position to make an exception as I know little about this > platform. Carrying both strings is a NAK. Either you (and everyone using > these platforms) care about the ABI and are stuck with the "wrong" > string. In the end, they are just unique identifiers. Or you don't care > and break the ABI and rename everything. If you do that, do just that in > your patches and make it crystal clear in the commit msg that is your > intention and why that is okay. Ralink had their MIPS SoCs pre-acquisition, RT2880, etc. MediaTek introduced new SoCs post-acquisition, MT7620, MT7621, MT7628, and MT7688, utilising the same platform from Ralink, sharing the same architecture code, pinctrl core driver, etc. I don't intend to break the ABI at all. On the contrary, I fix it where possible. If I understand correctly, from this conversation and what Krzysztof said, all strings must be kept on the schemas so I can do what I said on the composed mail. Only match the pin muxing information on the strings that won't match multiple pin muxing information from other schemas. This way we don't break the ABI, introduce new compatible strings while keeping the remaining ones, and make schemas match correctly. Let me know if this is acceptable to you. Arınç
On 01/03/2023 09:15, Arınç ÜNAL wrote: > On 1.03.2023 05:44, Rob Herring wrote: >> On Tue, Feb 28, 2023 at 07:46:36PM +0300, Arınç ÜNAL wrote: >>> On 27/02/2023 20:33, Rob Herring wrote: >>>> On Wed, Feb 22, 2023 at 09:39:23PM +0300, arinc9.unal@gmail.com wrote: >>>>> From: Arınç ÜNAL <arinc.unal@arinc9.com> >>>>> >>>>> Add the ralink,rt2880-pinmux compatible string. It had been removed from >>>>> the driver which broke the ABI. >>>>> >>>>> Add the mediatek compatible strings. Change the compatible string on the >>>>> examples with the mediatek compatible strings. >>>>> >>>>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> >>>>> --- >>>>> .../devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml | 7 +++++-- >>>>> .../devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml | 7 +++++-- >>>>> .../devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml | 7 +++++-- >>>>> .../devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml | 7 +++++-- >>>>> .../devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml | 7 +++++-- >>>>> 5 files changed, 25 insertions(+), 10 deletions(-) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>> index 1e63ea34146a..531b5f616c3d 100644 >>>>> --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>> +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>> @@ -17,7 +17,10 @@ description: >>>>> properties: >>>>> compatible: >>>>> - const: ralink,mt7620-pinctrl >>>>> + enum: >>>>> + - mediatek,mt7620-pinctrl >>>>> + - ralink,mt7620-pinctrl >>>> >>>> We don't update compatible strings based on acquistions nor marketing >>>> whims. If you want to use 'mediatek' for new things, then fine. >>> >>> Understood. Only the SoCs with rtXXXX were rebranded, the mtXXXX SoCs share >>> the same architecture from Ralink, so they were incorrectly called Ralink >>> SoCs. >>> >>> I can remove the new strings from Ralink SoCs and add them only for MediaTek >>> SoCs. Or you could make an exception for this one, regarding the situation. >>> Whatever you think is best. >> >> I'm not in a position to make an exception as I know little about this >> platform. Carrying both strings is a NAK. Either you (and everyone using >> these platforms) care about the ABI and are stuck with the "wrong" >> string. In the end, they are just unique identifiers. Or you don't care >> and break the ABI and rename everything. If you do that, do just that in >> your patches and make it crystal clear in the commit msg that is your >> intention and why that is okay. > > Ralink had their MIPS SoCs pre-acquisition, RT2880, etc. MediaTek > introduced new SoCs post-acquisition, MT7620, MT7621, MT7628, and > MT7688, utilising the same platform from Ralink, sharing the same > architecture code, pinctrl core driver, etc. > > I don't intend to break the ABI at all. On the contrary, I fix it where > possible. > > If I understand correctly, from this conversation and what Krzysztof > said, all strings must be kept on the schemas so I can do what I said on > the composed mail. Only match the pin muxing information on the strings > that won't match multiple pin muxing information from other schemas. > > This way we don't break the ABI, introduce new compatible strings while > keeping the remaining ones, and make schemas match correctly. > > Let me know if this is acceptable to you. If by "introduce new compatible strings" you mean duplicate compatibles to fix the ralink->mediatek, then you ignored entire email from Rob - this and previous. We don't do this. Leave them as is. If you meant something else, explain more... Best regards, Krzysztof
On 2.03.2023 11:28, Krzysztof Kozlowski wrote: > On 01/03/2023 09:15, Arınç ÜNAL wrote: >> On 1.03.2023 05:44, Rob Herring wrote: >>> On Tue, Feb 28, 2023 at 07:46:36PM +0300, Arınç ÜNAL wrote: >>>> On 27/02/2023 20:33, Rob Herring wrote: >>>>> On Wed, Feb 22, 2023 at 09:39:23PM +0300, arinc9.unal@gmail.com wrote: >>>>>> From: Arınç ÜNAL <arinc.unal@arinc9.com> >>>>>> >>>>>> Add the ralink,rt2880-pinmux compatible string. It had been removed from >>>>>> the driver which broke the ABI. >>>>>> >>>>>> Add the mediatek compatible strings. Change the compatible string on the >>>>>> examples with the mediatek compatible strings. >>>>>> >>>>>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> >>>>>> --- >>>>>> .../devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml | 7 +++++-- >>>>>> .../devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml | 7 +++++-- >>>>>> .../devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml | 7 +++++-- >>>>>> .../devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml | 7 +++++-- >>>>>> .../devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml | 7 +++++-- >>>>>> 5 files changed, 25 insertions(+), 10 deletions(-) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>>> index 1e63ea34146a..531b5f616c3d 100644 >>>>>> --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>>> +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>>> @@ -17,7 +17,10 @@ description: >>>>>> properties: >>>>>> compatible: >>>>>> - const: ralink,mt7620-pinctrl >>>>>> + enum: >>>>>> + - mediatek,mt7620-pinctrl >>>>>> + - ralink,mt7620-pinctrl >>>>> >>>>> We don't update compatible strings based on acquistions nor marketing >>>>> whims. If you want to use 'mediatek' for new things, then fine. >>>> >>>> Understood. Only the SoCs with rtXXXX were rebranded, the mtXXXX SoCs share >>>> the same architecture from Ralink, so they were incorrectly called Ralink >>>> SoCs. >>>> >>>> I can remove the new strings from Ralink SoCs and add them only for MediaTek >>>> SoCs. Or you could make an exception for this one, regarding the situation. >>>> Whatever you think is best. >>> >>> I'm not in a position to make an exception as I know little about this >>> platform. Carrying both strings is a NAK. Either you (and everyone using >>> these platforms) care about the ABI and are stuck with the "wrong" >>> string. In the end, they are just unique identifiers. Or you don't care >>> and break the ABI and rename everything. If you do that, do just that in >>> your patches and make it crystal clear in the commit msg that is your >>> intention and why that is okay. >> >> Ralink had their MIPS SoCs pre-acquisition, RT2880, etc. MediaTek >> introduced new SoCs post-acquisition, MT7620, MT7621, MT7628, and >> MT7688, utilising the same platform from Ralink, sharing the same >> architecture code, pinctrl core driver, etc. >> >> I don't intend to break the ABI at all. On the contrary, I fix it where >> possible. >> >> If I understand correctly, from this conversation and what Krzysztof >> said, all strings must be kept on the schemas so I can do what I said on >> the composed mail. Only match the pin muxing information on the strings >> that won't match multiple pin muxing information from other schemas. >> >> This way we don't break the ABI, introduce new compatible strings while >> keeping the remaining ones, and make schemas match correctly. >> >> Let me know if this is acceptable to you. > > If by "introduce new compatible strings" you mean duplicate compatibles > to fix the ralink->mediatek, then you ignored entire email from Rob - > this and previous. We don't do this. Leave them as is. > > If you meant something else, explain more... Let me put them in a group to better explain. ## Fix ABI ralink,rt2880-pinmux was there before, it was removed which broke the ABI. I'm reintroducing it to fix it. ## New strings to be able to split bindings New strings are needed for MT7628/MT7688 and some RT SoCs to be able to properly document the pin muxing information. ## Incorrect naming MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, introduce new ralink->mediatek compatible strings to address it. ## Exception for RT SoCs to be called MediaTek This is where I was asking an exception to be made. Rob told us here they know little about the platform so I explained it. MediaTek acquired Ralink and then introduced new MediaTek SoCs utilising the same platform from Ralink. Anyway, now that I look at this again, it makes sense to me as well not to rename the Ralink SoCs. I'll call the RT SoCs Ralink on the kconfig, pinctrl driver, and dt-binding schemas on my next version. Arınç
On 02/03/2023 10:17, Arınç ÜNAL wrote: > On 2.03.2023 11:28, Krzysztof Kozlowski wrote: >> On 01/03/2023 09:15, Arınç ÜNAL wrote: >>> On 1.03.2023 05:44, Rob Herring wrote: >>>> On Tue, Feb 28, 2023 at 07:46:36PM +0300, Arınç ÜNAL wrote: >>>>> On 27/02/2023 20:33, Rob Herring wrote: >>>>>> On Wed, Feb 22, 2023 at 09:39:23PM +0300, arinc9.unal@gmail.com wrote: >>>>>>> From: Arınç ÜNAL <arinc.unal@arinc9.com> >>>>>>> >>>>>>> Add the ralink,rt2880-pinmux compatible string. It had been removed from >>>>>>> the driver which broke the ABI. >>>>>>> >>>>>>> Add the mediatek compatible strings. Change the compatible string on the >>>>>>> examples with the mediatek compatible strings. >>>>>>> >>>>>>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> >>>>>>> --- >>>>>>> .../devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml | 7 +++++-- >>>>>>> .../devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml | 7 +++++-- >>>>>>> .../devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml | 7 +++++-- >>>>>>> .../devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml | 7 +++++-- >>>>>>> .../devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml | 7 +++++-- >>>>>>> 5 files changed, 25 insertions(+), 10 deletions(-) >>>>>>> >>>>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>>>> index 1e63ea34146a..531b5f616c3d 100644 >>>>>>> --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>>>> +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>>>> @@ -17,7 +17,10 @@ description: >>>>>>> properties: >>>>>>> compatible: >>>>>>> - const: ralink,mt7620-pinctrl >>>>>>> + enum: >>>>>>> + - mediatek,mt7620-pinctrl >>>>>>> + - ralink,mt7620-pinctrl >>>>>> >>>>>> We don't update compatible strings based on acquistions nor marketing >>>>>> whims. If you want to use 'mediatek' for new things, then fine. >>>>> >>>>> Understood. Only the SoCs with rtXXXX were rebranded, the mtXXXX SoCs share >>>>> the same architecture from Ralink, so they were incorrectly called Ralink >>>>> SoCs. >>>>> >>>>> I can remove the new strings from Ralink SoCs and add them only for MediaTek >>>>> SoCs. Or you could make an exception for this one, regarding the situation. >>>>> Whatever you think is best. >>>> >>>> I'm not in a position to make an exception as I know little about this >>>> platform. Carrying both strings is a NAK. Either you (and everyone using >>>> these platforms) care about the ABI and are stuck with the "wrong" >>>> string. In the end, they are just unique identifiers. Or you don't care >>>> and break the ABI and rename everything. If you do that, do just that in >>>> your patches and make it crystal clear in the commit msg that is your >>>> intention and why that is okay. >>> >>> Ralink had their MIPS SoCs pre-acquisition, RT2880, etc. MediaTek >>> introduced new SoCs post-acquisition, MT7620, MT7621, MT7628, and >>> MT7688, utilising the same platform from Ralink, sharing the same >>> architecture code, pinctrl core driver, etc. >>> >>> I don't intend to break the ABI at all. On the contrary, I fix it where >>> possible. >>> >>> If I understand correctly, from this conversation and what Krzysztof >>> said, all strings must be kept on the schemas so I can do what I said on >>> the composed mail. Only match the pin muxing information on the strings >>> that won't match multiple pin muxing information from other schemas. >>> >>> This way we don't break the ABI, introduce new compatible strings while >>> keeping the remaining ones, and make schemas match correctly. >>> >>> Let me know if this is acceptable to you. >> >> If by "introduce new compatible strings" you mean duplicate compatibles >> to fix the ralink->mediatek, then you ignored entire email from Rob - >> this and previous. We don't do this. Leave them as is. >> >> If you meant something else, explain more... > > Let me put them in a group to better explain. > > ## Fix ABI > > ralink,rt2880-pinmux was there before, it was removed which broke the > ABI. I'm reintroducing it to fix it. > > ## New strings to be able to split bindings > > New strings are needed for MT7628/MT7688 and some RT SoCs to be able to > properly document the pin muxing information. Then ok. > > ## Incorrect naming > > MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, > introduce new ralink->mediatek compatible strings to address it. So this part was addressed by Rob - we don't do it, because it does not matter. Ralink is now Mediatek, thus there is no conflict and no issues with different vendor used. > > ## Exception for RT SoCs to be called MediaTek > > This is where I was asking an exception to be made. Rob told us here > they know little about the platform so I explained it. > > MediaTek acquired Ralink and then introduced new MediaTek SoCs utilising > the same platform from Ralink. > > Anyway, now that I look at this again, it makes sense to me as well not > to rename the Ralink SoCs. I'll call the RT SoCs Ralink on the kconfig, > pinctrl driver, These are separate. We did not comment on how you call Linux drivers. The mail thread was only about: > and dt-binding schemas on my next version. Best regards, Krzysztof
On 2.03.2023 12:58, Krzysztof Kozlowski wrote: > On 02/03/2023 10:17, Arınç ÜNAL wrote: >> On 2.03.2023 11:28, Krzysztof Kozlowski wrote: >>> On 01/03/2023 09:15, Arınç ÜNAL wrote: >>>> On 1.03.2023 05:44, Rob Herring wrote: >>>>> On Tue, Feb 28, 2023 at 07:46:36PM +0300, Arınç ÜNAL wrote: >>>>>> On 27/02/2023 20:33, Rob Herring wrote: >>>>>>> On Wed, Feb 22, 2023 at 09:39:23PM +0300, arinc9.unal@gmail.com wrote: >>>>>>>> From: Arınç ÜNAL <arinc.unal@arinc9.com> >>>>>>>> >>>>>>>> Add the ralink,rt2880-pinmux compatible string. It had been removed from >>>>>>>> the driver which broke the ABI. >>>>>>>> >>>>>>>> Add the mediatek compatible strings. Change the compatible string on the >>>>>>>> examples with the mediatek compatible strings. >>>>>>>> >>>>>>>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> >>>>>>>> --- >>>>>>>> .../devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml | 7 +++++-- >>>>>>>> .../devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml | 7 +++++-- >>>>>>>> .../devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml | 7 +++++-- >>>>>>>> .../devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml | 7 +++++-- >>>>>>>> .../devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml | 7 +++++-- >>>>>>>> 5 files changed, 25 insertions(+), 10 deletions(-) >>>>>>>> >>>>>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>>>>> index 1e63ea34146a..531b5f616c3d 100644 >>>>>>>> --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>>>>> +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml >>>>>>>> @@ -17,7 +17,10 @@ description: >>>>>>>> properties: >>>>>>>> compatible: >>>>>>>> - const: ralink,mt7620-pinctrl >>>>>>>> + enum: >>>>>>>> + - mediatek,mt7620-pinctrl >>>>>>>> + - ralink,mt7620-pinctrl >>>>>>> >>>>>>> We don't update compatible strings based on acquistions nor marketing >>>>>>> whims. If you want to use 'mediatek' for new things, then fine. >>>>>> >>>>>> Understood. Only the SoCs with rtXXXX were rebranded, the mtXXXX SoCs share >>>>>> the same architecture from Ralink, so they were incorrectly called Ralink >>>>>> SoCs. >>>>>> >>>>>> I can remove the new strings from Ralink SoCs and add them only for MediaTek >>>>>> SoCs. Or you could make an exception for this one, regarding the situation. >>>>>> Whatever you think is best. >>>>> >>>>> I'm not in a position to make an exception as I know little about this >>>>> platform. Carrying both strings is a NAK. Either you (and everyone using >>>>> these platforms) care about the ABI and are stuck with the "wrong" >>>>> string. In the end, they are just unique identifiers. Or you don't care >>>>> and break the ABI and rename everything. If you do that, do just that in >>>>> your patches and make it crystal clear in the commit msg that is your >>>>> intention and why that is okay. >>>> >>>> Ralink had their MIPS SoCs pre-acquisition, RT2880, etc. MediaTek >>>> introduced new SoCs post-acquisition, MT7620, MT7621, MT7628, and >>>> MT7688, utilising the same platform from Ralink, sharing the same >>>> architecture code, pinctrl core driver, etc. >>>> >>>> I don't intend to break the ABI at all. On the contrary, I fix it where >>>> possible. >>>> >>>> If I understand correctly, from this conversation and what Krzysztof >>>> said, all strings must be kept on the schemas so I can do what I said on >>>> the composed mail. Only match the pin muxing information on the strings >>>> that won't match multiple pin muxing information from other schemas. >>>> >>>> This way we don't break the ABI, introduce new compatible strings while >>>> keeping the remaining ones, and make schemas match correctly. >>>> >>>> Let me know if this is acceptable to you. >>> >>> If by "introduce new compatible strings" you mean duplicate compatibles >>> to fix the ralink->mediatek, then you ignored entire email from Rob - >>> this and previous. We don't do this. Leave them as is. >>> >>> If you meant something else, explain more... >> >> Let me put them in a group to better explain. >> >> ## Fix ABI >> >> ralink,rt2880-pinmux was there before, it was removed which broke the >> ABI. I'm reintroducing it to fix it. >> >> ## New strings to be able to split bindings >> >> New strings are needed for MT7628/MT7688 and some RT SoCs to be able to >> properly document the pin muxing information. > > Then ok. > >> >> ## Incorrect naming >> >> MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, >> introduce new ralink->mediatek compatible strings to address it. > > So this part was addressed by Rob - we don't do it, because it does not > matter. Ralink is now Mediatek, thus there is no conflict and no issues > with different vendor used. I think Rob was rather addressing that updating compatible strings based on acquisition or marketing whims is not permitted. This condition does not apply here as these SoCs were never Ralink. I understand your point that Ralink is now MediaTek but still, calling these SoCs Ralink would be a bit misleading, don't you think? > >> >> ## Exception for RT SoCs to be called MediaTek >> >> This is where I was asking an exception to be made. Rob told us here >> they know little about the platform so I explained it. >> >> MediaTek acquired Ralink and then introduced new MediaTek SoCs utilising >> the same platform from Ralink. >> >> Anyway, now that I look at this again, it makes sense to me as well not >> to rename the Ralink SoCs. I'll call the RT SoCs Ralink on the kconfig, >> pinctrl driver, > > These are separate. We did not comment on how you call Linux drivers. > The mail thread was only about: > >> and dt-binding schemas on my next version. Understood, thanks. Arınç
On 02/03/2023 11:22, Arınç ÜNAL wrote: >>> >>> ## Incorrect naming >>> >>> MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, >>> introduce new ralink->mediatek compatible strings to address it. >> >> So this part was addressed by Rob - we don't do it, because it does not >> matter. Ralink is now Mediatek, thus there is no conflict and no issues >> with different vendor used. > > I think Rob was rather addressing that updating compatible strings based > on acquisition or marketing whims is not permitted. This condition does > not apply here as these SoCs were never Ralink. > > I understand your point that Ralink is now MediaTek but still, calling > these SoCs Ralink would be a bit misleading, don't you think? Misleading yes, but also does not matter. At least matter not enough to justify ABI break, so you would need to deprecate old ones and keep everything backwards compatible. You still would affect 3rd party users of DTS, though... Best regards, Krzysztof
On 2.03.2023 13:29, Krzysztof Kozlowski wrote: > On 02/03/2023 11:22, Arınç ÜNAL wrote: >>>> >>>> ## Incorrect naming >>>> >>>> MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, >>>> introduce new ralink->mediatek compatible strings to address it. >>> >>> So this part was addressed by Rob - we don't do it, because it does not >>> matter. Ralink is now Mediatek, thus there is no conflict and no issues >>> with different vendor used. >> >> I think Rob was rather addressing that updating compatible strings based >> on acquisition or marketing whims is not permitted. This condition does >> not apply here as these SoCs were never Ralink. >> >> I understand your point that Ralink is now MediaTek but still, calling >> these SoCs Ralink would be a bit misleading, don't you think? > > Misleading yes, but also does not matter. At least matter not enough to > justify ABI break, so you would need to deprecate old ones and keep > everything backwards compatible. You still would affect 3rd party users > of DTS, though... I intend to do just that. Introduce new mediatek strings, keep the old ones so it's backwards compatible, therefore don't break the ABI. Instead of deprecating old strings, I intend to introduce the checks I mentioned, on the schema, so the pin muxing bindings only apply if the DT has got a string that won't match multiple schemas. This way it shouldn't affect 3rd party DTs. Arınç
On 02/03/2023 11:47, Arınç ÜNAL wrote: > On 2.03.2023 13:29, Krzysztof Kozlowski wrote: >> On 02/03/2023 11:22, Arınç ÜNAL wrote: >>>>> >>>>> ## Incorrect naming >>>>> >>>>> MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, >>>>> introduce new ralink->mediatek compatible strings to address it. >>>> >>>> So this part was addressed by Rob - we don't do it, because it does not >>>> matter. Ralink is now Mediatek, thus there is no conflict and no issues >>>> with different vendor used. >>> >>> I think Rob was rather addressing that updating compatible strings based >>> on acquisition or marketing whims is not permitted. This condition does >>> not apply here as these SoCs were never Ralink. >>> >>> I understand your point that Ralink is now MediaTek but still, calling >>> these SoCs Ralink would be a bit misleading, don't you think? >> >> Misleading yes, but also does not matter. At least matter not enough to >> justify ABI break, so you would need to deprecate old ones and keep >> everything backwards compatible. You still would affect 3rd party users >> of DTS, though... > > I intend to do just that. Introduce new mediatek strings, keep the old > ones so it's backwards compatible, therefore don't break the ABI. > > Instead of deprecating old strings, I intend to introduce the checks I > mentioned, on the schema, so the pin muxing bindings only apply if the > DT has got a string that won't match multiple schemas. This way it > shouldn't affect 3rd party DTs. I meant, 3rd party users of DTS. You will replace the compatible in the DTS, right? So the DTS exported and used in all other projects, OS, firmwares, bootloaders, out of tree kernel forks will stop working. Best regards, Krzysztof
On 2.03.2023 14:36, Krzysztof Kozlowski wrote: > On 02/03/2023 11:47, Arınç ÜNAL wrote: >> On 2.03.2023 13:29, Krzysztof Kozlowski wrote: >>> On 02/03/2023 11:22, Arınç ÜNAL wrote: >>>>>> >>>>>> ## Incorrect naming >>>>>> >>>>>> MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, >>>>>> introduce new ralink->mediatek compatible strings to address it. >>>>> >>>>> So this part was addressed by Rob - we don't do it, because it does not >>>>> matter. Ralink is now Mediatek, thus there is no conflict and no issues >>>>> with different vendor used. >>>> >>>> I think Rob was rather addressing that updating compatible strings based >>>> on acquisition or marketing whims is not permitted. This condition does >>>> not apply here as these SoCs were never Ralink. >>>> >>>> I understand your point that Ralink is now MediaTek but still, calling >>>> these SoCs Ralink would be a bit misleading, don't you think? >>> >>> Misleading yes, but also does not matter. At least matter not enough to >>> justify ABI break, so you would need to deprecate old ones and keep >>> everything backwards compatible. You still would affect 3rd party users >>> of DTS, though... >> >> I intend to do just that. Introduce new mediatek strings, keep the old >> ones so it's backwards compatible, therefore don't break the ABI. >> >> Instead of deprecating old strings, I intend to introduce the checks I >> mentioned, on the schema, so the pin muxing bindings only apply if the >> DT has got a string that won't match multiple schemas. This way it >> shouldn't affect 3rd party DTs. > > I meant, 3rd party users of DTS. You will replace the compatible in the > DTS, right? So the DTS exported and used in all other projects, OS, > firmwares, bootloaders, out of tree kernel forks will stop working. I plan to change it on the DTs for MediaTek SoCs, yes. Is this a problem? From what I can tell, what must be ensured is that old DTs must work with newer kernels, not new DTs on older kernels. Arınç
On 2.03.2023 13:47, Arınç ÜNAL wrote: > On 2.03.2023 13:29, Krzysztof Kozlowski wrote: >> On 02/03/2023 11:22, Arınç ÜNAL wrote: >>>>> >>>>> ## Incorrect naming >>>>> >>>>> MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, >>>>> introduce new ralink->mediatek compatible strings to address it. >>>> >>>> So this part was addressed by Rob - we don't do it, because it does not >>>> matter. Ralink is now Mediatek, thus there is no conflict and no issues >>>> with different vendor used. >>> >>> I think Rob was rather addressing that updating compatible strings based >>> on acquisition or marketing whims is not permitted. This condition does >>> not apply here as these SoCs were never Ralink. >>> >>> I understand your point that Ralink is now MediaTek but still, calling >>> these SoCs Ralink would be a bit misleading, don't you think? >> >> Misleading yes, but also does not matter. At least matter not enough to >> justify ABI break, so you would need to deprecate old ones and keep >> everything backwards compatible. You still would affect 3rd party users >> of DTS, though... > > I intend to do just that. Introduce new mediatek strings, keep the old > ones so it's backwards compatible, therefore don't break the ABI. > > Instead of deprecating old strings, I intend to introduce the checks I > mentioned, on the schema, so the pin muxing bindings only apply if the > DT has got a string that won't match multiple schemas. This way it > shouldn't affect 3rd party DTs. I'm looking at this again and I see that doing this brings more issues than it solves. I think deprecating the old strings from the schemas is better. They will be on the driver anyway so newer kernels will still work fine with old DTs. Arınç
On 02/03/2023 12:50, Arınç ÜNAL wrote: > On 2.03.2023 14:36, Krzysztof Kozlowski wrote: >> On 02/03/2023 11:47, Arınç ÜNAL wrote: >>> On 2.03.2023 13:29, Krzysztof Kozlowski wrote: >>>> On 02/03/2023 11:22, Arınç ÜNAL wrote: >>>>>>> >>>>>>> ## Incorrect naming >>>>>>> >>>>>>> MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, >>>>>>> introduce new ralink->mediatek compatible strings to address it. >>>>>> >>>>>> So this part was addressed by Rob - we don't do it, because it does not >>>>>> matter. Ralink is now Mediatek, thus there is no conflict and no issues >>>>>> with different vendor used. >>>>> >>>>> I think Rob was rather addressing that updating compatible strings based >>>>> on acquisition or marketing whims is not permitted. This condition does >>>>> not apply here as these SoCs were never Ralink. >>>>> >>>>> I understand your point that Ralink is now MediaTek but still, calling >>>>> these SoCs Ralink would be a bit misleading, don't you think? >>>> >>>> Misleading yes, but also does not matter. At least matter not enough to >>>> justify ABI break, so you would need to deprecate old ones and keep >>>> everything backwards compatible. You still would affect 3rd party users >>>> of DTS, though... >>> >>> I intend to do just that. Introduce new mediatek strings, keep the old >>> ones so it's backwards compatible, therefore don't break the ABI. >>> >>> Instead of deprecating old strings, I intend to introduce the checks I >>> mentioned, on the schema, so the pin muxing bindings only apply if the >>> DT has got a string that won't match multiple schemas. This way it >>> shouldn't affect 3rd party DTs. >> >> I meant, 3rd party users of DTS. You will replace the compatible in the >> DTS, right? So the DTS exported and used in all other projects, OS, >> firmwares, bootloaders, out of tree kernel forks will stop working. > > I plan to change it on the DTs for MediaTek SoCs, yes. Is this a > problem? From what I can tell, what must be ensured is that old DTs must > work with newer kernels, not new DTs on older kernels. Can I be clearer than this? " So the DTS exported and used in all other projects, OS, firmwares, bootloaders, out of tree kernel forks will stop working." Yes, this is a problem - they will stop working. Best regards, Krzysztof
On 3.03.2023 10:05, Krzysztof Kozlowski wrote: > On 02/03/2023 12:50, Arınç ÜNAL wrote: >> On 2.03.2023 14:36, Krzysztof Kozlowski wrote: >>> On 02/03/2023 11:47, Arınç ÜNAL wrote: >>>> On 2.03.2023 13:29, Krzysztof Kozlowski wrote: >>>>> On 02/03/2023 11:22, Arınç ÜNAL wrote: >>>>>>>> >>>>>>>> ## Incorrect naming >>>>>>>> >>>>>>>> MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, >>>>>>>> introduce new ralink->mediatek compatible strings to address it. >>>>>>> >>>>>>> So this part was addressed by Rob - we don't do it, because it does not >>>>>>> matter. Ralink is now Mediatek, thus there is no conflict and no issues >>>>>>> with different vendor used. >>>>>> >>>>>> I think Rob was rather addressing that updating compatible strings based >>>>>> on acquisition or marketing whims is not permitted. This condition does >>>>>> not apply here as these SoCs were never Ralink. >>>>>> >>>>>> I understand your point that Ralink is now MediaTek but still, calling >>>>>> these SoCs Ralink would be a bit misleading, don't you think? >>>>> >>>>> Misleading yes, but also does not matter. At least matter not enough to >>>>> justify ABI break, so you would need to deprecate old ones and keep >>>>> everything backwards compatible. You still would affect 3rd party users >>>>> of DTS, though... >>>> >>>> I intend to do just that. Introduce new mediatek strings, keep the old >>>> ones so it's backwards compatible, therefore don't break the ABI. >>>> >>>> Instead of deprecating old strings, I intend to introduce the checks I >>>> mentioned, on the schema, so the pin muxing bindings only apply if the >>>> DT has got a string that won't match multiple schemas. This way it >>>> shouldn't affect 3rd party DTs. >>> >>> I meant, 3rd party users of DTS. You will replace the compatible in the >>> DTS, right? So the DTS exported and used in all other projects, OS, >>> firmwares, bootloaders, out of tree kernel forks will stop working. >> >> I plan to change it on the DTs for MediaTek SoCs, yes. Is this a >> problem? From what I can tell, what must be ensured is that old DTs must >> work with newer kernels, not new DTs on older kernels. > > Can I be clearer than this? > > " So the DTS exported and used in all other projects, OS, > firmwares, bootloaders, out of tree kernel forks will stop working." > > Yes, this is a problem - they will stop working. I've never seen any project just exporting DTs from the latest kernel version and slap it onto old versions, as a new devicetree that was introduced with a newer kernel version is not guaranteed to work with older kernel versions. If someone is actually doing this on a project, I think it's the responsibility of the maintainers of these said projects to account for this and modify the DT for the kernel version they're running it on. What's more usual is one'd run the kernel version where the new DT was introduced, which will work fine. On to real life implications, popular projects like U-Boot and OpenWrt maintain their own DTs for this platform so I think the impact is very minimal. Anyway, I'm not doing this change on this patch series so why don't we cross this bridge when we get to it. Arınç
On 03/03/2023 08:44, Arınç ÜNAL wrote: > On 3.03.2023 10:05, Krzysztof Kozlowski wrote: >> On 02/03/2023 12:50, Arınç ÜNAL wrote: >>> On 2.03.2023 14:36, Krzysztof Kozlowski wrote: >>>> On 02/03/2023 11:47, Arınç ÜNAL wrote: >>>>> On 2.03.2023 13:29, Krzysztof Kozlowski wrote: >>>>>> On 02/03/2023 11:22, Arınç ÜNAL wrote: >>>>>>>>> >>>>>>>>> ## Incorrect naming >>>>>>>>> >>>>>>>>> MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, >>>>>>>>> introduce new ralink->mediatek compatible strings to address it. >>>>>>>> >>>>>>>> So this part was addressed by Rob - we don't do it, because it does not >>>>>>>> matter. Ralink is now Mediatek, thus there is no conflict and no issues >>>>>>>> with different vendor used. >>>>>>> >>>>>>> I think Rob was rather addressing that updating compatible strings based >>>>>>> on acquisition or marketing whims is not permitted. This condition does >>>>>>> not apply here as these SoCs were never Ralink. >>>>>>> >>>>>>> I understand your point that Ralink is now MediaTek but still, calling >>>>>>> these SoCs Ralink would be a bit misleading, don't you think? >>>>>> >>>>>> Misleading yes, but also does not matter. At least matter not enough to >>>>>> justify ABI break, so you would need to deprecate old ones and keep >>>>>> everything backwards compatible. You still would affect 3rd party users >>>>>> of DTS, though... >>>>> >>>>> I intend to do just that. Introduce new mediatek strings, keep the old >>>>> ones so it's backwards compatible, therefore don't break the ABI. >>>>> >>>>> Instead of deprecating old strings, I intend to introduce the checks I >>>>> mentioned, on the schema, so the pin muxing bindings only apply if the >>>>> DT has got a string that won't match multiple schemas. This way it >>>>> shouldn't affect 3rd party DTs. >>>> >>>> I meant, 3rd party users of DTS. You will replace the compatible in the >>>> DTS, right? So the DTS exported and used in all other projects, OS, >>>> firmwares, bootloaders, out of tree kernel forks will stop working. >>> >>> I plan to change it on the DTs for MediaTek SoCs, yes. Is this a >>> problem? From what I can tell, what must be ensured is that old DTs must >>> work with newer kernels, not new DTs on older kernels. >> >> Can I be clearer than this? >> >> " So the DTS exported and used in all other projects, OS, >> firmwares, bootloaders, out of tree kernel forks will stop working." >> >> Yes, this is a problem - they will stop working. > > I've never seen any project just exporting DTs from the latest kernel > version and slap it onto old versions, as a new devicetree that was Really? U-Boot does it all the time, other projects (like BSD) do it periodically to some extend as well. > introduced with a newer kernel version is not guaranteed to work with > older kernel versions. Not guaranteed but it is expected, though, to some level and under some conditions. Therefore it might be or might not be a problem. For some platforms no one cares. For some people care. > > If someone is actually doing this on a project, I think it's the > responsibility of the maintainers of these said projects to account for > this and modify the DT for the kernel version they're running it on. > > What's more usual is one'd run the kernel version where the new DT was > introduced, which will work fine. "kernel" as Linux is only one part of it. I mentioned several other projects. > > On to real life implications, popular projects like U-Boot and OpenWrt > maintain their own DTs for this platform so I think the impact is very > minimal. And they sync with Linux kernel DTS. > > Anyway, I'm not doing this change on this patch series so why don't we > cross this bridge when we get to it. Best regards, Krzysztof
On 3.03.2023 10:53, Krzysztof Kozlowski wrote: > On 03/03/2023 08:44, Arınç ÜNAL wrote: >> On 3.03.2023 10:05, Krzysztof Kozlowski wrote: >>> On 02/03/2023 12:50, Arınç ÜNAL wrote: >>>> On 2.03.2023 14:36, Krzysztof Kozlowski wrote: >>>>> On 02/03/2023 11:47, Arınç ÜNAL wrote: >>>>>> On 2.03.2023 13:29, Krzysztof Kozlowski wrote: >>>>>>> On 02/03/2023 11:22, Arınç ÜNAL wrote: >>>>>>>>>> >>>>>>>>>> ## Incorrect naming >>>>>>>>>> >>>>>>>>>> MT7620, MT7621, MT7628, and MT7688 SoCs are incorrectly called Ralink, >>>>>>>>>> introduce new ralink->mediatek compatible strings to address it. >>>>>>>>> >>>>>>>>> So this part was addressed by Rob - we don't do it, because it does not >>>>>>>>> matter. Ralink is now Mediatek, thus there is no conflict and no issues >>>>>>>>> with different vendor used. >>>>>>>> >>>>>>>> I think Rob was rather addressing that updating compatible strings based >>>>>>>> on acquisition or marketing whims is not permitted. This condition does >>>>>>>> not apply here as these SoCs were never Ralink. >>>>>>>> >>>>>>>> I understand your point that Ralink is now MediaTek but still, calling >>>>>>>> these SoCs Ralink would be a bit misleading, don't you think? >>>>>>> >>>>>>> Misleading yes, but also does not matter. At least matter not enough to >>>>>>> justify ABI break, so you would need to deprecate old ones and keep >>>>>>> everything backwards compatible. You still would affect 3rd party users >>>>>>> of DTS, though... >>>>>> >>>>>> I intend to do just that. Introduce new mediatek strings, keep the old >>>>>> ones so it's backwards compatible, therefore don't break the ABI. >>>>>> >>>>>> Instead of deprecating old strings, I intend to introduce the checks I >>>>>> mentioned, on the schema, so the pin muxing bindings only apply if the >>>>>> DT has got a string that won't match multiple schemas. This way it >>>>>> shouldn't affect 3rd party DTs. >>>>> >>>>> I meant, 3rd party users of DTS. You will replace the compatible in the >>>>> DTS, right? So the DTS exported and used in all other projects, OS, >>>>> firmwares, bootloaders, out of tree kernel forks will stop working. >>>> >>>> I plan to change it on the DTs for MediaTek SoCs, yes. Is this a >>>> problem? From what I can tell, what must be ensured is that old DTs must >>>> work with newer kernels, not new DTs on older kernels. >>> >>> Can I be clearer than this? >>> >>> " So the DTS exported and used in all other projects, OS, >>> firmwares, bootloaders, out of tree kernel forks will stop working." >>> >>> Yes, this is a problem - they will stop working. >> >> I've never seen any project just exporting DTs from the latest kernel >> version and slap it onto old versions, as a new devicetree that was > > Really? U-Boot does it all the time, other projects (like BSD) do it > periodically to some extend as well. They must do heavy reviewing before shipping it. Drivers like MediaTek ethernet on U-Boot is different than in Linux, the dt-bindings are all different. Under a review, these changes will pop out for them to address so there're no problems. > >> introduced with a newer kernel version is not guaranteed to work with >> older kernel versions. > > Not guaranteed but it is expected, though, to some level and under some > conditions. Therefore it might be or might not be a problem. For some > platforms no one cares. For some people care. I'm going to assume there's not much care for this platform, at least for mt7621, as I've heard no complaints when I did this before. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/mips/boot/dts/ralink/mt7621.dtsi?id=b4f209e32ba5c283e7b1dd00d867b0536d3e215e > >> >> If someone is actually doing this on a project, I think it's the >> responsibility of the maintainers of these said projects to account for >> this and modify the DT for the kernel version they're running it on. >> >> What's more usual is one'd run the kernel version where the new DT was >> introduced, which will work fine. > > "kernel" as Linux is only one part of it. I mentioned several other > projects. > >> >> On to real life implications, popular projects like U-Boot and OpenWrt >> maintain their own DTs for this platform so I think the impact is very >> minimal. > > And they sync with Linux kernel DTS. Again, the DTs must be reviewed so they will be modified and the potential issue will be addressed. Arınç
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml index 1e63ea34146a..531b5f616c3d 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml @@ -17,7 +17,10 @@ description: properties: compatible: - const: ralink,mt7620-pinctrl + enum: + - mediatek,mt7620-pinctrl + - ralink,mt7620-pinctrl + - ralink,rt2880-pinmux patternProperties: '-pins$': @@ -647,7 +650,7 @@ additionalProperties: false examples: - | pinctrl { - compatible = "ralink,mt7620-pinctrl"; + compatible = "mediatek,mt7620-pinctrl"; i2c_pins: i2c0-pins { pinmux { diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml index 1b1d37b981d9..74923ca35c81 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml @@ -17,7 +17,10 @@ description: properties: compatible: - const: ralink,mt7621-pinctrl + enum: + - mediatek,mt7621-pinctrl + - ralink,mt7621-pinctrl + - ralink,rt2880-pinmux patternProperties: '-pins$': @@ -251,7 +254,7 @@ additionalProperties: false examples: - | pinctrl { - compatible = "ralink,mt7621-pinctrl"; + compatible = "mediatek,mt7621-pinctrl"; i2c_pins: i2c0-pins { pinmux { diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml index 7fd0df880a76..aceea6248614 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml @@ -17,7 +17,10 @@ description: properties: compatible: - const: ralink,rt2880-pinctrl + enum: + - mediatek,rt2880-pinctrl + - ralink,rt2880-pinctrl + - ralink,rt2880-pinmux patternProperties: '-pins$': @@ -131,7 +134,7 @@ additionalProperties: false examples: - | pinctrl { - compatible = "ralink,rt2880-pinctrl"; + compatible = "mediatek,rt2880-pinctrl"; i2c_pins: i2c0-pins { pinmux { diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml index 4d66ca752a30..4c87fe201809 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml @@ -18,7 +18,10 @@ description: properties: compatible: - const: ralink,rt305x-pinctrl + enum: + - mediatek,rt305x-pinctrl + - ralink,rt305x-pinctrl + - ralink,rt2880-pinmux patternProperties: '-pins$': @@ -264,7 +267,7 @@ additionalProperties: false examples: - | pinctrl { - compatible = "ralink,rt305x-pinctrl"; + compatible = "mediatek,rt305x-pinctrl"; i2c_pins: i2c0-pins { pinmux { diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml index 008d93181aea..71049a2b2779 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml @@ -17,7 +17,10 @@ description: properties: compatible: - const: ralink,rt3883-pinctrl + enum: + - mediatek,rt3883-pinctrl + - ralink,rt3883-pinctrl + - ralink,rt2880-pinmux patternProperties: '-pins$': @@ -251,7 +254,7 @@ additionalProperties: false examples: - | pinctrl { - compatible = "ralink,rt3883-pinctrl"; + compatible = "mediatek,rt3883-pinctrl"; i2c_pins: i2c0-pins { pinmux {