[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b48e0a5e-dd45-8b8a-4ee3-357a0985ca9c@arinc9.com>
Date: Thu, 2 Mar 2023 13:47:05 +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 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.
Arınç
Powered by blists - more mailing lists