Since "rt2x00: Fix LED state handling", rt2x00leds_led_radio wrongly
checks that the LED type is LED_TYPE_ASSOC. This patch makes it check
for LED_TYPE_RADIO once again.
Signed-off-by: NAndrew Price <andy@andrewprice.me.uk>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When we switch off the LEDS during initialization
we kill rt73usb from proper functioning. The immediate
result after the first LED command are MCU failures
and a complete breakdown of TX/RX.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For every global LED state change (register/unregister,
suspend/resume) we should force the LEDS to turn off.
This makes sure that the LEDS will always be in a sane
state after the state switch.

Note that when unregister is called but the LED class
wasn't resumed yet, we shouldn't change the LED state
since we might not have access to the device (device
was unplugged while suspended).

Also remove the checks in the activity, assoc and
radio LEDS which blocked calls to brightness_set()
when the state hasn't changed. Some of those LEDS
could be enabled by themselves when something happens
in the hardware (e.g. firmware is loaded). We already
did called rt2x00leds to switch the LED off, but those
calls were blocked.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There was an obvious typo in LED structure
initialization which caused the radio and quality/activity
leds to be incorrectly initialized which resulted in
the leds not being enabled.

Additionally add the rt2x00led_led_activity() handler
that will enable TX/RX activity leds when the radio
is being enabled.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Implement triggers inside rt2x00 itself based
on input from mac80211. This replaces the method
of using the mac80211 trigger events which do
not work for USB drivers due to the scheduling
requirement.

After this patch RT2500USB_LEDS and RT73USB_LEDS
no longer need to be tagged as broken since they
now support LED handling again without having to
check for in_atomic().
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2x00dev isn't interested in the rt2x00leds_register() value
anyway. So lets make it return void to even prevent people from
assuming there is anybody interested in the returnvalue.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add kerneldoc for vendor request functions in rt2x00usb.
Add asynchroneous vendor request function in rt2x00usb.

With the availability of the asynchroneuous vendor request
we can now enable LED class support for rt2500usb and rt73usb.
Since LED handling is not important, it doesn't really matter
if a register call fails (This solution is better then no
LED class support at all).
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>