[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170612233203.GT12920@tuxbook>
Date: Mon, 12 Jun 2017 16:32:03 -0700
From: Bjorn Andersson <bjorn.andersson@...aro.org>
To: Sebastian Reichel <sebastian.reichel@...labora.co.uk>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Rob Herring <robh@...nel.org>,
John Stultz <john.stultz@...aro.org>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH 2/2] Input: pm8941-pwrkey: Introduce reboot mode support
On Thu 08 Jun 09:32 PDT 2017, Sebastian Reichel wrote:
> Hi,
>
> On Mon, May 29, 2017 at 09:47:11PM -0700, Bjorn Andersson wrote:
> > On Mon 29 May 19:53 PDT 2017, Dmitry Torokhov wrote:
> >
> > > On Fri, May 26, 2017 at 11:51:30PM -0700, Bjorn Andersson wrote:
> > > > In some Qualcomm platforms the magic for informing LK which mode to
> > > > reboot into is stored in the PON_SOFT_RB_SPARE register. Register with
> > > > the reboot mode helpers to expose this to the user.
> > >
> > > Hmm, is the power key driver the best place to have this? WHy isn't this
> > > a driver in its own right?
> > >
> >
> > The functionality is part of the "PON" block in the Qualcomm PMICs,
> > other functionality from this block relates to configuration and
> > handling related to power-key and reset-key.
> >
> > Several of these properties are intermingled, so I do believe it's best
> > to handle them in a single driver; that said, it might no longer be
> > correct to name the driver "pwrkey" or that it is a "misc input" driver.
>
> I merged patch 1 and provided an immutable branch, so
> that this could go through the input subsystem.
>
Thanks
> To me it doesn't look that intermingled, though. I think
> the reboot and reboot-mode parts could go into their own
> driver in drivers/power/reset.
>
I did reach out to Rob regarding this and the single hardware block
should be described by a single node in DeviceTree.
As such if we split the non-input related handling into another driver
we would need to make the input driver create a subdevice during probe -
or create a new pon-driver with a new compatible that internally spawns
the pwrkey driver. Neither seems desirable to me...
The features of the PON block not yet shown on LKML are status registers
to indicate the reason for powering up the PMIC and a watchdog (which I
don't believe is used or exposed today).
Regards,
Bjorn
Powered by blists - more mailing lists