linux-kernel - Re: [PATCH] Input: gpio-keys - fix un-responsive keys issue on hibernate exit

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] [day] [month] [year] [list]

Message-ID: <ZxKwj8RFXFmdiVi2@google.com>
Date: Fri, 18 Oct 2024 12:01:35 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Kamal Wadhwa <quic_kamalw@...cinc.com>
Cc: linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jishnu Prakash <quic_jprakash@...cinc.com>,
	Rakesh Kota <quic_kotarake@...cinc.com>,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH] Input: gpio-keys - fix un-responsive keys issue on
 hibernate exit

Hi Kamal,

On Fri, Oct 18, 2024 at 06:22:35PM +0530, Kamal Wadhwa wrote:
> GPIO IRQ setting may get reset during hibernate mode, as device
> is completely powered off. This can cause the GPIO keys to become
> un-responsive after hibernate-exit.
> 
> To fix this problem, re-request IRQs in restore() callback, in the
> hibernate exit flow.

No, absolutely not. GPIO state and configuration is owned by GPIO
controller and it should be the entity tasked with restoring the
configuration after hibernation. Individual GPIO consumers need not do
that. Same goes for coprocessor and what's not.

Also, as a side statement: whenever you call devm API outside of probe
and remove path you are likely introduce bugs, because that interferes
with the original order of acquisition of the resources so order of
releasing them during unbinding of the device from the driver will
likely be wrong.

Thanks.

-- 
Dmitry