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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 24/07/2025 21:07, Dmitry Baryshkov wrote:
> On Thu, Jul 24, 2025 at 03:20:29PM +0200, Krzysztof Kozlowski wrote:
>> 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.
> 
> Sometimes this also causes a rename, so yes, it breaks the users. It not
> frequent, but it's not something unseen.

They shouldn't so, but if that is happening then it is not a reason to
do again. We should not add bugs. But if someone added bugs, do you
claim other people can do the same? We should not break ABI, but if it
happens (is allowed sometimes) is that argument for "I can break ABI too"?

No.


> 
>>
>>> 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.
> 
> It's still that amount of boards, but it's much easier to follow what is
> going on with those boards. You might say that I'm biased, but I think
> this is much better than all previous attempts.

That's not the argument I am disputing. Argument was:

"We don't want to spawn meaningless .dts files NUM_SKUS * NUM_BOARDS times."

I dispute that. You will have the same amount of "meaningless" DTS files.



Best regards,
Krzysztof