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: <3cbbace5-eff9-470e-a530-36895d562556@kernel.org>
Date: Thu, 24 Jul 2025 15:20:29 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Wasim Nazir <wasim.nazir@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Richard Cochran <richardcochran@...il.com>,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org, kernel@....qualcomm.com
Subject: Re: [PATCH 1/7] arm64: dts: qcom: Rename sa8775p SoC to "lemans"

On 24/07/2025 15:11, Konrad Dybcio wrote:
> On 7/24/25 2:51 PM, Krzysztof Kozlowski wrote:
>> On 24/07/2025 14:47, Konrad Dybcio wrote:
>>> On 7/23/25 10:29 AM, 'Krzysztof Kozlowski' via kernel wrote:
>>>> On Tue, Jul 22, 2025 at 08:19:20PM +0530, Wasim Nazir wrote:
>>>>> SA8775P, QCS9100 and QCS9075 are all variants of the same die,
>>>>> collectively referred to as lemans. Most notably, the last of them
>>>>> has the SAIL (Safety Island) fused off, but remains identical
>>>>> otherwise.
>>>>>
>>>>> In an effort to streamline the codebase, rename the SoC DTSI, moving
>>>>> away from less meaningful numerical model identifiers.
>>>>>
>>>>> Signed-off-by: Wasim Nazir <wasim.nazir@....qualcomm.com>
>>>>> ---
>>>>>  arch/arm64/boot/dts/qcom/{sa8775p.dtsi => lemans.dtsi} | 0
>>>>>  arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi             | 2 +-
>>>>
>>>> No, stop with this rename.
>>>>
>>>> There is no policy of renaming existing files.
>>>
>>> There's no policy against renaming existing files either.
>>
>> There is, because you break all the users. All the distros, bootloaders
>> using this DTS, people's scripts.
> 
> Renames happen every now and then, when new variants are added or
> discovered (-oled/lcd, -rev-xyz etc.) and they break things as well.

There is a reason to add new variant. Also it does not break existing
users, so not a good example.

> Same way as (non-uapi) headers move around and break compilation for
> external projects as well.

Maybe they should not...

> 
>>
>>>
>>>> It's ridicilous. Just
>>>> because you introduced a new naming model for NEW SOC, does not mean you
>>>> now going to rename all boards which you already upstreamed.
>>>
>>> This is a genuine improvement, trying to untangle the mess that you
>>> expressed vast discontent about..
>>>
>>> There will be new boards based on this family of SoCs submitted either
>>> way, so I really think it makes sense to solve it once and for all,
>>> instead of bikeshedding over it again and again each time you get a new
>>> dt-bindings change in your inbox.
>>>
>>> I understand you're unhappy about patch 6, but the others are
>>> basically code janitoring.
>>
>> Renaming already accepted DTS is not improvement and not untangling
>> anything. These names were discussed (for very long time) and agreed on.
> 
> We did not have clearance to use the real name of the silicon back then,
> so this wasn't an option.
> 
>> What is the point of spending DT maintainers time to discuss the sa8775p
>> earlier when year later you come and start reversing things (like in
>> patch 6).
> 
> It's quite obviously a huge mess.. but we have a choice between sitting on
> it and complaining, or moving on.
> 
> I don't really see the need for patch 6, but I think the filename changes
> are truly required for sanity going forward.
> We don't want to spawn meaningless .dts files NUM_SKUS * NUM_BOARDS times.

Renaming will not change that. You will have still that amount of boards.

> 
> So far these are basically Qualcomm-internal boards, or at the very least
> there was zero interest shown from people that weren't contracted to work
> on them.

They committed them to upstream for a reason. This comes with
obligations and responsibility, especially for big vendor like Qualcomm.
Qualcomm does not want to commit? No problem, don't upstream...


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ