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

[Krzysztof Kozlowski]

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