On 9.03.2023 14:33, Sergio Paracuellos wrote:

On Thu, Mar 9, 2023 at 11:34 AM Arınç ÜNAL [off-list ref] wrote:

quoted

On 9.03.2023 12:52, Krzysztof Kozlowski wrote:

quoted

On 09/03/2023 08:53, Arınç ÜNAL wrote:

quoted

On 9.03.2023 00:19, Arınç ÜNAL wrote:

quoted

On 9.03.2023 00:05, Rob Herring wrote:

quoted

On Fri, Mar 03, 2023 at 03:28:38AM +0300, arinc9.unal@gmail.com wrote:

quoted

From: Arınç ÜNAL <redacted>

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.

quoted

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"

quoted

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.

quoted

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ç

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