linux-kernel - Re: [PATCH 4/5] arm64: dts: qcom: Add support for ECS LIVA QC710

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: <3dd54179-7a22-4596-a6ef-224530c4b2c6@packett.cool>
Date: Sun, 11 Jan 2026 21:31:40 -0300
From: Val Packett <val@...kett.cool>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: cros-qcom-dts-watchers@...omium.org, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] arm64: dts: qcom: Add support for ECS LIVA QC710

[resent for the lists as plaintext, oops]

On 1/11/26 1:50 PM, Dmitry Baryshkov wrote:

> On Sun, Jan 11, 2026 at 05:35:12AM -0300, Val Packett wrote:
>> Add a device tree for the ECS LIVA QC710 (Snapdragon 7c) mini PC/devkit.
>> [..]
>> +&dpu_intf1_out {
>> +	/delete-property/ remote-endpoint;
> Why? It should not be necessary.

It seemed to be implicated in annoying EPROBE_DEFER issues.. But you're 
right, it wasn't this after all.

>> +
>> +&pm6150_pon {
>> +	status = "disabled";
> Do you know, how is Power-On routed?
I think it's handled by the EC. Keeping this enabled doesn't make 
power-off work, and doesn't make the power button deliver events either.
>> +};
>> +
>> +&pm6150_rtc {
>> +	status = "okay";
> No need for qcom,uefi-rtc-info ?

Ack, will add it, the efivar is present of course.

Will send it for Aspire1 too..

>> [..]
>> +&usb_1_dwc3 {
>> +	dr_mode = "host";
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +
>> +	hub@1 {
>> +		compatible = "usb5e3,608";
>> +		reg = <1>;
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
> Are other ports routed somehow?

Port 001 is routed to the 3.0 Type-A port on the back, Port 002 to the 
2.0 Type-A on the side. Should all of that be modeled?


// re: Wi-Fi calibration, submitting that to ath10k now too (though the 
default one worked perfectly fine)

Thanks,
~val