Re: [RFC PATCH 07/16] dt-bindings: pinctrl: ralink: add new compatible strings

[Arınç ÜNAL]

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ç