[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e3530bff3d39bbb06b01364b30a5a21a@trvn.ru>
Date: Tue, 13 Jan 2026 14:30:01 +0500
From: Nikita Travkin <nikita@...n.ru>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, 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
Konrad Dybcio писал(а) 13.01.2026 13:30:
> On 1/13/26 2:31 AM, Dmitry Baryshkov wrote:
>> 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.
>
> I got that part, but this doesn't answer my question. Val mentioned that
> separately from the power button not generating keypress events.
>
FWIW on Aspire1 the power key is routed to the ec, and ec is routed to
pmic pon/resin (as well as ps_hold etc etc). Pressing the power key,
obviously, boots the laptop but after that it has no effect in windows
or in firmware. In linux neither pon nor resin receive any input events
when pressed so my guess was that EC pokes PON once to boot the system
and maybe pokes resin if user presses it long to do a hard reset. Due
to that I've disabled the pon node in aspire1 so there is no bogus input
device. I'm guessing Val has inherited that from aspire1.
Nikita
> Konrad
Powered by blists - more mailing lists