On Wed, Nov 04, 2009 at 04:30:19PM +0100, Christian Lamparter wrote: > On Wednesday 04 November 2009 16:11:33 John W. Linville wrote: > > This seems like a band-aid. If anything, the original order would > > seem to make more sense. > > really? > > take this code from led-class.c > > void led_classdev_unregister(struct led_classdev *led_cdev) > { > device_remove_file(led_cdev->dev, &dev_attr_max_brightness); > device_remove_file(led_cdev->dev, &dev_attr_brightness); > #ifdef CONFIG_LEDS_TRIGGERS > device_remove_file(led_cdev->dev, &dev_attr_trigger); > down_write(&led_cdev->trigger_lock); > if (led_cdev->trigger) > led_trigger_set(led_cdev, NULL); > up_write(&led_cdev->trigger_lock); > #endif > > device_unregister(led_cdev->dev); > > down_write(&leds_list_lock); > list_del(&led_cdev->node); > up_write(&leds_list_lock); > } > > as you can see the led is switched-off right before the device is unregistered. > but rtl8187, p54 & ar9170 led-triggers are timed & asynchronous. So > we really need a cancel_delayed_work_sync after the unregister routine > finished... else the timed trigger might fire when the device/module > is _faded_ from memory. OK, I got it...the unregister can queue-up more work. Thanks for the explanation. John -- John W. Linville Someday the world will need a hero, and you linville@xxxxxxxxxxxxx might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html