[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e7j3hctjlly44pjwe3jvjtpjuj33bdvpyo6pzc6o3q5tjjlyib@7evgyweq2deg>
Date: Tue, 13 Jan 2026 03:31:20 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Val Packett <val@...kett.cool>, 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 Mon, Jan 12, 2026 at 11:50:25AM +0100, Konrad Dybcio wrote:
> On 1/12/26 1:31 AM, 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.
> >
> >>> +
> >>> +&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.
> >>> +};
>
> FYI I don't think a modern QC SoC can turn on without PON
>
> What do you mean by "doesn't make power-off work"?
It is basically a laptop SoM in the embedded case, so it has EC and PoN
generated via the EC.
--
With best wishes
Dmitry
Powered by blists - more mailing lists