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. > 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. > > 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. > > Anyway, I'm not doing this change on this patch series so why don't we > cross this bridge when we get to it. Best regards, Krzysztof
