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: <3u6q3lyqjto22ln33432vizgj7jzcvroy5rx3dljnglyovqjei@ozfm5qacljwc>
Date: Mon, 12 Jan 2026 02:55:06 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Val Packett <val@...kett.cool>
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

On Sun, Jan 11, 2026 at 09:31:40PM -0300, Val Packett wrote:
> [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.

ok. Which EPROBE_DEFER issues do you observe?

> 
> > > +
> > > +&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.

ok

> > > +};
> > > +
> > > +&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?

I think, the comment would be sufficient for now.

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

Thanks!

-- 
With best wishes
Dmitry