Messages in this thread | | | Date | Fri, 3 Mar 2023 11:03:36 +0300 | Subject | Re: [RFC PATCH 07/16] dt-bindings: pinctrl: ralink: add new compatible strings | From | 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ç
| |