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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 13 Apr 2017 14:14:25 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
Cc:     Richard Fitzgerald <rf@...nsource.wolfsonmicro.com>,
        Rob Herring <robh@...nel.org>,
        Lee Jones <lee.jones@...aro.org>,
        Alexandre Courbot <gnurou@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:WOLFSON MICROELECTRONICS DRIVERS" 
        <patches@...nsource.wolfsonmicro.com>
Subject: Re: [PATCH 1/2] mfd: arizona: Add GPIO maintain state flag

On Thu, Apr 13, 2017 at 11:15 AM, Charles Keepax
<ckeepax@...nsource.wolfsonmicro.com> wrote:
> On Tue, Apr 11, 2017 at 10:34:27AM +0100, Richard Fitzgerald wrote:

>> 3) The codec only has to be kept awake while any such GPIO is actually
>> in use. See (2)
>
> Yeah option 3 is the primary issue here, we only want to keep the
> CODEC enabled whilst specific GPIOs are in use. As GPIOs can be
> dynamically requested/released by things in the kernel we want to
> know which GPIOs require the CODEC to be kept alive. Also in the
> future one might be tempted to add maintain whilst high and
> maintain whilst low options for lines with pulls on them to
> further optimise power.

Why does this have to be encoded as information in the device
tree? Isn't it better to use a static table in the driver?

I don't see what use system integrators and others playing
around with the device tree has of this, it will just be confusing
to them if it is a chip-internal detail.

Yours,
Linus Walleij

Powered by blists - more mailing lists