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:   Tue, 8 Oct 2019 09:47:31 +0200
From:   Pavel Machek <pavel@....cz>
To:     Guru Das Srinagesh <gurus@...eaurora.org>
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

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.

Thanks,
								Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ