rt2x00: Remove async vendor request calls from rt2x00usb
The async vendor requests are a ugly hack which is not working correctly.
The proper fix for the scheduling while atomic issue is finding out why
we can't use led classes for USB drivers and fix that.
Just replace all async calls with the regular ones and print an
error for the disallowed LED configuration attempts. That will
help in determining which led class is causing the problem.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 826ed69..9f59db9 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -292,6 +292,12 @@
unsigned int activity =
led->rt2x00dev->led_flags & LED_SUPPORT_ACTIVITY;
+ if (in_atomic()) {
+ NOTICE(led->rt2x00dev,
+ "Ignoring LED brightness command for led %d", led->type);
+ return;
+ }
+
if (led->type == LED_TYPE_RADIO || led->type == LED_TYPE_ASSOC) {
rt2x00_set_field16(&led->rt2x00dev->led_mcu_reg,
MAC_CSR20_LINK, enabled);
@@ -299,8 +305,8 @@
MAC_CSR20_ACTIVITY, enabled && activity);
}
- rt2x00usb_vendor_request_async(led->rt2x00dev, USB_SINGLE_WRITE,
- MAC_CSR20, led->rt2x00dev->led_mcu_reg);
+ rt2500usb_register_write(led->rt2x00dev, MAC_CSR20,
+ led->rt2x00dev->led_mcu_reg);
}
#else
#define rt2500usb_led_brightness NULL