linux-kernel - Re: [PATCH 2/2] Input: pm8941-pwrkey: Introduce reboot mode support

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

Message-ID: <20170615183342.GX12920@tuxbook>
Date:   Thu, 15 Jun 2017 11:33:42 -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 15 Jun 09:26 PDT 2017, Sebastian Reichel wrote:

> Hi,
> 
> On Mon, Jun 12, 2017 at 04:32:03PM -0700, Bjorn Andersson wrote:
[..]
> > 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 pon-driver would have been the proper solution, but with the
> binding already being defined that's no longer a nice option :(
> 

We have a binding for the "qcom,pm8941-pwrkey", but as long as we
maintain the compatibility in the input driver with this we could come
up with a new binding for the "pon" block.

> > 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).
> 
> So we have a block, which has watchdog, powerdown, reboot, boot-reason,
> reboot-mode and power key. To me that does not look like it should be
> one driver.
> 

Unfortunately I do agree with this.

It would make sense to describe the pon in a single DT-node and have a
pon-driver spawning off individual driver for each functionality. That
way we get a clean representation in DT and we get clean implementation
of each component...

Regards,
Bjorn