| 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
| ||
|
Message-ID: <cc139316-03da-41e9-8bf0-f792bfdf5bb3@oss.qualcomm.com>
Date: Wed, 30 Jul 2025 10:50:56 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: jens.glathe@...schoolsolutions.biz,
Bjorn Andersson
<andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Matthias Kaehlcke <mka@...omium.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Aleksandrs Vinarskis <alex.vinarskis@...il.com>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH v9 4/4] arm64: dts: qcom: Add Lenovo ThinkBook 16 G7 QOY
device tree
On 7/1/25 7:02 PM, Jens Glathe via B4 Relay wrote:
> From: Jens Glathe <jens.glathe@...schoolsolutions.biz>
>
> Device tree for the Lenovo Thinkbook 16 G7 QOY
>
> The Laptop is a Snapdragon X1 / X1 Plus (Purwa) based device [1].
>
> Supported features:
>
> - USB type-c and type-a ports
> - Keyboard
> - Touchpad (all that are described in the dsdt)
> - Touchscreen (described in the dsdt, no known SKUss)
> - Display including PWM backlight control
> - PCIe devices
> - nvme
> - SDHC card reader
> - ath12k WCN7850 Wifi and Bluetooth
> - ADSP and CDSP
> - GPIO keys (Lid switch)
> - Sound via internal speakers / DMIC / USB / headphone jack
> - DP Altmode with 2 lanes (as all of these still do)
> - Integrated fingerprint reader (FPC)
> - Integrated UVC camera
> - X1-45 GPU
>
> Not supported yet:
>
> - HDMI port.
> - EC and some fn hotkeys.
>
> Limited support yet:
>
> - SDHC card reader is based on the on-chip sdhc_2 controller, but the driver from
> the Snapdragon Dev Kit is only a partial match. It can do normal slow sd cards,
> but not UHS-I (SD104) and UHS-II.
>
> This work was done without any schematics or non-public knowledge of the device.
> So, it is based on the existing x1e device trees, dsdt analysis, using HWInfo
> ARM64, and pure guesswork. It has been confirmed, however, that the device really
> has 4 NXP PTN3222 eUSB2 repeaters, one of which doesn't have a reset GPIO (eusb5
> @43).
>
> Signed-off-by: Jens Glathe <jens.glathe@...schoolsolutions.biz>
> Co-developed by: Aleksandrs Vinarskis <alex.vinarskis@...il.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi | 2 +-
> .../boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts | 1657 ++++++++++++++++++++
> 3 files changed, 1660 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 4bfa926b6a0850c3c459bcba28129c559d50a7cf..6b1d71daff5a778237c5e3706aaea8e29dafa001 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -333,3 +333,5 @@ x1p42100-asus-zenbook-a14-el2-dtbs := x1p42100-asus-zenbook-a14.dtb x1-el2.dtbo
> dtb-$(CONFIG_ARCH_QCOM) += x1p42100-asus-zenbook-a14.dtb x1p42100-asus-zenbook-a14-el2.dtb
> x1p42100-crd-el2-dtbs := x1p42100-crd.dtb x1-el2.dtbo
> dtb-$(CONFIG_ARCH_QCOM) += x1p42100-crd.dtb x1p42100-crd-el2.dtb
> +x1p42100-lenovo-thinkbook-16-el2-dtbs := x1p42100-lenovo-thinkbook-16.dtb x1-el2.dtbo
> +dtb-$(CONFIG_ARCH_QCOM) += x1p42100-lenovo-thinkbook-16.dtb x1p42100-lenovo-thinkbook-16-el2.dtb
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi b/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi
> index e3888bc143a0aaae23c92d400d48ea94423e0366..378635f7cb0bfe37cf10644a16bd8b3cca447f3c 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi
> @@ -170,7 +170,7 @@ trip1 {
> };
> };
>
> - pm8010-thermal {
> + pm8010_thermal: pm8010-thermal {
Let's rebase on:
https://lore.kernel.org/linux-arm-msm/20250701183625.1968246-1-alex.vinarskis@gmail.com/
[...]
> + /*
> + * This is an odd one. The camera is physically behind the eusb9 repeater (confirmed) but
> + * if it is placed below the usb_2_dwc3 node, it will be switched of after ~30 seconds.
> + * The reason seems to be that the dwc3 driver does not probe for child nodes when in
> + * host-only mode. But that's the default setting for the xhci controllers due to issues
> + * when in OTG mode. https://lore.kernel.org/all/20241210111444.26240-1-johan+linaro@kernel.org/
> + * The whole reason it is described in the dt (as an USB device) is its requirement for
> + * that additional regulator, and to get power management to switch it off when suspended.
> + * Defining it stand-alone does work.
> + */
> + camera {
> + compatible = "usb5986,1198";
> +
> + vdd-supply = <&vreg_cam_5p0>;
> + };
If the bindings checker is happy, I think we can keep it here for now..
[...]
> + wcd-playback-dai-link {
> + link-name = "WCD Playback";
> +
> + cpu {
> + sound-dai = <&q6apmbedai RX_CODEC_DMA_RX_0>;
> + };
> +
> + codec {
'co'dec < 'cp'u
[...]
> +&i2c2 {
> + clock-frequency = <400000>;
> +
> + pinctrl-0 = <&qup_i2c2_data_clk>, <&tpad_default>, <&kybd_default>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + /* ELAN06FA */
> + touchpad@15 {
5 touchpad variants is a lot. Does DSDT give any clues as to whether
all of them are plausibly present on production hw?
[...]
> +&mdss_dp0_out {
> + data-lanes = <0 1 2 3>;
> + link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
> +};
> +
> +&mdss_dp1 {
> + status = "okay";
> +};
> +
> +&mdss_dp1_out {
> + data-lanes = <0 1 2 3>;
Does defining all 4 lanes not upset the driver without additional
patches?
> + link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
> +};
> +
> +&mdss_dp2 {
> + status = "okay";
> +};
> +
> +&mdss_dp2_out {
> + data-lanes = <0 1 2 3>;
> + link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
> +};
> +
> +&mdss_dp2_phy {
> +// vdda-phy-supply = <&vreg_l3b>;
> +// vdda-pll-supply = <&vreg_l6b>;
The regulators are usecase-specialized, feel free to trust what
is present on the CRD
[...]
> + 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>;
> + };
> + };
> + };
> +};
Please rebase on:
https://lore.kernel.org/linux-arm-msm/20250724-move-edp-endpoints-v1-3-6ca569812838@oss.qualcomm.com/
[...]
> +&sdhc_2 {
> + cd-gpios = <&tlmm 71 GPIO_ACTIVE_LOW>;
> + pinctrl-0 = <&sdc2_default &sdc2_card_det_n>;
> + pinctrl-1 = <&sdc2_sleep &sdc2_card_det_n>;
> + pinctrl-names = "default", "sleep";
> + vmmc-supply = <&vreg_l9b_2p9>;
> + vqmmc-supply = <&vreg_l6b_1p8>;
> +// bus-width = <4>;
> +// no-sdio;
> +// no-mmc;
Please either remove the '//' or remove the lines
[...]
> +&tlmm {
> + gpio-reserved-ranges = <34 2>, /* Unused */
> + <72 2>, /* Secure EC I2C connection (?) */
> + <238 1>; /* UFS Reset */
Try removing the UFS reset block and see if the platform still
boots, this turned out to be a false flag on CRD
I'd also suggest removing voltage suffixes from regulator names (i.e.
turn them to e.g. vreg_l6b).
Konrad
Powered by blists - more mailing lists