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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <11d10e4e-65ec-3bec-3e0c-7e57feb03506@arinc9.com>
Date:   Thu, 2 Mar 2023 14:50:49 +0300
From:   Arınç ÜNAL <arinc.unal@...nc9.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Rob Herring <robh@...nel.org>
Cc:     Sergio Paracuellos <sergio.paracuellos@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-mediatek@...ts.infradead.org, linux-mips@...r.kernel.org,
        linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Matthias Brugger <matthias.bgg@...il.com>,
        Sean Wang <sean.wang@...nel.org>,
        William Dean <williamsukatube@...il.com>,
        Daniel Golle <daniel@...rotopia.org>,
        Daniel Santos <daniel.santos@...ox.com>,
        Luiz Angelo Daros de Luca <luizluca@...il.com>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        Landen Chao <Landen.Chao@...iatek.com>,
        DENG Qingfang <dqfext@...il.com>,
        Sean Wang <sean.wang@...iatek.com>, erkin.bozoglu@...ont.com
Subject: Re: [RFC PATCH 07/16] dt-bindings: pinctrl: ralink: add new
 compatible strings

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.

Arınç