Re: [PATCH 1/7] arm64: dts: qcom: Rename sa8775p SoC to "lemans"

[Krzysztof Kozlowski <krzk@kernel.org>]

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@oss.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