linux-kernel - Re: [PATCH 01/10] dt: bindings: clock: add mtmips SoCs clock device tree binding documentation

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <543ad00d-4171-ed02-0d31-676c6b003e54@arinc9.com>
Date:   Tue, 21 Mar 2023 11:24:39 +0300
From:   Arınç ÜNAL <arinc.unal@...nc9.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Sergio Paracuellos <sergio.paracuellos@...il.com>
Cc:     linux-clk@...r.kernel.org, linux-mips@...r.kernel.org,
        tsbogend@...ha.franken.de, john@...ozen.org,
        linux-kernel@...r.kernel.org, p.zabel@...gutronix.de,
        mturquette@...libre.com, sboyd@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, matthias.bgg@...il.com,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 01/10] dt: bindings: clock: add mtmips SoCs clock device
 tree binding documentation

On 21.03.2023 11:04, Krzysztof Kozlowski wrote:
> On 21/03/2023 08:39, Arınç ÜNAL wrote:
>>>>
>>>> arch/mips/ralink/mt7620.c:      rt_sysc_membase =
>>>> plat_of_remap_node("ralink,mt7620a-sysc");
>>>>
>>>> That's the reason I also used prefix ralink for the rest.
>>>>
>>>> Does it make sense to you to maintain this one as ralink,mt7620a-sysc
>>>> and add the following with mediatek prefix?
>>>>
>>>> mediatek,mt7620-sysc
>>>> mediatek,mt7628-sysc
>>>> mediatek,mt7688-sysc
>>>>
>>>> That would be weird IMHO.
>>>
>>> What exactly would be weird? Did you read the discussion about vendor
>>> prefix from Arinc? mt7620 is not a Ralink product, so what would be
>>> weird is to use "ralink" vendor prefix. This was never a Ralink. However
>>> since there are compatibles using "ralink" for non-ralink devices, we
>>> agreed not to change them.
>>>
>>> These though use at least in one place mediatek, so the above argument
>>> does not apply. (and before you say "but they also use ralink and
>>> mediatek", it does not matter - it is already inconsistent thus we can
>>> choose whatever we want and ralink is not correct).
>>
>> My argument was that your point being Ralink is now Mediatek, thus there
>> is no conflict and no issues with different vendor used. It's the next
>> best thing to be able to address the inconsistency, call everything of
>> the MTMIPS platform ralink on the compatible strings.
> 
> And how does it help consistency? The mt7620 is used also with mediatek
> prefix and adding more variants of realtek does not make the
> inconsistency smaller. It's still inconsistent.
> 
>>
>> If we take the calling new things mediatek route, we will never get to
>> the bottom of fixing the naming inconsistency.
> 
> All new things, so new SoCs, should be called mediatek, because there is
> no ralink and mediatek is already used for them. So why some new
> Mediatek SoCs are "mediatek" but some other also new SoCs are "ralink"?
> 
> You can do nothing (and no actual need) about existing inconsistency...

I couldn't change ralink -> mediatek because company acquisitions don't 
grant the change. I don't see any reason to prevent changing mediatek -> 
ralink without breaking the ABI on the existing schemas.

Arınç