[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180515172055.GB205769@dtor-ws>
Date: Tue, 15 May 2018 10:20:55 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Tirupathi Reddy <tirupath@...eaurora.org>, robh+dt@...nel.org,
mark.rutland@....com, linux-input@...r.kernel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3] Input: pm8941-pwrkey: add resin key capabilities
On Mon, May 07, 2018 at 11:46:59AM -0700, Bjorn Andersson wrote:
> On Fri 04 May 17:10 PDT 2018, Dmitry Torokhov wrote:
>
> > Hi Tirupathi,
> >
> > On Fri, Mar 23, 2018 at 11:53:12AM +0530, Tirupathi Reddy wrote:
> > > Add resin key support to handle different types of key events
> > > defined in different platforms.
> > >
> > > Signed-off-by: Tirupathi Reddy <tirupath@...eaurora.org>
> > > ---
> > > .../bindings/input/qcom,pm8941-pwrkey.txt | 32 +++++++++
> > > drivers/input/misc/pm8941-pwrkey.c | 81 ++++++++++++++++++++++
> > > 2 files changed, 113 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> [..]
> > > EXAMPLE
> > >
> > > pwrkey@800 {
> > > @@ -40,4 +66,10 @@ EXAMPLE
> > > interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
> > > debounce = <15625>;
> > > bias-pull-up;
> > > +
> > > + resin {
> > > + interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
> > > + linux,code = <KEY_VOLUMEDOWN>;
> > > + bias-pull-up;
> > > + };
> > > };
> >
> > The new key and power key bindings are very similar, I would prefer if
> > we shared the parsing code and our new DTS looked like:
> >
> > power {
> > ...
> > };
> >
> > resin {
> > ...
> > };
> >
> > (we can easily keep backward compatibility with power properties being
> > in device node).
> >
>
> As discussed here https://patchwork.kernel.org/patch/9751627/ the PON
> block does, in addition to providing power and resin key support also
> handle the restart reason ("reboot bootloader" in Android).
>
> My interpretation of our conclusion was to come up with a new binding
> for the "pon" and a driver for this block that instantiates the power
> key device.
>
> It seems reasonable for such binding to describe the two keys, as you
> propose here Dmitry, and instantiates the two input devices based on
> this.
OK, I'll wait for the new driver and binding then.
Thanks.
--
Dmitry
Powered by blists - more mailing lists