[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f0d6bd9-0786-4445-94d2-5189f6b44d01@oss.qualcomm.com>
Date: Mon, 12 Jan 2026 11:50:25 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Val Packett <val@...kett.cool>,
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
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"?
Konrad
Powered by blists - more mailing lists