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

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]