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

["Arınç ÜNAL" <arinc.unal@arinc9.com>]

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 
introduced with a newer kernel version is not guaranteed to work with 
older kernel versions.

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.

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.

Anyway, I'm not doing this change on this patch series so why don't we 
cross this bridge when we get to it.

Arınç