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 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/arm64/boot/dts/qcom/{sa8775p.dtsi => lemans.dtsi} (100%)
diff --git a/arch/arm64/boot/dts/qcom/sa8775p.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
similarity index 100%
rename from arch/arm64/boot/dts/qcom/sa8775p.dtsi
rename to arch/arm64/boot/dts/qcom/lemans.dtsi
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi
index 63b3031cfcc1..bcd284c0f939 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi
+++ b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi
@@ -8,7 +8,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
-#include "sa8775p.dtsi"
+#include "lemans.dtsi"
#include "sa8775p-pmics.dtsi"
/ {
--
2.49.0On 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. 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.
Best regards,
Krzysztof
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.
> 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.
Konrad
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.
>
>> 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.
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).
Best regards,
Krzysztof
On Thu, Jul 24, 2025 at 02:51:54PM +0200, 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.
>
None of these users are affected by the rename of the .dtsi file.
Patch 5 does have user impact, so that one would be "controversial".
From the answers I've gotten, I'm questioning which of thees files
actually has users - but that's best done in a standalone patch removing
or renaming them, with a proper commit message.
> >
> >> 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.
No, but the rename of the dtsi file and avoiding introducing yet another
qcs<random numbers> prefix in the soup is a huge improvement.
> These names were discussed (for very long time) and agreed on.
> 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).
>
There was no point, all the information wasn't brought to those
discussions...
What we know now is that QCS9100 and QCS9075 (and perhaps more?) are the
Lemans IoT product line and the EVK is the main development board
there on.
It's unclear if there are any lingering users of sa8775p-ride, but
the platform we describe in sa8775p.dtsi doesn't exist anymore. To the
best of my understanding, any users of the ride hardware should be on
qcs9100-ride...
Regards,
Bjorn
On Thu, Jul 24, 2025 at 5:52 AM Krzysztof Kozlowski <krzk@kernel.org> 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.
I think that is a valid argument against renaming the toplevel .dts
(and therefore .dtb), but renaming .dtsi should be a harmless internal
detail to the kernel. And less confusing, IMHO, than
qsc9100-myboard.dts #including sa8775p.dtsi.
So wouldn't the sensible way forward be to rename .dtsi but not .dts?
BR,
-R
> >
> >> 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.
> 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).
>
>
> Best regards,
> Krzysztof
>
On Thu, Jul 24, 2025 at 08:59:38AM -0700, Rob Clark wrote:
> On Thu, Jul 24, 2025 at 5:52 AM Krzysztof Kozlowski <krzk@kernel.org> 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.
>
> I think that is a valid argument against renaming the toplevel .dts
> (and therefore .dtb), but renaming .dtsi should be a harmless internal
> detail to the kernel. And less confusing, IMHO, than
> qsc9100-myboard.dts #including sa8775p.dtsi.
>
> So wouldn't the sensible way forward be to rename .dtsi but not .dts?
FWIIW, and with the dual caveats that: I do not have the full context of
this series; and SoCs are not somewhere where I am active these days:
I am also under the impression that, in general, renames to
match product or other organisational changes are a non-starter.
But reading over this patchset, I also felt that renaming the .dsti files
would improve things. And seems to have little scope to break things for
users.
</2c>
On Sat, Jul 26, 2025 at 07:04:51PM +0100, Simon Horman wrote:
> On Thu, Jul 24, 2025 at 08:59:38AM -0700, Rob Clark wrote:
> > On Thu, Jul 24, 2025 at 5:52 AM Krzysztof Kozlowski <krzk@kernel.org> 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.
> >
> > I think that is a valid argument against renaming the toplevel .dts
> > (and therefore .dtb), but renaming .dtsi should be a harmless internal
> > detail to the kernel. And less confusing, IMHO, than
> > qsc9100-myboard.dts #including sa8775p.dtsi.
> >
> > So wouldn't the sensible way forward be to rename .dtsi but not .dts?
>
> FWIIW, and with the dual caveats that: I do not have the full context of
> this series; and SoCs are not somewhere where I am active these days:
>
> I am also under the impression that, in general, renames to
> match product or other organisational changes are a non-starter.
>
This is indeed a key reason for the new naming scheme. Until now we've
named things based on the "product number" and we're here facing the
introduction of the 3rd product name for the same die.
The purpose of this series is to detach from the product naming (and
introduce the EVK board).
Regards,
Bjorn
> But reading over this patchset, I also felt that renaming the .dsti files
> would improve things. And seems to have little scope to break things for
> users.
>
> </2c>
On Mon, Jul 28, 2025 at 09:36:42PM -0500, Bjorn Andersson wrote:
> On Sat, Jul 26, 2025 at 07:04:51PM +0100, Simon Horman wrote:
> > On Thu, Jul 24, 2025 at 08:59:38AM -0700, Rob Clark wrote:
> > > On Thu, Jul 24, 2025 at 5:52 AM Krzysztof Kozlowski <krzk@kernel.org> 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.
> > >
> > > I think that is a valid argument against renaming the toplevel .dts
> > > (and therefore .dtb), but renaming .dtsi should be a harmless internal
> > > detail to the kernel. And less confusing, IMHO, than
> > > qsc9100-myboard.dts #including sa8775p.dtsi.
> > >
> > > So wouldn't the sensible way forward be to rename .dtsi but not .dts?
> >
> > FWIIW, and with the dual caveats that: I do not have the full context of
> > this series; and SoCs are not somewhere where I am active these days:
> >
> > I am also under the impression that, in general, renames to
> > match product or other organisational changes are a non-starter.
> >
>
> This is indeed a key reason for the new naming scheme. Until now we've
> named things based on the "product number" and we're here facing the
> introduction of the 3rd product name for the same die.
>
> The purpose of this series is to detach from the product naming (and
> introduce the EVK board).
In general, something detached from product naming, and the whims thereof,
does seem sensible to me.
> > But reading over this patchset, I also felt that renaming the .dsti files
> > would improve things. And seems to have little scope to break things for
> > users.
> >
> > </2c>
>
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.
Same way as (non-uapi) headers move around and break compilation for
external projects as well.
>
>>
>>> 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.
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.
Konrad
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
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.
>
> > 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.
>
> >
> > 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
--
With best wishes
Dmitry
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
On 7/22/25 4:49 PM, 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> > --- Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Konrad
© 2016 - 2025 Red Hat, Inc.