[PATCH 0/7] Refactor sa8775p/qcs9100 to common names lemans-auto/lemans

[PATCH 0/7] Refactor sa8775p/qcs9100 to common names lemans-auto/lemans

[Wasim Nazir]

This patch series refactors the sa8775p and qcs9100 platforms and introduces
a unified naming convention for current and future platforms (qcs9075).

The motivation behind this change is to group similar platforms under a
consistent naming scheme and to avoid using numeric identifiers.
For example, qcs9100 and qcs9075 differ only in safety features provided by
the Safety-Island (SAIL) subsystem but safety features are currently
unsupported, so both can be categorized as the same chip today.

Since, most of our platforms are IoT-based so "lemans" can be served as the
default IoT variant, with "lemans-auto" derived from it. Accordingly:
  - qcs9100/qcs9075 and its associated IoT platforms are renamed to lemans
    which needs different memory-map. So, latest memory-map is updated
    here as per IOT requirements.
  - sa8775p and its associated platforms are renamed to "lemans-auto", which
    is derived from "lemans", that retains the old automotive memory map to
    support legacy use cases.
  - Both lemans & lemans-auto are serving as non-safe chip and if needed
    additional dtsi can be appended in the future to enable safety features.

Additionally:
  - Refactor common daughter cards used in Ride/Ride-R3 platforms into a
    common configuration. Also, introduce new files for different ethernet
    capabilities in Ride/Ride-r3. Since Ethernet functionality in Ride/Ride-r3
    is currently broken upstream, this patch focuses only on refactoring.
  - Include support for qcs9075 EVK[1] platform as lemans-evk. Currently,
    basic features are enabled supporting 'boot to shell'.
  - Remove support for qcs9100-ride, as no platform currently exists for it.

Funtional impact to current boards with refactoring:
  - No functional change on auto boards i.e sa8775p ride/ride-r3 boards
    (renamed as lemans-auto ride/ride-r3), and it is verified by comparing
    decompiled DTB (dtx_diff).
  - qcs9100 ride-r3 (renamed as lemans-ride-r3) is having new memory-map
    and rest other functionalities are still same.

[1] https://lore.kernel.org/all/20250612155437.146925-1-quic_wasimn@quicinc.com/


---
Wasim Nazir (7):
  arm64: dts: qcom: Rename sa8775p SoC to "lemans"
  arm64: dts: qcom: Update memory-map for IoT platforms in lemans
  arm64: dts: qcom: lemans: Separate out ethernet card for ride &
    ride-r3
  arm64: dts: qcom: lemans: Refactor ride/ride-r3 boards based on
    daughter cards
  arm64: dts: qcom: lemans: Rename boards and clean up unsupported
    platforms
  dt-bindings: arm: qcom: Refactor QCS9100 and SA8775P board names to
    reflect Lemans variants
  arm64: dts: qcom: Add lemans evaluation kit (EVK) initial board
    support

 .../devicetree/bindings/arm/qcom.yaml         |  16 +-
 arch/arm64/boot/dts/qcom/Makefile             |   8 +-
 ...8775p-ride.dts => lemans-auto-ride-r3.dts} |  44 +--
 ...{qcs9100-ride.dts => lemans-auto-ride.dts} |  14 +-
 arch/arm64/boot/dts/qcom/lemans-auto.dtsi     | 104 +++++++
 arch/arm64/boot/dts/qcom/lemans-evk.dts       | 291 ++++++++++++++++++
 .../{sa8775p-pmics.dtsi => lemans-pmics.dtsi} |   0
 ...775p-ride.dtsi => lemans-ride-common.dtsi} | 168 ----------
 .../qcom/lemans-ride-ethernet-88ea1512.dtsi   | 205 ++++++++++++
 .../qcom/lemans-ride-ethernet-aqr115c.dtsi    | 205 ++++++++++++
 ...qcs9100-ride-r3.dts => lemans-ride-r3.dts} |  12 +-
 .../dts/qcom/{sa8775p.dtsi => lemans.dtsi}    |  75 +++--
 arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts  |  47 ---
 13 files changed, 884 insertions(+), 305 deletions(-)
 rename arch/arm64/boot/dts/qcom/{sa8775p-ride.dts => lemans-auto-ride-r3.dts} (11%)
 rename arch/arm64/boot/dts/qcom/{qcs9100-ride.dts => lemans-auto-ride.dts} (18%)
 create mode 100644 arch/arm64/boot/dts/qcom/lemans-auto.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/lemans-evk.dts
 rename arch/arm64/boot/dts/qcom/{sa8775p-pmics.dtsi => lemans-pmics.dtsi} (100%)
 rename arch/arm64/boot/dts/qcom/{sa8775p-ride.dtsi => lemans-ride-common.dtsi} (87%)
 create mode 100644 arch/arm64/boot/dts/qcom/lemans-ride-ethernet-88ea1512.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/lemans-ride-ethernet-aqr115c.dtsi
 rename arch/arm64/boot/dts/qcom/{qcs9100-ride-r3.dts => lemans-ride-r3.dts} (36%)
 rename arch/arm64/boot/dts/qcom/{sa8775p.dtsi => lemans.dtsi} (99%)
 delete mode 100644 arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts


base-commit: 05adbee3ad528100ab0285c15c91100e19e10138
--
2.49.0

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

[Wasim Nazir]

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.0

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

[Konrad Dybcio]

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

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

[Krzysztof Kozlowski]

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

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

[Konrad Dybcio]

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

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

[Krzysztof Kozlowski]

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

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

[Konrad Dybcio]

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

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

[Krzysztof Kozlowski]

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

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

[Dmitry Baryshkov]

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

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

[Krzysztof Kozlowski]

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

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

[Rob Clark]

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
>

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

[Simon Horman]

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>

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

[Bjorn Andersson]

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>

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

[Simon Horman]

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>
> 

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

[Bjorn Andersson]

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

[PATCH 2/7] arm64: dts: qcom: Update memory-map for IoT platforms in lemans

[Wasim Nazir]

Stop using the outdated automotive memory map for Lemans; update it to
meet IoT requirements.

Since, most platforms are IoT-based, treat IoT as the default variant
under "lemans" and apply it to all platforms, except those requiring the
old memory-map (e.g., sa8775p, ride, and ride-r3).
Introduce "lemans-auto" as a derivative of "lemans" that retains the old
automotive memory map to support legacy use cases.

As part of the IoT memory map updates:
  - Introduce new carveouts for gunyah_md and pil_dtb. Adjust the size and
    base address of the PIL carveout to accommodate these changes.
  - Increase the size of the video/camera PIL carveout without affecting
    existing functionality.
  - Reduce the size of the trusted apps carveout to meet IoT-specific
    requirements.
  - Remove audio_mdf_mem, tz_ffi_mem, and their corresponding SCM references,
    as they are not required for IoT platforms.

Co-developed-by: Pratyush Brahma <quic_pbrahma@quicinc.com>
Signed-off-by: Pratyush Brahma <quic_pbrahma@quicinc.com>
Co-developed-by: Prakash Gupta <quic_guptap@quicinc.com>
Signed-off-by: Prakash Gupta <quic_guptap@quicinc.com>
Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/lemans-auto.dtsi  | 104 +++++++++++++++++++++
 arch/arm64/boot/dts/qcom/lemans.dtsi       |  75 +++++++++------
 arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi |   2 +-
 3 files changed, 149 insertions(+), 32 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/lemans-auto.dtsi

diff --git a/arch/arm64/boot/dts/qcom/lemans-auto.dtsi b/arch/arm64/boot/dts/qcom/lemans-auto.dtsi
new file mode 100644
index 000000000000..8db958d60fd1
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/lemans-auto.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+/dts-v1/;
+
+#include "lemans.dtsi"
+
+/delete-node/ &pil_camera_mem;
+/delete-node/ &pil_adsp_mem;
+/delete-node/ &q6_adsp_dtb_mem;
+/delete-node/ &q6_gdsp0_dtb_mem;
+/delete-node/ &pil_gdsp0_mem;
+/delete-node/ &pil_gdsp1_mem;
+/delete-node/ &q6_gdsp1_dtb_mem;
+/delete-node/ &q6_cdsp0_dtb_mem;
+/delete-node/ &pil_cdsp0_mem;
+/delete-node/ &pil_gpu_mem;
+/delete-node/ &pil_cdsp1_mem;
+/delete-node/ &q6_cdsp1_dtb_mem;
+/delete-node/ &pil_cvp_mem;
+/delete-node/ &pil_video_mem;
+/delete-node/ &gunyah_md_mem;
+
+/ {
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		tz_ffi_mem: tz-ffi@91c00000 {
+			compatible = "shared-dma-pool";
+			reg = <0x0 0x91c00000 0x0 0x1400000>;
+			no-map;
+		};
+
+		pil_camera_mem: pil-camera@95200000 {
+			reg = <0x0 0x95200000 0x0 0x500000>;
+			no-map;
+		};
+
+		pil_adsp_mem: pil-adsp@95c00000 {
+			reg = <0x0 0x95c00000 0x0 0x1e00000>;
+			no-map;
+		};
+
+		pil_gdsp0_mem: pil-gdsp0@97b00000 {
+			reg = <0x0 0x97b00000 0x0 0x1e00000>;
+			no-map;
+		};
+
+		pil_gdsp1_mem: pil-gdsp1@99900000 {
+			reg = <0x0 0x99900000 0x0 0x1e00000>;
+			no-map;
+		};
+
+		pil_cdsp0_mem: pil-cdsp0@9b800000 {
+			reg = <0x0 0x9b800000 0x0 0x1e00000>;
+			no-map;
+		};
+
+		pil_gpu_mem: pil-gpu@9d600000 {
+			reg = <0x0 0x9d600000 0x0 0x2000>;
+			no-map;
+		};
+
+		pil_cdsp1_mem: pil-cdsp1@9d700000 {
+			reg = <0x0 0x9d700000 0x0 0x1e00000>;
+			no-map;
+		};
+
+		pil_cvp_mem: pil-cvp@9f500000 {
+			reg = <0x0 0x9f500000 0x0 0x700000>;
+			no-map;
+		};
+
+		pil_video_mem: pil-video@9fc00000 {
+			reg = <0x0 0x9fc00000 0x0 0x700000>;
+			no-map;
+		};
+
+		audio_mdf_mem: audio-mdf-region@ae000000 {
+			reg = <0x0 0xae000000 0x0 0x1000000>;
+			no-map;
+		};
+
+		hyptz_reserved_mem: hyptz-reserved@beb00000 {
+			reg = <0x0 0xbeb00000 0x0 0x11500000>;
+			no-map;
+		};
+
+		trusted_apps_mem: trusted-apps@d1900000 {
+			reg = <0x0 0xd1900000 0x0 0x3800000>;
+			no-map;
+		};
+	};
+
+	firmware {
+		scm {
+			memory-region = <&tz_ffi_mem>;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index 9997a29901f5..bf273660e0cb 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -514,7 +514,6 @@ firmware {
 		scm {
 			compatible = "qcom,scm-sa8775p", "qcom,scm";
 			qcom,dload-mode = <&tcsr 0x13000>;
-			memory-region = <&tz_ffi_mem>;
 		};
 	};

@@ -773,6 +772,11 @@ sail_ota_mem: sail-ss@90e00000 {
 			no-map;
 		};

+		gunyah_md_mem: gunyah-md@91a80000 {
+			reg = <0x0 0x91a80000 0x0 0x80000>;
+			no-map;
+		};
+
 		aoss_backup_mem: aoss-backup@91b00000 {
 			reg = <0x0 0x91b00000 0x0 0x40000>;
 			no-map;
@@ -798,12 +802,6 @@ cdt_data_backup_mem: cdt-data-backup@91ba0000 {
 			no-map;
 		};

-		tz_ffi_mem: tz-ffi@91c00000 {
-			compatible = "shared-dma-pool";
-			reg = <0x0 0x91c00000 0x0 0x1400000>;
-			no-map;
-		};
-
 		lpass_machine_learning_mem: lpass-machine-learning@93b00000 {
 			reg = <0x0 0x93b00000 0x0 0xf00000>;
 			no-map;
@@ -815,62 +813,77 @@ adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap@94a00000 {
 		};

 		pil_camera_mem: pil-camera@95200000 {
-			reg = <0x0 0x95200000 0x0 0x500000>;
+			reg = <0x0 0x95200000 0x0 0x700000>;
 			no-map;
 		};

-		pil_adsp_mem: pil-adsp@95c00000 {
-			reg = <0x0 0x95c00000 0x0 0x1e00000>;
+		pil_adsp_mem: pil-adsp@95900000 {
+			reg = <0x0 0x95900000 0x0 0x1e00000>;
 			no-map;
 		};

-		pil_gdsp0_mem: pil-gdsp0@97b00000 {
-			reg = <0x0 0x97b00000 0x0 0x1e00000>;
+		q6_adsp_dtb_mem: q6-adsp-dtb@97700000 {
+			reg = <0x0 0x97700000 0x0 0x80000>;
 			no-map;
 		};

-		pil_gdsp1_mem: pil-gdsp1@99900000 {
-			reg = <0x0 0x99900000 0x0 0x1e00000>;
+		q6_gdsp0_dtb_mem: q6-gdsp0-dtb@97780000 {
+			reg = <0x0 0x97780000 0x0 0x80000>;
 			no-map;
 		};

-		pil_cdsp0_mem: pil-cdsp0@9b800000 {
-			reg = <0x0 0x9b800000 0x0 0x1e00000>;
+		pil_gdsp0_mem: pil-gdsp0@97800000 {
+			reg = <0x0 0x97800000 0x0 0x1e00000>;
 			no-map;
 		};

-		pil_gpu_mem: pil-gpu@9d600000 {
-			reg = <0x0 0x9d600000 0x0 0x2000>;
+		pil_gdsp1_mem: pil-gdsp1@99600000 {
+			reg = <0x0 0x99600000 0x0 0x1e00000>;
 			no-map;
 		};

-		pil_cdsp1_mem: pil-cdsp1@9d700000 {
-			reg = <0x0 0x9d700000 0x0 0x1e00000>;
+		q6_gdsp1_dtb_mem: q6-gdsp1-dtb@9b400000 {
+			reg = <0x0 0x9b400000 0x0 0x80000>;
 			no-map;
 		};

-		pil_cvp_mem: pil-cvp@9f500000 {
-			reg = <0x0 0x9f500000 0x0 0x700000>;
+		q6_cdsp0_dtb_mem: q6-cdsp0-dtb@9b480000 {
+			reg = <0x0 0x9b480000 0x0 0x80000>;
 			no-map;
 		};

-		pil_video_mem: pil-video@9fc00000 {
-			reg = <0x0 0x9fc00000 0x0 0x700000>;
+		pil_cdsp0_mem: pil-cdsp0@9b500000 {
+			reg = <0x0 0x9b500000 0x0 0x1e00000>;
 			no-map;
 		};

-		audio_mdf_mem: audio-mdf-region@ae000000 {
-			reg = <0x0 0xae000000 0x0 0x1000000>;
+		pil_gpu_mem: pil-gpu@9d300000 {
+			reg = <0x0 0x9d300000 0x0 0x2000>;
 			no-map;
 		};

-		firmware_mem: firmware-region@b0000000 {
-			reg = <0x0 0xb0000000 0x0 0x800000>;
+		q6_cdsp1_dtb_mem: q6-cdsp1-dtb@9d380000 {
+			reg = <0x0 0x9d380000 0x0 0x80000>;
 			no-map;
 		};

-		hyptz_reserved_mem: hyptz-reserved@beb00000 {
-			reg = <0x0 0xbeb00000 0x0 0x11500000>;
+		pil_cdsp1_mem: pil-cdsp1@9d400000 {
+			reg = <0x0 0x9d400000 0x0 0x1e00000>;
+			no-map;
+		};
+
+		pil_cvp_mem: pil-cvp@9f200000 {
+			reg = <0x0 0x9f200000 0x0 0x700000>;
+			no-map;
+		};
+
+		pil_video_mem: pil-video@9f900000 {
+			reg = <0x0 0x9f900000 0x0 0x1000000>;
+			no-map;
+		};
+
+		firmware_mem: firmware-region@b0000000 {
+			reg = <0x0 0xb0000000 0x0 0x800000>;
 			no-map;
 		};

@@ -915,7 +928,7 @@ deepsleep_backup_mem: deepsleep-backup@d1800000 {
 		};

 		trusted_apps_mem: trusted-apps@d1900000 {
-			reg = <0x0 0xd1900000 0x0 0x3800000>;
+			reg = <0x0 0xd1900000 0x0 0x1c00000>;
 			no-map;
 		};

diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi
index bcd284c0f939..a9ec6ded412e 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 "lemans.dtsi"
+#include "lemans-auto.dtsi"
 #include "sa8775p-pmics.dtsi"

 / {
--
2.49.0

Re: [PATCH 2/7] arm64: dts: qcom: Update memory-map for IoT platforms in lemans

[Bjorn Andersson]

On Tue, Jul 22, 2025 at 08:19:21PM +0530, Wasim Nazir wrote:

Please prefix the $subject with "arm64: dts: qcom: lemans: ".

> Stop using the outdated automotive memory map for Lemans; update it to
> meet IoT requirements.
> 

Please start your commit message with the problem description, not a
summary of the solution.

> Since, most platforms are IoT-based, treat IoT as the default variant

The word "platform" is mostly equivalent to "soc" outside Qualcomm, so
this statement is weird.

Regards,
Bjorn

> under "lemans" and apply it to all platforms, except those requiring the
> old memory-map (e.g., sa8775p, ride, and ride-r3).
> Introduce "lemans-auto" as a derivative of "lemans" that retains the old
> automotive memory map to support legacy use cases.
> 
> As part of the IoT memory map updates:
>   - Introduce new carveouts for gunyah_md and pil_dtb. Adjust the size and
>     base address of the PIL carveout to accommodate these changes.
>   - Increase the size of the video/camera PIL carveout without affecting
>     existing functionality.
>   - Reduce the size of the trusted apps carveout to meet IoT-specific
>     requirements.
>   - Remove audio_mdf_mem, tz_ffi_mem, and their corresponding SCM references,
>     as they are not required for IoT platforms.
> 
> Co-developed-by: Pratyush Brahma <quic_pbrahma@quicinc.com>
> Signed-off-by: Pratyush Brahma <quic_pbrahma@quicinc.com>
> Co-developed-by: Prakash Gupta <quic_guptap@quicinc.com>
> Signed-off-by: Prakash Gupta <quic_guptap@quicinc.com>
> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/lemans-auto.dtsi  | 104 +++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/lemans.dtsi       |  75 +++++++++------
>  arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi |   2 +-
>  3 files changed, 149 insertions(+), 32 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/qcom/lemans-auto.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/lemans-auto.dtsi b/arch/arm64/boot/dts/qcom/lemans-auto.dtsi
> new file mode 100644
> index 000000000000..8db958d60fd1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/lemans-auto.dtsi
> @@ -0,0 +1,104 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2023, Linaro Limited
> + */
> +
> +/dts-v1/;
> +
> +#include "lemans.dtsi"
> +
> +/delete-node/ &pil_camera_mem;
> +/delete-node/ &pil_adsp_mem;
> +/delete-node/ &q6_adsp_dtb_mem;
> +/delete-node/ &q6_gdsp0_dtb_mem;
> +/delete-node/ &pil_gdsp0_mem;
> +/delete-node/ &pil_gdsp1_mem;
> +/delete-node/ &q6_gdsp1_dtb_mem;
> +/delete-node/ &q6_cdsp0_dtb_mem;
> +/delete-node/ &pil_cdsp0_mem;
> +/delete-node/ &pil_gpu_mem;
> +/delete-node/ &pil_cdsp1_mem;
> +/delete-node/ &q6_cdsp1_dtb_mem;
> +/delete-node/ &pil_cvp_mem;
> +/delete-node/ &pil_video_mem;
> +/delete-node/ &gunyah_md_mem;
> +
> +/ {
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		tz_ffi_mem: tz-ffi@91c00000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x0 0x91c00000 0x0 0x1400000>;
> +			no-map;
> +		};
> +
> +		pil_camera_mem: pil-camera@95200000 {
> +			reg = <0x0 0x95200000 0x0 0x500000>;
> +			no-map;
> +		};
> +
> +		pil_adsp_mem: pil-adsp@95c00000 {
> +			reg = <0x0 0x95c00000 0x0 0x1e00000>;
> +			no-map;
> +		};
> +
> +		pil_gdsp0_mem: pil-gdsp0@97b00000 {
> +			reg = <0x0 0x97b00000 0x0 0x1e00000>;
> +			no-map;
> +		};
> +
> +		pil_gdsp1_mem: pil-gdsp1@99900000 {
> +			reg = <0x0 0x99900000 0x0 0x1e00000>;
> +			no-map;
> +		};
> +
> +		pil_cdsp0_mem: pil-cdsp0@9b800000 {
> +			reg = <0x0 0x9b800000 0x0 0x1e00000>;
> +			no-map;
> +		};
> +
> +		pil_gpu_mem: pil-gpu@9d600000 {
> +			reg = <0x0 0x9d600000 0x0 0x2000>;
> +			no-map;
> +		};
> +
> +		pil_cdsp1_mem: pil-cdsp1@9d700000 {
> +			reg = <0x0 0x9d700000 0x0 0x1e00000>;
> +			no-map;
> +		};
> +
> +		pil_cvp_mem: pil-cvp@9f500000 {
> +			reg = <0x0 0x9f500000 0x0 0x700000>;
> +			no-map;
> +		};
> +
> +		pil_video_mem: pil-video@9fc00000 {
> +			reg = <0x0 0x9fc00000 0x0 0x700000>;
> +			no-map;
> +		};
> +
> +		audio_mdf_mem: audio-mdf-region@ae000000 {
> +			reg = <0x0 0xae000000 0x0 0x1000000>;
> +			no-map;
> +		};
> +
> +		hyptz_reserved_mem: hyptz-reserved@beb00000 {
> +			reg = <0x0 0xbeb00000 0x0 0x11500000>;
> +			no-map;
> +		};
> +
> +		trusted_apps_mem: trusted-apps@d1900000 {
> +			reg = <0x0 0xd1900000 0x0 0x3800000>;
> +			no-map;
> +		};
> +	};
> +
> +	firmware {
> +		scm {
> +			memory-region = <&tz_ffi_mem>;
> +		};
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
> index 9997a29901f5..bf273660e0cb 100644
> --- a/arch/arm64/boot/dts/qcom/lemans.dtsi
> +++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
> @@ -514,7 +514,6 @@ firmware {
>  		scm {
>  			compatible = "qcom,scm-sa8775p", "qcom,scm";
>  			qcom,dload-mode = <&tcsr 0x13000>;
> -			memory-region = <&tz_ffi_mem>;
>  		};
>  	};
> 
> @@ -773,6 +772,11 @@ sail_ota_mem: sail-ss@90e00000 {
>  			no-map;
>  		};
> 
> +		gunyah_md_mem: gunyah-md@91a80000 {
> +			reg = <0x0 0x91a80000 0x0 0x80000>;
> +			no-map;
> +		};
> +
>  		aoss_backup_mem: aoss-backup@91b00000 {
>  			reg = <0x0 0x91b00000 0x0 0x40000>;
>  			no-map;
> @@ -798,12 +802,6 @@ cdt_data_backup_mem: cdt-data-backup@91ba0000 {
>  			no-map;
>  		};
> 
> -		tz_ffi_mem: tz-ffi@91c00000 {
> -			compatible = "shared-dma-pool";
> -			reg = <0x0 0x91c00000 0x0 0x1400000>;
> -			no-map;
> -		};
> -
>  		lpass_machine_learning_mem: lpass-machine-learning@93b00000 {
>  			reg = <0x0 0x93b00000 0x0 0xf00000>;
>  			no-map;
> @@ -815,62 +813,77 @@ adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap@94a00000 {
>  		};
> 
>  		pil_camera_mem: pil-camera@95200000 {
> -			reg = <0x0 0x95200000 0x0 0x500000>;
> +			reg = <0x0 0x95200000 0x0 0x700000>;
>  			no-map;
>  		};
> 
> -		pil_adsp_mem: pil-adsp@95c00000 {
> -			reg = <0x0 0x95c00000 0x0 0x1e00000>;
> +		pil_adsp_mem: pil-adsp@95900000 {
> +			reg = <0x0 0x95900000 0x0 0x1e00000>;
>  			no-map;
>  		};
> 
> -		pil_gdsp0_mem: pil-gdsp0@97b00000 {
> -			reg = <0x0 0x97b00000 0x0 0x1e00000>;
> +		q6_adsp_dtb_mem: q6-adsp-dtb@97700000 {
> +			reg = <0x0 0x97700000 0x0 0x80000>;
>  			no-map;
>  		};
> 
> -		pil_gdsp1_mem: pil-gdsp1@99900000 {
> -			reg = <0x0 0x99900000 0x0 0x1e00000>;
> +		q6_gdsp0_dtb_mem: q6-gdsp0-dtb@97780000 {
> +			reg = <0x0 0x97780000 0x0 0x80000>;
>  			no-map;
>  		};
> 
> -		pil_cdsp0_mem: pil-cdsp0@9b800000 {
> -			reg = <0x0 0x9b800000 0x0 0x1e00000>;
> +		pil_gdsp0_mem: pil-gdsp0@97800000 {
> +			reg = <0x0 0x97800000 0x0 0x1e00000>;
>  			no-map;
>  		};
> 
> -		pil_gpu_mem: pil-gpu@9d600000 {
> -			reg = <0x0 0x9d600000 0x0 0x2000>;
> +		pil_gdsp1_mem: pil-gdsp1@99600000 {
> +			reg = <0x0 0x99600000 0x0 0x1e00000>;
>  			no-map;
>  		};
> 
> -		pil_cdsp1_mem: pil-cdsp1@9d700000 {
> -			reg = <0x0 0x9d700000 0x0 0x1e00000>;
> +		q6_gdsp1_dtb_mem: q6-gdsp1-dtb@9b400000 {
> +			reg = <0x0 0x9b400000 0x0 0x80000>;
>  			no-map;
>  		};
> 
> -		pil_cvp_mem: pil-cvp@9f500000 {
> -			reg = <0x0 0x9f500000 0x0 0x700000>;
> +		q6_cdsp0_dtb_mem: q6-cdsp0-dtb@9b480000 {
> +			reg = <0x0 0x9b480000 0x0 0x80000>;
>  			no-map;
>  		};
> 
> -		pil_video_mem: pil-video@9fc00000 {
> -			reg = <0x0 0x9fc00000 0x0 0x700000>;
> +		pil_cdsp0_mem: pil-cdsp0@9b500000 {
> +			reg = <0x0 0x9b500000 0x0 0x1e00000>;
>  			no-map;
>  		};
> 
> -		audio_mdf_mem: audio-mdf-region@ae000000 {
> -			reg = <0x0 0xae000000 0x0 0x1000000>;
> +		pil_gpu_mem: pil-gpu@9d300000 {
> +			reg = <0x0 0x9d300000 0x0 0x2000>;
>  			no-map;
>  		};
> 
> -		firmware_mem: firmware-region@b0000000 {
> -			reg = <0x0 0xb0000000 0x0 0x800000>;
> +		q6_cdsp1_dtb_mem: q6-cdsp1-dtb@9d380000 {
> +			reg = <0x0 0x9d380000 0x0 0x80000>;
>  			no-map;
>  		};
> 
> -		hyptz_reserved_mem: hyptz-reserved@beb00000 {
> -			reg = <0x0 0xbeb00000 0x0 0x11500000>;
> +		pil_cdsp1_mem: pil-cdsp1@9d400000 {
> +			reg = <0x0 0x9d400000 0x0 0x1e00000>;
> +			no-map;
> +		};
> +
> +		pil_cvp_mem: pil-cvp@9f200000 {
> +			reg = <0x0 0x9f200000 0x0 0x700000>;
> +			no-map;
> +		};
> +
> +		pil_video_mem: pil-video@9f900000 {
> +			reg = <0x0 0x9f900000 0x0 0x1000000>;
> +			no-map;
> +		};
> +
> +		firmware_mem: firmware-region@b0000000 {
> +			reg = <0x0 0xb0000000 0x0 0x800000>;
>  			no-map;
>  		};
> 
> @@ -915,7 +928,7 @@ deepsleep_backup_mem: deepsleep-backup@d1800000 {
>  		};
> 
>  		trusted_apps_mem: trusted-apps@d1900000 {
> -			reg = <0x0 0xd1900000 0x0 0x3800000>;
> +			reg = <0x0 0xd1900000 0x0 0x1c00000>;
>  			no-map;
>  		};
> 
> diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi
> index bcd284c0f939..a9ec6ded412e 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 "lemans.dtsi"
> +#include "lemans-auto.dtsi"
>  #include "sa8775p-pmics.dtsi"
> 
>  / {
> --
> 2.49.0
> 

[PATCH 3/7] arm64: dts: qcom: lemans: Separate out ethernet card for ride & ride-r3

[Wasim Nazir]

Ride & Ride-r3 in lemans/lemans-auto uses different ethernet cards
with different phy capabilities. Separate out the ethernet card
information from main board so that it can be reused for all the
variants of ride & ride-r3 platforms in lemans/lemans-auto.

Lemans/lemans-auto Ride uses 1G phy while Lemans/lemans-auto Ride-r3
uses 2.5G phy.

Introduce ethernet cards with 1G & 2.5G phy capabilities respectively:
  *-88ea1512.dtsi is for 2x 1G - SGMII (Marvell 88EA1512-B2) phy
  *-aqr115c.dtsi is for 2x 2.5G - HSGMII (Marvell AQR115c) phy

Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
---
 .../qcom/lemans-ride-ethernet-88ea1512.dtsi   | 205 ++++++++++++++++++
 .../qcom/lemans-ride-ethernet-aqr115c.dtsi    | 205 ++++++++++++++++++
 arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts  |  35 +--
 arch/arm64/boot/dts/qcom/sa8775p-ride.dts     |  35 +--
 arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi    | 163 --------------
 5 files changed, 412 insertions(+), 231 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/lemans-ride-ethernet-88ea1512.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/lemans-ride-ethernet-aqr115c.dtsi

diff --git a/arch/arm64/boot/dts/qcom/lemans-ride-ethernet-88ea1512.dtsi b/arch/arm64/boot/dts/qcom/lemans-ride-ethernet-88ea1512.dtsi
new file mode 100644
index 000000000000..9d6bbe1447a4
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/lemans-ride-ethernet-88ea1512.dtsi
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+/*
+ * Ethernet card for Lemans based Ride boards.
+ * It supports 2x 1G - SGMII (Marvell 88EA1512-B2) phy for Main domain
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	aliases {
+		ethernet0 = &ethernet0;
+		ethernet1 = &ethernet1;
+	};
+};
+
+&tlmm {
+	ethernet0_default: ethernet0-default-state {
+		ethernet0_mdc: ethernet0-mdc-pins {
+			pins = "gpio8";
+			function = "emac0_mdc";
+			drive-strength = <16>;
+			bias-pull-up;
+		};
+
+		ethernet0_mdio: ethernet0-mdio-pins {
+			pins = "gpio9";
+			function = "emac0_mdio";
+			drive-strength = <16>;
+			bias-pull-up;
+		};
+	};
+};
+
+&ethernet0 {
+	phy-handle = <&sgmii_phy0>;
+	phy-mode = "sgmii";
+
+	pinctrl-0 = <&ethernet0_default>;
+	pinctrl-names = "default";
+
+	snps,mtl-rx-config = <&mtl_rx_setup>;
+	snps,mtl-tx-config = <&mtl_tx_setup>;
+	snps,ps-speed = <1000>;
+
+	status = "okay";
+
+	mdio {
+		compatible = "snps,dwmac-mdio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		sgmii_phy0: phy@8 {
+			compatible = "ethernet-phy-id0141.0dd4";
+			reg = <0x8>;
+			device_type = "ethernet-phy";
+			interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
+			reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <11000>;
+			reset-deassert-us = <70000>;
+		};
+
+		sgmii_phy1: phy@a {
+			compatible = "ethernet-phy-id0141.0dd4";
+			reg = <0xa>;
+			device_type = "ethernet-phy";
+			interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
+			reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <11000>;
+			reset-deassert-us = <70000>;
+		};
+	};
+
+	mtl_rx_setup: rx-queues-config {
+		snps,rx-queues-to-use = <4>;
+		snps,rx-sched-sp;
+
+		queue0 {
+			snps,dcb-algorithm;
+			snps,map-to-dma-channel = <0x0>;
+			snps,route-up;
+			snps,priority = <0x1>;
+		};
+
+		queue1 {
+			snps,dcb-algorithm;
+			snps,map-to-dma-channel = <0x1>;
+			snps,route-ptp;
+		};
+
+		queue2 {
+			snps,avb-algorithm;
+			snps,map-to-dma-channel = <0x2>;
+			snps,route-avcp;
+		};
+
+		queue3 {
+			snps,avb-algorithm;
+			snps,map-to-dma-channel = <0x3>;
+			snps,priority = <0xc>;
+		};
+	};
+
+	mtl_tx_setup: tx-queues-config {
+		snps,tx-queues-to-use = <4>;
+
+		queue0 {
+			snps,dcb-algorithm;
+		};
+
+		queue1 {
+			snps,dcb-algorithm;
+		};
+
+		queue2 {
+			snps,avb-algorithm;
+			snps,send_slope = <0x1000>;
+			snps,idle_slope = <0x1000>;
+			snps,high_credit = <0x3e800>;
+			snps,low_credit = <0xffc18000>;
+		};
+
+		queue3 {
+			snps,avb-algorithm;
+			snps,send_slope = <0x1000>;
+			snps,idle_slope = <0x1000>;
+			snps,high_credit = <0x3e800>;
+			snps,low_credit = <0xffc18000>;
+		};
+	};
+};
+
+&ethernet1 {
+	phy-handle = <&sgmii_phy1>;
+	phy-mode = "sgmii";
+
+	snps,mtl-rx-config = <&mtl_rx_setup1>;
+	snps,mtl-tx-config = <&mtl_tx_setup1>;
+	snps,ps-speed = <1000>;
+
+	status = "okay";
+
+	mtl_rx_setup1: rx-queues-config {
+		snps,rx-queues-to-use = <4>;
+		snps,rx-sched-sp;
+
+		queue0 {
+			snps,dcb-algorithm;
+			snps,map-to-dma-channel = <0x0>;
+			snps,route-up;
+			snps,priority = <0x1>;
+		};
+
+		queue1 {
+			snps,dcb-algorithm;
+			snps,map-to-dma-channel = <0x1>;
+			snps,route-ptp;
+		};
+
+		queue2 {
+			snps,avb-algorithm;
+			snps,map-to-dma-channel = <0x2>;
+			snps,route-avcp;
+		};
+
+		queue3 {
+			snps,avb-algorithm;
+			snps,map-to-dma-channel = <0x3>;
+			snps,priority = <0xc>;
+		};
+	};
+
+	mtl_tx_setup1: tx-queues-config {
+		snps,tx-queues-to-use = <4>;
+
+		queue0 {
+			snps,dcb-algorithm;
+		};
+
+		queue1 {
+			snps,dcb-algorithm;
+		};
+
+		queue2 {
+			snps,avb-algorithm;
+			snps,send_slope = <0x1000>;
+			snps,idle_slope = <0x1000>;
+			snps,high_credit = <0x3e800>;
+			snps,low_credit = <0xffc18000>;
+		};
+
+		queue3 {
+			snps,avb-algorithm;
+			snps,send_slope = <0x1000>;
+			snps,idle_slope = <0x1000>;
+			snps,high_credit = <0x3e800>;
+			snps,low_credit = <0xffc18000>;
+		};
+	};
+};
+
diff --git a/arch/arm64/boot/dts/qcom/lemans-ride-ethernet-aqr115c.dtsi b/arch/arm64/boot/dts/qcom/lemans-ride-ethernet-aqr115c.dtsi
new file mode 100644
index 000000000000..2d2d9ee5f0d9
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/lemans-ride-ethernet-aqr115c.dtsi
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+/*
+ * Ethernet card for Lemans based Ride r3 boards.
+ * It supports 2x 2.5G - HSGMII (Marvell hsgmii) phy for Main domain
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	aliases {
+		ethernet0 = &ethernet0;
+		ethernet1 = &ethernet1;
+	};
+};
+
+&tlmm {
+	ethernet0_default: ethernet0-default-state {
+		ethernet0_mdc: ethernet0-mdc-pins {
+			pins = "gpio8";
+			function = "emac0_mdc";
+			drive-strength = <16>;
+			bias-pull-up;
+		};
+
+		ethernet0_mdio: ethernet0-mdio-pins {
+			pins = "gpio9";
+			function = "emac0_mdio";
+			drive-strength = <16>;
+			bias-pull-up;
+		};
+	};
+};
+
+&ethernet0 {
+	phy-handle = <&hsgmii_phy0>;
+	phy-mode = "2500base-x";
+
+	pinctrl-0 = <&ethernet0_default>;
+	pinctrl-names = "default";
+
+	snps,mtl-rx-config = <&mtl_rx_setup>;
+	snps,mtl-tx-config = <&mtl_tx_setup>;
+	snps,ps-speed = <1000>;
+
+	status = "okay";
+
+	mdio {
+		compatible = "snps,dwmac-mdio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		hsgmii_phy0: phy@8 {
+			compatible = "ethernet-phy-id31c3.1c33";
+			reg = <0x8>;
+			device_type = "ethernet-phy";
+			interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
+			reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <11000>;
+			reset-deassert-us = <70000>;
+		};
+
+		hsgmii_phy1: phy@0 {
+			compatible = "ethernet-phy-id31c3.1c33";
+			reg = <0x0>;
+			device_type = "ethernet-phy";
+			interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
+			reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <11000>;
+			reset-deassert-us = <70000>;
+		};
+	};
+
+	mtl_rx_setup: rx-queues-config {
+		snps,rx-queues-to-use = <4>;
+		snps,rx-sched-sp;
+
+		queue0 {
+			snps,dcb-algorithm;
+			snps,map-to-dma-channel = <0x0>;
+			snps,route-up;
+			snps,priority = <0x1>;
+		};
+
+		queue1 {
+			snps,dcb-algorithm;
+			snps,map-to-dma-channel = <0x1>;
+			snps,route-ptp;
+		};
+
+		queue2 {
+			snps,avb-algorithm;
+			snps,map-to-dma-channel = <0x2>;
+			snps,route-avcp;
+		};
+
+		queue3 {
+			snps,avb-algorithm;
+			snps,map-to-dma-channel = <0x3>;
+			snps,priority = <0xc>;
+		};
+	};
+
+	mtl_tx_setup: tx-queues-config {
+		snps,tx-queues-to-use = <4>;
+
+		queue0 {
+			snps,dcb-algorithm;
+		};
+
+		queue1 {
+			snps,dcb-algorithm;
+		};
+
+		queue2 {
+			snps,avb-algorithm;
+			snps,send_slope = <0x1000>;
+			snps,idle_slope = <0x1000>;
+			snps,high_credit = <0x3e800>;
+			snps,low_credit = <0xffc18000>;
+		};
+
+		queue3 {
+			snps,avb-algorithm;
+			snps,send_slope = <0x1000>;
+			snps,idle_slope = <0x1000>;
+			snps,high_credit = <0x3e800>;
+			snps,low_credit = <0xffc18000>;
+		};
+	};
+};
+
+&ethernet1 {
+	phy-handle = <&hsgmii_phy1>;
+	phy-mode = "2500base-x";
+
+	snps,mtl-rx-config = <&mtl_rx_setup1>;
+	snps,mtl-tx-config = <&mtl_tx_setup1>;
+	snps,ps-speed = <1000>;
+
+	status = "okay";
+
+	mtl_rx_setup1: rx-queues-config {
+		snps,rx-queues-to-use = <4>;
+		snps,rx-sched-sp;
+
+		queue0 {
+			snps,dcb-algorithm;
+			snps,map-to-dma-channel = <0x0>;
+			snps,route-up;
+			snps,priority = <0x1>;
+		};
+
+		queue1 {
+			snps,dcb-algorithm;
+			snps,map-to-dma-channel = <0x1>;
+			snps,route-ptp;
+		};
+
+		queue2 {
+			snps,avb-algorithm;
+			snps,map-to-dma-channel = <0x2>;
+			snps,route-avcp;
+		};
+
+		queue3 {
+			snps,avb-algorithm;
+			snps,map-to-dma-channel = <0x3>;
+			snps,priority = <0xc>;
+		};
+	};
+
+	mtl_tx_setup1: tx-queues-config {
+		snps,tx-queues-to-use = <4>;
+
+		queue0 {
+			snps,dcb-algorithm;
+		};
+
+		queue1 {
+			snps,dcb-algorithm;
+		};
+
+		queue2 {
+			snps,avb-algorithm;
+			snps,send_slope = <0x1000>;
+			snps,idle_slope = <0x1000>;
+			snps,high_credit = <0x3e800>;
+			snps,low_credit = <0xffc18000>;
+		};
+
+		queue3 {
+			snps,avb-algorithm;
+			snps,send_slope = <0x1000>;
+			snps,idle_slope = <0x1000>;
+			snps,high_credit = <0x3e800>;
+			snps,low_credit = <0xffc18000>;
+		};
+	};
+};
+
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts b/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
index ae065ae92478..a7f377dc4733 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
+++ b/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
@@ -6,42 +6,9 @@
 /dts-v1/;

 #include "sa8775p-ride.dtsi"
+#include "lemans-ride-ethernet-aqr115c.dtsi"

 / {
 	model = "Qualcomm SA8775P Ride Rev3";
 	compatible = "qcom,sa8775p-ride-r3", "qcom,sa8775p";
 };
-
-&ethernet0 {
-	phy-mode = "2500base-x";
-};
-
-&ethernet1 {
-	phy-mode = "2500base-x";
-};
-
-&mdio {
-	compatible = "snps,dwmac-mdio";
-	#address-cells = <1>;
-	#size-cells = <0>;
-
-	sgmii_phy0: phy@8 {
-		compatible = "ethernet-phy-id31c3.1c33";
-		reg = <0x8>;
-		device_type = "ethernet-phy";
-		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
-		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
-		reset-assert-us = <11000>;
-		reset-deassert-us = <70000>;
-	};
-
-	sgmii_phy1: phy@0 {
-		compatible = "ethernet-phy-id31c3.1c33";
-		reg = <0x0>;
-		device_type = "ethernet-phy";
-		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
-		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
-		reset-assert-us = <11000>;
-		reset-deassert-us = <70000>;
-	};
-};
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dts b/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
index 2e87fd760dbd..b765794f7e54 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
+++ b/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
@@ -6,42 +6,9 @@
 /dts-v1/;

 #include "sa8775p-ride.dtsi"
+#include "lemans-ride-ethernet-88ea1512.dtsi"

 / {
 	model = "Qualcomm SA8775P Ride";
 	compatible = "qcom,sa8775p-ride", "qcom,sa8775p";
 };
-
-&ethernet0 {
-	phy-mode = "sgmii";
-};
-
-&ethernet1 {
-	phy-mode = "sgmii";
-};
-
-&mdio {
-	compatible = "snps,dwmac-mdio";
-	#address-cells = <1>;
-	#size-cells = <0>;
-
-	sgmii_phy0: phy@8 {
-		compatible = "ethernet-phy-id0141.0dd4";
-		reg = <0x8>;
-		device_type = "ethernet-phy";
-		interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
-		reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
-		reset-assert-us = <11000>;
-		reset-deassert-us = <70000>;
-	};
-
-	sgmii_phy1: phy@a {
-		compatible = "ethernet-phy-id0141.0dd4";
-		reg = <0xa>;
-		device_type = "ethernet-phy";
-		interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
-		reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
-		reset-assert-us = <11000>;
-		reset-deassert-us = <70000>;
-	};
-};
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi
index a9ec6ded412e..f512363f6222 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi
+++ b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi
@@ -13,8 +13,6 @@

 / {
 	aliases {
-		ethernet0 = &ethernet0;
-		ethernet1 = &ethernet1;
 		i2c11 = &i2c11;
 		i2c18 = &i2c18;
 		serial0 = &uart10;
@@ -443,151 +441,6 @@ vreg_l8e: ldo8 {
 	};
 };

-&ethernet0 {
-	phy-handle = <&sgmii_phy0>;
-
-	pinctrl-0 = <&ethernet0_default>;
-	pinctrl-names = "default";
-
-	snps,mtl-rx-config = <&mtl_rx_setup>;
-	snps,mtl-tx-config = <&mtl_tx_setup>;
-	snps,ps-speed = <1000>;
-
-	status = "okay";
-
-	mdio: mdio {
-		compatible = "snps,dwmac-mdio";
-		#address-cells = <1>;
-		#size-cells = <0>;
-	};
-
-	mtl_rx_setup: rx-queues-config {
-		snps,rx-queues-to-use = <4>;
-		snps,rx-sched-sp;
-
-		queue0 {
-			snps,dcb-algorithm;
-			snps,map-to-dma-channel = <0x0>;
-			snps,route-up;
-			snps,priority = <0x1>;
-		};
-
-		queue1 {
-			snps,dcb-algorithm;
-			snps,map-to-dma-channel = <0x1>;
-			snps,route-ptp;
-		};
-
-		queue2 {
-			snps,avb-algorithm;
-			snps,map-to-dma-channel = <0x2>;
-			snps,route-avcp;
-		};
-
-		queue3 {
-			snps,avb-algorithm;
-			snps,map-to-dma-channel = <0x3>;
-			snps,priority = <0xc>;
-		};
-	};
-
-	mtl_tx_setup: tx-queues-config {
-		snps,tx-queues-to-use = <4>;
-
-		queue0 {
-			snps,dcb-algorithm;
-		};
-
-		queue1 {
-			snps,dcb-algorithm;
-		};
-
-		queue2 {
-			snps,avb-algorithm;
-			snps,send_slope = <0x1000>;
-			snps,idle_slope = <0x1000>;
-			snps,high_credit = <0x3e800>;
-			snps,low_credit = <0xffc18000>;
-		};
-
-		queue3 {
-			snps,avb-algorithm;
-			snps,send_slope = <0x1000>;
-			snps,idle_slope = <0x1000>;
-			snps,high_credit = <0x3e800>;
-			snps,low_credit = <0xffc18000>;
-		};
-	};
-};
-
-&ethernet1 {
-	phy-handle = <&sgmii_phy1>;
-
-	snps,mtl-rx-config = <&mtl_rx_setup1>;
-	snps,mtl-tx-config = <&mtl_tx_setup1>;
-	snps,ps-speed = <1000>;
-
-	status = "okay";
-
-	mtl_rx_setup1: rx-queues-config {
-		snps,rx-queues-to-use = <4>;
-		snps,rx-sched-sp;
-
-		queue0 {
-			snps,dcb-algorithm;
-			snps,map-to-dma-channel = <0x0>;
-			snps,route-up;
-			snps,priority = <0x1>;
-		};
-
-		queue1 {
-			snps,dcb-algorithm;
-			snps,map-to-dma-channel = <0x1>;
-			snps,route-ptp;
-		};
-
-		queue2 {
-			snps,avb-algorithm;
-			snps,map-to-dma-channel = <0x2>;
-			snps,route-avcp;
-		};
-
-		queue3 {
-			snps,avb-algorithm;
-			snps,map-to-dma-channel = <0x3>;
-			snps,priority = <0xc>;
-		};
-	};
-
-	mtl_tx_setup1: tx-queues-config {
-		snps,tx-queues-to-use = <4>;
-
-		queue0 {
-			snps,dcb-algorithm;
-		};
-
-		queue1 {
-			snps,dcb-algorithm;
-		};
-
-		queue2 {
-			snps,avb-algorithm;
-			snps,send_slope = <0x1000>;
-			snps,idle_slope = <0x1000>;
-			snps,high_credit = <0x3e800>;
-			snps,low_credit = <0xffc18000>;
-		};
-
-		queue3 {
-			snps,avb-algorithm;
-			snps,send_slope = <0x1000>;
-			snps,idle_slope = <0x1000>;
-			snps,high_credit = <0x3e800>;
-			snps,low_credit = <0xffc18000>;
-		};
-	};
-};
-
 &i2c11 {
 	clock-frequency = <400000>;
 	status = "okay";
@@ -960,22 +813,6 @@ dp1_hot_plug_det: dp1-hot-plug-det-state {
 		bias-disable;
 	};

-	ethernet0_default: ethernet0-default-state {
-		ethernet0_mdc: ethernet0-mdc-pins {
-			pins = "gpio8";
-			function = "emac0_mdc";
-			drive-strength = <16>;
-			bias-pull-up;
-		};
-
-		ethernet0_mdio: ethernet0-mdio-pins {
-			pins = "gpio9";
-			function = "emac0_mdio";
-			drive-strength = <16>;
-			bias-pull-up;
-		};
-	};
-
 	io_expander_intr_active: io-expander-intr-active-state {
 		pins = "gpio98";
 		function = "gpio";
--
2.49.0

[PATCH 4/7] arm64: dts: qcom: lemans: Refactor ride/ride-r3 boards based on daughter cards

[Wasim Nazir]

Ride/Ride-r3 boards used with lemans and derivatives:
  - Are composed of multiple daughter cards (SoC-card, display, camera,
    ethernet, pcie, sensor, front & backplane, WLAN & BT).
  - Across lemans & its derivatives, SoM is changing.
  - Across Ride & Ride-r3 board, ethernet card is changing.

Excluding the differences all other cards i.e SoC-card, display,
camera, PCIe, sensor, front & backplane are same across Ride/Ride-r3
boards used with lemans and derivatives.

Describe all the common cards in lemans-ride-common so that it can be
reused for all the variants of ride & ride-r3 platforms in lemans and
derivatives.

Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
---
 .../dts/qcom/{sa8775p-ride.dtsi => lemans-ride-common.dtsi}  | 5 -----
 arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts                 | 5 ++++-
 arch/arm64/boot/dts/qcom/sa8775p-ride.dts                    | 5 ++++-
 3 files changed, 8 insertions(+), 7 deletions(-)
 rename arch/arm64/boot/dts/qcom/{sa8775p-ride.dtsi => lemans-ride-common.dtsi} (99%)

diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi b/arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi
similarity index 99%
rename from arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi
rename to arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi
index f512363f6222..25e756c14160 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi
@@ -3,14 +3,9 @@
  * Copyright (c) 2023, Linaro Limited
  */

-/dts-v1/;
-
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/regulator/qcom,rpmh-regulator.h>

-#include "lemans-auto.dtsi"
-#include "sa8775p-pmics.dtsi"
-
 / {
 	aliases {
 		i2c11 = &i2c11;
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts b/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
index a7f377dc4733..3e19ff5e061f 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
+++ b/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
@@ -5,7 +5,10 @@

 /dts-v1/;

-#include "sa8775p-ride.dtsi"
+#include "lemans-auto.dtsi"
+
+#include "sa8775p-pmics.dtsi"
+#include "lemans-ride-common.dtsi"
 #include "lemans-ride-ethernet-aqr115c.dtsi"

 / {
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dts b/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
index b765794f7e54..68a99582b538 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
+++ b/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
@@ -5,7 +5,10 @@

 /dts-v1/;

-#include "sa8775p-ride.dtsi"
+#include "lemans-auto.dtsi"
+
+#include "sa8775p-pmics.dtsi"
+#include "lemans-ride-common.dtsi"
 #include "lemans-ride-ethernet-88ea1512.dtsi"

 / {
--
2.49.0

[PATCH 5/7] arm64: dts: qcom: lemans: Rename boards and clean up unsupported platforms

[Wasim Nazir]

Rename qcs9100 based ride-r3 board to lemans ride-r3 and use it for all
the IoT ride-r3 boards.
Rename sa8775p based ride/ride-r3 boards to lemans-auto ride/ride-r3,
to allow users to run with old automotive memory-map.

Remove support for qcs9100-ride, as no platform currently uses it.

Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/Makefile                    |  7 +++----
 .../{sa8775p-ride-r3.dts => lemans-auto-ride-r3.dts} |  6 +++---
 .../qcom/{sa8775p-ride.dts => lemans-auto-ride.dts}  |  6 +++---
 .../qcom/{sa8775p-pmics.dtsi => lemans-pmics.dtsi}   |  0
 .../qcom/{qcs9100-ride-r3.dts => lemans-ride-r3.dts} | 12 +++++++++---
 arch/arm64/boot/dts/qcom/qcs9100-ride.dts            | 11 -----------
 6 files changed, 18 insertions(+), 24 deletions(-)
 rename arch/arm64/boot/dts/qcom/{sa8775p-ride-r3.dts => lemans-auto-ride-r3.dts} (59%)
 rename arch/arm64/boot/dts/qcom/{sa8775p-ride.dts => lemans-auto-ride.dts} (60%)
 rename arch/arm64/boot/dts/qcom/{sa8775p-pmics.dtsi => lemans-pmics.dtsi} (100%)
 rename arch/arm64/boot/dts/qcom/{qcs9100-ride-r3.dts => lemans-ride-r3.dts} (36%)
 delete mode 100644 arch/arm64/boot/dts/qcom/qcs9100-ride.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 4bfa926b6a08..2a1941c29537 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -29,6 +29,9 @@ dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp433.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp449.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp453.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp454.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= lemans-auto-ride.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= lemans-auto-ride-r3.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= lemans-ride-r3.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8216-samsung-fortuna3g.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-acer-a1-724.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-alcatel-idol347.dtb
@@ -126,8 +129,6 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2-industrial-mezzanine.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2-vision-mezzanine.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
-dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
-dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qrb2210-rb1.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qrb4210-rb2.dtb
@@ -140,8 +141,6 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qru1000-idp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sa8155p-adp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sa8295p-adp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sa8540p-ride.dtb
-dtb-$(CONFIG_ARCH_QCOM)	+= sa8775p-ride.dtb
-dtb-$(CONFIG_ARCH_QCOM)	+= sa8775p-ride-r3.dtb
 sc7180-acer-aspire1-el2-dtbs	:= sc7180-acer-aspire1.dtb sc7180-el2.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= sc7180-acer-aspire1.dtb sc7180-acer-aspire1-el2.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sc7180-idp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts b/arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dts
similarity index 59%
rename from arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
rename to arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dts
index 3e19ff5e061f..0e19ec46be3c 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
+++ b/arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dts
@@ -7,11 +7,11 @@

 #include "lemans-auto.dtsi"

-#include "sa8775p-pmics.dtsi"
+#include "lemans-pmics.dtsi"
 #include "lemans-ride-common.dtsi"
 #include "lemans-ride-ethernet-aqr115c.dtsi"

 / {
-	model = "Qualcomm SA8775P Ride Rev3";
-	compatible = "qcom,sa8775p-ride-r3", "qcom,sa8775p";
+	model = "Qualcomm Technologies, Inc. Lemans-auto Ride Rev3";
+	compatible = "qcom,lemans-auto-ride-r3", "qcom,sa8775p";
 };
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dts b/arch/arm64/boot/dts/qcom/lemans-auto-ride.dts
similarity index 60%
rename from arch/arm64/boot/dts/qcom/sa8775p-ride.dts
rename to arch/arm64/boot/dts/qcom/lemans-auto-ride.dts
index 68a99582b538..6af707263ad7 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
+++ b/arch/arm64/boot/dts/qcom/lemans-auto-ride.dts
@@ -7,11 +7,11 @@

 #include "lemans-auto.dtsi"

-#include "sa8775p-pmics.dtsi"
+#include "lemans-pmics.dtsi"
 #include "lemans-ride-common.dtsi"
 #include "lemans-ride-ethernet-88ea1512.dtsi"

 / {
-	model = "Qualcomm SA8775P Ride";
-	compatible = "qcom,sa8775p-ride", "qcom,sa8775p";
+	model = "Qualcomm Technologies, Inc. Lemans-auto Ride";
+	compatible = "qcom,lemans-auto-ride", "qcom,sa8775p";
 };
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-pmics.dtsi b/arch/arm64/boot/dts/qcom/lemans-pmics.dtsi
similarity index 100%
rename from arch/arm64/boot/dts/qcom/sa8775p-pmics.dtsi
rename to arch/arm64/boot/dts/qcom/lemans-pmics.dtsi
diff --git a/arch/arm64/boot/dts/qcom/qcs9100-ride-r3.dts b/arch/arm64/boot/dts/qcom/lemans-ride-r3.dts
similarity index 36%
rename from arch/arm64/boot/dts/qcom/qcs9100-ride-r3.dts
rename to arch/arm64/boot/dts/qcom/lemans-ride-r3.dts
index 759d1ec694b2..310c93f4a275 100644
--- a/arch/arm64/boot/dts/qcom/qcs9100-ride-r3.dts
+++ b/arch/arm64/boot/dts/qcom/lemans-ride-r3.dts
@@ -2,10 +2,16 @@
 /*
  * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
  */
+
 /dts-v1/;

-#include "sa8775p-ride-r3.dts"
+#include "lemans.dtsi"
+#include "lemans-pmics.dtsi"
+
+#include "lemans-ride-common.dtsi"
+#include "lemans-ride-ethernet-aqr115c.dtsi"
+
 / {
-	model = "Qualcomm QCS9100 Ride Rev3";
-	compatible = "qcom,qcs9100-ride-r3", "qcom,qcs9100", "qcom,sa8775p";
+	model = "Qualcomm Technologies, Inc. Lemans Ride Rev3";
+	compatible = "qcom,lemans-ride-r3", "qcom,sa8775p";
 };
diff --git a/arch/arm64/boot/dts/qcom/qcs9100-ride.dts b/arch/arm64/boot/dts/qcom/qcs9100-ride.dts
deleted file mode 100644
index 979462dfec30..000000000000
--- a/arch/arm64/boot/dts/qcom/qcs9100-ride.dts
+++ /dev/null
@@ -1,11 +0,0 @@
-// SPDX-License-Identifier: BSD-3-Clause
-/*
- * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
- */
-/dts-v1/;
-
-#include "sa8775p-ride.dts"
-/ {
-	model = "Qualcomm QCS9100 Ride";
-	compatible = "qcom,qcs9100-ride", "qcom,qcs9100", "qcom,sa8775p";
-};
--
2.49.0

Re: [PATCH 5/7] arm64: dts: qcom: lemans: Rename boards and clean up unsupported platforms

[Krzysztof Kozlowski]

On Tue, Jul 22, 2025 at 08:19:24PM +0530, Wasim Nazir wrote:
> Rename qcs9100 based ride-r3 board to lemans ride-r3 and use it for all
> the IoT ride-r3 boards.
> Rename sa8775p based ride/ride-r3 boards to lemans-auto ride/ride-r3,
> to allow users to run with old automotive memory-map.
> 
> Remove support for qcs9100-ride, as no platform currently uses it.
> 
> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile                    |  7 +++----
>  .../{sa8775p-ride-r3.dts => lemans-auto-ride-r3.dts} |  6 +++---
>  .../qcom/{sa8775p-ride.dts => lemans-auto-ride.dts}  |  6 +++---
>  .../qcom/{sa8775p-pmics.dtsi => lemans-pmics.dtsi}   |  0
>  .../qcom/{qcs9100-ride-r3.dts => lemans-ride-r3.dts} | 12 +++++++++---

I cannot stress more how HUGE MESS you made over the time.

All the discussions one and two years ago about SA8775p mess.... and now
you just call everything lemans.

Srsly, this is just irresponsibler. It's like random moves from
Qualcomm. Whatever you decided, stay with it. Take ownership and
responsibility, not change minds just because manager asked you to do
something. Say no to the manager.

NAK.

Best regards,
Krzysztof

Re: [PATCH 5/7] arm64: dts: qcom: lemans: Rename boards and clean up unsupported platforms

[Bjorn Andersson]

On Tue, Jul 22, 2025 at 08:19:24PM +0530, Wasim Nazir wrote:
> Rename qcs9100 based ride-r3 board to lemans ride-r3 and use it for all
> the IoT ride-r3 boards.
> Rename sa8775p based ride/ride-r3 boards to lemans-auto ride/ride-r3,
> to allow users to run with old automotive memory-map.
> 
> Remove support for qcs9100-ride, as no platform currently uses it.

As pointed out by Krzysztof, this has user impact, so we have to weight
the benefit of this against the impact on those users.

As such, this needs a proper problem description
(https://docs.kernel.org/process/submitting-patches.html#describe-your-changes)
and are there are three (probably different) set of developers/users
impacted it would make sense to split it in three patches.

Regards,
Bjorn

> 
> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile                    |  7 +++----
>  .../{sa8775p-ride-r3.dts => lemans-auto-ride-r3.dts} |  6 +++---
>  .../qcom/{sa8775p-ride.dts => lemans-auto-ride.dts}  |  6 +++---
>  .../qcom/{sa8775p-pmics.dtsi => lemans-pmics.dtsi}   |  0
>  .../qcom/{qcs9100-ride-r3.dts => lemans-ride-r3.dts} | 12 +++++++++---
>  arch/arm64/boot/dts/qcom/qcs9100-ride.dts            | 11 -----------
>  6 files changed, 18 insertions(+), 24 deletions(-)
>  rename arch/arm64/boot/dts/qcom/{sa8775p-ride-r3.dts => lemans-auto-ride-r3.dts} (59%)
>  rename arch/arm64/boot/dts/qcom/{sa8775p-ride.dts => lemans-auto-ride.dts} (60%)
>  rename arch/arm64/boot/dts/qcom/{sa8775p-pmics.dtsi => lemans-pmics.dtsi} (100%)
>  rename arch/arm64/boot/dts/qcom/{qcs9100-ride-r3.dts => lemans-ride-r3.dts} (36%)
>  delete mode 100644 arch/arm64/boot/dts/qcom/qcs9100-ride.dts
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 4bfa926b6a08..2a1941c29537 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -29,6 +29,9 @@ dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp433.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp449.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp453.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp454.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= lemans-auto-ride.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= lemans-auto-ride-r3.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= lemans-ride-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8216-samsung-fortuna3g.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-acer-a1-724.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-alcatel-idol347.dtb
> @@ -126,8 +129,6 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2-industrial-mezzanine.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2-vision-mezzanine.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
> -dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
> -dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qdu1000-idp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qrb2210-rb1.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qrb4210-rb2.dtb
> @@ -140,8 +141,6 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qru1000-idp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sa8155p-adp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sa8295p-adp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sa8540p-ride.dtb
> -dtb-$(CONFIG_ARCH_QCOM)	+= sa8775p-ride.dtb
> -dtb-$(CONFIG_ARCH_QCOM)	+= sa8775p-ride-r3.dtb
>  sc7180-acer-aspire1-el2-dtbs	:= sc7180-acer-aspire1.dtb sc7180-el2.dtbo
>  dtb-$(CONFIG_ARCH_QCOM)	+= sc7180-acer-aspire1.dtb sc7180-acer-aspire1-el2.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sc7180-idp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts b/arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dts
> similarity index 59%
> rename from arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
> rename to arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dts
> index 3e19ff5e061f..0e19ec46be3c 100644
> --- a/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
> +++ b/arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dts
> @@ -7,11 +7,11 @@
> 
>  #include "lemans-auto.dtsi"
> 
> -#include "sa8775p-pmics.dtsi"
> +#include "lemans-pmics.dtsi"
>  #include "lemans-ride-common.dtsi"
>  #include "lemans-ride-ethernet-aqr115c.dtsi"
> 
>  / {
> -	model = "Qualcomm SA8775P Ride Rev3";
> -	compatible = "qcom,sa8775p-ride-r3", "qcom,sa8775p";
> +	model = "Qualcomm Technologies, Inc. Lemans-auto Ride Rev3";
> +	compatible = "qcom,lemans-auto-ride-r3", "qcom,sa8775p";
>  };
> diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dts b/arch/arm64/boot/dts/qcom/lemans-auto-ride.dts
> similarity index 60%
> rename from arch/arm64/boot/dts/qcom/sa8775p-ride.dts
> rename to arch/arm64/boot/dts/qcom/lemans-auto-ride.dts
> index 68a99582b538..6af707263ad7 100644
> --- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
> +++ b/arch/arm64/boot/dts/qcom/lemans-auto-ride.dts
> @@ -7,11 +7,11 @@
> 
>  #include "lemans-auto.dtsi"
> 
> -#include "sa8775p-pmics.dtsi"
> +#include "lemans-pmics.dtsi"
>  #include "lemans-ride-common.dtsi"
>  #include "lemans-ride-ethernet-88ea1512.dtsi"
> 
>  / {
> -	model = "Qualcomm SA8775P Ride";
> -	compatible = "qcom,sa8775p-ride", "qcom,sa8775p";
> +	model = "Qualcomm Technologies, Inc. Lemans-auto Ride";
> +	compatible = "qcom,lemans-auto-ride", "qcom,sa8775p";
>  };
> diff --git a/arch/arm64/boot/dts/qcom/sa8775p-pmics.dtsi b/arch/arm64/boot/dts/qcom/lemans-pmics.dtsi
> similarity index 100%
> rename from arch/arm64/boot/dts/qcom/sa8775p-pmics.dtsi
> rename to arch/arm64/boot/dts/qcom/lemans-pmics.dtsi
> diff --git a/arch/arm64/boot/dts/qcom/qcs9100-ride-r3.dts b/arch/arm64/boot/dts/qcom/lemans-ride-r3.dts
> similarity index 36%
> rename from arch/arm64/boot/dts/qcom/qcs9100-ride-r3.dts
> rename to arch/arm64/boot/dts/qcom/lemans-ride-r3.dts
> index 759d1ec694b2..310c93f4a275 100644
> --- a/arch/arm64/boot/dts/qcom/qcs9100-ride-r3.dts
> +++ b/arch/arm64/boot/dts/qcom/lemans-ride-r3.dts
> @@ -2,10 +2,16 @@
>  /*
>   * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
>   */
> +
>  /dts-v1/;
> 
> -#include "sa8775p-ride-r3.dts"
> +#include "lemans.dtsi"
> +#include "lemans-pmics.dtsi"
> +
> +#include "lemans-ride-common.dtsi"
> +#include "lemans-ride-ethernet-aqr115c.dtsi"
> +
>  / {
> -	model = "Qualcomm QCS9100 Ride Rev3";
> -	compatible = "qcom,qcs9100-ride-r3", "qcom,qcs9100", "qcom,sa8775p";
> +	model = "Qualcomm Technologies, Inc. Lemans Ride Rev3";
> +	compatible = "qcom,lemans-ride-r3", "qcom,sa8775p";
>  };
> diff --git a/arch/arm64/boot/dts/qcom/qcs9100-ride.dts b/arch/arm64/boot/dts/qcom/qcs9100-ride.dts
> deleted file mode 100644
> index 979462dfec30..000000000000
> --- a/arch/arm64/boot/dts/qcom/qcs9100-ride.dts
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -// SPDX-License-Identifier: BSD-3-Clause
> -/*
> - * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> - */
> -/dts-v1/;
> -
> -#include "sa8775p-ride.dts"
> -/ {
> -	model = "Qualcomm QCS9100 Ride";
> -	compatible = "qcom,qcs9100-ride", "qcom,qcs9100", "qcom,sa8775p";
> -};
> --
> 2.49.0
> 

[PATCH 6/7] dt-bindings: arm: qcom: Refactor QCS9100 and SA8775P board names to reflect Lemans variants

[Wasim Nazir]

Remove qcs9100 SoC and rename its associated boards to "lemans-*",
to represent the IoT variants.
Rename sa8775p based boards to "lemans-auto-*", derived from "lemans",
to represent boards which uses old automotive memory-map.

Preserve sa8775p SoC definition to maintain backward compatibility.

Both "lemans" and "lemans-auto" are essentially the same non-safe chips,
since the safety monitoring feature of Safety Island (SAIL) subsystem is
not supported, but they differ in memory-map.

Introduce new bindings for the Lemans Evaluation Kit (EVK), an
additional IoT board without safety features.

Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 47a7b1cb3cac..174ef6924906 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -59,14 +59,13 @@ description: |
         qcs8550
         qcm2290
         qcm6490
-        qcs9100
         qdu1000
         qrb2210
         qrb4210
         qru1000
         sa8155p
         sa8540p
-        sa8775p
+        sa8775p    # lemans
         sar2130p
         sc7180
         sc7280
@@ -972,15 +971,10 @@ properties:

       - items:
           - enum:
-              - qcom,sa8775p-ride
-              - qcom,sa8775p-ride-r3
-          - const: qcom,sa8775p
-
-      - items:
-          - enum:
-              - qcom,qcs9100-ride
-              - qcom,qcs9100-ride-r3
-          - const: qcom,qcs9100
+              - qcom,lemans-evk
+              - qcom,lemans-ride-r3
+              - qcom,lemans-auto-ride
+              - qcom,lemans-auto-ride-r3
           - const: qcom,sa8775p

       - items:
--
2.49.0

Re: [PATCH 6/7] dt-bindings: arm: qcom: Refactor QCS9100 and SA8775P board names to reflect Lemans variants

[Krzysztof Kozlowski]

On Tue, Jul 22, 2025 at 08:19:25PM +0530, Wasim Nazir wrote:
> Remove qcs9100 SoC and rename its associated boards to "lemans-*",
> to represent the IoT variants.
> Rename sa8775p based boards to "lemans-auto-*", derived from "lemans",
> to represent boards which uses old automotive memory-map.

No.

We have been there and you got very clear feedback that this is a no-go.

NAK

Best regards,
Krzysztof

Re: [PATCH 6/7] dt-bindings: arm: qcom: Refactor QCS9100 and SA8775P board names to reflect Lemans variants

[Krzysztof Kozlowski]

On 22/07/2025 16:49, Wasim Nazir wrote:
>          sa8155p
>          sa8540p
> -        sa8775p
> +        sa8775p    # lemans

I already commented on other patch on this and I am dissapointed this
pattern keeps growing.

Linux kernel is not the place to store map of your internal company
names/codenames and products.

Best regards,
Krzysztof

[PATCH 7/7] arm64: dts: qcom: Add lemans evaluation kit (EVK) initial board support

[Wasim Nazir]

Lemans EVK is an IoT board without safety monitoring feature of
Safety Island(SAIL) subsystem.

Lemans EVK is single board supporting these peripherals:
  - Storage: 2 × 128 GB UFS, micro-SD card, EEPROMs for MACs,
    eMMC on mezzanine card
  - Audio/Video, Camera & Display ports
  - Connectivity: RJ45 2.5GbE, WLAN/Bluetooth, CAN/CAN-FD
  - Sensors: IMU
  - PCIe ports
  - USB & UART ports

On top of lemans EVK board additional mezzanine boards can be stacked
in future.

Implement basic features like uart/ufs to enable 'boot to shell'.

Co-developed-by: Rakesh Kota <quic_kotarake@quicinc.com>
Signed-off-by: Rakesh Kota <quic_kotarake@quicinc.com>
Co-developed-by: Sayali Lokhande <quic_sayalil@quicinc.com>
Signed-off-by: Sayali Lokhande <quic_sayalil@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/Makefile       |   1 +
 arch/arm64/boot/dts/qcom/lemans-evk.dts | 291 ++++++++++++++++++++++++
 2 files changed, 292 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/lemans-evk.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 2a1941c29537..cbc89c54f92b 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -31,6 +31,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp453.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp454.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= lemans-auto-ride.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= lemans-auto-ride-r3.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= lemans-evk.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= lemans-ride-r3.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8216-samsung-fortuna3g.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-acer-a1-724.dtb
diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
new file mode 100644
index 000000000000..dd357d514587
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
@@ -0,0 +1,291 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "lemans.dtsi"
+#include "lemans-pmics.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. Lemans EVK";
+	compatible = "qcom,lemans-evk", "qcom,sa8775p";
+
+	aliases {
+		serial0 = &uart10;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&apps_rsc {
+	regulators-0 {
+		compatible = "qcom,pmm8654au-rpmh-regulators";
+		qcom,pmic-id = "a";
+
+		vreg_s4a: smps4 {
+			regulator-name = "vreg_s4a";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1816000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s5a: smps5 {
+			regulator-name = "vreg_s5a";
+			regulator-min-microvolt = <1850000>;
+			regulator-max-microvolt = <1996000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s9a: smps9 {
+			regulator-name = "vreg_s9a";
+			regulator-min-microvolt = <535000>;
+			regulator-max-microvolt = <1120000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l4a: ldo4 {
+			regulator-name = "vreg_l4a";
+			regulator-min-microvolt = <788000>;
+			regulator-max-microvolt = <1050000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l5a: ldo5 {
+			regulator-name = "vreg_l5a";
+			regulator-min-microvolt = <870000>;
+			regulator-max-microvolt = <950000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6a: ldo6 {
+			regulator-name = "vreg_l6a";
+			regulator-min-microvolt = <870000>;
+			regulator-max-microvolt = <970000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7a: ldo7 {
+			regulator-name = "vreg_l7a";
+			regulator-min-microvolt = <720000>;
+			regulator-max-microvolt = <950000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8a: ldo8 {
+			regulator-name = "vreg_l8a";
+			regulator-min-microvolt = <2504000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9a: ldo9 {
+			regulator-name = "vreg_l9a";
+			regulator-min-microvolt = <2970000>;
+			regulator-max-microvolt = <3544000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-1 {
+		compatible = "qcom,pmm8654au-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		vreg_l1c: ldo1 {
+			regulator-name = "vreg_l1c";
+			regulator-min-microvolt = <1140000>;
+			regulator-max-microvolt = <1260000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2c: ldo2 {
+			regulator-name = "vreg_l2c";
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <1100000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3c: ldo3 {
+			regulator-name = "vreg_l3c";
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l4c: ldo4 {
+			regulator-name = "vreg_l4c";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l5c: ldo5 {
+			regulator-name = "vreg_l5c";
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6c: ldo6 {
+			regulator-name = "vreg_l6c";
+			regulator-min-microvolt = <1620000>;
+			regulator-max-microvolt = <1980000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7c: ldo7 {
+			regulator-name = "vreg_l7c";
+			regulator-min-microvolt = <1620000>;
+			regulator-max-microvolt = <2000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8c: ldo8 {
+			regulator-name = "vreg_l8c";
+			regulator-min-microvolt = <2400000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9c: ldo9 {
+			regulator-name = "vreg_l9c";
+			regulator-min-microvolt = <1650000>;
+			regulator-max-microvolt = <2700000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-2 {
+		compatible = "qcom,pmm8654au-rpmh-regulators";
+		qcom,pmic-id = "e";
+
+		vreg_s4e: smps4 {
+			regulator-name = "vreg_s4e";
+			regulator-min-microvolt = <970000>;
+			regulator-max-microvolt = <1520000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s7e: smps7 {
+			regulator-name = "vreg_s7e";
+			regulator-min-microvolt = <1010000>;
+			regulator-max-microvolt = <1170000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s9e: smps9 {
+			regulator-name = "vreg_s9e";
+			regulator-min-microvolt = <300000>;
+			regulator-max-microvolt = <570000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6e: ldo6 {
+			regulator-name = "vreg_l6e";
+			regulator-min-microvolt = <1280000>;
+			regulator-max-microvolt = <1450000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8e: ldo8 {
+			regulator-name = "vreg_l8e";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1950000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+						   RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+};
+
+&qupv3_id_1 {
+	status = "okay";
+};
+
+&sleep_clk {
+	clock-frequency = <32768>;
+};
+
+&uart10 {
+	compatible = "qcom,geni-debug-uart";
+	pinctrl-0 = <&qup_uart10_default>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
+
+&ufs_mem_hc {
+	reset-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
+	vcc-supply = <&vreg_l8a>;
+	vcc-max-microamp = <1100000>;
+	vccq-supply = <&vreg_l4c>;
+	vccq-max-microamp = <1200000>;
+
+	status = "okay";
+};
+
+&ufs_mem_phy {
+	vdda-phy-supply = <&vreg_l4a>;
+	vdda-pll-supply = <&vreg_l1c>;
+
+	status = "okay";
+};
+
+&xo_board_clk {
+	clock-frequency = <38400000>;
+};
--
2.49.0

Re: [PATCH 7/7] arm64: dts: qcom: Add lemans evaluation kit (EVK) initial board support

[Krzysztof Kozlowski]

On 22/07/2025 16:49, Wasim Nazir wrote:
> Lemans EVK is an IoT board without safety monitoring feature of
> Safety Island(SAIL) subsystem.
> 
> Lemans EVK is single board supporting these peripherals:
>   - Storage: 2 × 128 GB UFS, micro-SD card, EEPROMs for MACs,
>     eMMC on mezzanine card
>   - Audio/Video, Camera & Display ports
>   - Connectivity: RJ45 2.5GbE, WLAN/Bluetooth, CAN/CAN-FD
>   - Sensors: IMU
>   - PCIe ports
>   - USB & UART ports
> 
> On top of lemans EVK board additional mezzanine boards can be stacked
> in future.
> 
> Implement basic features like uart/ufs to enable 'boot to shell'.
> 
> Co-developed-by: Rakesh Kota <quic_kotarake@quicinc.com>
> Signed-off-by: Rakesh Kota <quic_kotarake@quicinc.com>
> Co-developed-by: Sayali Lokhande <quic_sayalil@quicinc.com>
> Signed-off-by: Sayali Lokhande <quic_sayalil@quicinc.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile       |   1 +
>  arch/arm64/boot/dts/qcom/lemans-evk.dts | 291 ++++++++++++++++++++++++
>  2 files changed, 292 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/lemans-evk.dts
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 2a1941c29537..cbc89c54f92b 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -31,6 +31,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp453.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp454.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= lemans-auto-ride.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= lemans-auto-ride-r3.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= lemans-evk.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= lemans-ride-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8216-samsung-fortuna3g.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-acer-a1-724.dtb
> diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
> new file mode 100644
> index 000000000000..dd357d514587
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
> @@ -0,0 +1,291 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.

Missing date, as discussed in other thread your internal guidelines are
not relevant here and to my knowledge upstream guidelines (provided in
other linked discussion) ask for year of first publication.

Best regards,
Krzysztof

Re: [PATCH 0/7] Refactor sa8775p/qcs9100 to common names lemans-auto/lemans

[Rob Herring (Arm)]

On Tue, 22 Jul 2025 20:19:19 +0530, Wasim Nazir wrote:
> This patch series refactors the sa8775p and qcs9100 platforms and introduces
> a unified naming convention for current and future platforms (qcs9075).
> 
> The motivation behind this change is to group similar platforms under a
> consistent naming scheme and to avoid using numeric identifiers.
> For example, qcs9100 and qcs9075 differ only in safety features provided by
> the Safety-Island (SAIL) subsystem but safety features are currently
> unsupported, so both can be categorized as the same chip today.
> 
> Since, most of our platforms are IoT-based so "lemans" can be served as the
> default IoT variant, with "lemans-auto" derived from it. Accordingly:
>   - qcs9100/qcs9075 and its associated IoT platforms are renamed to lemans
>     which needs different memory-map. So, latest memory-map is updated
>     here as per IOT requirements.
>   - sa8775p and its associated platforms are renamed to "lemans-auto", which
>     is derived from "lemans", that retains the old automotive memory map to
>     support legacy use cases.
>   - Both lemans & lemans-auto are serving as non-safe chip and if needed
>     additional dtsi can be appended in the future to enable safety features.
> 
> Additionally:
>   - Refactor common daughter cards used in Ride/Ride-R3 platforms into a
>     common configuration. Also, introduce new files for different ethernet
>     capabilities in Ride/Ride-r3. Since Ethernet functionality in Ride/Ride-r3
>     is currently broken upstream, this patch focuses only on refactoring.
>   - Include support for qcs9075 EVK[1] platform as lemans-evk. Currently,
>     basic features are enabled supporting 'boot to shell'.
>   - Remove support for qcs9100-ride, as no platform currently exists for it.
> 
> Funtional impact to current boards with refactoring:
>   - No functional change on auto boards i.e sa8775p ride/ride-r3 boards
>     (renamed as lemans-auto ride/ride-r3), and it is verified by comparing
>     decompiled DTB (dtx_diff).
>   - qcs9100 ride-r3 (renamed as lemans-ride-r3) is having new memory-map
>     and rest other functionalities are still same.
> 
> [1] https://lore.kernel.org/all/20250612155437.146925-1-quic_wasimn@quicinc.com/
> 
> 
> ---
> Wasim Nazir (7):
>   arm64: dts: qcom: Rename sa8775p SoC to "lemans"
>   arm64: dts: qcom: Update memory-map for IoT platforms in lemans
>   arm64: dts: qcom: lemans: Separate out ethernet card for ride &
>     ride-r3
>   arm64: dts: qcom: lemans: Refactor ride/ride-r3 boards based on
>     daughter cards
>   arm64: dts: qcom: lemans: Rename boards and clean up unsupported
>     platforms
>   dt-bindings: arm: qcom: Refactor QCS9100 and SA8775P board names to
>     reflect Lemans variants
>   arm64: dts: qcom: Add lemans evaluation kit (EVK) initial board
>     support
> 
>  .../devicetree/bindings/arm/qcom.yaml         |  16 +-
>  arch/arm64/boot/dts/qcom/Makefile             |   8 +-
>  ...8775p-ride.dts => lemans-auto-ride-r3.dts} |  44 +--
>  ...{qcs9100-ride.dts => lemans-auto-ride.dts} |  14 +-
>  arch/arm64/boot/dts/qcom/lemans-auto.dtsi     | 104 +++++++
>  arch/arm64/boot/dts/qcom/lemans-evk.dts       | 291 ++++++++++++++++++
>  .../{sa8775p-pmics.dtsi => lemans-pmics.dtsi} |   0
>  ...775p-ride.dtsi => lemans-ride-common.dtsi} | 168 ----------
>  .../qcom/lemans-ride-ethernet-88ea1512.dtsi   | 205 ++++++++++++
>  .../qcom/lemans-ride-ethernet-aqr115c.dtsi    | 205 ++++++++++++
>  ...qcs9100-ride-r3.dts => lemans-ride-r3.dts} |  12 +-
>  .../dts/qcom/{sa8775p.dtsi => lemans.dtsi}    |  75 +++--
>  arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts  |  47 ---
>  13 files changed, 884 insertions(+), 305 deletions(-)
>  rename arch/arm64/boot/dts/qcom/{sa8775p-ride.dts => lemans-auto-ride-r3.dts} (11%)
>  rename arch/arm64/boot/dts/qcom/{qcs9100-ride.dts => lemans-auto-ride.dts} (18%)
>  create mode 100644 arch/arm64/boot/dts/qcom/lemans-auto.dtsi
>  create mode 100644 arch/arm64/boot/dts/qcom/lemans-evk.dts
>  rename arch/arm64/boot/dts/qcom/{sa8775p-pmics.dtsi => lemans-pmics.dtsi} (100%)
>  rename arch/arm64/boot/dts/qcom/{sa8775p-ride.dtsi => lemans-ride-common.dtsi} (87%)
>  create mode 100644 arch/arm64/boot/dts/qcom/lemans-ride-ethernet-88ea1512.dtsi
>  create mode 100644 arch/arm64/boot/dts/qcom/lemans-ride-ethernet-aqr115c.dtsi
>  rename arch/arm64/boot/dts/qcom/{qcs9100-ride-r3.dts => lemans-ride-r3.dts} (36%)
>  rename arch/arm64/boot/dts/qcom/{sa8775p.dtsi => lemans.dtsi} (99%)
>  delete mode 100644 arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
> 
> 
> base-commit: 05adbee3ad528100ab0285c15c91100e19e10138
> --
> 2.49.0
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: using specified base-commit 05adbee3ad528100ab0285c15c91100e19e10138

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20250722144926.995064-1-wasim.nazir@oss.qualcomm.com:

arch/arm64/boot/dts/qcom/lemans-auto-ride.dtb: bluetooth (qcom,wcn6855-bt): 'vddwlcx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride.dtb: bluetooth (qcom,wcn6855-bt): 'vddwlmx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride.dtb: bluetooth (qcom,wcn6855-bt): 'vddrfa1p8-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride.dtb: ethernet@23000000 (qcom,sa8775p-ethqos): Unevaluated properties are not allowed ('interconnect-names', 'interconnects' were unexpected)
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride.dtb: ethernet@23040000 (qcom,sa8775p-ethqos): Unevaluated properties are not allowed ('interconnect-names', 'interconnects' were unexpected)
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride.dtb: wcn6855-pmu (qcom,wcn6855-pmu): 'vddpmumx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride.dtb: wcn6855-pmu (qcom,wcn6855-pmu): 'vddpmucx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#
arch/arm64/boot/dts/qcom/lemans-ride-r3.dtb: bluetooth (qcom,wcn6855-bt): 'vddwlcx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/lemans-ride-r3.dtb: bluetooth (qcom,wcn6855-bt): 'vddwlmx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/lemans-ride-r3.dtb: bluetooth (qcom,wcn6855-bt): 'vddrfa1p8-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dtb: bluetooth (qcom,wcn6855-bt): 'vddwlcx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dtb: bluetooth (qcom,wcn6855-bt): 'vddwlmx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dtb: bluetooth (qcom,wcn6855-bt): 'vddrfa1p8-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/lemans-ride-r3.dtb: ethernet@23000000 (qcom,sa8775p-ethqos): Unevaluated properties are not allowed ('interconnect-names', 'interconnects' were unexpected)
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/lemans-ride-r3.dtb: ethernet@23040000 (qcom,sa8775p-ethqos): Unevaluated properties are not allowed ('interconnect-names', 'interconnects' were unexpected)
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dtb: ethernet@23000000 (qcom,sa8775p-ethqos): Unevaluated properties are not allowed ('interconnect-names', 'interconnects' were unexpected)
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dtb: ethernet@23040000 (qcom,sa8775p-ethqos): Unevaluated properties are not allowed ('interconnect-names', 'interconnects' were unexpected)
	from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
arch/arm64/boot/dts/qcom/lemans-ride-r3.dtb: wcn6855-pmu (qcom,wcn6855-pmu): 'vddpmumx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#
arch/arm64/boot/dts/qcom/lemans-ride-r3.dtb: wcn6855-pmu (qcom,wcn6855-pmu): 'vddpmucx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dtb: wcn6855-pmu (qcom,wcn6855-pmu): 'vddpmumx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#
arch/arm64/boot/dts/qcom/lemans-auto-ride-r3.dtb: wcn6855-pmu (qcom,wcn6855-pmu): 'vddpmucx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#

Re: [PATCH 0/7] Refactor sa8775p/qcs9100 to common names lemans-auto/lemans

[Krzysztof Kozlowski]

On Tue, Jul 22, 2025 at 08:19:19PM +0530, Wasim Nazir wrote:
> This patch series refactors the sa8775p and qcs9100 platforms and introduces
> a unified naming convention for current and future platforms (qcs9075).
> 
> The motivation behind this change is to group similar platforms under a
> consistent naming scheme and to avoid using numeric identifiers.
> For example, qcs9100 and qcs9075 differ only in safety features provided by
> the Safety-Island (SAIL) subsystem but safety features are currently
> unsupported, so both can be categorized as the same chip today.
>

I expressed strong disagreement with this patchset in individual
patches. I expect NO NEW versions of it, but by any chance you send it,
then please always carry my:

Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [PATCH 0/7] Refactor sa8775p/qcs9100 to common names lemans-auto/lemans

[Bjorn Andersson]

On Wed, Jul 23, 2025 at 10:32:43AM +0200, Krzysztof Kozlowski wrote:
> On Tue, Jul 22, 2025 at 08:19:19PM +0530, Wasim Nazir wrote:
> > This patch series refactors the sa8775p and qcs9100 platforms and introduces
> > a unified naming convention for current and future platforms (qcs9075).
> > 
> > The motivation behind this change is to group similar platforms under a
> > consistent naming scheme and to avoid using numeric identifiers.
> > For example, qcs9100 and qcs9075 differ only in safety features provided by
> > the Safety-Island (SAIL) subsystem but safety features are currently
> > unsupported, so both can be categorized as the same chip today.
> >
> 
> I expressed strong disagreement with this patchset in individual
> patches. I expect NO NEW versions of it, but by any chance you send it,
> then please always carry my:
> 

I requested Wasim to prepare this patch set. Something that would have
been useful to include in the cover letter and some of the patches...


I definitely agree with your position when it comes to renaming working
platforms and I also think there has been way too much churn in relation
to this platform.

But the thing we call SA8775P upstream is not SA8775P. The hardware +
firmware that is described by sa8775p.dtsi doesn't exist.

Reactively and without telling us the whole story, we seem to have
gotten qcs9100-ride*.dts to represent what folks has been using to
upstream the platform support.

But the board where I see people actually running upstream (the EVK
introduced in this series) is based on the QCS9075 variant, which is the
same die but with some hardware features disabled.



In other words, this is a mess resulting from lacking communication and
reactive shortsighted attempts to get things merged. I don't want to
maintain it in this form.

> Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 

I'm fine carrying this token of disapproval for how we got here. 

Regards,
Bjorn

> Best regards,
> Krzysztof
>