linux-kernel - Re: [PATCH 1/2] leds: Add flag to keep trigger always

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

Date:   Wed, 9 Oct 2019 17:52:24 -0700
From:   Guru Das Srinagesh <gurus@...eaurora.org>
To:     Pavel Machek <pavel@....cz>
Cc:     Greg KH <gregkh@...uxfoundation.org>, linux-leds@...r.kernel.org,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Dan Murphy <dmurphy@...com>, linux-kernel@...r.kernel.org,
        Subbaraman Narayanamurthy <subbaram@...eaurora.org>
Subject: Re: [PATCH 1/2] leds: Add flag to keep trigger always

On Tue, Oct 08, 2019 at 09:47:31AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > I don't understand.  The original commit broke userspace operations.
> > > > > Shouldn't it be reverted, or fixed this way in order to have userspace
> > > > > work properly again?
> > > > 
> > > > So, what it is exactly that is not working? :-). Yes, root can
> > > > disconnect LED from v4l2 interface; he can also connect it
> > > > back. Documentation says that happens.
> > > > 
> > > > Yes, root can do stupid things.
> > > > 
> > > > Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 is from 2008. I'd
> > > > prefer we did not apply it in 2008, but...
> > > 
> > > Ah, my fault, I thought this was a new commit.
> > > 
> > > Guru, what are you doing here that this is required all of a sudden?  No
> > > other kernel seems to need these changes, what is different in your
> > > Android userspace that requires this patch series?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > Hi Greg,
> > 
> > Our camera flash driver first requests the available current from the
> > flash LED before setting its brightness. It passes a trigger as argument
> > to the function that determines the available current. This function
> > uses trigger_to_lcdev() to look up the led_classdev associated with that
> > trigger as a first step. This lookup will fail if the trigger has been
> > dissociated from its led_classdev as a result of a user setting that
> > led_classdev's brightness to zero manually through sysfs. 
> > 
> > Why would the user set the brightness to zero? The user does this as
> > part of camera and LED testing activities which include, amongst other
> > things, visual inspection of the operation of various onboard LEDs. The
> > user uses sysfs to manually turn on and off the LEDs by setting their
> > brightness to max and then to zero in order to verify that they are
> > working as expected.
> 
> Yes, so you should really set trigger to none before changing
> brightness manually and restore it back to whatever it was when you
> are done with manual testing.

Hi Pavel,

Tried your suggestion to set the trigger to "none" before manual testing
and to restore it afterwards, and it works.

Thanks a lot.