linux-kernel - Re: [PATCH 2/2] iio: misc: add support for GPIO power switches

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: <0c3511be-6a3c-f65c-c562-1c4b9318acb1@kernel.org>
Date:   Fri, 30 Dec 2016 15:15:30 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Sebastian Reichel <sre@...nel.org>
Cc:     Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kevin Hilman <khilman@...libre.com>,
        Patrick Titiano <ptitiano@...libre.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Alexandre Courbot <gnurou@...il.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH 2/2] iio: misc: add support for GPIO power switches

On 30/12/16 13:05, Linus Walleij wrote:
> n Thu, Dec 29, 2016 at 5:29 PM, Sebastian Reichel <sre@...nel.org> wrote:
>> On Wed, Dec 28, 2016 at 01:50:17PM +0100, Linus Walleij wrote:
>>> On Sun, Dec 11, 2016 at 11:21 PM, Bartosz Golaszewski
>>> <bgolaszewski@...libre.com> wrote:
>>>
>>>> Some power-measuring ADCs work together with power load switches which
>>>> allow to power-cycle measured devices.
>>>>
>>>> An example use case would be measuring the power consumption of a
>>>> development board during boot using a power monitor such as TI INA226
>>>> and power-cycling the board remotely using a TPS229* power switch.
>>>>
>>>> Add an iio driver for simple GPIO power switches and expose a sysfs
>>>> attribute allowing to toggle their state.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@...libre.com>
>>>
>>> I don't get this, isn't this doing the same as
>>> drivers/power/reset/gpio-poweroff.c
>>> ?
>>>
>>> With the only difference that the latter uses the standard syscall
>>> from pm_power_off to reboot the system instead of some random
>>> sysfs file.
>>
>> As far as I understand it, the TPS229 is used by Barzosz to poweroff
>> a remote system. The gpio-poweroff driver is used to poweroff the
>> local system.
> 
> Thanks yeah I understood this from the context of later patches.
> 
> Well if such a property is used it should be the property of the remote
> system per se, and the remote system should then also be desribed in
> DT, not half-described by dangling references at random nodes.
> 
> So this needs to be re-architected to either describe the remote system
> in DT and handle it in the kernel, or handle it all from userspace if it
> is a one-off non-product thing.
I'm not sure this is always true (though it might be here).  There is always
a need to describe the edge of the known world.  Be it that we have
an accelerometer - ultimately we could describe the device generating the
acceleration but we have no way of knowing what it is or what it will do..

What we have here is a rather simple case, but what about an I/O bank on
a PLC.  Obviously we can handle that as a bunch of GPIOs but if we know
more about it we should have means to describe that.  Say we know they are
always driving relays, we should be able to describe that additional known
stuff. Relays have characteristics such as bounce times etc that if described
would allow us to do the relevant filtering on inputs to handle this.

Here the fact it is a power supply switch should be describable.  Hard to
get right in a generic way though so in cases like this perhaps you
are right and it should just be left undescribed and handled in userspace.

Anyhow, here I think leaving it as a gpio interface is probably the way to
go, but I'm not sure that will always be the case.

Jonathan
> 
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>