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

[Heiner Kallweit <hkallweit1@gmail.com>]

Am 19.01.2016 um 10:10 schrieb Jacek Anaszewski:
> Hi Heiner,
> 
> On 01/18/2016 09:52 PM, Heiner Kallweit wrote:
> 
>>> Yes, this seems to be the best solution. Driver should set this flag
>>> before calling led_classdev_unregister. If the flag is set the -ENODEV
>>> error will not be reported. It could be named LED_HW_ABSENT for
>>> instance. Feel free to propose other ideas.
>>>
>> 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:
> 
> Ignoring -ENODEV errors for all devices would filter out also valid
> error cases and hinder debugging.
> 
> How about adding a flag LED_HW_PLUGGABLE in addition to
> LED_UNREGISTERING, and make the pluggable LED class drivers having set
> it all the time. The -ENODEV error would be reported only
> if !(LED_UNREGISTERING && LED_HW_PLUGGABLE).
> 
Sounds good, I'll send a patch including the additional LED_HW_PLUGGABLE flag.
The patch may apply cleanly only after applying a comment fix I sent on Jan 10th.
(led: core: fix misleading comment after workqueue removal from drivers)

Regards, Heiner