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

[Val Packett]

[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