Hi, Some time ago I introduced LED classes to rt2x00. For the USB drivers this has prooven to be tricky since LED triggers are called in non-sleepable context and USB drivers do need some sleep for register access. As a workaround I introduced the in_atomic() check which prints an error and skips the call. I am now reading a discussion about in_atomic() on the netdev mailinglist, and drivers are urged to remove the usage as much as possible. I must admit that I don't know if LED triggers work in non-sleepable context by design or if it depends on the calling trigger.... For rt2x00 there are now 2 options, either find the trigger that is calling rt2x00 in non-sleepable context and fix it or drop the LED class feature for USB drivers. Has anybody recently tested the LED class option with rt2500usb or rt73usb? And if so, do the following lines appear in the log: Ignoring LED brightness command for led If so, please post all those error messages so the problem can be tracked down. Otherwise I will start with either disabling LED handling completely or create a large workaround which still uses LED classes but works without LED triggers. Depending on the amount of code, the LED triggers for PCI drivers will also be sacrificed to keep the code as simple as possible. Ivo -- 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
