| Message ID | 20230303002850.51858-10-arinc.unal@arinc9.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | pinctrl: ralink: fix ABI, improve driver, move to mediatek, improve dt-bindings | expand |
On 9.03.2023 00:05, Rob Herring wrote: > On Fri, Mar 03, 2023 at 03:28:38AM +0300, arinc9.unal@gmail.com wrote: >> From: Arınç ÜNAL <arinc.unal@arinc9.com> >> >> This platform from Ralink was acquired by MediaTek in 2011. Then, MediaTek >> introduced these SoCs which utilise this platform. Rename the schemas to >> mediatek to address the incorrect naming. > > I said we don't do renames due to acquistions, you said that wasn't the > reason, but then that's your reasoning here. It's not a marketing/acquistion rename as the name of these SoCs were wrong from the get go. The information on the first sentence is to give the idea of why these SoCs were wrongfully named as the base platform that these new MediaTek SoCs share code with was called Ralink. > > To give you another example, *new* i.MX things are still called > 'fsl,imx...' and it has been how many years since merging with NXP? Ok this is a point I see now. Though, I fail to see how this is called renaming when there's only new SoCs (from NXP in this case) to be added. Arınç
On 9.03.2023 00:19, Arınç ÜNAL wrote: > On 9.03.2023 00:05, Rob Herring wrote: >> On Fri, Mar 03, 2023 at 03:28:38AM +0300, arinc9.unal@gmail.com wrote: >>> From: Arınç ÜNAL <arinc.unal@arinc9.com> >>> >>> This platform from Ralink was acquired by MediaTek in 2011. Then, >>> MediaTek >>> introduced these SoCs which utilise this platform. Rename the schemas to >>> mediatek to address the incorrect naming. >> >> I said we don't do renames due to acquistions, you said that wasn't the >> reason, but then that's your reasoning here. > > It's not a marketing/acquistion rename as the name of these SoCs were > wrong from the get go. The information on the first sentence is to give > the idea of why these SoCs were wrongfully named as the base platform > that these new MediaTek SoCs share code with was called Ralink. > >> >> To give you another example, *new* i.MX things are still called >> 'fsl,imx...' and it has been how many years since merging with NXP? > > Ok this is a point I see now. Though, I fail to see how this is called > renaming when there's only new SoCs (from NXP in this case) to be added. If I understand correctly, i.MX is a family from Freescale so the name was kept the same on new SoC releases from NXP. I believe it's different in this case here. There's no family name. The closest thing on the name of the SoC model is, it's RT for Ralink, MT for MediaTek. On top of that, mediatek strings already exist for MT SoCs already, at least for MT7621. https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/Documentation/devicetree/bindings/mips/ralink.yaml?id=dd3cb467ebb5659d6552999d6f16a616653f9933#n83 Arınç
On 09/03/2023 08:53, Arınç ÜNAL wrote: > On 9.03.2023 00:19, Arınç ÜNAL wrote: >> On 9.03.2023 00:05, Rob Herring wrote: >>> On Fri, Mar 03, 2023 at 03:28:38AM +0300, arinc9.unal@gmail.com wrote: >>>> From: Arınç ÜNAL <arinc.unal@arinc9.com> >>>> >>>> This platform from Ralink was acquired by MediaTek in 2011. Then, >>>> MediaTek >>>> introduced these SoCs which utilise this platform. Rename the schemas to >>>> mediatek to address the incorrect naming. >>> >>> I said we don't do renames due to acquistions, you said that wasn't the >>> reason, but then that's your reasoning here. >> >> It's not a marketing/acquistion rename as the name of these SoCs were >> wrong from the get go. The information on the first sentence is to give >> the idea of why these SoCs were wrongfully named as the base platform >> that these new MediaTek SoCs share code with was called Ralink. >> >>> >>> To give you another example, *new* i.MX things are still called >>> 'fsl,imx...' and it has been how many years since merging with NXP? >> >> Ok this is a point I see now. Though, I fail to see how this is called >> renaming when there's only new SoCs (from NXP in this case) to be added. > > If I understand correctly, i.MX is a family from Freescale so the name It's the same "family" as your platform, because as you said: "introduced these SoCs which utilise this platform" > was kept the same on new SoC releases from NXP. I believe it's different > in this case here. There's no family name. The closest thing on the name > of the SoC model is, it's RT for Ralink, MT for MediaTek. It's not about the name. NXP took Freescale platform and since many years makes entirely new products, currently far, far away from original platform. That's the same case you have here - Mediatek took existing platform and started making new products with it. > > On top of that, mediatek strings already exist for MT SoCs already, at > least for MT7621. > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/Documentation/devicetree/bindings/mips/ralink.yaml?id=dd3cb467ebb5659d6552999d6f16a616653f9933#n83 NXP also has compatibles with nxp, thus still not that good reason. Best regards, Krzysztof
On 9.03.2023 12:52, Krzysztof Kozlowski wrote: > On 09/03/2023 08:53, Arınç ÜNAL wrote: >> On 9.03.2023 00:19, Arınç ÜNAL wrote: >>> On 9.03.2023 00:05, Rob Herring wrote: >>>> On Fri, Mar 03, 2023 at 03:28:38AM +0300, arinc9.unal@gmail.com wrote: >>>>> From: Arınç ÜNAL <arinc.unal@arinc9.com> >>>>> >>>>> This platform from Ralink was acquired by MediaTek in 2011. Then, >>>>> MediaTek >>>>> introduced these SoCs which utilise this platform. Rename the schemas to >>>>> mediatek to address the incorrect naming. >>>> >>>> I said we don't do renames due to acquistions, you said that wasn't the >>>> reason, but then that's your reasoning here. >>> >>> It's not a marketing/acquistion rename as the name of these SoCs were >>> wrong from the get go. The information on the first sentence is to give >>> the idea of why these SoCs were wrongfully named as the base platform >>> that these new MediaTek SoCs share code with was called Ralink. >>> >>>> >>>> To give you another example, *new* i.MX things are still called >>>> 'fsl,imx...' and it has been how many years since merging with NXP? >>> >>> Ok this is a point I see now. Though, I fail to see how this is called >>> renaming when there's only new SoCs (from NXP in this case) to be added. >> >> If I understand correctly, i.MX is a family from Freescale so the name > > It's the same "family" as your platform, because as you said: > "introduced these SoCs which utilise this platform" > >> was kept the same on new SoC releases from NXP. I believe it's different >> in this case here. There's no family name. The closest thing on the name >> of the SoC model is, it's RT for Ralink, MT for MediaTek. > > It's not about the name. NXP took Freescale platform and since many > years makes entirely new products, currently far, far away from original > platform. > > That's the same case you have here - Mediatek took existing platform and > started making new products with it. > >> >> On top of that, mediatek strings already exist for MT SoCs already, at >> least for MT7621. >> >> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/Documentation/devicetree/bindings/mips/ralink.yaml?id=dd3cb467ebb5659d6552999d6f16a616653f9933#n83 > > NXP also has compatibles with nxp, thus still not that good reason. Ok, makes sense. Am I free to call the SoCs MediaTek, change the schema name from ralink,mtXXXX-pinctrl.yaml to mediatek,mtXXXX-pinctrl.yaml whilst keeping the compatible string ralink? I plan to do some cleanup on ralink.yaml as well. From what I understand, I should change the mediatek,mt7621-soc compatible string to ralink,mt7621-soc? Arınç
On Thu, Mar 9, 2023 at 11:34 AM Arınç ÜNAL <arinc.unal@arinc9.com> wrote: > > On 9.03.2023 12:52, Krzysztof Kozlowski wrote: > > On 09/03/2023 08:53, Arınç ÜNAL wrote: > >> On 9.03.2023 00:19, Arınç ÜNAL wrote: > >>> On 9.03.2023 00:05, Rob Herring wrote: > >>>> On Fri, Mar 03, 2023 at 03:28:38AM +0300, arinc9.unal@gmail.com wrote: > >>>>> From: Arınç ÜNAL <arinc.unal@arinc9.com> > >>>>> > >>>>> This platform from Ralink was acquired by MediaTek in 2011. Then, > >>>>> MediaTek > >>>>> introduced these SoCs which utilise this platform. Rename the schemas to > >>>>> mediatek to address the incorrect naming. > >>>> > >>>> I said we don't do renames due to acquistions, you said that wasn't the > >>>> reason, but then that's your reasoning here. > >>> > >>> It's not a marketing/acquistion rename as the name of these SoCs were > >>> wrong from the get go. The information on the first sentence is to give > >>> the idea of why these SoCs were wrongfully named as the base platform > >>> that these new MediaTek SoCs share code with was called Ralink. > >>> > >>>> > >>>> To give you another example, *new* i.MX things are still called > >>>> 'fsl,imx...' and it has been how many years since merging with NXP? > >>> > >>> Ok this is a point I see now. Though, I fail to see how this is called > >>> renaming when there's only new SoCs (from NXP in this case) to be added. > >> > >> If I understand correctly, i.MX is a family from Freescale so the name > > > > It's the same "family" as your platform, because as you said: > > "introduced these SoCs which utilise this platform" > > > >> was kept the same on new SoC releases from NXP. I believe it's different > >> in this case here. There's no family name. The closest thing on the name > >> of the SoC model is, it's RT for Ralink, MT for MediaTek. > > > > It's not about the name. NXP took Freescale platform and since many > > years makes entirely new products, currently far, far away from original > > platform. > > > > That's the same case you have here - Mediatek took existing platform and > > started making new products with it. > > > >> > >> On top of that, mediatek strings already exist for MT SoCs already, at > >> least for MT7621. > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/Documentation/devicetree/bindings/mips/ralink.yaml?id=dd3cb467ebb5659d6552999d6f16a616653f9933#n83 > > > > NXP also has compatibles with nxp, thus still not that good reason. > > Ok, makes sense. Am I free to call the SoCs MediaTek, change the schema > name from ralink,mtXXXX-pinctrl.yaml to mediatek,mtXXXX-pinctrl.yaml > whilst keeping the compatible string ralink? > > I plan to do some cleanup on ralink.yaml as well. From what I > understand, I should change the mediatek,mt7621-soc compatible string to > ralink,mt7621-soc? You have to take care of these SoC strings since they are used in the very beginning of the ralink startup platforms for any single ralink SoC. See for example [0] and [1] (but they are in all soc init code). I think it is better to maintain the ralink.yaml file as it is. Best regards, Sergio Paracuellos [0]: https://elixir.bootlin.com/linux/v6.2.1/source/arch/mips/ralink/mt7621.c#L200 [1] https://elixir.bootlin.com/linux/v6.2.1/source/arch/mips/ralink/rt305x.c#L161 > > Arınç
On 9.03.2023 14:33, Sergio Paracuellos wrote: > On Thu, Mar 9, 2023 at 11:34 AM Arınç ÜNAL <arinc.unal@arinc9.com> wrote: >> >> On 9.03.2023 12:52, Krzysztof Kozlowski wrote: >>> On 09/03/2023 08:53, Arınç ÜNAL wrote: >>>> On 9.03.2023 00:19, Arınç ÜNAL wrote: >>>>> On 9.03.2023 00:05, Rob Herring wrote: >>>>>> On Fri, Mar 03, 2023 at 03:28:38AM +0300, arinc9.unal@gmail.com wrote: >>>>>>> From: Arınç ÜNAL <arinc.unal@arinc9.com> >>>>>>> >>>>>>> This platform from Ralink was acquired by MediaTek in 2011. Then, >>>>>>> MediaTek >>>>>>> introduced these SoCs which utilise this platform. Rename the schemas to >>>>>>> mediatek to address the incorrect naming. >>>>>> >>>>>> I said we don't do renames due to acquistions, you said that wasn't the >>>>>> reason, but then that's your reasoning here. >>>>> >>>>> It's not a marketing/acquistion rename as the name of these SoCs were >>>>> wrong from the get go. The information on the first sentence is to give >>>>> the idea of why these SoCs were wrongfully named as the base platform >>>>> that these new MediaTek SoCs share code with was called Ralink. >>>>> >>>>>> >>>>>> To give you another example, *new* i.MX things are still called >>>>>> 'fsl,imx...' and it has been how many years since merging with NXP? >>>>> >>>>> Ok this is a point I see now. Though, I fail to see how this is called >>>>> renaming when there's only new SoCs (from NXP in this case) to be added. >>>> >>>> If I understand correctly, i.MX is a family from Freescale so the name >>> >>> It's the same "family" as your platform, because as you said: >>> "introduced these SoCs which utilise this platform" >>> >>>> was kept the same on new SoC releases from NXP. I believe it's different >>>> in this case here. There's no family name. The closest thing on the name >>>> of the SoC model is, it's RT for Ralink, MT for MediaTek. >>> >>> It's not about the name. NXP took Freescale platform and since many >>> years makes entirely new products, currently far, far away from original >>> platform. >>> >>> That's the same case you have here - Mediatek took existing platform and >>> started making new products with it. >>> >>>> >>>> On top of that, mediatek strings already exist for MT SoCs already, at >>>> least for MT7621. >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/Documentation/devicetree/bindings/mips/ralink.yaml?id=dd3cb467ebb5659d6552999d6f16a616653f9933#n83 >>> >>> NXP also has compatibles with nxp, thus still not that good reason. >> >> Ok, makes sense. Am I free to call the SoCs MediaTek, change the schema >> name from ralink,mtXXXX-pinctrl.yaml to mediatek,mtXXXX-pinctrl.yaml >> whilst keeping the compatible string ralink? >> >> I plan to do some cleanup on ralink.yaml as well. From what I >> understand, I should change the mediatek,mt7621-soc compatible string to >> ralink,mt7621-soc? > > You have to take care of these SoC strings since they are used in the > very beginning of the ralink startup platforms for any single ralink > SoC. See for example [0] and [1] (but they are in all soc init code). > I think it is better to maintain the ralink.yaml file as it is. I'd really rather address this inconsistency everywhere possible. The code you pointed out looks different than what I did on the pinctrl driver but, surely it's possible on the code to introduce ralink and keep the mediatek string for the sake of old DTs, no? Arınç
On Thu, Mar 9, 2023 at 10:09 PM Arınç ÜNAL <arinc.unal@arinc9.com> wrote: > > On 9.03.2023 14:33, Sergio Paracuellos wrote: > > On Thu, Mar 9, 2023 at 11:34 AM Arınç ÜNAL <arinc.unal@arinc9.com> wrote: > >> > >> On 9.03.2023 12:52, Krzysztof Kozlowski wrote: > >>> On 09/03/2023 08:53, Arınç ÜNAL wrote: > >>>> On 9.03.2023 00:19, Arınç ÜNAL wrote: > >>>>> On 9.03.2023 00:05, Rob Herring wrote: > >>>>>> On Fri, Mar 03, 2023 at 03:28:38AM +0300, arinc9.unal@gmail.com wrote: > >>>>>>> From: Arınç ÜNAL <arinc.unal@arinc9.com> > >>>>>>> > >>>>>>> This platform from Ralink was acquired by MediaTek in 2011. Then, > >>>>>>> MediaTek > >>>>>>> introduced these SoCs which utilise this platform. Rename the schemas to > >>>>>>> mediatek to address the incorrect naming. > >>>>>> > >>>>>> I said we don't do renames due to acquistions, you said that wasn't the > >>>>>> reason, but then that's your reasoning here. > >>>>> > >>>>> It's not a marketing/acquistion rename as the name of these SoCs were > >>>>> wrong from the get go. The information on the first sentence is to give > >>>>> the idea of why these SoCs were wrongfully named as the base platform > >>>>> that these new MediaTek SoCs share code with was called Ralink. > >>>>> > >>>>>> > >>>>>> To give you another example, *new* i.MX things are still called > >>>>>> 'fsl,imx...' and it has been how many years since merging with NXP? > >>>>> > >>>>> Ok this is a point I see now. Though, I fail to see how this is called > >>>>> renaming when there's only new SoCs (from NXP in this case) to be added. > >>>> > >>>> If I understand correctly, i.MX is a family from Freescale so the name > >>> > >>> It's the same "family" as your platform, because as you said: > >>> "introduced these SoCs which utilise this platform" > >>> > >>>> was kept the same on new SoC releases from NXP. I believe it's different > >>>> in this case here. There's no family name. The closest thing on the name > >>>> of the SoC model is, it's RT for Ralink, MT for MediaTek. > >>> > >>> It's not about the name. NXP took Freescale platform and since many > >>> years makes entirely new products, currently far, far away from original > >>> platform. > >>> > >>> That's the same case you have here - Mediatek took existing platform and > >>> started making new products with it. > >>> > >>>> > >>>> On top of that, mediatek strings already exist for MT SoCs already, at > >>>> least for MT7621. > >>>> > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/Documentation/devicetree/bindings/mips/ralink.yaml?id=dd3cb467ebb5659d6552999d6f16a616653f9933#n83 > >>> > >>> NXP also has compatibles with nxp, thus still not that good reason. > >> > >> Ok, makes sense. Am I free to call the SoCs MediaTek, change the schema > >> name from ralink,mtXXXX-pinctrl.yaml to mediatek,mtXXXX-pinctrl.yaml > >> whilst keeping the compatible string ralink? > >> > >> I plan to do some cleanup on ralink.yaml as well. From what I > >> understand, I should change the mediatek,mt7621-soc compatible string to > >> ralink,mt7621-soc? > > > > You have to take care of these SoC strings since they are used in the > > very beginning of the ralink startup platforms for any single ralink > > SoC. See for example [0] and [1] (but they are in all soc init code). > > I think it is better to maintain the ralink.yaml file as it is. > > I'd really rather address this inconsistency everywhere possible. The > code you pointed out looks different than what I did on the pinctrl > driver but, surely it's possible on the code to introduce ralink and > keep the mediatek string for the sake of old DTs, no? In any case, the changes you might have in mind for this should be a different patch series. Best regards, Sergio Paracuellos > > Arınç
On 10.03.2023 10:05, Sergio Paracuellos wrote: > On Thu, Mar 9, 2023 at 10:09 PM Arınç ÜNAL <arinc.unal@arinc9.com> wrote: >> >> On 9.03.2023 14:33, Sergio Paracuellos wrote: >>> On Thu, Mar 9, 2023 at 11:34 AM Arınç ÜNAL <arinc.unal@arinc9.com> wrote: >>>> >>>> On 9.03.2023 12:52, Krzysztof Kozlowski wrote: >>>>> On 09/03/2023 08:53, Arınç ÜNAL wrote: >>>>>> On 9.03.2023 00:19, Arınç ÜNAL wrote: >>>>>>> On 9.03.2023 00:05, Rob Herring wrote: >>>>>>>> On Fri, Mar 03, 2023 at 03:28:38AM +0300, arinc9.unal@gmail.com wrote: >>>>>>>>> From: Arınç ÜNAL <arinc.unal@arinc9.com> >>>>>>>>> >>>>>>>>> This platform from Ralink was acquired by MediaTek in 2011. Then, >>>>>>>>> MediaTek >>>>>>>>> introduced these SoCs which utilise this platform. Rename the schemas to >>>>>>>>> mediatek to address the incorrect naming. >>>>>>>> >>>>>>>> I said we don't do renames due to acquistions, you said that wasn't the >>>>>>>> reason, but then that's your reasoning here. >>>>>>> >>>>>>> It's not a marketing/acquistion rename as the name of these SoCs were >>>>>>> wrong from the get go. The information on the first sentence is to give >>>>>>> the idea of why these SoCs were wrongfully named as the base platform >>>>>>> that these new MediaTek SoCs share code with was called Ralink. >>>>>>> >>>>>>>> >>>>>>>> To give you another example, *new* i.MX things are still called >>>>>>>> 'fsl,imx...' and it has been how many years since merging with NXP? >>>>>>> >>>>>>> Ok this is a point I see now. Though, I fail to see how this is called >>>>>>> renaming when there's only new SoCs (from NXP in this case) to be added. >>>>>> >>>>>> If I understand correctly, i.MX is a family from Freescale so the name >>>>> >>>>> It's the same "family" as your platform, because as you said: >>>>> "introduced these SoCs which utilise this platform" >>>>> >>>>>> was kept the same on new SoC releases from NXP. I believe it's different >>>>>> in this case here. There's no family name. The closest thing on the name >>>>>> of the SoC model is, it's RT for Ralink, MT for MediaTek. >>>>> >>>>> It's not about the name. NXP took Freescale platform and since many >>>>> years makes entirely new products, currently far, far away from original >>>>> platform. >>>>> >>>>> That's the same case you have here - Mediatek took existing platform and >>>>> started making new products with it. >>>>> >>>>>> >>>>>> On top of that, mediatek strings already exist for MT SoCs already, at >>>>>> least for MT7621. >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/Documentation/devicetree/bindings/mips/ralink.yaml?id=dd3cb467ebb5659d6552999d6f16a616653f9933#n83 >>>>> >>>>> NXP also has compatibles with nxp, thus still not that good reason. >>>> >>>> Ok, makes sense. Am I free to call the SoCs MediaTek, change the schema >>>> name from ralink,mtXXXX-pinctrl.yaml to mediatek,mtXXXX-pinctrl.yaml >>>> whilst keeping the compatible string ralink? >>>> >>>> I plan to do some cleanup on ralink.yaml as well. From what I >>>> understand, I should change the mediatek,mt7621-soc compatible string to >>>> ralink,mt7621-soc? >>> >>> You have to take care of these SoC strings since they are used in the >>> very beginning of the ralink startup platforms for any single ralink >>> SoC. See for example [0] and [1] (but they are in all soc init code). >>> I think it is better to maintain the ralink.yaml file as it is. >> >> I'd really rather address this inconsistency everywhere possible. The >> code you pointed out looks different than what I did on the pinctrl >> driver but, surely it's possible on the code to introduce ralink and >> keep the mediatek string for the sake of old DTs, no? > > In any case, the changes you might have in mind for this should be a > different patch series. Agreed. Arınç
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7620-pinctrl.yaml similarity index 98% rename from Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml rename to Documentation/devicetree/bindings/pinctrl/mediatek,mt7620-pinctrl.yaml index a94d2e7a5f37..1c9ca0bf9750 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7620-pinctrl.yaml @@ -1,17 +1,17 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/pinctrl/ralink,mt7620-pinctrl.yaml# +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7620-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Ralink MT7620 Pin Controller +title: MediaTek MT7620 Pin Controller maintainers: - Arınç ÜNAL <arinc.unal@arinc9.com> - Sergio Paracuellos <sergio.paracuellos@gmail.com> description: - Ralink MT7620 pin controller for MT7620, MT7628 and MT7688 SoCs. + MediaTek MT7620 pin controller for MT7620, MT7628 and MT7688 SoCs. The pin controller can only set the muxing of pin groups. Muxing individual pins is not supported. There is no pinconf support. diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7621-pinctrl.yaml similarity index 97% rename from Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml rename to Documentation/devicetree/bindings/pinctrl/mediatek,mt7621-pinctrl.yaml index eb0746cfc6d6..717c948951be 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7621-pinctrl.yaml @@ -1,17 +1,17 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/pinctrl/ralink,mt7621-pinctrl.yaml# +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7621-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Ralink MT7621 Pin Controller +title: MediaTek MT7621 Pin Controller maintainers: - Arınç ÜNAL <arinc.unal@arinc9.com> - Sergio Paracuellos <sergio.paracuellos@gmail.com> description: - Ralink MT7621 pin controller for MT7621 SoC. + MediaTek MT7621 pin controller for MT7621 SoC. The pin controller can only set the muxing of pin groups. Muxing individual pins is not supported. There is no pinconf support.