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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe linux-leds" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux