Am 19.01.2016 um 01:11 schrieb Milo Kim: > 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 > Most likely not the LED subsystem but the respective driver would have to register the notifier as only the driver knows what kind of subsystem (usb, ..) is used. I agree that this would be somewhat cleaner. However I have my doubts that the relatively small benefit of getting read of one a little annoying error message justifies the required efforts. > > 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). > At a first glance I dont't think this is an issue because the notifier chain is blocking. > Best regards, > Milo > Regards, Heiner -- 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
