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] [day] [month] [year] [list]
Message-ID: <a13003ea-27be-43ea-b739-8d5d6ba69d0d@oss.qualcomm.com>
Date: Tue, 3 Feb 2026 12:02:44 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: wwf <wwfu06@....com>
Cc: linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, conor+dt@...nel.org, krzk+dt@...nel.org,
        robh@...nel.org, andersson@...nel.org,
        Krzysztof Kozlowski <krzk@...nel.org>
Subject: Re: [PATCH v3 2/2] arm64: dts: qcom: add Acer Swift SFA14-11 device
 tree

On 1/28/26 3:05 PM, wwf wrote:
> 
> 
> 
> 
> 
> 
> 
> At 2026-01-28 20:25:22, "Konrad Dybcio" <konrad.dybcio@....qualcomm.com> wrote:
>> On 1/21/26 12:27 PM, weifu wu wrote:
>>> Add initial device tree for Acer Swift SFA14-11 laptop based on Qualcomm X1E78100 SoC.
>>>
>>> Generated based on x1e78100-lenovo-thinkpad-t14s.dts.
>>>
>>> Adjusted node ordering according to review feedback.
>>>
>>> Passed format checks and successfully built without errors.
>>>
>>> Signed-off-by: weifu wu <wwfu06@....com>
>>> ---
>>
>> [...]
>>
>>> +#include "hamoa.dtsi"
>>> +#include "hamoa-pmics.dtsi"
>>> +
>>> +/ {
>>> +	model = "Acer Swift 14 Go Pro AI (SFA14-11)";
>>> +	compatible = "acer,swift-sfa14-11", "lenovo,thinkpad-t14s", "qcom,x1e78100", "qcom,x1e80100";
>>
>> The lenovo part needs to go
> R:
> I have reviewed the DTS files for two other Acer models in the same series submitted by other contributors, and they all directly utilize certain drivers for the T14s.
>  Due to the lack of official support from Acer, removing the "lenovo,thinkpad-t14s" node will likely cause some hardware components to malfunction.

This is plainly untrue. The T14s is not special in any regard, and there
doesn't exist any sort of ""T14s drivers"" for the X1 SoC.

If you came up with this reasoning, grep for the T14s compatible string
in the kernel and convince yourself that's not the case.

If an LLM suggested this, it's hallucinating, very badly.

>>
>> [...]
>>
>>
>>> +	/* two muxes together support CTIA and OMTP switching */
>>> +	us_euro_mux_ctrl: mux-controller {
>>> +		compatible = "gpio-mux";
>>> +		pinctrl-0 = <&us_euro_hs_sel>;
>>> +		pinctrl-names = "default";
>>> +		mux-supply = <&vreg_l16b_2p5>;
>>> +		#mux-control-cells = <0>;
>>> +		mux-gpios = <&tlmm 68 GPIO_ACTIVE_HIGH>;
>>> +	};
>>
>> Are you sure this is present on the Acer as well?
> R:Untested!

Why would you include it then?

[...]

>>> +	/* ELAN06F1 or SYNA06F2 */
>>
>> These look directly copypasted from the Lenovo DT, so I have concerns
>> about their validity
>>
> R:It is mostly the Lenovo DT with only very minor modifications.

Again, that's not the way to go

[...]

>> [...]
>>
>>> +&i2c5 {
>>> +	clock-frequency = <400000>;
>>> +
>>> +	status = "okay";
>>> +
>>> +	eusb5_repeater: redriver@43 {
>>> +		compatible = "nxp,ptn3222";
>>> +		reg = <0x43>;
>>> +		#phy-cells = <0>;
>>> +
>>> +		vdd3v3-supply = <&vreg_l13b_3p0>;
>>> +		vdd1v8-supply = <&vreg_l4b_1p8>;
>>> +
>>> +		reset-gpios = <&tlmm 7 GPIO_ACTIVE_LOW>;
>>> +
>>> +		pinctrl-0 = <&eusb5_reset_n>;
>>> +		pinctrl-names = "default";
>>> +	};
>>> +
>>> +	eusb3_repeater: redriver@47 {
>>> +		compatible = "nxp,ptn3222";
>>> +		reg = <0x47>;
>>> +		#phy-cells = <0>;
>>> +
>>> +		vdd3v3-supply = <&vreg_l13b_3p0>;
>>> +		vdd1v8-supply = <&vreg_l4b_1p8>;
>>> +
>>> +		reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
>>> +
>>> +		pinctrl-0 = <&eusb3_reset_n>;
>>> +		pinctrl-names = "default";
>>> +	};
>>> +
>>> +	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";
>>> +	};
>>
>> This laptop seems to have 2 USB-A ports and no fingerprint/SDCard reader,
>> are you sure all of these are present onboard?
>>
> R:
> This laptop features 2 USB-A ports, 1 USB-C port and a fingerprint reader, with no SD card reader.

Then unless there's something else dangling off the USB bus, not all of
these redrivers are physically present.

>>> +};
>>> +
>>> +&i2c6 {
>>> +	clock-frequency = <400000>;
>>> +
>>> +	status = "okay";
>>> +
>>> +	embedded-controller@28 {
>>> +		compatible = "lenovo,thinkpad-t14s-ec";
>>
>> I highly doubt this is the case
>>
> R:
> It has at least been tested on the physical device. Due to my lack of professional expertise, making excessive modifications rashly would be more likely to cause hardware damage. To be clear, when booting the sfa14-11 with the T14s DTB under Linux, the power consumption and heat generation are both more severe compared to WOA. However, based on what I’ve learned from the Ubuntu community, this is likely an issue with the Qualcomm power management driver itself.

I understand your position, however due to you admitting you're just
copypasting things and hoping they work, we can not accept this submission
in its current state, as there are parts of it that are clearly incorrect

>> [...]
>>
>>> +&i2c8 {
>>> +	clock-frequency = <400000>;
>>> +
>>> +	status = "okay";
>>> +
>>> +	/* ILIT2911 or GTCH1563 */
>>> +	touchscreen@10 {
>>> +		compatible = "hid-over-i2c";
>>> +		reg = <0x10>;
>>> +
>>> +		hid-descr-addr = <0x1>;
>>> +		interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>;
>>> +
>>> +		vdd-supply = <&vreg_misc_3p3>;
>>> +		vddl-supply = <&vreg_l15b_1p8>;
>>> +
>>> +		pinctrl-0 = <&ts0_default>;
>>> +		pinctrl-names = "default";
>>> +	};
>>> +
>>> +	/* TODO: second-sourced touchscreen @ 0x41 */
>>
>> This again looks directly copypasted
>>
> R: 
> Indeed!
>> [...]
>>
>>> +&usb_1_ss2_qmpphy {
>>> +	vdda-phy-supply = <&vreg_l2j_1p2>;
>>> +	vdda-pll-supply = <&vreg_l2d_0p9>;
>>> +
>>> +	/delete-property/ mode-switch;
>>> +	/delete-property/ orientation-switch;
>>> +
>>> +	status = "okay";
>>> +
>>> +	ports {
>>> +		port@0 {
>>> +			#address-cells = <1>;
>>> +			#size-cells = <0>;
>>> +
>>> +			/delete-node/ endpoint;
>>> +
>>> +			usb_1_ss2_qmpphy_out_dp: endpoint@0 {
>>> +				reg = <0>;
>>> +
>>> +				data-lanes = <3 2 1 0>;
>>> +				remote-endpoint = <&hdmi_bridge_dp_in>;
>>
>> I don't see a HDMI port on this laptop
>>
> R: This laptop does have an HDMI port.

I don't think that's the case, see this image from Acer. Unless the
SKU that they sell in Europe is different, with the same model number..

https://static2-ecemea.acer.com/media/catalog/product/_/a/_acer-swift-14-ai-sf14-11-with-fp-with-bl-on-wp-copilot-gray_11_nx.kzxep.002.png?quality=80&bg-color=255,255,255&fit=bounds&height=500&width=500&canvas=500:500&format=jpeg


>> Moreover, I'm highly concerned about the regulator settings, which
>> differ between boards and may lead to permanent hardware damage if
>> misconfigured. If you took the values from the T14s DT as-is, you
>> may be doing yourself a bad favor..
>>
> R: Thank you for your careful review. I believe that currently, with the exception of a few specific laptop models (e.g., the ThinkPad T14s), all other laptops utilizing the X1 Elite/Plus SoC experience more or less issues when running Linux on ARM—and the SFA14-11 is no exception. That said, I hope to raise its visibility and improve it through my efforts.

Your reply doesn't at all address my serious concern stated above.

Konrad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ