[PATCH v1 0/6] X1E Asus Zenbook A14 support

[PATCH v1 0/6] X1E Asus Zenbook A14 support

[Aleksandrs Vinarskis]

Introduce support for the mentioned laptop.

Particular device exists in two model numbers:
* UX3407QA: X1P-42-100 or X1-26-100 (as tested)
* UX3407RA: X1E-78-100

Mostly similar to other X1-based laptops. Notable differences are:
* Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA
  and Qualcomm FastConnect 7800 on UX3407RA
* USB Type-C retimers are Parade PS8833, appear to behave identical
  to Parade PS8830
* gpio90 is TZ protected

Document new Parade PS883x variant. Move pcie6a_phy's compatible change
from X1P-42-100's dtsi to be CRD specific, at it seems it does not
apply to all machines - on X1-26-100 phy times-out when using new x1p
compatible.

When comparing device firmware between UX3407QA, UX3407RA, it seems
that only ADSP firmware is different, CDSP and GPU firmware appears to
be the same. (At least assuming the GPU firmware name in both cases is
`qcdxkmsuc8380.mbn`). Since at least some blobs are different betweeen
X1E and X1/X1P, define new firmware directory for `qcom/x1p42100`. This
also makes it easier for distros to automatically extract firmware from
Windows and place all blobs for the model under the same path. If/When
firmware blobs make it to linux-firmware, same blobs can be easily
symlinked between `qcom/x1e80100` and `qcom/x1p42100`.

Qualcomm FastConnect 6900 on UX3407QA did not work out of the box, and
additionally required both newer firmware and patches to `board-2.bin`.
I added a short how-to [1], as it is not exactly trivial.

ACPI dumps can be found on aarch64-laptops' github [2]. HWids on
dtbloader's github [3].

[1] https://github.com/alexVinarskis/linux-x1e80100-zenbook-a14?tab=readme-ov-file#wcn688x-wifi
[2] https://github.com/aarch64-laptops/build/pull/134/files
[3] https://github.com/TravMurav/dtbloader/pull/4/files

Aleksandrs Vinarskis (6):
  arm64: dts: qcom: move pcie6a type change from X1P42100 to
    X1P42100-crd
  usb: typec: Add Parade PS8833 Type-C Retimer variant
  dt-bindings: usb: Add Parade PS8833 Type-C retimer variant
  dt-bindings: arm: qcom: Add Asus Zenbook A14
  firmware: qcom: scm: Allow QSEECOM on Asus Zenbook A14
  arm64: dts: qcom: Add support for X1-based Asus Zenbook A14

 .../devicetree/bindings/arm/qcom.yaml         |    2 +
 .../bindings/usb/parade,ps8830.yaml           |    1 +
 arch/arm64/boot/dts/qcom/Makefile             |    2 +
 arch/arm64/boot/dts/qcom/x1-zenbook-a14.dtsi  | 1251 +++++++++++++++++
 .../dts/qcom/x1e80100-asus-zenbook-a14.dts    |   45 +
 .../dts/qcom/x1p42100-asus-zenbook-a14.dts    |   48 +
 arch/arm64/boot/dts/qcom/x1p42100-crd.dts     |    4 +
 arch/arm64/boot/dts/qcom/x1p42100.dtsi        |    4 -
 drivers/firmware/qcom/qcom_scm.c              |    2 +
 drivers/usb/typec/mux/ps883x.c                |    1 +
 10 files changed, 1356 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/x1-zenbook-a14.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dts
 create mode 100644 arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts

-- 
2.45.2

[PATCH v1 1/6] arm64: dts: qcom: move pcie6a type change from X1P42100 to X1P42100-crd

[Aleksandrs Vinarskis]

It appears at least on some devices (Asus Zenbook A14, x1-26-100) change
of pcie6a_phy's compatible breaks the controller. Move compatible change
from generic x1p42100.dtsi to CRD's specific x1p42100-crd.dts instead.

Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
---
 arch/arm64/boot/dts/qcom/x1p42100-crd.dts | 4 ++++
 arch/arm64/boot/dts/qcom/x1p42100.dtsi    | 4 ----
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
index cf07860a63e9..a2a212b31556 100644
--- a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
+++ b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
@@ -15,3 +15,7 @@ / {
 	model = "Qualcomm Technologies, Inc. X1P42100 CRD";
 	compatible = "qcom,x1p42100-crd", "qcom,x1p42100";
 };
+
+&pcie6a_phy {
+	compatible = "qcom,x1p42100-qmp-gen4x4-pcie-phy";
+};
diff --git a/arch/arm64/boot/dts/qcom/x1p42100.dtsi b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
index 27f479010bc3..4424a8708d39 100644
--- a/arch/arm64/boot/dts/qcom/x1p42100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
@@ -37,10 +37,6 @@ &pcie3 {
 	num-lanes = <4>;
 };
 
-&pcie6a_phy {
-	compatible = "qcom,x1p42100-qmp-gen4x4-pcie-phy";
-};
-
 &soc {
 	/* The PCIe3 PHY on X1P42100 uses a different IP block */
 	pcie3_phy: phy@1bd4000 {
-- 
2.45.2

Re: [PATCH v1 1/6] arm64: dts: qcom: move pcie6a type change from X1P42100 to X1P42100-crd

[Konrad Dybcio]

On 3/31/25 11:53 PM, Aleksandrs Vinarskis wrote:
> It appears at least on some devices (Asus Zenbook A14, x1-26-100) change
> of pcie6a_phy's compatible breaks the controller. Move compatible change
> from generic x1p42100.dtsi to CRD's specific x1p42100-crd.dts instead.
> 
> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
> ---
>  arch/arm64/boot/dts/qcom/x1p42100-crd.dts | 4 ++++
>  arch/arm64/boot/dts/qcom/x1p42100.dtsi    | 4 ----
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> index cf07860a63e9..a2a212b31556 100644
> --- a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> @@ -15,3 +15,7 @@ / {
>  	model = "Qualcomm Technologies, Inc. X1P42100 CRD";
>  	compatible = "qcom,x1p42100-crd", "qcom,x1p42100";
>  };
> +
> +&pcie6a_phy {
> +	compatible = "qcom,x1p42100-qmp-gen4x4-pcie-phy";
> +};
> diff --git a/arch/arm64/boot/dts/qcom/x1p42100.dtsi b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> index 27f479010bc3..4424a8708d39 100644
> --- a/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> @@ -37,10 +37,6 @@ &pcie3 {
>  	num-lanes = <4>;
>  };
>  
> -&pcie6a_phy {
> -	compatible = "qcom,x1p42100-qmp-gen4x4-pcie-phy";
> -};


This is not correct. The hardware is different in all SoCs, not just the
ones put in the CRD.

You're probably missing this change [1], please test it out and leave a t-b
if it's confirmed working for you.

Konrad

[1] https://lore.kernel.org/linux-arm-msm/4c7059a0-46a0-424d-9068-60894c6cec1c@quicinc.com/T/#m9675593a62b2334ab2afd4269da6938464a03fa6

Re: [PATCH v1 1/6] arm64: dts: qcom: move pcie6a type change from X1P42100 to X1P42100-crd

[Aleksandrs Vinarskis]

On Tue, 1 Apr 2025 at 12:19, Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 3/31/25 11:53 PM, Aleksandrs Vinarskis wrote:
> > It appears at least on some devices (Asus Zenbook A14, x1-26-100) change
> > of pcie6a_phy's compatible breaks the controller. Move compatible change
> > from generic x1p42100.dtsi to CRD's specific x1p42100-crd.dts instead.
> >
> > Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
> > ---
> >  arch/arm64/boot/dts/qcom/x1p42100-crd.dts | 4 ++++
> >  arch/arm64/boot/dts/qcom/x1p42100.dtsi    | 4 ----
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> > index cf07860a63e9..a2a212b31556 100644
> > --- a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> > +++ b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> > @@ -15,3 +15,7 @@ / {
> >       model = "Qualcomm Technologies, Inc. X1P42100 CRD";
> >       compatible = "qcom,x1p42100-crd", "qcom,x1p42100";
> >  };
> > +
> > +&pcie6a_phy {
> > +     compatible = "qcom,x1p42100-qmp-gen4x4-pcie-phy";
> > +};
> > diff --git a/arch/arm64/boot/dts/qcom/x1p42100.dtsi b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> > index 27f479010bc3..4424a8708d39 100644
> > --- a/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> > @@ -37,10 +37,6 @@ &pcie3 {
> >       num-lanes = <4>;
> >  };
> >
> > -&pcie6a_phy {
> > -     compatible = "qcom,x1p42100-qmp-gen4x4-pcie-phy";
> > -};
>
>
> This is not correct. The hardware is different in all SoCs, not just the
> ones put in the CRD.
>
> You're probably missing this change [1], please test it out and leave a t-b
> if it's confirmed working for you.

Thanks for the pointer, with the missing peace it indeed works now!
Left t-b. Will drop this change on re-spin later today.

Thanks for the review,
Alex

>
> Konrad
>
> [1] https://lore.kernel.org/linux-arm-msm/4c7059a0-46a0-424d-9068-60894c6cec1c@quicinc.com/T/#m9675593a62b2334ab2afd4269da6938464a03fa6

[PATCH v1 2/6] usb: typec: Add Parade PS8833 Type-C Retimer variant

[Aleksandrs Vinarskis]

Appears to behave similarly to Parade PS8830. Found on some Qualcomm
Snapdragon X1 devices, such as Asus Zenbook A14.

Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
---
 drivers/usb/typec/mux/ps883x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/typec/mux/ps883x.c b/drivers/usb/typec/mux/ps883x.c
index ad59babf7cce..095c36530904 100644
--- a/drivers/usb/typec/mux/ps883x.c
+++ b/drivers/usb/typec/mux/ps883x.c
@@ -447,6 +447,7 @@ static void ps883x_retimer_remove(struct i2c_client *client)
 
 static const struct of_device_id ps883x_retimer_of_table[] = {
 	{ .compatible = "parade,ps8830" },
+	{ .compatible = "parade,ps8833" },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, ps883x_retimer_of_table);
-- 
2.45.2

Re: [PATCH v1 2/6] usb: typec: Add Parade PS8833 Type-C Retimer variant

[Krzysztof Kozlowski]

On 31/03/2025 23:53, Aleksandrs Vinarskis wrote:
> Appears to behave similarly to Parade PS8830. Found on some Qualcomm
> Snapdragon X1 devices, such as Asus Zenbook A14.
> 
> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
> ---
>  drivers/usb/typec/mux/ps883x.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/typec/mux/ps883x.c b/drivers/usb/typec/mux/ps883x.c
> index ad59babf7cce..095c36530904 100644
> --- a/drivers/usb/typec/mux/ps883x.c
> +++ b/drivers/usb/typec/mux/ps883x.c
> @@ -447,6 +447,7 @@ static void ps883x_retimer_remove(struct i2c_client *client)
>  
>  static const struct of_device_id ps883x_retimer_of_table[] = {
>  	{ .compatible = "parade,ps8830" },
> +	{ .compatible = "parade,ps8833" },


Don't create unnecessary entries for compatible devices. Patch should be
dropped.

Best regards,
Krzysztof

[PATCH v1 3/6] dt-bindings: usb: Add Parade PS8833 Type-C retimer variant

[Aleksandrs Vinarskis]

Appears to behave similarly to Parade PS8830. Found on some Qualcomm
Snapdragon X1 devices, such as Asus Zenbook A14.

Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
---
 Documentation/devicetree/bindings/usb/parade,ps8830.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/parade,ps8830.yaml b/Documentation/devicetree/bindings/usb/parade,ps8830.yaml
index 935d57f5d26f..699f4e1d9283 100644
--- a/Documentation/devicetree/bindings/usb/parade,ps8830.yaml
+++ b/Documentation/devicetree/bindings/usb/parade,ps8830.yaml
@@ -13,6 +13,7 @@ properties:
   compatible:
     enum:
       - parade,ps8830
+      - parade,ps8833
 
   reg:
     maxItems: 1
-- 
2.45.2

Re: [PATCH v1 3/6] dt-bindings: usb: Add Parade PS8833 Type-C retimer variant

[Krzysztof Kozlowski]

On 31/03/2025 23:53, Aleksandrs Vinarskis wrote:
> Appears to behave similarly to Parade PS8830. Found on some Qualcomm
> Snapdragon X1 devices, such as Asus Zenbook A14.
> 
> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>


Looks compatible, so express it with fallback.

Best regards,
Krzysztof

[PATCH v1 4/6] dt-bindings: arm: qcom: Add Asus Zenbook A14

[Aleksandrs Vinarskis]

Document the X1E-78-100 and X1P-42-100/X1-26-100 variants.

Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 08c329b1e919..1b7e2ed56baa 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1133,6 +1133,7 @@ properties:
       - items:
           - enum:
               - asus,vivobook-s15
+              - asus,x1e80100-zenbook-a14
               - dell,xps13-9345
               - hp,omnibook-x14
               - lenovo,yoga-slim7x
@@ -1144,6 +1145,7 @@ properties:
 
       - items:
           - enum:
+              - asus,x1p42100-zenbook-a14
               - qcom,x1p42100-crd
           - const: qcom,x1p42100
 
-- 
2.45.2

Re: [PATCH v1 4/6] dt-bindings: arm: qcom: Add Asus Zenbook A14

[Krzysztof Kozlowski]

On 31/03/2025 23:53, Aleksandrs Vinarskis wrote:
> Document the X1E-78-100 and X1P-42-100/X1-26-100 variants.
> 
> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 08c329b1e919..1b7e2ed56baa 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -1133,6 +1133,7 @@ properties:
>        - items:
>            - enum:
>                - asus,vivobook-s15
> +              - asus,x1e80100-zenbook-a14

asus,zenbook-a14-x1e80100

asus did not make a component of x1e80100 soc.

>                - dell,xps13-9345
>                - hp,omnibook-x14
>                - lenovo,yoga-slim7x
> @@ -1144,6 +1145,7 @@ properties:
>  
>        - items:
>            - enum:
> +              - asus,x1p42100-zenbook-a14

Same here.


Best regards,
Krzysztof

Re: [PATCH v1 4/6] dt-bindings: arm: qcom: Add Asus Zenbook A14

[Aleksandrs Vinarskis]

On Tue, 1 Apr 2025 at 07:38, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 31/03/2025 23:53, Aleksandrs Vinarskis wrote:
> > Document the X1E-78-100 and X1P-42-100/X1-26-100 variants.
> >
> > Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
> > ---
> >  Documentation/devicetree/bindings/arm/qcom.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> > index 08c329b1e919..1b7e2ed56baa 100644
> > --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> > @@ -1133,6 +1133,7 @@ properties:
> >        - items:
> >            - enum:
> >                - asus,vivobook-s15
> > +              - asus,x1e80100-zenbook-a14
>
> asus,zenbook-a14-x1e80100
>
> asus did not make a component of x1e80100 soc.

I see, I misunderstood the meaning of qcom,x1e80100-crd, clear now.
In that case, perhaps follow pattern of other devices, describe by
model differences (eg. -oled) instead of soc? eg:

`asus,zenbook-a14-ux3407ra` (for x1e variant)
`asus,zenbook-a14-ux3407qa` (for x1/x1p variants)

Thanks for the review,
Alex

>
> >                - dell,xps13-9345
> >                - hp,omnibook-x14
> >                - lenovo,yoga-slim7x
> > @@ -1144,6 +1145,7 @@ properties:
> >
> >        - items:
> >            - enum:
> > +              - asus,x1p42100-zenbook-a14
>
> Same here.
>
>
> Best regards,
> Krzysztof

Re: [PATCH v1 4/6] dt-bindings: arm: qcom: Add Asus Zenbook A14

[Konrad Dybcio]

On 4/1/25 12:16 PM, Aleksandrs Vinarskis wrote:
> On Tue, 1 Apr 2025 at 07:38, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 31/03/2025 23:53, Aleksandrs Vinarskis wrote:
>>> Document the X1E-78-100 and X1P-42-100/X1-26-100 variants.
>>>
>>> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/qcom.yaml | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>> index 08c329b1e919..1b7e2ed56baa 100644
>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>> @@ -1133,6 +1133,7 @@ properties:
>>>        - items:
>>>            - enum:
>>>                - asus,vivobook-s15
>>> +              - asus,x1e80100-zenbook-a14
>>
>> asus,zenbook-a14-x1e80100
>>
>> asus did not make a component of x1e80100 soc.
> 
> I see, I misunderstood the meaning of qcom,x1e80100-crd, clear now.
> In that case, perhaps follow pattern of other devices, describe by
> model differences (eg. -oled) instead of soc? eg:
> 
> `asus,zenbook-a14-ux3407ra` (for x1e variant)
> `asus,zenbook-a14-ux3407qa` (for x1/x1p variants)

This seems to make more sense indeed, we don't want to put the SoC name
in the compatible, as it may turn out that there's some other variants
(e.g. different panel or present/absent modem) that may make it impossible
to maintain in the future

Konrad

Re: [PATCH v1 4/6] dt-bindings: arm: qcom: Add Asus Zenbook A14

[Krzysztof Kozlowski]

On 01/04/2025 12:16, Aleksandrs Vinarskis wrote:
> On Tue, 1 Apr 2025 at 07:38, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 31/03/2025 23:53, Aleksandrs Vinarskis wrote:
>>> Document the X1E-78-100 and X1P-42-100/X1-26-100 variants.
>>>
>>> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/qcom.yaml | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>> index 08c329b1e919..1b7e2ed56baa 100644
>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>> @@ -1133,6 +1133,7 @@ properties:
>>>        - items:
>>>            - enum:
>>>                - asus,vivobook-s15
>>> +              - asus,x1e80100-zenbook-a14
>>
>> asus,zenbook-a14-x1e80100
>>
>> asus did not make a component of x1e80100 soc.
> 
> I see, I misunderstood the meaning of qcom,x1e80100-crd, clear now.
> In that case, perhaps follow pattern of other devices, describe by

Qualcomm dev boards follow such pattern, even though actual name is for
example mtp8750.

> model differences (eg. -oled) instead of soc? eg:
> 
> `asus,zenbook-a14-ux3407ra` (for x1e variant)
> `asus,zenbook-a14-ux3407qa` (for x1/x1p variants)

I am fine with both, just wanted the actual generic/common product name
first.

> 
> Thanks for the review,
> Alex
> 
>>
>>>                - dell,xps13-9345
>>>                - hp,omnibook-x14
>>>                - lenovo,yoga-slim7x
>>> @@ -1144,6 +1145,7 @@ properties:
>>>
>>>        - items:
>>>            - enum:
>>> +              - asus,x1p42100-zenbook-a14
>>
>> Same here.
>>
>>
>> Best regards,
>> Krzysztof


Best regards,
Krzysztof

[PATCH v1 5/6] firmware: qcom: scm: Allow QSEECOM on Asus Zenbook A14

[Aleksandrs Vinarskis]

Allow particular machine accessing eg. efivars.

Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
---
 drivers/firmware/qcom/qcom_scm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index fc4d67e4c4a6..0d2467c04248 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -1986,6 +1986,8 @@ EXPORT_SYMBOL_GPL(qcom_scm_qseecom_app_send);
  */
 static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
 	{ .compatible = "asus,vivobook-s15" },
+	{ .compatible = "asus,x1e80100-zenbook-a14" },
+	{ .compatible = "asus,x1p42100-zenbook-a14" },
 	{ .compatible = "dell,xps13-9345" },
 	{ .compatible = "hp,omnibook-x14" },
 	{ .compatible = "huawei,gaokun3" },
-- 
2.45.2

[PATCH v1 6/6] arm64: dts: qcom: Add support for X1-based Asus Zenbook A14

[Aleksandrs Vinarskis]

Initial support for Asus Zenbook A14. Particular moddel exists
in X1-26-100, X1P-42-100 (UX3407QA) and X1E-78-100 (UX3407RA).

Mostly similar to other X1-based laptops. Notable differences are:
* Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA
  and Qualcomm FastConnect 7800 on UX3407RA
* USB Type-C retimers are Parade PS8833, appear to behave identical
  to Parade PS8830
* gpio90 is TZ protected

Working:
* Keyboard
* Touchpad
* NVME
* Lid switch
* Camera LED
* eDP (FHD OLED, SDC420D) with brightness control
* Bluetooth, WiFi (WCN6855)
* USB Type-A port
* USB Type-C ports in USB2/USB3/DP (both orientations)
* aDSP/cDPS firmware loading, battery info
* Sleep/suspend, nothing visibly broken on resume

Out of scope of this series:
* Audio (Speakers/microphones/headphone jack)
* Camera (OmniVision OV02C10)
* HDMI (Parade PS185HDM)
* EC

Add dtsi and create two configurations for UX3407QA, UX3407RA.
Tested on UX3407QA with X1-26-100.

Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
---
 arch/arm64/boot/dts/qcom/Makefile             |    2 +
 arch/arm64/boot/dts/qcom/x1-zenbook-a14.dtsi  | 1251 +++++++++++++++++
 .../dts/qcom/x1e80100-asus-zenbook-a14.dts    |   45 +
 .../dts/qcom/x1p42100-asus-zenbook-a14.dts    |   48 +
 4 files changed, 1346 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/x1-zenbook-a14.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dts
 create mode 100644 arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index adb4d026bcc4..baa99f9e43ab 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -297,6 +297,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= x1e001de-devkit.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e78100-lenovo-thinkpad-t14s.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e78100-lenovo-thinkpad-t14s-oled.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-asus-vivobook-s15.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-asus-zenbook-a14.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-crd.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-dell-xps13-9345.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-hp-omnibook-x14.dtb
@@ -304,4 +305,5 @@ dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-lenovo-yoga-slim7x.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-microsoft-romulus13.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-microsoft-romulus15.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-qcp.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= x1p42100-asus-zenbook-a14.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= x1p42100-crd.dtb
diff --git a/arch/arm64/boot/dts/qcom/x1-zenbook-a14.dtsi b/arch/arm64/boot/dts/qcom/x1-zenbook-a14.dtsi
new file mode 100644
index 000000000000..148517fe50e1
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/x1-zenbook-a14.dtsi
@@ -0,0 +1,1251 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2025 Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/gpio-keys.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "x1e80100-pmics.dtsi"
+
+/ {
+	model = "ASUS Zenbook A14";
+	chassis-type = "laptop";
+
+	aliases {
+		serial0 = &uart21;
+		serial1 = &uart14;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		pinctrl-0 = <&hall_int_n_default>;
+		pinctrl-names = "default";
+
+		switch-lid {
+			label = "lid";
+			gpios = <&tlmm 92 GPIO_ACTIVE_LOW>;
+			linux,input-type = <EV_SW>;
+			linux,code = <SW_LID>;
+			wakeup-source;
+			wakeup-event-action = <EV_ACT_DEASSERTED>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&cam_indicator_en>;
+
+		led-camera-indicator {
+			label = "white:camera-indicator";
+			function = LED_FUNCTION_INDICATOR;
+			color = <LED_COLOR_ID_WHITE>;
+			gpios = <&tlmm 110 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "none";
+			default-state = "off";
+			/* Reuse as a panic indicator until we get a "camera on" trigger */
+			panic-indicator;
+		};
+	};
+
+	pmic-glink {
+		compatible = "qcom,x1e80100-pmic-glink",
+			     "qcom,sm8550-pmic-glink",
+			     "qcom,pmic-glink";
+		orientation-gpios = <&tlmm 121 GPIO_ACTIVE_HIGH>,
+				    <&tlmm 123 GPIO_ACTIVE_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		/* Left-side display-adjacent port */
+		connector@0 {
+			compatible = "usb-c-connector";
+			reg = <0>;
+			power-role = "dual";
+			data-role = "dual";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+
+					pmic_glink_ss0_hs_in: endpoint {
+						remote-endpoint = <&usb_1_ss0_dwc3_hs>;
+					};
+				};
+
+				port@1 {
+					reg = <1>;
+
+					pmic_glink_ss0_ss_in: endpoint {
+						remote-endpoint = <&retimer_ss0_ss_out>;
+					};
+				};
+
+				port@2 {
+					reg = <2>;
+
+					pmic_glink_ss0_con_sbu_in: endpoint {
+						remote-endpoint = <&retimer_ss0_con_sbu_out>;
+					};
+				};
+			};
+		};
+
+		/* Left-side user-adjacent port */
+		connector@1 {
+			compatible = "usb-c-connector";
+			reg = <1>;
+			power-role = "dual";
+			data-role = "dual";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+
+					pmic_glink_ss1_hs_in: endpoint {
+						remote-endpoint = <&usb_1_ss1_dwc3_hs>;
+					};
+				};
+
+				port@1 {
+					reg = <1>;
+
+					pmic_glink_ss1_ss_in: endpoint {
+						remote-endpoint = <&retimer_ss1_ss_out>;
+					};
+				};
+
+				port@2 {
+					reg = <2>;
+
+					pmic_glink_ss1_con_sbu_in: endpoint {
+						remote-endpoint = <&retimer_ss1_con_sbu_out>;
+					};
+				};
+			};
+		};
+	};
+
+	reserved-memory {
+		linux,cma {
+			compatible = "shared-dma-pool";
+			size = <0x0 0x8000000>;
+			reusable;
+			linux,cma-default;
+		};
+	};
+
+	vreg_edp_3p3: regulator-edp-3p3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_EDP_3P3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 70 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&edp_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_misc_3p3: regulator-misc-3p3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_MISC_3P3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&pm8550ve_8_gpios 6 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&misc_3p3_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
+	vreg_nvme: regulator-nvme {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_NVME_3P3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 18 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&nvme_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr0_1p15: regulator-rtmr0-1p15 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR0_1P15";
+		regulator-min-microvolt = <1150000>;
+		regulator-max-microvolt = <1150000>;
+
+		gpio = <&pmc8380_5_gpios 8 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&usb0_pwr_1p15_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr0_1p8: regulator-rtmr0-1p8 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR0_1P8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		gpio = <&pm8550ve_9_gpios 8 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&usb0_1p8_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr0_3p3: regulator-rtmr0-3p3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR0_3P3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&pm8550_gpios 11 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&usb0_3p3_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr1_1p15: regulator-rtmr1-1p15 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR1_1P15";
+		regulator-min-microvolt = <1150000>;
+		regulator-max-microvolt = <1150000>;
+
+		gpio = <&tlmm 188 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&usb1_pwr_1p15_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr1_1p8: regulator-rtmr1-1p8 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR1_1P8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		gpio = <&tlmm 175 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&usb1_pwr_1p8_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr1_3p3: regulator-rtmr1-3p3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR1_3P3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 186 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&usb1_pwr_3p3_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_vph_pwr: regulator-vph-pwr {
+		compatible = "regulator-fixed";
+
+		regulator-name = "vph_pwr";
+		regulator-min-microvolt = <3700000>;
+		regulator-max-microvolt = <3700000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+	};
+};
+
+&apps_rsc {
+	regulators-0 {
+		compatible = "qcom,pm8550-rpmh-regulators";
+		qcom,pmic-id = "b";
+
+		vdd-bob1-supply = <&vreg_vph_pwr>;
+		vdd-bob2-supply = <&vreg_vph_pwr>;
+		vdd-l1-l4-l10-supply = <&vreg_s4c_1p8>;
+		vdd-l2-l13-l14-supply = <&vreg_bob1>;
+		vdd-l5-l16-supply = <&vreg_bob1>;
+		vdd-l6-l7-supply = <&vreg_bob2>;
+		vdd-l8-l9-supply = <&vreg_bob1>;
+		vdd-l12-supply = <&vreg_s5j_1p2>;
+		vdd-l15-supply = <&vreg_s4c_1p8>;
+		vdd-l17-supply = <&vreg_bob2>;
+
+		vreg_bob1: bob1 {
+			regulator-name = "vreg_bob1";
+			regulator-min-microvolt = <3008000>;
+			regulator-max-microvolt = <3960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_bob2: bob2 {
+			regulator-name = "vreg_bob2";
+			regulator-min-microvolt = <2504000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2b_3p0: ldo2 {
+			regulator-name = "vreg_l2b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l4b_1p8: ldo4 {
+			regulator-name = "vreg_l4b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6b_1p8: ldo6 {
+			regulator-name = "vreg_l6b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8b_3p0: ldo8 {
+			regulator-name = "vreg_l8b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9b_2p9: ldo9 {
+			regulator-name = "vreg_l9b_2p9";
+			regulator-min-microvolt = <2960000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l10b_1p8: ldo10 {
+			regulator-name = "vreg_l10b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l12b_1p2: ldo12 {
+			regulator-name = "vreg_l12b_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-always-on;
+		};
+
+		vreg_l13b_3p0: ldo13 {
+			regulator-name = "vreg_l13b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l14b_3p0: ldo14 {
+			regulator-name = "vreg_l14b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l15b_1p8: ldo15 {
+			regulator-name = "vreg_l15b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-always-on;
+		};
+
+		vreg_l17b_2p5: ldo17 {
+			regulator-name = "vreg_l17b_2p5";
+			regulator-min-microvolt = <2504000>;
+			regulator-max-microvolt = <2504000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-1 {
+		compatible = "qcom,pm8550ve-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		vdd-l1-supply = <&vreg_s5j_1p2>;
+		vdd-l2-supply = <&vreg_s1f_0p7>;
+		vdd-l3-supply = <&vreg_s1f_0p7>;
+		vdd-s4-supply = <&vreg_vph_pwr>;
+
+		vreg_s4c_1p8: smps4 {
+			regulator-name = "vreg_s4c_1p8";
+			regulator-min-microvolt = <1856000>;
+			regulator-max-microvolt = <2000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1c_1p2: ldo1 {
+			regulator-name = "vreg_l1c_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2c_0p8: ldo2 {
+			regulator-name = "vreg_l2c_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3c_0p9: ldo3 {
+			regulator-name = "vreg_l3c_0p9";
+			regulator-min-microvolt = <912000>;
+			regulator-max-microvolt = <912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-2 {
+		compatible = "qcom,pmc8380-rpmh-regulators";
+		qcom,pmic-id = "d";
+
+		vdd-l1-supply = <&vreg_s1f_0p7>;
+		vdd-l2-supply = <&vreg_s1f_0p7>;
+		vdd-l3-supply = <&vreg_s4c_1p8>;
+		vdd-s1-supply = <&vreg_vph_pwr>;
+
+		vreg_l1d_0p8: ldo1 {
+			regulator-name = "vreg_l1d_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2d_0p9: ldo2 {
+			regulator-name = "vreg_l2d_0p9";
+			regulator-min-microvolt = <912000>;
+			regulator-max-microvolt = <912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3d_1p8: ldo3 {
+			regulator-name = "vreg_l3d_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-3 {
+		compatible = "qcom,pmc8380-rpmh-regulators";
+		qcom,pmic-id = "e";
+
+		vdd-l2-supply = <&vreg_s1f_0p7>;
+		vdd-l3-supply = <&vreg_s5j_1p2>;
+
+		vreg_l2e_0p8: ldo2 {
+			regulator-name = "vreg_l2e_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3e_1p2: ldo3 {
+			regulator-name = "vreg_l3e_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-4 {
+		compatible = "qcom,pmc8380-rpmh-regulators";
+		qcom,pmic-id = "f";
+
+		vdd-l1-supply = <&vreg_s5j_1p2>;
+		vdd-l2-supply = <&vreg_s5j_1p2>;
+		vdd-l3-supply = <&vreg_s5j_1p2>;
+		vdd-s1-supply = <&vreg_vph_pwr>;
+
+		vreg_s1f_0p7: smps1 {
+			regulator-name = "vreg_s1f_0p7";
+			regulator-min-microvolt = <700000>;
+			regulator-max-microvolt = <1100000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-6 {
+		compatible = "qcom,pm8550ve-rpmh-regulators";
+		qcom,pmic-id = "i";
+
+		vdd-l1-supply = <&vreg_s4c_1p8>;
+		vdd-l2-supply = <&vreg_s5j_1p2>;
+		vdd-l3-supply = <&vreg_s1f_0p7>;
+		vdd-s1-supply = <&vreg_vph_pwr>;
+		vdd-s2-supply = <&vreg_vph_pwr>;
+
+		vreg_s1i_0p9: smps1 {
+			regulator-name = "vreg_s1i_0p9";
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s2i_1p0: smps2 {
+			regulator-name = "vreg_s2i_1p0";
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1100000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1i_1p8: ldo1 {
+			regulator-name = "vreg_l1i_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2i_1p2: ldo2 {
+			regulator-name = "vreg_l2i_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3i_0p8: ldo3 {
+			regulator-name = "vreg_l3i_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-7 {
+		compatible = "qcom,pm8550ve-rpmh-regulators";
+		qcom,pmic-id = "j";
+
+		vdd-l1-supply = <&vreg_s1f_0p7>;
+		vdd-l2-supply = <&vreg_s5j_1p2>;
+		vdd-l3-supply = <&vreg_s1f_0p7>;
+		vdd-s5-supply = <&vreg_vph_pwr>;
+
+		vreg_s5j_1p2: smps5 {
+			regulator-name = "vreg_s5j_1p2";
+			regulator-min-microvolt = <1256000>;
+			regulator-max-microvolt = <1304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1j_0p9: ldo1 {
+			regulator-name = "vreg_l1j_0p9";
+			regulator-min-microvolt = <912000>;
+			regulator-max-microvolt = <912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2j_1p2: ldo2 {
+			regulator-name = "vreg_l2j_1p2";
+			regulator-min-microvolt = <1256000>;
+			regulator-max-microvolt = <1256000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3j_0p8: ldo3 {
+			regulator-name = "vreg_l3j_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+};
+
+&gpu {
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	/* ELAN, 04F3:3315 */
+	touchpad@15 {
+		compatible = "hid-over-i2c";
+		reg = <0x15>;
+
+		hid-descr-addr = <0x1>;
+		interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
+
+		pinctrl-0 = <&tpad_default>;
+		pinctrl-names = "default";
+
+		wakeup-source;
+	};
+};
+
+&i2c3 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	/* Left-side display-adjacent port */
+	typec-mux@8 {
+		compatible = "parade,ps8833";
+		reg = <0x08>;
+
+		clocks = <&rpmhcc RPMH_RF_CLK3>;
+
+		vdd-supply = <&vreg_rtmr0_1p15>;
+		vdd33-supply = <&vreg_rtmr0_3p3>;
+		vdd33-cap-supply = <&vreg_rtmr0_3p3>;
+		vddar-supply = <&vreg_rtmr0_1p15>;
+		vddat-supply = <&vreg_rtmr0_1p15>;
+		vddio-supply = <&vreg_rtmr0_1p8>;
+
+		reset-gpios = <&pm8550_gpios 10 GPIO_ACTIVE_LOW>;
+
+		pinctrl-0 = <&rtmr0_default>;
+		pinctrl-names = "default";
+
+		retimer-switch;
+		orientation-switch;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				retimer_ss0_ss_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss0_ss_in>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+
+				retimer_ss0_ss_in: endpoint {
+					remote-endpoint = <&usb_1_ss0_qmpphy_out>;
+				};
+			};
+
+			port@2 {
+				reg = <2>;
+
+				retimer_ss0_con_sbu_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss0_con_sbu_in>;
+				};
+			};
+		};
+	};
+};
+
+&i2c4 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	/* ASUSTek, 0B05:4543 */
+	hdtl@17 {
+		compatible = "hid-over-i2c";
+		reg = <0x17>;
+
+		hid-descr-addr = <0x1>;
+		interrupts-extended = <&tlmm 95 IRQ_TYPE_LEVEL_LOW>;
+
+		pinctrl-0 = <&hdtl_default>;
+		pinctrl-names = "default";
+
+		wakeup-source;
+	};
+};
+
+&i2c5 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	eusb6_repeater: redriver@4f {
+		compatible = "nxp,ptn3222";
+		reg = <0x4f>;
+		#phy-cells = <0>;
+
+		vdd3v3-supply = <&vreg_l13b_3p0>;
+		vdd1v8-supply = <&vreg_l4b_1p8>;
+
+		reset-gpios = <&tlmm 184 GPIO_ACTIVE_LOW>;
+
+		pinctrl-0 = <&eusb6_reset_n>;
+		pinctrl-names = "default";
+	};
+
+	/* EC */
+};
+
+&i2c7 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	/* Left-side user-adjacent port */
+	typec-mux@8 {
+		compatible = "parade,ps8833";
+		reg = <0x08>;
+
+		clocks = <&rpmhcc RPMH_RF_CLK4>;
+
+		vdd-supply = <&vreg_rtmr1_1p15>;
+		vdd33-supply = <&vreg_rtmr1_3p3>;
+		vdd33-cap-supply = <&vreg_rtmr1_3p3>;
+		vddar-supply = <&vreg_rtmr1_1p15>;
+		vddat-supply = <&vreg_rtmr1_1p15>;
+		vddio-supply = <&vreg_rtmr1_1p8>;
+
+		reset-gpios = <&tlmm 176 GPIO_ACTIVE_LOW>;
+
+		pinctrl-0 = <&rtmr1_default>;
+		pinctrl-names = "default";
+
+		retimer-switch;
+		orientation-switch;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				retimer_ss1_ss_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss1_ss_in>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+
+				retimer_ss1_ss_in: endpoint {
+					remote-endpoint = <&usb_1_ss1_qmpphy_out>;
+				};
+			};
+
+			port@2 {
+				reg = <2>;
+
+				retimer_ss1_con_sbu_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss1_con_sbu_in>;
+				};
+			};
+		};
+	};
+};
+
+&i2c8 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	/* ASUSTek, 0B05:0220 */
+	keyboard@15 {
+		compatible = "hid-over-i2c";
+		reg = <0x15>;
+
+		hid-descr-addr = <0x1>;
+		interrupts-extended = <&tlmm 67 IRQ_TYPE_LEVEL_LOW>;
+
+		pinctrl-0 = <&kybd_default>;
+		pinctrl-names = "default";
+
+		wakeup-source;
+	};
+};
+
+&mdss {
+	status = "okay";
+};
+
+&mdss_dp0 {
+	status = "okay";
+};
+
+&mdss_dp0_out {
+	data-lanes = <0 1>;
+	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+};
+
+&mdss_dp1 {
+	status = "okay";
+};
+
+&mdss_dp1_out {
+	data-lanes = <0 1>;
+	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+};
+
+&mdss_dp3 {
+	compatible = "qcom,x1e80100-dp";
+	/delete-property/ #sound-dai-cells;
+
+	status = "okay";
+
+	aux-bus {
+		panel {
+			compatible = "edp-panel";
+			enable-gpios = <&pmc8380_3_gpios 4 GPIO_ACTIVE_HIGH>;
+			power-supply = <&vreg_edp_3p3>;
+
+			pinctrl-0 = <&edp_bl_en>;
+			pinctrl-names = "default";
+
+			port {
+				edp_panel_in: endpoint {
+					remote-endpoint = <&mdss_dp3_out>;
+				};
+			};
+		};
+	};
+
+	ports {
+		port@1 {
+			reg = <1>;
+
+			mdss_dp3_out: endpoint {
+				data-lanes = <0 1 2 3>;
+				link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+
+				remote-endpoint = <&edp_panel_in>;
+			};
+		};
+	};
+};
+
+&mdss_dp3_phy {
+	vdda-phy-supply = <&vreg_l3j_0p8>;
+	vdda-pll-supply = <&vreg_l2j_1p2>;
+
+	status = "okay";
+};
+
+&pcie4 {
+	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
+	pinctrl-0 = <&pcie4_default>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
+
+&pcie4_phy {
+	vdda-phy-supply = <&vreg_l3i_0p8>;
+	vdda-pll-supply = <&vreg_l3e_1p2>;
+
+	status = "okay";
+};
+
+&pcie6a {
+	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+
+	vddpe-3v3-supply = <&vreg_nvme>;
+
+	pinctrl-0 = <&pcie6a_default>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
+
+&pcie6a_phy {
+	vdda-phy-supply = <&vreg_l1d_0p8>;
+	vdda-pll-supply = <&vreg_l2j_1p2>;
+
+	status = "okay";
+};
+
+&pm8550_gpios {
+	rtmr0_default: rtmr0-reset-n-active-state {
+		pins = "gpio10";
+		function = "normal";
+		power-source = <1>; /* 1.8V */
+		bias-disable;
+		input-disable;
+		output-enable;
+	};
+
+	usb0_3p3_reg_en: usb0-3p3-reg-en-state {
+		pins = "gpio11";
+		function = "normal";
+		power-source = <1>; /* 1.8V */
+		bias-disable;
+		input-disable;
+		output-enable;
+	};
+};
+
+&pm8550ve_8_gpios {
+	misc_3p3_reg_en: misc-3p3-reg-en-state {
+		pins = "gpio6";
+		function = "normal";
+		bias-disable;
+		input-disable;
+		output-enable;
+		drive-push-pull;
+		power-source = <1>; /* 1.8 V */
+		qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
+	};
+};
+
+&pm8550ve_9_gpios {
+	usb0_1p8_reg_en: usb0-1p8-reg-en-state {
+		pins = "gpio8";
+		function = "normal";
+		power-source = <1>; /* 1.8V */
+		bias-disable;
+		input-disable;
+		output-enable;
+	};
+};
+
+&pmc8380_3_gpios {
+	edp_bl_en: edp-bl-en-state {
+		pins = "gpio4";
+		function = "normal";
+		power-source = <1>; /* 1.8V */
+		input-disable;
+		output-enable;
+	};
+};
+
+&pmc8380_5_gpios {
+	usb0_pwr_1p15_reg_en: usb0-pwr-1p15-reg-en-state {
+		pins = "gpio8";
+		function = "normal";
+		power-source = <1>; /* 1.8V */
+		bias-disable;
+		input-disable;
+		output-enable;
+	};
+};
+
+&qupv3_0 {
+	status = "okay";
+};
+
+&qupv3_1 {
+	status = "okay";
+};
+
+&qupv3_2 {
+	status = "okay";
+};
+
+&smb2360_0 {
+	status = "okay";
+};
+
+&smb2360_0_eusb2_repeater {
+	vdd18-supply = <&vreg_l3d_1p8>;
+	vdd3-supply = <&vreg_l2b_3p0>;
+};
+
+&smb2360_1 {
+	status = "okay";
+};
+
+&smb2360_1_eusb2_repeater {
+	vdd18-supply = <&vreg_l3d_1p8>;
+	vdd3-supply = <&vreg_l14b_3p0>;
+};
+
+&spi10 {
+	status = "disabled";
+
+	/* Unknown device */
+};
+
+&tlmm {
+	gpio-reserved-ranges = <44 4>,  /* SPI11, TZ Protected */
+			       <90 1>;	/* Unknown, TZ Protected */
+
+	bt_en_default: bt-en-sleep {
+		pins = "gpio116";
+		function = "gpio";
+		output-low;
+		bias-disable;
+		qcom,drive-strength = <16>;
+	};
+
+	cam_indicator_en: cam-indicator-en-state {
+		pins = "gpio110";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	edp_reg_en: edp-reg-en-state {
+		pins = "gpio70";
+		function = "gpio";
+		drive-strength = <16>;
+		bias-disable;
+	};
+
+	eusb6_reset_n: eusb6-reset-n-state {
+		pins = "gpio184";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+		output-low;
+	};
+
+	hall_int_n_default: hall-int-n-state {
+		pins = "gpio92";
+		function = "gpio";
+		bias-disable;
+	};
+
+	hdtl_default: hdtl-default-state {
+		pins = "gpio95";
+		function = "gpio";
+	};
+
+	kybd_default: kybd-default-state {
+		pins = "gpio67";
+		function = "gpio";
+		bias-pull-up;
+	};
+
+	nvme_reg_en: nvme-reg-en-state {
+		pins = "gpio18";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	pcie4_default: pcie4-default-state {
+		clkreq-n-pins {
+			pins = "gpio147";
+			function = "pcie4_clk";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+
+		perst-n-pins {
+			pins = "gpio146";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-disable;
+		};
+
+		wake-n-pins {
+			pins = "gpio148";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+	};
+
+	pcie6a_default: pcie6a-default-state {
+		clkreq-n-pins {
+			pins = "gpio153";
+			function = "pcie6a_clk";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+
+		perst-n-pins {
+			pins = "gpio152";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-disable;
+		};
+
+		wake-n-pins {
+			pins = "gpio154";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+	};
+
+	rtmr1_default: rtmr1-reset-n-active-state {
+		pins = "gpio176";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	tpad_default: tpad-default-state {
+		pins = "gpio3";
+		function = "gpio";
+		bias-disable;
+	};
+
+	usb1_pwr_1p15_reg_en: usb1-pwr-1p15-reg-en-state {
+		pins = "gpio188";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	usb1_pwr_1p8_reg_en: usb1-pwr-1p8-reg-en-state {
+		pins = "gpio175";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	usb1_pwr_3p3_reg_en: usb1-pwr-3p3-reg-en-state {
+		pins = "gpio186";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+};
+
+&uart21 {
+	compatible = "qcom,geni-debug-uart";
+	status = "okay";
+};
+
+&usb_1_ss0_hsphy {
+	vdd-supply = <&vreg_l3j_0p8>;
+	vdda12-supply = <&vreg_l2j_1p2>;
+
+	phys = <&smb2360_0_eusb2_repeater>;
+
+	status = "okay";
+};
+
+&usb_1_ss0_qmpphy {
+	vdda-phy-supply = <&vreg_l2j_1p2>;
+	vdda-pll-supply = <&vreg_l1j_0p9>;
+
+	status = "okay";
+};
+
+&usb_1_ss0 {
+	status = "okay";
+};
+
+&usb_1_ss0_dwc3 {
+	dr_mode = "host";
+};
+
+&usb_1_ss0_dwc3_hs {
+	remote-endpoint = <&pmic_glink_ss0_hs_in>;
+};
+
+&usb_1_ss0_qmpphy_out {
+	remote-endpoint = <&retimer_ss0_ss_in>;
+};
+
+&usb_1_ss1_hsphy {
+	vdd-supply = <&vreg_l3j_0p8>;
+	vdda12-supply = <&vreg_l2j_1p2>;
+
+	phys = <&smb2360_1_eusb2_repeater>;
+
+	status = "okay";
+};
+
+&usb_1_ss1_qmpphy {
+	vdda-phy-supply = <&vreg_l2j_1p2>;
+	vdda-pll-supply = <&vreg_l2d_0p9>;
+
+	status = "okay";
+};
+
+&usb_1_ss1 {
+	status = "okay";
+};
+
+&usb_1_ss1_dwc3 {
+	dr_mode = "host";
+};
+
+&usb_1_ss1_dwc3_hs {
+	remote-endpoint = <&pmic_glink_ss1_hs_in>;
+};
+
+&usb_1_ss1_qmpphy_out {
+	remote-endpoint = <&retimer_ss1_ss_in>;
+};
+
+&usb_mp {
+	status = "okay";
+};
+
+&usb_mp_hsphy0 {
+	vdd-supply = <&vreg_l2e_0p8>;
+	vdda12-supply = <&vreg_l3e_1p2>;
+
+	status = "okay";
+};
+
+&usb_mp_hsphy1 {
+	vdd-supply = <&vreg_l2e_0p8>;
+	vdda12-supply = <&vreg_l3e_1p2>;
+
+	phys = <&eusb6_repeater>;
+
+	status = "okay";
+};
+
+&usb_mp_qmpphy0 {
+	vdda-phy-supply = <&vreg_l3e_1p2>;
+	vdda-pll-supply = <&vreg_l3c_0p9>;
+
+	status = "okay";
+};
+
+&usb_mp_qmpphy1 {
+	vdda-phy-supply = <&vreg_l3e_1p2>;
+	vdda-pll-supply = <&vreg_l3c_0p9>;
+
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dts b/arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dts
new file mode 100644
index 000000000000..6bddf50435b2
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2025 Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "x1e80100.dtsi"
+#include "x1-zenbook-a14.dtsi"
+
+/ {
+	model = "ASUS Zenbook A14 UX3407RA";
+	compatible = "asus,x1e80100-zenbook-a14", "qcom,x1e80100";
+};
+
+&gpu_zap_shader {
+	firmware-name = "qcom/x1e80100/ASUSTeK/zenbook-a14/qcdxkmsuc8380.mbn";
+};
+
+&remoteproc_adsp {
+	firmware-name = "qcom/x1e80100/ASUSTeK/zenbook-a14/qcadsp8380.mbn",
+			"qcom/x1e80100/ASUSTeK/zenbook-a14/adsp_dtbs.elf";
+
+	status = "okay";
+};
+
+&remoteproc_cdsp {
+	firmware-name = "qcom/x1e80100/ASUSTeK/zenbook-a14/qccdsp8380.mbn",
+			"qcom/x1e80100/ASUSTeK/zenbook-a14/cdsp_dtbs.elf";
+
+	status = "okay";
+};
+
+&uart14 {
+	status = "okay";
+
+	bluetooth {
+		compatible = "qcom,wcn7850-bt";
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_en_default>;
+		enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
+		max-speed = <3000000>;
+	};
+};
diff --git a/arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts b/arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts
new file mode 100644
index 000000000000..b6c9a707090f
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2025 Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "x1p42100.dtsi"
+#include "x1-zenbook-a14.dtsi"
+
+/delete-node/ &pmc8380_6;
+/delete-node/ &pmc8380_6_thermal;
+
+/ {
+	model = "ASUS Zenbook A14 UX3407QA";
+	compatible = "asus,x1p42100-zenbook-a14", "qcom,x1p42100";
+};
+
+&gpu_zap_shader {
+	firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qcdxkmsuc8380.mbn";
+};
+
+&remoteproc_adsp {
+	firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qcadsp8380.mbn",
+			"qcom/x1p42100/ASUSTeK/zenbook-a14/adsp_dtbs.elf";
+
+	status = "okay";
+};
+
+&remoteproc_cdsp {
+	firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qccdsp8380.mbn",
+			"qcom/x1p42100/ASUSTeK/zenbook-a14/cdsp_dtbs.elf";
+
+	status = "okay";
+};
+
+&uart14 {
+	status = "okay";
+
+	bluetooth {
+		compatible = "qcom,wcn6855-bt";
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_en_default>;
+		enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
+		max-speed = <3000000>;
+	};
+};
-- 
2.45.2

Re: [PATCH v1 6/6] arm64: dts: qcom: Add support for X1-based Asus Zenbook A14

[Konrad Dybcio]

On 3/31/25 11:53 PM, Aleksandrs Vinarskis wrote:
> Initial support for Asus Zenbook A14. Particular moddel exists
> in X1-26-100, X1P-42-100 (UX3407QA) and X1E-78-100 (UX3407RA).
> 
> Mostly similar to other X1-based laptops. Notable differences are:
> * Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA
>   and Qualcomm FastConnect 7800 on UX3407RA
> * USB Type-C retimers are Parade PS8833, appear to behave identical
>   to Parade PS8830
> * gpio90 is TZ protected

[...]

> +	leds {
> +		compatible = "gpio-leds";
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&cam_indicator_en>;

property-n
property-names

please, we're trying to unify such small things even though we know
it's "wrong" in a lot of places

> +
> +&i2c0 {
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	/* ELAN, 04F3:3315 */
> +	touchpad@15 {
> +		compatible = "hid-over-i2c";
> +		reg = <0x15>;
> +
> +		hid-descr-addr = <0x1>;
> +		interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
> +
> +		pinctrl-0 = <&tpad_default>;
> +		pinctrl-names = "default";
> +
> +		wakeup-source;
> +	};
> +};
> +
> +&i2c3 {
> +	clock-frequency = <400000>;
> +	status = "okay";

It's also customary to leave a newline before 'status'

> +&pm8550_gpios {
> +	rtmr0_default: rtmr0-reset-n-active-state {
> +		pins = "gpio10";
> +		function = "normal";
> +		power-source = <1>; /* 1.8V */

Drop the 1.8v comments please

[...]

> +&spi10 {
> +	status = "disabled";
> +
> +	/* Unknown device */
> +};

Does the device crash if you enable this bus? Keeping it 'okay' would
make it easier for folks to poke at it

> +
> +&tlmm {
> +	gpio-reserved-ranges = <44 4>,  /* SPI11, TZ Protected */
> +			       <90 1>;	/* Unknown, TZ Protected */
> +
> +	bt_en_default: bt-en-sleep {
> +		pins = "gpio116";
> +		function = "gpio";
> +		output-low;
> +		bias-disable;
> +		qcom,drive-strength = <16>;

drop "qcom," and please keep the order of:

pins
function
drive-strength
bias
output/input

as you did below

> +
> +/ {
> +	model = "ASUS Zenbook A14 UX3407RA";

There's no strict policy, but variants usually go in braces

> +	compatible = "asus,x1e80100-zenbook-a14", "qcom,x1e80100";
> +};
> +
> +&gpu_zap_shader {
> +	firmware-name = "qcom/x1e80100/ASUSTeK/zenbook-a14/qcdxkmsuc8380.mbn";
> +};
> +
> +&remoteproc_adsp {
> +	firmware-name = "qcom/x1e80100/ASUSTeK/zenbook-a14/qcadsp8380.mbn",
> +			"qcom/x1e80100/ASUSTeK/zenbook-a14/adsp_dtbs.elf";
> +
> +	status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> +	firmware-name = "qcom/x1e80100/ASUSTeK/zenbook-a14/qccdsp8380.mbn",
> +			"qcom/x1e80100/ASUSTeK/zenbook-a14/cdsp_dtbs.elf";
> +
> +	status = "okay";
> +};
> +
> +&uart14 {
> +	status = "okay";
> +
> +	bluetooth {
> +		compatible = "qcom,wcn7850-bt";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bt_en_default>;
> +		enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
> +		max-speed = <3000000>;
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts b/arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts
> new file mode 100644
> index 000000000000..b6c9a707090f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2025 Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
> + */
> +
> +/dts-v1/;
> +
> +#include "x1p42100.dtsi"
> +#include "x1-zenbook-a14.dtsi"
> +
> +/delete-node/ &pmc8380_6;
> +/delete-node/ &pmc8380_6_thermal;
> +
> +/ {
> +	model = "ASUS Zenbook A14 UX3407QA";
> +	compatible = "asus,x1p42100-zenbook-a14", "qcom,x1p42100";
> +};
> +
> +&gpu_zap_shader {
> +	firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qcdxkmsuc8380.mbn";
> +};

This file is not going to work on this SoC, you can drop it

> +
> +&remoteproc_adsp {
> +	firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qcadsp8380.mbn",
> +			"qcom/x1p42100/ASUSTeK/zenbook-a14/adsp_dtbs.elf";
> +
> +	status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> +	firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qccdsp8380.mbn",
> +			"qcom/x1p42100/ASUSTeK/zenbook-a14/cdsp_dtbs.elf";
> +
> +	status = "okay";

Are the DSP firmware files actually different between the two?

Konrad

Re: [PATCH v1 6/6] arm64: dts: qcom: Add support for X1-based Asus Zenbook A14

[Aleksandrs Vinarskis]

On Tue, 1 Apr 2025 at 17:59, Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 3/31/25 11:53 PM, Aleksandrs Vinarskis wrote:
> > Initial support for Asus Zenbook A14. Particular moddel exists
> > in X1-26-100, X1P-42-100 (UX3407QA) and X1E-78-100 (UX3407RA).
> >
> > Mostly similar to other X1-based laptops. Notable differences are:
> > * Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA
> >   and Qualcomm FastConnect 7800 on UX3407RA
> > * USB Type-C retimers are Parade PS8833, appear to behave identical
> >   to Parade PS8830
> > * gpio90 is TZ protected
>
> [...]
>
> > +     leds {
> > +             compatible = "gpio-leds";
> > +
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&cam_indicator_en>;
>
> property-n
> property-names
>
> please, we're trying to unify such small things even though we know
> it's "wrong" in a lot of places
>

will do.

> > +
> > +&i2c0 {
> > +     clock-frequency = <400000>;
> > +     status = "okay";
> > +
> > +     /* ELAN, 04F3:3315 */
> > +     touchpad@15 {
> > +             compatible = "hid-over-i2c";
> > +             reg = <0x15>;
> > +
> > +             hid-descr-addr = <0x1>;
> > +             interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
> > +
> > +             pinctrl-0 = <&tpad_default>;
> > +             pinctrl-names = "default";
> > +
> > +             wakeup-source;
> > +     };
> > +};
> > +
> > +&i2c3 {
> > +     clock-frequency = <400000>;
> > +     status = "okay";
>
> It's also customary to leave a newline before 'status'

will do.

>
> > +&pm8550_gpios {
> > +     rtmr0_default: rtmr0-reset-n-active-state {
> > +             pins = "gpio10";
> > +             function = "normal";
> > +             power-source = <1>; /* 1.8V */
>
> Drop the 1.8v comments please

will do.

>
> [...]
>
> > +&spi10 {
> > +     status = "disabled";
> > +
> > +     /* Unknown device */
> > +};
>
> Does the device crash if you enable this bus? Keeping it 'okay' would
> make it easier for folks to poke at it

It does boot just fine, but does not initialize:
```
geni_spi a88000.spi: Invalid proto 9
...
qnoc-x1e80100 interconnect-1: sync_state() pending due to a88000.spi
...
```

I only quickly checked that 9 is indeed invalid state, iirc should've
been 2. But haven't looked deeper into it, so left it disabled. So I
thought best to leave it off for now. Unless you prefer to drop it
altogether?

>
> > +
> > +&tlmm {
> > +     gpio-reserved-ranges = <44 4>,  /* SPI11, TZ Protected */
> > +                            <90 1>;  /* Unknown, TZ Protected */
> > +
> > +     bt_en_default: bt-en-sleep {
> > +             pins = "gpio116";
> > +             function = "gpio";
> > +             output-low;
> > +             bias-disable;
> > +             qcom,drive-strength = <16>;
>
> drop "qcom," and please keep the order of:
>
> pins
> function
> drive-strength
> bias
> output/input
>
> as you did below

Will do.

Should I also drop 'qcom,' from the 'misc_3p3_reg_en' and adjust order
the same way, or that one is somehow special?

>
> > +
> > +/ {
> > +     model = "ASUS Zenbook A14 UX3407RA";
>
> There's no strict policy, but variants usually go in braces

Parenthesis I guess, "ASUS Zenbook A14 (UX3407RA)" ?

>
> > +     compatible = "asus,x1e80100-zenbook-a14", "qcom,x1e80100";
> > +};
> > +
> > +&gpu_zap_shader {
> > +     firmware-name = "qcom/x1e80100/ASUSTeK/zenbook-a14/qcdxkmsuc8380.mbn";
> > +};
> > +
> > +&remoteproc_adsp {
> > +     firmware-name = "qcom/x1e80100/ASUSTeK/zenbook-a14/qcadsp8380.mbn",
> > +                     "qcom/x1e80100/ASUSTeK/zenbook-a14/adsp_dtbs.elf";
> > +
> > +     status = "okay";
> > +};
> > +
> > +&remoteproc_cdsp {
> > +     firmware-name = "qcom/x1e80100/ASUSTeK/zenbook-a14/qccdsp8380.mbn",
> > +                     "qcom/x1e80100/ASUSTeK/zenbook-a14/cdsp_dtbs.elf";
> > +
> > +     status = "okay";
> > +};
> > +
> > +&uart14 {
> > +     status = "okay";
> > +
> > +     bluetooth {
> > +             compatible = "qcom,wcn7850-bt";
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&bt_en_default>;
> > +             enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
> > +             max-speed = <3000000>;
> > +     };
> > +};
> > diff --git a/arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts b/arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts
> > new file mode 100644
> > index 000000000000..b6c9a707090f
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts
> > @@ -0,0 +1,48 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
> > + * Copyright (c) 2025 Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "x1p42100.dtsi"
> > +#include "x1-zenbook-a14.dtsi"
> > +
> > +/delete-node/ &pmc8380_6;
> > +/delete-node/ &pmc8380_6_thermal;
> > +
> > +/ {
> > +     model = "ASUS Zenbook A14 UX3407QA";
> > +     compatible = "asus,x1p42100-zenbook-a14", "qcom,x1p42100";
> > +};
> > +
> > +&gpu_zap_shader {
> > +     firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qcdxkmsuc8380.mbn";
> > +};
>
> This file is not going to work on this SoC, you can drop it

I guess it would need a different firmware name? If yes, can we
already add the new name, such that once x1p42100 gains GPU support it
will get enabled 'automatically'?

Otherwise, I will just drop it.

>
> > +
> > +&remoteproc_adsp {
> > +     firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qcadsp8380.mbn",
> > +                     "qcom/x1p42100/ASUSTeK/zenbook-a14/adsp_dtbs.elf";
> > +
> > +     status = "okay";
> > +};
> > +
> > +&remoteproc_cdsp {
> > +     firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qccdsp8380.mbn",
> > +                     "qcom/x1p42100/ASUSTeK/zenbook-a14/cdsp_dtbs.elf";
> > +
> > +     status = "okay";
>
> Are the DSP firmware files actually different between the two?

CDSP is the same. ADSP blobs to my surprise are different, both '.elf'
and '.mbn'. But like I wrote in the cover letter, perhaps Asus just
forgot to update adsp firmware? Though according to changelong on
device pages [2],[4] both have "ADSP Driver : 2.0.4135.0200"

Compared by:
* Downloading UX3407QA's drivers [1], from the device page [2] and
UX3407RA'a drivers [3] from the device page [4]
* Extract and flatten with `7z e filename.exe`
* Compare via `md5sum *dsp*elf *dsp*mbn *dsp*jsn`

Though, even if the blobs would be/will be the same, I think it is
still beneficial to define firmware path per model, as this makes
firmware extraction from driver/Windows partition and placement much
easier. Unfortunately, as it seems so far, most of the devices besides
Lenovos are not having firmware upstreamed, so this is pretty
relevant. Eg. Ubuntu already has 'firmware extracting tool' [5] (draft
MR to include Zenbook as well), I'm guessing other distros have
something similar, though I haven't followed up.

On the other hand, these tools could of course get path from device
tree directly, eg. via `cat
/sys/firmware/devicetree/base/soc@0/remoteproc@32300000/firmware-name`,
then having all the blobs for the device in one location is less
relevant...

Thanks for reviewing,
Alex

[1] https://dlcdnets.asus.com/pub/ASUS/nb/Image/Driver/DriverPackage/42706/SOCPackage_forWebSite_Qualcomm_Z_V1.305.7550.2_42706.exe?model=UX3407QA
[2] https://www.asus.com/ch-en/laptops/for-home/zenbook/asus-zenbook-a14-ux3407/helpdesk_download?model2Name=UX3407QA
[3] https://dlcdnets.asus.com/pub/ASUS/nb/Image/Driver/DriverPackage/42705/SOCPackage_forWebSite_Qualcomm_Z_V1.305.7550.2_42705.exe?model=UX3407RA
[4] https://www.asus.com/ch-en/laptops/for-home/zenbook/asus-zenbook-a14-ux3407/helpdesk_download?model2Name=UX3407RA
[5] https://git.launchpad.net/~alexvinarskis/ubuntu/+source/qcom-firmware-extract/tree/qcom-firmware-extract?h=asus-zenbook-a14

>
> Konrad

Re: [PATCH v1 6/6] arm64: dts: qcom: Add support for X1-based Asus Zenbook A14

[Konrad Dybcio]

On 4/1/25 8:05 PM, Aleksandrs Vinarskis wrote:
> On Tue, 1 Apr 2025 at 17:59, Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 3/31/25 11:53 PM, Aleksandrs Vinarskis wrote:
>>> Initial support for Asus Zenbook A14. Particular moddel exists
>>> in X1-26-100, X1P-42-100 (UX3407QA) and X1E-78-100 (UX3407RA).
>>>
>>> Mostly similar to other X1-based laptops. Notable differences are:
>>> * Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA
>>>   and Qualcomm FastConnect 7800 on UX3407RA
>>> * USB Type-C retimers are Parade PS8833, appear to behave identical
>>>   to Parade PS8830
>>> * gpio90 is TZ protected
>>

[...]

>>
>>> +&spi10 {
>>> +     status = "disabled";
>>> +
>>> +     /* Unknown device */
>>> +};
>>
>> Does the device crash if you enable this bus? Keeping it 'okay' would
>> make it easier for folks to poke at it
> 
> It does boot just fine, but does not initialize:
> ```
> geni_spi a88000.spi: Invalid proto 9
> ...
> qnoc-x1e80100 interconnect-1: sync_state() pending due to a88000.spi
> ...
> ```
> 
> I only quickly checked that 9 is indeed invalid state, iirc should've
> been 2. But haven't looked deeper into it, so left it disabled. So I
> thought best to leave it off for now. Unless you prefer to drop it
> altogether?

That means this QUP is configured to work as a QSPI host, which is not yet 
supported upstream. I looked at the DSDT you submitted to aa64-laptops, but
there doesn't seem to be anything connected there, perhaps it's loaded at
runtime. Since your keyboard and touchpad work, maybe it's a touchscreen?


> 
>>
>>> +
>>> +&tlmm {
>>> +     gpio-reserved-ranges = <44 4>,  /* SPI11, TZ Protected */
>>> +                            <90 1>;  /* Unknown, TZ Protected */
>>> +
>>> +     bt_en_default: bt-en-sleep {
>>> +             pins = "gpio116";
>>> +             function = "gpio";
>>> +             output-low;
>>> +             bias-disable;
>>> +             qcom,drive-strength = <16>;
>>
>> drop "qcom," and please keep the order of:
>>
>> pins
>> function
>> drive-strength
>> bias
>> output/input
>>
>> as you did below
> 
> Will do.
> 
> Should I also drop 'qcom,' from the 'misc_3p3_reg_en' and adjust order
> the same way, or that one is somehow special?

Sort of. &tlmm and &pm8xxx_gpios use two different drivers, each one
of which has slightly different expectations about their subnodes.
 > 
>>
>>> +
>>> +/ {
>>> +     model = "ASUS Zenbook A14 UX3407RA";
>>
>> There's no strict policy, but variants usually go in braces
> 
> Parenthesis I guess, "ASUS Zenbook A14 (UX3407RA)" ?

Ugh, yes!

[...]

>>> +
>>> +&gpu_zap_shader {
>>> +     firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qcdxkmsuc8380.mbn";
>>> +};
>>
>> This file is not going to work on this SoC, you can drop it
> 
> I guess it would need a different firmware name? If yes, can we
> already add the new name, such that once x1p42100 gains GPU support it
> will get enabled 'automatically'?

The filename is different indeed. You can add it, as currently this
property is not yet consumed by anything, anyway.

[...]

>>
>>> +
>>> +&remoteproc_adsp {
>>> +     firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qcadsp8380.mbn",
>>> +                     "qcom/x1p42100/ASUSTeK/zenbook-a14/adsp_dtbs.elf";
>>> +
>>> +     status = "okay";
>>> +};
>>> +
>>> +&remoteproc_cdsp {
>>> +     firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qccdsp8380.mbn",
>>> +                     "qcom/x1p42100/ASUSTeK/zenbook-a14/cdsp_dtbs.elf";
>>> +
>>> +     status = "okay";
>>
>> Are the DSP firmware files actually different between the two?
> 
> CDSP is the same. ADSP blobs to my surprise are different, both '.elf'
> and '.mbn'. But like I wrote in the cover letter, perhaps Asus just
> forgot to update adsp firmware? Though according to changelong on
> device pages [2],[4] both have "ADSP Driver : 2.0.4135.0200"
> 
> Compared by:
> * Downloading UX3407QA's drivers [1], from the device page [2] and
> UX3407RA'a drivers [3] from the device page [4]
> * Extract and flatten with `7z e filename.exe`
> * Compare via `md5sum *dsp*elf *dsp*mbn *dsp*jsn`
> 
> Though, even if the blobs would be/will be the same, I think it is
> still beneficial to define firmware path per model, as this makes
> firmware extraction from driver/Windows partition and placement much
> easier. Unfortunately, as it seems so far, most of the devices besides
> Lenovos are not having firmware upstreamed, so this is pretty
> relevant. Eg. Ubuntu already has 'firmware extracting tool' [5] (draft
> MR to include Zenbook as well), I'm guessing other distros have
> something similar, though I haven't followed up.
> 
> On the other hand, these tools could of course get path from device
> tree directly, eg. via `cat
> /sys/firmware/devicetree/base/soc@0/remoteproc@32300000/firmware-name`,
> then having all the blobs for the device in one location is less
> relevant...

More importantly, different blobs may (but don't necessarily have to) include
different, hardcoded expectations about the board (or platform) they run on.
So let's keep them separate.

Konrad

Re: [PATCH v1 6/6] arm64: dts: qcom: Add support for X1-based Asus Zenbook A14

[Aleksandrs Vinarskis]

On Tue, 1 Apr 2025 at 23:15, Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 4/1/25 8:05 PM, Aleksandrs Vinarskis wrote:
> > On Tue, 1 Apr 2025 at 17:59, Konrad Dybcio
> > <konrad.dybcio@oss.qualcomm.com> wrote:
> >>
> >> On 3/31/25 11:53 PM, Aleksandrs Vinarskis wrote:
> >>> Initial support for Asus Zenbook A14. Particular moddel exists
> >>> in X1-26-100, X1P-42-100 (UX3407QA) and X1E-78-100 (UX3407RA).
> >>>
> >>> Mostly similar to other X1-based laptops. Notable differences are:
> >>> * Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA
> >>>   and Qualcomm FastConnect 7800 on UX3407RA
> >>> * USB Type-C retimers are Parade PS8833, appear to behave identical
> >>>   to Parade PS8830
> >>> * gpio90 is TZ protected
> >>
>
> [...]
>
> >>
> >>> +&spi10 {
> >>> +     status = "disabled";
> >>> +
> >>> +     /* Unknown device */
> >>> +};
> >>
> >> Does the device crash if you enable this bus? Keeping it 'okay' would
> >> make it easier for folks to poke at it
> >
> > It does boot just fine, but does not initialize:
> > ```
> > geni_spi a88000.spi: Invalid proto 9
> > ...
> > qnoc-x1e80100 interconnect-1: sync_state() pending due to a88000.spi
> > ...
> > ```
> >
> > I only quickly checked that 9 is indeed invalid state, iirc should've
> > been 2. But haven't looked deeper into it, so left it disabled. So I
> > thought best to leave it off for now. Unless you prefer to drop it
> > altogether?
>
> That means this QUP is configured to work as a QSPI host, which is not yet
> supported upstream. I looked at the DSDT you submitted to aa64-laptops, but
> there doesn't seem to be anything connected there, perhaps it's loaded at
> runtime. Since your keyboard and touchpad work, maybe it's a touchscreen?
>

Indeed it is just defined without anything attached. I am suspecting
it also may be just leftover, won't be the first one...
No, this particular laptop doesn't have a touchscreen in any of the
three screen configurations announced.

It also does not have a fingerprint reader, nor hardware TPM2.0 (yet
SPI11 typically used for it is still TZ protected :). EC seems to be
over i2c5. Asus's touchpad supports some fancy gesture controls, but
there is in fact another 'extra' hidraw device 'hdtl', I assume that's
the one. No sdcard reader.
Only other still unsupported features are audio (i guess unlikely that
they used different smart amp?), camera (ov02c01, pm8010, so also no)
and DP-HDMI bridge PS185HDM, which from what I can guesstimate is i2c.

So I am a bit out of ideas of what it could be...only thing that comes
to my mind is headphone jack smart amp, ifff they did not use qcom amp
one there as well?

>
> >
> >>
> >>> +
> >>> +&tlmm {
> >>> +     gpio-reserved-ranges = <44 4>,  /* SPI11, TZ Protected */
> >>> +                            <90 1>;  /* Unknown, TZ Protected */
> >>> +
> >>> +     bt_en_default: bt-en-sleep {
> >>> +             pins = "gpio116";
> >>> +             function = "gpio";
> >>> +             output-low;
> >>> +             bias-disable;
> >>> +             qcom,drive-strength = <16>;
> >>
> >> drop "qcom," and please keep the order of:
> >>
> >> pins
> >> function
> >> drive-strength
> >> bias
> >> output/input
> >>
> >> as you did below
> >
> > Will do.
> >
> > Should I also drop 'qcom,' from the 'misc_3p3_reg_en' and adjust order
> > the same way, or that one is somehow special?
>
> Sort of. &tlmm and &pm8xxx_gpios use two different drivers, each one
> of which has slightly different expectations about their subnodes.

Ah I see. Okay, will fix the order, but will leave `qcom,` as is.

>  >
> >>
> >>> +
> >>> +/ {
> >>> +     model = "ASUS Zenbook A14 UX3407RA";
> >>
> >> There's no strict policy, but variants usually go in braces
> >
> > Parenthesis I guess, "ASUS Zenbook A14 (UX3407RA)" ?
>
> Ugh, yes!

Sounds reasonable and looks a bit better, will update.

>
> [...]
>
> >>> +
> >>> +&gpu_zap_shader {
> >>> +     firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qcdxkmsuc8380.mbn";
> >>> +};
> >>
> >> This file is not going to work on this SoC, you can drop it
> >
> > I guess it would need a different firmware name? If yes, can we
> > already add the new name, such that once x1p42100 gains GPU support it
> > will get enabled 'automatically'?
>
> The filename is different indeed. You can add it, as currently this
> property is not yet consumed by anything, anyway.

Just checked, should be the `qcdxkmsucpurwa.mbn` then. Will update it,
thanks for confirmation.

>
> [...]
>
> >>
> >>> +
> >>> +&remoteproc_adsp {
> >>> +     firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qcadsp8380.mbn",
> >>> +                     "qcom/x1p42100/ASUSTeK/zenbook-a14/adsp_dtbs.elf";
> >>> +
> >>> +     status = "okay";
> >>> +};
> >>> +
> >>> +&remoteproc_cdsp {
> >>> +     firmware-name = "qcom/x1p42100/ASUSTeK/zenbook-a14/qccdsp8380.mbn",
> >>> +                     "qcom/x1p42100/ASUSTeK/zenbook-a14/cdsp_dtbs.elf";
> >>> +
> >>> +     status = "okay";
> >>
> >> Are the DSP firmware files actually different between the two?
> >
> > CDSP is the same. ADSP blobs to my surprise are different, both '.elf'
> > and '.mbn'. But like I wrote in the cover letter, perhaps Asus just
> > forgot to update adsp firmware? Though according to changelong on
> > device pages [2],[4] both have "ADSP Driver : 2.0.4135.0200"
> >
> > Compared by:
> > * Downloading UX3407QA's drivers [1], from the device page [2] and
> > UX3407RA'a drivers [3] from the device page [4]
> > * Extract and flatten with `7z e filename.exe`
> > * Compare via `md5sum *dsp*elf *dsp*mbn *dsp*jsn`
> >
> > Though, even if the blobs would be/will be the same, I think it is
> > still beneficial to define firmware path per model, as this makes
> > firmware extraction from driver/Windows partition and placement much
> > easier. Unfortunately, as it seems so far, most of the devices besides
> > Lenovos are not having firmware upstreamed, so this is pretty
> > relevant. Eg. Ubuntu already has 'firmware extracting tool' [5] (draft
> > MR to include Zenbook as well), I'm guessing other distros have
> > something similar, though I haven't followed up.
> >
> > On the other hand, these tools could of course get path from device
> > tree directly, eg. via `cat
> > /sys/firmware/devicetree/base/soc@0/remoteproc@32300000/firmware-name`,
> > then having all the blobs for the device in one location is less
> > relevant...
>
> More importantly, different blobs may (but don't necessarily have to) include
> different, hardcoded expectations about the board (or platform) they run on.
> So let's keep them separate.

Ah okay. Perfect, keeping as is.

Thanks,
Alex

>
> Konrad

Re: [PATCH v1 6/6] arm64: dts: qcom: Add support for X1-based Asus Zenbook A14

[Maud Spierings]

> On Tue, 1 Apr 2025 at 23:15, Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 4/1/25 8:05 PM, Aleksandrs Vinarskis wrote:
>> > On Tue, 1 Apr 2025 at 17:59, Konrad Dybcio
>> > <konrad.dybcio@oss.qualcomm.com> wrote:
>> >>
>> >> On 3/31/25 11:53 PM, Aleksandrs Vinarskis wrote:
>> >>> Initial support for Asus Zenbook A14. Particular moddel exists
>> >>> in X1-26-100, X1P-42-100 (UX3407QA) and X1E-78-100 (UX3407RA).
>> >>>
>> >>> Mostly similar to other X1-based laptops. Notable differences are:
>> >>> * Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA
>> >>>   and Qualcomm FastConnect 7800 on UX3407RA
>> >>> * USB Type-C retimers are Parade PS8833, appear to behave identical
>> >>>   to Parade PS8830
>> >>> * gpio90 is TZ protected
>> >>
>>
>> [...]
>>
>> >>
>> >>> +&spi10 {
>> >>> +     status = "disabled";
>> >>> +
>> >>> +     /* Unknown device */
>> >>> +};
>> >>
>> >> Does the device crash if you enable this bus? Keeping it 'okay' would
>> >> make it easier for folks to poke at it
>> >
>> > It does boot just fine, but does not initialize:
>> > ```
>> > geni_spi a88000.spi: Invalid proto 9
>> > ...
>> > qnoc-x1e80100 interconnect-1: sync_state() pending due to a88000.spi
>> > ...
>> > ```
>> >
>> > I only quickly checked that 9 is indeed invalid state, iirc should've
>> > been 2. But haven't looked deeper into it, so left it disabled. So I
>> > thought best to leave it off for now. Unless you prefer to drop it
>> > altogether?
>>
>> That means this QUP is configured to work as a QSPI host, which is not yet
>> supported upstream. I looked at the DSDT you submitted to aa64-laptops, but
>> there doesn't seem to be anything connected there, perhaps it's loaded at
>> runtime. Since your keyboard and touchpad work, maybe it's a touchscreen?
>>
> 
> Indeed it is just defined without anything attached. I am suspecting
> it also may be just leftover, won't be the first one...
> No, this particular laptop doesn't have a touchscreen in any of the
> three screen configurations announced.
> 
> It also does not have a fingerprint reader, nor hardware TPM2.0 (yet
> SPI11 typically used for it is still TZ protected :). EC seems to be
> over i2c5. Asus's touchpad supports some fancy gesture controls, but
> there is in fact another 'extra' hidraw device 'hdtl', I assume that's
> the one. No sdcard reader.
> Only other still unsupported features are audio (i guess unlikely that
> they used different smart amp?), camera (ov02c01, pm8010, so also no)
> and DP-HDMI bridge PS185HDM, which from what I can guesstimate is i2c.

I actually managed to contact someone about the ps185hdm as it is also 
used in my asus vivobook s15. But from what they told me it is a dumb 
bridge that does not require any further configuration. I have tried 
getting it to work but I've had no luck yet. I did find a hpd gpio at 
tlmm 126.

I currently have just tried ignoring its existence and describing a non 
existent dp-connector with the hpd gpio hooked up to mdss_dp2_out but no 
luck. I get a timeout on the aux bus communication I think, so something 
is blocking that still.

I think it may just be some regulator or something required to actually 
power up the ps185hdm

from my correspondence:
`
Hi Maud,

There is no “enable pin” on the PS185 but there are several GPIO’s. The 
FW associated with the device is programmable so the manufacturer of the 
motherboard you are using may have requested a special feature (such as 
an enable pin on one of the GPIO) to be added by Parade. If that’s the 
case then you would need to contact the motherboard manufacturer to find 
out more details.

Hot plug events are normally routed through the DP_HPD pin but, as noted 
above, it’s possible that the motherboard manufacturer asked for this to 
be replicated on the GPIO pin.
`

some messing around of me in the dts can be found here: [1]

[...]

[1]: 
https://github.com/SpieringsAE/linux/blob/wip/x1e80100-6.14/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts

kind regards,
Maud

Re: [PATCH v1 6/6] arm64: dts: qcom: Add support for X1-based Asus Zenbook A14

[Aleksandrs Vinarskis]

On Wed, 2 Apr 2025 at 08:30, Maud Spierings <maud_spierings@hotmail.com> wrote:
>
> > On Tue, 1 Apr 2025 at 23:15, Konrad Dybcio
> > <konrad.dybcio@oss.qualcomm.com> wrote:
> >>
> >> On 4/1/25 8:05 PM, Aleksandrs Vinarskis wrote:
> >> > On Tue, 1 Apr 2025 at 17:59, Konrad Dybcio
> >> > <konrad.dybcio@oss.qualcomm.com> wrote:
> >> >>
> >> >> On 3/31/25 11:53 PM, Aleksandrs Vinarskis wrote:
> >> >>> Initial support for Asus Zenbook A14. Particular moddel exists
> >> >>> in X1-26-100, X1P-42-100 (UX3407QA) and X1E-78-100 (UX3407RA).
> >> >>>
> >> >>> Mostly similar to other X1-based laptops. Notable differences are:
> >> >>> * Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA
> >> >>>   and Qualcomm FastConnect 7800 on UX3407RA
> >> >>> * USB Type-C retimers are Parade PS8833, appear to behave identical
> >> >>>   to Parade PS8830
> >> >>> * gpio90 is TZ protected
> >> >>
> >>
> >> [...]
> >>
> >> >>
> >> >>> +&spi10 {
> >> >>> +     status = "disabled";
> >> >>> +
> >> >>> +     /* Unknown device */
> >> >>> +};
> >> >>
> >> >> Does the device crash if you enable this bus? Keeping it 'okay' would
> >> >> make it easier for folks to poke at it
> >> >
> >> > It does boot just fine, but does not initialize:
> >> > ```
> >> > geni_spi a88000.spi: Invalid proto 9
> >> > ...
> >> > qnoc-x1e80100 interconnect-1: sync_state() pending due to a88000.spi
> >> > ...
> >> > ```
> >> >
> >> > I only quickly checked that 9 is indeed invalid state, iirc should've
> >> > been 2. But haven't looked deeper into it, so left it disabled. So I
> >> > thought best to leave it off for now. Unless you prefer to drop it
> >> > altogether?
> >>
> >> That means this QUP is configured to work as a QSPI host, which is not yet
> >> supported upstream. I looked at the DSDT you submitted to aa64-laptops, but
> >> there doesn't seem to be anything connected there, perhaps it's loaded at
> >> runtime. Since your keyboard and touchpad work, maybe it's a touchscreen?
> >>
> >
> > Indeed it is just defined without anything attached. I am suspecting
> > it also may be just leftover, won't be the first one...
> > No, this particular laptop doesn't have a touchscreen in any of the
> > three screen configurations announced.
> >
> > It also does not have a fingerprint reader, nor hardware TPM2.0 (yet
> > SPI11 typically used for it is still TZ protected :). EC seems to be
> > over i2c5. Asus's touchpad supports some fancy gesture controls, but
> > there is in fact another 'extra' hidraw device 'hdtl', I assume that's
> > the one. No sdcard reader.
> > Only other still unsupported features are audio (i guess unlikely that
> > they used different smart amp?), camera (ov02c01, pm8010, so also no)
> > and DP-HDMI bridge PS185HDM, which from what I can guesstimate is i2c.
>
> I actually managed to contact someone about the ps185hdm as it is also
> used in my asus vivobook s15. But from what they told me it is a dumb
> bridge that does not require any further configuration. I have tried
> getting it to work but I've had no luck yet. I did find a hpd gpio at
> tlmm 126.
>
> I currently have just tried ignoring its existence and describing a non
> existent dp-connector with the hpd gpio hooked up to mdss_dp2_out but no
> luck. I get a timeout on the aux bus communication I think, so something
> is blocking that still.

I think it was your messages that I saw on IRC of aarch64-laptops
then. Can confirm both HPD on tlmm, and lack of any i2c devices on
newly created virtual bus.

>
> I think it may just be some regulator or something required to actually
> power up the ps185hdm

That was my conclusion as well. Would you mind following up with them,
if they could disclose the amount of voltage supplies the IC is
expecting? if it's 1 or 2, it's rather easy to bruteforce all unused
pin combinations. If it's more than that, it's only reasonable to
enable all unused GPIOs to high at once, which I wouldn't do tbh :)

The weird thing is that according to a rather simplified publically
available diagram, HPD is actually propagated through the PS185,
implying that bridge is on. It could be that IC requires multiple
supplies, hence Aux bus is not working, but in my experience these
devices typically don't start until all of the required supplies are
up.

>
> from my correspondence:
> `
> Hi Maud,
>
> There is no “enable pin” on the PS185 but there are several GPIO’s. The
> FW associated with the device is programmable so the manufacturer of the
> motherboard you are using may have requested a special feature (such as
> an enable pin on one of the GPIO) to be added by Parade. If that’s the
> case then you would need to contact the motherboard manufacturer to find
> out more details.
>
> Hot plug events are normally routed through the DP_HPD pin but, as noted
> above, it’s possible that the motherboard manufacturer asked for this to
> be replicated on the GPIO pin.
> `
>
> some messing around of me in the dts can be found here: [1]

I think, you would also need to enable usb_1_ss2 combo phy, afaik only
mdss3 (for eDP) has a dedicated DP phy, for the rest it's a combo
qmpphy. Konrad could probably confirm?
Once i2c/aux works, maybe we would also need a small driver to set phy
to DP mode, as afaik pmic-glink handles these. Just hypothesis though.
I have tried adding a dummy "dp-connector" like you did, but as a
child node to pmic-glink, hoping that it would handle the alt mode,
but it is probably not that easy :)

Would be happy to cooperate on debugging this offline.

Alex



>
> [...]
>
> [1]:
> https://github.com/SpieringsAE/linux/blob/wip/x1e80100-6.14/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts
>
> kind regards,
> Maud

Re: [PATCH v1 6/6] arm64: dts: qcom: Add support for X1-based Asus Zenbook A14

[Aleksandrs Vinarskis]

On Wed, 2 Apr 2025 at 10:36, Aleksandrs Vinarskis
<alex.vinarskis@gmail.com> wrote:
>
> On Wed, 2 Apr 2025 at 08:30, Maud Spierings <maud_spierings@hotmail.com> wrote:
> >
> > > On Tue, 1 Apr 2025 at 23:15, Konrad Dybcio
> > > <konrad.dybcio@oss.qualcomm.com> wrote:
> > >>
> > >> On 4/1/25 8:05 PM, Aleksandrs Vinarskis wrote:
> > >> > On Tue, 1 Apr 2025 at 17:59, Konrad Dybcio
> > >> > <konrad.dybcio@oss.qualcomm.com> wrote:
> > >> >>
> > >> >> On 3/31/25 11:53 PM, Aleksandrs Vinarskis wrote:
> > >> >>> Initial support for Asus Zenbook A14. Particular moddel exists
> > >> >>> in X1-26-100, X1P-42-100 (UX3407QA) and X1E-78-100 (UX3407RA).
> > >> >>>
> > >> >>> Mostly similar to other X1-based laptops. Notable differences are:
> > >> >>> * Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA
> > >> >>>   and Qualcomm FastConnect 7800 on UX3407RA
> > >> >>> * USB Type-C retimers are Parade PS8833, appear to behave identical
> > >> >>>   to Parade PS8830
> > >> >>> * gpio90 is TZ protected
> > >> >>
> > >>
> > >> [...]
> > >>
> > >> >>
> > >> >>> +&spi10 {
> > >> >>> +     status = "disabled";
> > >> >>> +
> > >> >>> +     /* Unknown device */
> > >> >>> +};
> > >> >>
> > >> >> Does the device crash if you enable this bus? Keeping it 'okay' would
> > >> >> make it easier for folks to poke at it
> > >> >
> > >> > It does boot just fine, but does not initialize:
> > >> > ```
> > >> > geni_spi a88000.spi: Invalid proto 9
> > >> > ...
> > >> > qnoc-x1e80100 interconnect-1: sync_state() pending due to a88000.spi
> > >> > ...
> > >> > ```
> > >> >
> > >> > I only quickly checked that 9 is indeed invalid state, iirc should've
> > >> > been 2. But haven't looked deeper into it, so left it disabled. So I
> > >> > thought best to leave it off for now. Unless you prefer to drop it
> > >> > altogether?
> > >>
> > >> That means this QUP is configured to work as a QSPI host, which is not yet
> > >> supported upstream. I looked at the DSDT you submitted to aa64-laptops, but
> > >> there doesn't seem to be anything connected there, perhaps it's loaded at
> > >> runtime. Since your keyboard and touchpad work, maybe it's a touchscreen?
> > >>
> > >
> > > Indeed it is just defined without anything attached. I am suspecting
> > > it also may be just leftover, won't be the first one...
> > > No, this particular laptop doesn't have a touchscreen in any of the
> > > three screen configurations announced.
> > >
> > > It also does not have a fingerprint reader, nor hardware TPM2.0 (yet
> > > SPI11 typically used for it is still TZ protected :). EC seems to be
> > > over i2c5. Asus's touchpad supports some fancy gesture controls, but
> > > there is in fact another 'extra' hidraw device 'hdtl', I assume that's
> > > the one. No sdcard reader.
> > > Only other still unsupported features are audio (i guess unlikely that
> > > they used different smart amp?), camera (ov02c01, pm8010, so also no)
> > > and DP-HDMI bridge PS185HDM, which from what I can guesstimate is i2c.
> >
> > I actually managed to contact someone about the ps185hdm as it is also
> > used in my asus vivobook s15. But from what they told me it is a dumb
> > bridge that does not require any further configuration. I have tried
> > getting it to work but I've had no luck yet. I did find a hpd gpio at
> > tlmm 126.
> >
> > I currently have just tried ignoring its existence and describing a non
> > existent dp-connector with the hpd gpio hooked up to mdss_dp2_out but no
> > luck. I get a timeout on the aux bus communication I think, so something
> > is blocking that still.
>
> I think it was your messages that I saw on IRC of aarch64-laptops
> then. Can confirm both HPD on tlmm, and lack of any i2c devices on
> newly created virtual bus.
>
> >
> > I think it may just be some regulator or something required to actually
> > power up the ps185hdm
>
> That was my conclusion as well. Would you mind following up with them,
> if they could disclose the amount of voltage supplies the IC is
> expecting? if it's 1 or 2, it's rather easy to bruteforce all unused
> pin combinations. If it's more than that, it's only reasonable to
> enable all unused GPIOs to high at once, which I wouldn't do tbh :)
>
> The weird thing is that according to a rather simplified publically
> available diagram, HPD is actually propagated through the PS185,
> implying that bridge is on. It could be that IC requires multiple
> supplies, hence Aux bus is not working, but in my experience these
> devices typically don't start until all of the required supplies are
> up.
>
> >
> > from my correspondence:
> > `
> > Hi Maud,
> >
> > There is no “enable pin” on the PS185 but there are several GPIO’s. The
> > FW associated with the device is programmable so the manufacturer of the
> > motherboard you are using may have requested a special feature (such as
> > an enable pin on one of the GPIO) to be added by Parade. If that’s the
> > case then you would need to contact the motherboard manufacturer to find
> > out more details.
> >
> > Hot plug events are normally routed through the DP_HPD pin but, as noted
> > above, it’s possible that the motherboard manufacturer asked for this to
> > be replicated on the GPIO pin.
> > `
> >
> > some messing around of me in the dts can be found here: [1]
>
> I think, you would also need to enable usb_1_ss2 combo phy, afaik only
> mdss3 (for eDP) has a dedicated DP phy, for the rest it's a combo
> qmpphy. Konrad could probably confirm?
> Once i2c/aux works, maybe we would also need a small driver to set phy
> to DP mode, as afaik pmic-glink handles these. Just hypothesis though.
> I have tried adding a dummy "dp-connector" like you did, but as a
> child node to pmic-glink, hoping that it would handle the alt mode,
> but it is probably not that easy :)
>
> Would be happy to cooperate on debugging this offline.
>
> Alex

Small update,

Following initial work from Maud, I hacked around a bit and got HDMI
working _most of the times_ on cold boot. Far from complete, but this
proves the IC is indeed working as dumb bridge. At least non Zenbook
DP routed to qmphy, like hinted by DSDT.
I am guessing the HPD event comes too early, before AUX is ready for
EDID readout to be the cause of the hotplug almost never working,
since I can always readout EDID manually just fine. Will need to
investigate it a bit more.

Initial (dirty) change for Asus Zenbook A14 [1].

[1] https://github.com/alexVinarskis/linux-x1e80100-zenbook-a14/commit/90466cd004c3df5d717295ae7dcd5ed183701de0

>
>
>
> >
> > [...]
> >
> > [1]:
> > https://github.com/SpieringsAE/linux/blob/wip/x1e80100-6.14/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts
> >
> > kind regards,
> > Maud

Re: [PATCH v1 0/6] X1E Asus Zenbook A14 support

[Rob Herring (Arm)]

On Mon, 31 Mar 2025 23:53:34 +0200, Aleksandrs Vinarskis wrote:
> Introduce support for the mentioned laptop.
> 
> Particular device exists in two model numbers:
> * UX3407QA: X1P-42-100 or X1-26-100 (as tested)
> * UX3407RA: X1E-78-100
> 
> Mostly similar to other X1-based laptops. Notable differences are:
> * Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA
>   and Qualcomm FastConnect 7800 on UX3407RA
> * USB Type-C retimers are Parade PS8833, appear to behave identical
>   to Parade PS8830
> * gpio90 is TZ protected
> 
> Document new Parade PS883x variant. Move pcie6a_phy's compatible change
> from X1P-42-100's dtsi to be CRD specific, at it seems it does not
> apply to all machines - on X1-26-100 phy times-out when using new x1p
> compatible.
> 
> When comparing device firmware between UX3407QA, UX3407RA, it seems
> that only ADSP firmware is different, CDSP and GPU firmware appears to
> be the same. (At least assuming the GPU firmware name in both cases is
> `qcdxkmsuc8380.mbn`). Since at least some blobs are different betweeen
> X1E and X1/X1P, define new firmware directory for `qcom/x1p42100`. This
> also makes it easier for distros to automatically extract firmware from
> Windows and place all blobs for the model under the same path. If/When
> firmware blobs make it to linux-firmware, same blobs can be easily
> symlinked between `qcom/x1e80100` and `qcom/x1p42100`.
> 
> Qualcomm FastConnect 6900 on UX3407QA did not work out of the box, and
> additionally required both newer firmware and patches to `board-2.bin`.
> I added a short how-to [1], as it is not exactly trivial.
> 
> ACPI dumps can be found on aarch64-laptops' github [2]. HWids on
> dtbloader's github [3].
> 
> [1] https://github.com/alexVinarskis/linux-x1e80100-zenbook-a14?tab=readme-ov-file#wcn688x-wifi
> [2] https://github.com/aarch64-laptops/build/pull/134/files
> [3] https://github.com/TravMurav/dtbloader/pull/4/files
> 
> Aleksandrs Vinarskis (6):
>   arm64: dts: qcom: move pcie6a type change from X1P42100 to
>     X1P42100-crd
>   usb: typec: Add Parade PS8833 Type-C Retimer variant
>   dt-bindings: usb: Add Parade PS8833 Type-C retimer variant
>   dt-bindings: arm: qcom: Add Asus Zenbook A14
>   firmware: qcom: scm: Allow QSEECOM on Asus Zenbook A14
>   arm64: dts: qcom: Add support for X1-based Asus Zenbook A14
> 
>  .../devicetree/bindings/arm/qcom.yaml         |    2 +
>  .../bindings/usb/parade,ps8830.yaml           |    1 +
>  arch/arm64/boot/dts/qcom/Makefile             |    2 +
>  arch/arm64/boot/dts/qcom/x1-zenbook-a14.dtsi  | 1251 +++++++++++++++++
>  .../dts/qcom/x1e80100-asus-zenbook-a14.dts    |   45 +
>  .../dts/qcom/x1p42100-asus-zenbook-a14.dts    |   48 +
>  arch/arm64/boot/dts/qcom/x1p42100-crd.dts     |    4 +
>  arch/arm64/boot/dts/qcom/x1p42100.dtsi        |    4 -
>  drivers/firmware/qcom/qcom_scm.c              |    2 +
>  drivers/usb/typec/mux/ps883x.c                |    1 +
>  10 files changed, 1356 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/qcom/x1-zenbook-a14.dtsi
>  create mode 100644 arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dts
> 
> --
> 2.45.2
> 
> 
> 


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: attempting to guess base-commit...
 Base: tags/next-20250331 (exact match)

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 20250331215720.19692-1-alex.vinarskis@gmail.com:

arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dtb: bluetooth: 'vddrfacmn-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dtb: bluetooth: 'vddaon-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dtb: bluetooth: 'vddwlcx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dtb: bluetooth: 'vddwlmx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dtb: bluetooth: 'vddrfa0p8-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dtb: bluetooth: 'vddrfa1p2-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dtb: bluetooth: 'vddrfa1p8-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dtb: pinctrl@f100000: Unevaluated properties are not allowed ('bt-en-sleep' was unexpected)
	from schema $id: http://devicetree.org/schemas/pinctrl/qcom,x1e80100-tlmm.yaml#
arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dtb: bluetooth: 'vddrfacmn-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dtb: bluetooth: 'vddaon-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dtb: bluetooth: 'vddwlcx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dtb: bluetooth: 'vddwlmx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dtb: bluetooth: 'vddbtcmx-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dtb: bluetooth: 'vddrfa0p8-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dtb: bluetooth: 'vddrfa1p2-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dtb: bluetooth: 'vddrfa1p8-supply' is a required property
	from schema $id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
arch/arm64/boot/dts/qcom/x1p42100-asus-zenbook-a14.dtb: pinctrl@f100000: Unevaluated properties are not allowed ('bt-en-sleep' was unexpected)
	from schema $id: http://devicetree.org/schemas/pinctrl/qcom,x1e80100-tlmm.yaml#