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]
Date:   Thu, 31 Aug 2017 16:28:40 -0500
From:   Rob Herring <robh@...nel.org>
To:     Andrew Jeffery <andrew@...id.au>
Cc:     linux-leds@...r.kernel.org, rpurdie@...ys.net,
        jacek.anaszewski@...il.com, pavel@....cz, mark.rutland@....com,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        joel@....id.au, openbmc@...ts.ozlabs.org
Subject: Re: [PATCH v2 1/2] dt-bindings: leds: gpio: Add optional
 retain-state-shutdown property

On Mon, Aug 28, 2017 at 09:47:10AM +0930, Andrew Jeffery wrote:
> On Baseboard Management Controller (BMC) systems it's sometimes
> necessary for a LED to retain its state across a BMC reset (which is
> independent of the host system state). Add a devicetree property to
> describe this behaviour. The property would typically be used in
> conjunction with 'default-state = "keep"'.

A bit quick on the applying of this...

I don't understand how this works. The BMC usecase is interesting but 
that's fairly irrelevant to the binding. How do you know the GPIO state 
thru a reset? You're doing a core reset, but not reseting the GPIO 
controller?

When you use 'default-state = "keep"' but not this property? Seems like 
the same thing to me. Presumably the bootloader would just distinguish 
between a warm and cold reset to decide whether to re-init the state.

Finally, if we do have this property, why is it GPIO specific. You could 
just as easily have a LED controller IC and want to do the same thing.

Rob

Powered by blists - more mailing lists