linux-kernel - Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

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: <64ee2334-aa99-7226-8946-84c95676041a@canonical.com>
Date:   Fri, 28 Jan 2022 10:57:15 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Luca Weiss <luca@...tu.xyz>, Petr Vorel <petr.vorel@...il.com>,
        linux-arm-msm@...r.kernel.org, Rob Herring <robh+dt@...nel.org>
Cc:     Shawn Guo <shawnguo@...nel.org>,
        Oleksij Rempel <linux@...pel-privat.de>,
        Sam Ravnborg <sam@...nborg.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Daniel Palmer <daniel@...f.com>,
        Max Merchel <Max.Merchel@...group.com>,
        Hao Fang <fanghao11@...wei.com>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Jean THOMAS <virgule@...nthomas.me>
Subject: Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

On 27/01/2022 21:51, Luca Weiss wrote:
> Hi all,
> 
> On Donnerstag, 27. Jänner 2022 08:45:33 CET Krzysztof Kozlowski wrote:
>> On 27/01/2022 01:20, Petr Vorel wrote:
>>> Hi all,
>>>
>>>>> Hi Krzysztof,
>>>>>
>>>>> On Montag, 13. September 2021 10:49:43 CEST Krzysztof Kozlowski wrote:
>>>>>> On 12/09/2021 01:27, Luca Weiss wrote:
>>>>>>> LG Electronics is a part of the LG Corporation and produces, amongst
>>>>>>> other things, consumer electronics such as phones and smartwatches.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Thanks for the patches.
>>>>>>
>>>>>> I think "lge" it's the same prefix as "lg". There is no sense in having
>>>>>> multiple vendor prefixes just because company splits inside business
>>>>>> units or subsidiaries. The same as with other conglomerates, e.g.
>>>>>> Samsung - if we wanted to be specific, there will be 4-5 Samsung
>>>>>> vendors... Not mentioning that company organisation is not always
>>>>>> disclosed and can change.
>>>>>
>>>>> I was mostly following qcom-msm8974-lge-nexus5-hammerhead as it's the
>>>>> other LG device tree I am aware of so I've picked lge instead of lg.
>>>>> Also worth noting that Google uses "LGE" in the Android device tree[1]
>>>>> or in the model name in the LG G Watch R kernel sources ("LGE APQ
>>>>> 8026v2 LENOK rev-1.0")
>>>>
>>>> [1] Does not point to kernel tree. Downstream user could be a good
>>>> argument to switch to lge, but then I would expect correcting other "lg"
>>>> devices which are in fact made by LGE.
>>>>
>>>>> I don't have a strong opinion either way so I'm fine with either.
>>>>>
>>>>> If we decide to go with "lg" do we want to change the Nexus 5 devicetree
>>>>> (hammerhead) also, that one has the lge name in at least compatible and
>>>>> filename (I don't know how much of a breaking change that would be
>>>>> considered as).
>>>>
>>>> We would have to add a new one and mark the old compatible as deprecated.
>>>
>>> Have we sorted this lg- vs. lge- ?
>>>
>>> There are both:
>>> arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
>>> vs
>>> arch/arm/boot/dts/qcom-apq8026-lg-lenok.dts
>>
>> Probably renaming/unifying/correcting prefix in existing compatibles is
>> not worth the effort. This would make a mess and affect other DTS users.
> 
> If wanted I can send a patch renaming the Nexus 5 to just LG, this would 
> adjust both compatible in the file (which shouldn't really affect anything) and 
> the filename (which probably will affect various scripts and whatnot used by 
> existing users of the dtb). 
> Is this something that can be done in mainline or should we rather just let it 
> be? I'm not sure what the policies there are.

The "lge" compatible is already in the bindings, so it should not be
changed without valid reason. Imagine there is an user-space code
parsing compatibles to adjust some power-management settings to
different models. It would be broken now.

What could be done is to mark it as deprecated and a add new one:
compatible = "lg,hammerhead", "lge,hammerhead", "qcom,msm8974";
This should be safe for user-space and allow transition to common "lg".


Best regards,
Krzysztof