Re: Problem with resetting LED in led_classdev_unregister in case of USB LED device removal

[Milo Kim <milo.kim@ti.com>]

On 01/19/2016 05:52 AM, Heiner Kallweit wrote:
> Setting such a flag from the driver might cause significant effort in different layers.
> When we talk about thingm as an example, it uses the hid subsystem with the usbhid low level driver.
> We would need a callback in the usbhid driver (to be notified when the device is unplugged)
> and a way to propagate this event to the hid core.
>
> Maybe simpler: We could ignore ENODEV errors if a function is called from led_classdev_unregister.
> This way we wouldn't have to touch drivers. I think of something like this:

Well, simple solution is good but I'm thinking about more generic handling.


LED subsystem				HID LED driver
-------------				--------------
					Create a LED device

Registers an event notifier

					Device is unplugged,
					notify an event to LED
					subsystem

Notification callback sets
a flag which means HW is removed

Set-brightness scheduler work
function checks this flag and
ignore the brightness update


blocking_notifier_chain_register() and blocking_notifier_call_chain() 
helpers can be used for this implementation.

However, I'm not sure how much latency will exist between step 3 (device 
is unplugged) and step 5 (check the flag and ignore brightness-set).

Best regards,
Milo