Messages in this thread | | | Date | Fri, 10 Mar 2023 10:45:33 +0300 | Subject | Re: [PATCH 09/20] dt-bindings: pinctrl: ralink: {mt7620,mt7621}: rename to mediatek | From | Arınç ÜNAL <> |
| |
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ç
| |