Re: [PATCH 2/2] arm64: dts: qcom: Add support for Acer Swift Go Pro AI (SFA14-11)

[Kaipeng Zeng <kaipeng94@gmail.com>]

Hi Konrad,

On 7/2/26 19:45, Konrad Dybcio wrote:
> On 7/2/26 8:31 AM, Kaipeng Zeng wrote:
>> +	wcd938x: audio-codec {
>
> Nodes should be sorted - by 'reg' and unit address if there's one,
> by name if there isn't (minus some special cases like GPIOs), see:
>
> https://docs.kernel.org/devicetree/bindings/dts-coding-style.html
>
>> +		compatible = "qcom,wcd9385-codec";
>
>
>> +
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&wcd_default>;
>
> property-n
> property-names
>
> in this order, file-wide, please
>

Got it, I will fix the property order file-wide.
Should I sort all nodes, including those copied from the x1-crd.dtsi?
For example, vph_pwr is inserted between two vreg_* nodes in
x1-crd.dtsi.

> [...]
>
>> +&apps_rsc {
>> +	regulators-0 {
>> +		compatible = "qcom,pm8550-rpmh-regulators";
>> +		qcom,pmic-id = "b";
>
> Have you verified this against the DSDT of your device? Incorrect
> settings may lead to hw damage
>
> [...]
>

Thank you for pointing this out, I had not verified this before.
Looking inside the DSDT, I found some "PMICVREGVOTE" packages that list
a value as the required voltage.
And I need to check if any required voltage falls outside the
range set by DTS. Is that correct?
However, some PPP_RESOURCE_ID_* seem to be mentioned only and lack a 
specific voltage.
For these, should I retain the original value (from x1e80100-crd.dtsi),
or is there another way to determine their correct ranges?

>> +&iris {
>> +	status = "okay";
>
> You need to specify a firmare path
>

I will add a firmware path.
But since the firmware of this device is not archived by linux-firmware, 
is it proper to use "qcom/x1e80100/ACER/SFA14-11/*.mbn" as the firmware 
path?
Currently, I use it for all firmware paths.

> Konrad

Thank you again for your helpful replies!