linux.git/drivers/net/wireless/rt2x00, branch v2.6.29 Linux kernel source tree rt2x00 : more devices to rt73usb.c 2009-03-05T18:43:05+00:00 Xose Vazquez Perez xose.vazquez@gmail.com 2009-02-27T23:34:23+00:00 ef4bb70d876b4ae5787cc43727477d1a36cdc2e8 add more usb_dev to rt73usb.c . IDs 'stolen' from the windows inf file(10/21/2008, 1.03.02.0000) plus some from the Ralink linux driver(2009_0206_RT73_Linux_STA_Drv1.1.0.2.tar.bz2) Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
add more usb_dev to rt73usb.c . IDs 'stolen' from the
windows inf file(10/21/2008, 1.03.02.0000) plus some
from the Ralink linux driver(2009_0206_RT73_Linux_STA_Drv1.1.0.2.tar.bz2)

Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00 : more devices to rt2500usb.c 2009-03-05T18:43:05+00:00 Xose Vazquez Perez xose.vazquez@gmail.com 2009-02-27T23:26:09+00:00 9eb77ab0762d8cfc4686e1ec5e9a52905f3a5009 add more usb_dev to rt2500usb.c . IDs 'stolen' from the windows inf file(02/12/2009, 2.01.01.0015). Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
add more usb_dev to rt2500usb.c . IDs 'stolen' from the
windows inf file(02/12/2009, 2.01.01.0015).

Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Fix TX rate short preamble detection 2009-01-22T18:55:01+00:00 Ivo van Doorn ivdoorn@gmail.com 2009-01-18T19:15:24+00:00 7490889c105764d80af58dee5983d91a84e4aec8 Mac80211 provides 2 structures to handle bitrates, namely ieee80211_rate and ieee80211_tx_rate. To determine the short preamble mode for an outgoing frame, the flag IEEE80211_TX_RC_USE_SHORT_PREAMBLE must be checked on ieee80211_tx_rate and not ieee80211_rate (which rt2x00 did). This fixes a regression which was triggered in 2.6.29-rcX as reported by Chris Clayton. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Tested-By: Chris Clayton <chris2553@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
Mac80211 provides 2 structures to handle bitrates, namely
ieee80211_rate and ieee80211_tx_rate. To determine the short preamble
mode for an outgoing frame, the flag IEEE80211_TX_RC_USE_SHORT_PREAMBLE
must be checked on ieee80211_tx_rate and not ieee80211_rate (which rt2x00 did).

This fixes a regression which was triggered in 2.6.29-rcX as reported by Chris Clayton.

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Tested-By: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: fix a wrong parameter for __test_and_clear_bit() in rt2x00rfkill_free(). 2009-01-16T22:08:24+00:00 Rami Rosen ramirose@gmail.com 2009-01-13T22:00:13+00:00 e223b6dc051ad030a70d5c6ed6226b95bdfc3af7 When running modprobe rt73usb, and then rmmod rt73usb, and then iwconfig, the wlan0 device does not disappear. When repeating this process again, we get a kernel Oops errors and "BUG: unable to handle kernel paging request..." message in the kernel log. The reason for this is that there is an error in rt2x00rfkill_free(), which is called in the process of removing the device (rt2x00lib_remove_dev() in rt2x00dev.c). rt2x00rfkill_free() clears the RFKILL_STATE_ALLOCATED bit , which is bit number 1 () in rt2x00dev->flags instead of in rt2x00dev->rfkill_state. As a result, when checking the DEVICE_STATE_REGISTERED_HW bit (bit number 1 in rt2x00dev->flags) in rt2x00lib_remove_hw() it is **unset**, and we wrongly **don't** call ieee80211_unregister_hw(). This patch corrects this: the parameter for __test_and_clear_bit() in rt2x00rfkill_free() should be &rt2x00dev->rfkill_state and not &rt2x00dev->flags. Signed-off-by: Rami Rosen <ramirose@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
When running modprobe rt73usb, and then rmmod rt73usb, and then
iwconfig, the wlan0 device does not disappear. When repeating this
process again, we get a kernel Oops errors and "BUG: unable to handle
kernel paging request..." message in the kernel log.

The reason for this is that there is an error in rt2x00rfkill_free(),
which is called in the process of removing the device
(rt2x00lib_remove_dev() in rt2x00dev.c).
rt2x00rfkill_free() clears the RFKILL_STATE_ALLOCATED bit , which is
bit number 1 () in rt2x00dev->flags instead of in
rt2x00dev->rfkill_state. As a result, when checking the
DEVICE_STATE_REGISTERED_HW bit (bit number 1 in rt2x00dev->flags) in
rt2x00lib_remove_hw() it is **unset**, and we wrongly **don't** call
ieee80211_unregister_hw().

This patch corrects this: the parameter for __test_and_clear_bit() in
rt2x00rfkill_free() should be &rt2x00dev->rfkill_state and not
&rt2x00dev->flags.

Signed-off-by: Rami Rosen <ramirose@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Fix rt2500usb HW crypto: WEP 128 & AES 2009-01-12T19:24:57+00:00 Ivo van Doorn ivdoorn@gmail.com 2009-01-03T15:27:14+00:00 f1dd2b23badfe8a28910a78be24452c627c4b6f2 The TXD_W0_CIPHER field is a 1-bit field. It only acts as boolean value to indicate if the frame must be encrypted or not. The way rt2x00_set_field32() worked it would grab the least signifcant bit from txdesc->cipher and use that as value. Because of that WEP 64 and TKIP worked since they had odd-numbered values, while WEP 128 and AES were even numbers and didn't work. Correctly booleanize the txdecs->cipher value to allow the hardware to encrypt the outgoing data. After this we can enable HW crypto by default again. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The TXD_W0_CIPHER field is a 1-bit field. It only acts as boolean value
to indicate if the frame must be encrypted or not.

The way rt2x00_set_field32() worked it would grab the least signifcant bit
from txdesc->cipher and use that as value. Because of that WEP 64 and TKIP
worked since they had odd-numbered values, while WEP 128 and AES were
even numbers and didn't work.

Correctly booleanize the txdecs->cipher value to allow the hardware to
encrypt the outgoing data. After this we can enable HW crypto by default again.

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix rt2500usb HW crypto: TKIP 2009-01-12T19:24:54+00:00 Ivo van Doorn ivdoorn@gmail.com 2008-12-21T22:19:17+00:00 f3d340c1d536fd3e5a104c99ac9c3f8694270d72 rt2500usb doesn't strip the IV/ICV data from received frames, so we don't need to set the RX_FLAG_IV_STRIPPED flag. We do need to set the RX_FLAG_MMIC_STRIPPED flag for all encryption types since the MMIC has been removed from the frame. After this patch TKIP Hardware crypto works for rt2500usb. WEP and AES are still failing. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
rt2500usb doesn't strip the IV/ICV data from received frames,
so we don't need to set the RX_FLAG_IV_STRIPPED flag.
We do need to set the RX_FLAG_MMIC_STRIPPED flag for all
encryption types since the MMIC has been removed from the frame.

After this patch TKIP Hardware crypto works for rt2500usb.
WEP and AES are still failing.

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Fix segementation fault 2009-01-12T19:24:53+00:00 Ivo van Doorn ivdoorn@gmail.com 2008-12-20T10:00:23+00:00 d15cfc3ac77388f1d588c57743d5f26b15eba9a8 The queue_end() macro points to 1 position after the queue, which means that if we want to know if queue is at the end of the queue we should first increment the position and then check if it is a valid entry. This fixes a segmentation fault which only occurs when the device has enough endpoints to provide a dedicated endpoint for all TX queues (which likely won't happen for rt2500usb and rt73usb, but will happen for rt2800usb). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The queue_end() macro points to 1 position after the
queue, which means that if we want to know if queue
is at the end of the queue we should first increment
the position and then check if it is a valid entry.

This fixes a segmentation fault which only occurs when
the device has enough endpoints to provide a dedicated
endpoint for all TX queues (which likely won't happen
for rt2500usb and rt73usb, but will happen for rt2800usb).

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Fix TX short preamble detection 2009-01-12T19:24:50+00:00 Ivo van Doorn ivdoorn@gmail.com 2009-01-04T16:33:25+00:00 3ea96463156123cbfd09ac412012a87fef068830 The short preamble mode was not correctly detected during TX, rt2x00 used the rate->hw_value_short field but mac80211 is not using this field that way. Instead the flag IEEE80211_TX_RC_USE_SHORT_PREAMBLE should be used to determine if the frame should be send out using short preamble or not. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The short preamble mode was not correctly detected during TX,
rt2x00 used the rate->hw_value_short field but mac80211 is not
using this field that way.
Instead the flag IEEE80211_TX_RC_USE_SHORT_PREAMBLE should be
used to determine if the frame should be send out using
short preamble or not.

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: add USB ID for the Linksys WUSB200. 2009-01-12T19:24:50+00:00 Stefan Lippers-Hollmann s.L-H@gmx.de 2009-01-04T00:10:49+00:00 3be36ae223271f9c2cfbe7406846c8fdcd2f50c3 add USB ID for the Linksys WUSB200 Wireless-G Business USB Adapter to rt73usb. Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Cc: stable <stable@kernel.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
add USB ID for the Linksys WUSB200 Wireless-G Business USB Adapter to
rt73usb.

Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Cc: stable <stable@kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Fix radio LED type check 2009-01-12T19:24:49+00:00 Andrew Price andy@andrewprice.me.uk 2009-01-02T08:05:27+00:00 d1b29405bd3590bc97c4d3ff2c9139ca55e56ccd 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: Andrew Price <andy@andrewprice.me.uk> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
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: Andrew Price <andy@andrewprice.me.uk>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>