linux-kernel - Re: [PATCH 3/3] arm64: dts: qcom: sc8280xp: Add Huawei Matebook E Go (sc8280xp)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241213122135.593760-1-mitltlatltl@gmail.com>
Date: Fri, 13 Dec 2024 20:21:35 +0800
From: Pengyu Luo <mitltlatltl@...il.com>
To: konrad.dybcio@....qualcomm.com
Cc: andersson@...nel.org,
	chenxuecong2009@...look.com,
	conor+dt@...nel.org,
	devicetree@...r.kernel.org,
	dmitry.baryshkov@...aro.org,
	gty0622@...il.com,
	johan+linaro@...nel.org,
	konradybcio@...nel.org,
	krzk+dt@...nel.org,
	linux-arm-msm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	mitltlatltl@...il.com,
	robh@...nel.org
Subject: Re: [PATCH 3/3] arm64: dts: qcom: sc8280xp: Add Huawei Matebook E Go (sc8280xp)

I am not sure, huawei even provided the PMGK driver, but I think it is
not loaded.

If you talking about adsp cdsp and sdsp/slpi (this one should be
unrelated), in the firmware driver files, some of them are same
as the x13s one

adspr.jsn
adspua.jsn
battmgr.jsn
cdspr.jsn

as for qcadsp8280.mbn should be different from x13s, in the old days,
Gao and Chen used firmware from x13s totally, and the firmware didn't
work (If I remember correctly, can't be loaded).

As I know, the adsp firmware is tied with many things, even if huawei
have moved many features to EC, the device still need it. (like normal
usb function, audio? btw, this device can use audioreach-tplg.bin from
x13s as well, I am not sure if it fits well.)


>>>
>>>> +     chosen {
>>>> +             #address-cells =3D <2>;
>>>> +             #size-cells =3D <2>;
>>>> +             ranges;
>>>> +
>>>> +             framebuffer0: framebuffer@...00000 {
>>>> +                     compatible =3D "simple-framebuffer";
>>>> +                     reg =3D <0x0 0xC6200000 0x0 0x02400000>;
>>>> +                     width =3D <1600>;
>>>> +                     height =3D <2560>;
>>>> +                     stride =3D <(1600 * 4)>;
>>>> +                     format =3D "a8r8g8b8";
>>>> +             };
>>>> +     };
>>>
>>> This should be redundant, as you should have efifb
>>>
>>
>> I think no, it won't boot up without it(stuck at EFI stub: Booting Linux
>> Kernel)
> 
> Do you have CONFIG_EFI and CONFIG_FB_EFI enabled?
> 

Yes, I enabled them.

> (also, your email client does something funny and posts 0x3d, which
> is ASCII for '=' after that symbol)
> 
> 

I am sorry, hah, the first time I reply it by gmail directly, but it
didn't help me cc to others. Then I sent the exported original
message(it added the 3D for `=`, I didn't notice that at that time).

>>
>> [...]
>>
>>>
>>>> +
>>>> +     wcd938x: audio-codec {
>>>> +             compatible =3D "qcom,wcd9380-codec";
>>>> +
>>>> +             pinctrl-names =3D "default";
>>>> +             pinctrl-0 =3D <&wcd_default>;
>>>
>>> Please follow this order throughout the file:
>>>
>>> property-n
>>> property-names
>>>
>>
>> Do you mean I should arragne as following? If so, I actually keep
>> reference devicetree untouched. x13s and crd are written like this.
> 
> Yeah, we try to unify the style as we progress and we still haven't
> gotten around to cleaning up files that have been in the tree for
> years..
> 
>>
>> pinctrl-0 =3D <&wcd_default>>;
>> pinctrl-names =3D "default";
> 
> Yes please
> 
> [...]
> 

Got it. I will do it in V2.

>>>> +     gpio-keys {
>>>> +             compatible =3D "gpio-keys";
>>>> +
>>>> +             pinctrl-names =3D "default";
>>>> +             pinctrl-0 =3D <&mode_pin_active>, <&vol_up_n>;
>>>> +
>>>> +             switch-mode {
>>>> +                     gpios =3D <&tlmm 26 GPIO_ACTIVE_HIGH>;
>>>
>>> This could use a label too - "Tablet Mode Switch", perhaps?
>>>
>>
>> This part I follow Lenovo Yoga C630 one (see [1]), it doesn't use it,
>> and this node is not referenced.
> 
> So "label" could mean
> 
> label: node-name@...t-address {
> 	  property = "value";
> };
> 
> when talking about DT nodes, but here I'm speaking of the
> "label" property (which you set to "Volume Up" in the node below).
> That is read by Linux and provides a nice human-readable name to
> the userspace.
> 

It makes sense, agree. I misunderstood.

>>>
>>>> +
>>>> +             /* /lib/firmware/ath11k/WCN6855/hw2.1/board-2.bin
>>>> +              * there is no calibrate data for huawei,
>>>> +              * but they have the same subsystem-device id
>>>> +              */
>>>> +             qcom,ath11k-calibration-variant =3D "LE_X13S";
>>>
>>> Oh, this can be taken care of! See [2], [3].
>>>
>>
>> I have a glance, now I know we should extract something or it won't be
>> there.
>> Question is how can I extract them? I have a quick search, got no luck.
>> As for windows drivers, in the folder
>>
>> bdwlan.e02
>> bdwlan.e07
>> bdwlan.e1d
>> bdwlan.e1e
>> bdwlan.e23
>> bdwlan.e26
>> bdwlan.e32
>> bdwlan.e47
>> bdwlan.e81
>> bdwlan.e84
>> bdwlan.e85
>> bdwlan.e8c
>> bdwlan.e8e
>> bdwlan.e9f
>> bdwlan.ea3
>> bdwlan.eb8
>> bdwlan.elf
>> bdwlan.elf.g
>> bdwlang.e8b
>> bdwlang.e9f
>> bdwlang.ea3
>> bdwlang.eb8
>> bdwlang.elf
>> Data20.msc
>> Data.msc
>> m320.bin
>> m3.bin
>> qcwlan8280.cat
>> qcwlan8280.inf
>> qcwlan8280.sys
>> regdb.bin
>> wlanfw20.mbn
>> wlanfw.mbn
> 
> Adding Dmitry who has gone through this multiple times and may be
> able to help
> 
> Konrad

I see, thanks.

Pengyu