linux.git/drivers/net/wireless/rt2x00, branch v2.6.27 Linux kernel source tree rt2x00: Compiler warning unmasked by fix of BUILD_BUG_ON 2008-09-02T21:40:02+00:00 Boaz Harrosh bharrosh@panasas.com 2008-09-01T11:47:19+00:00 445df54fec7c1924f44018c4db2a9613b877f10e A "Set" to a sign-bit in an "&" operation causes a compiler warning. Make calculations unsigned. [ The warning was masked by the old definition of BUILD_BUG_ON() ] Also remove __builtin_constant_p from FIELD_CHECK since BUILD_BUG_ON no longer permits non-const values. Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> CC: Ingo Molnar <mingo@elte.hu> CC: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
A "Set" to a sign-bit in an "&" operation causes a compiler warning.
Make calculations unsigned.

[ The warning was masked by the old definition of BUILD_BUG_ON() ]

Also remove __builtin_constant_p from FIELD_CHECK since BUILD_BUG_ON
no longer permits non-const values.

Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
CC: Ingo Molnar <mingo@elte.hu>
CC: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Fix txdone_entry_desc_flags 2008-08-18T15:05:15+00:00 Jochen Friedrich jochen@scram.de 2008-08-15T12:47:46+00:00 f126cba427170eac9e37311b2ab7afc0e2261906 txdone_entry_desc_flags is used with __set_bit and test_bit which bit-shift the values, so don't bit-shift the flags in the enum. Also make sure flags are initialized before being used. Signed-off-by: Jochen Friedrich <jochen@scram.de> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
txdone_entry_desc_flags is used with __set_bit and test_bit which
bit-shift the values, so don't bit-shift the flags in the enum.
Also make sure flags are initialized before being used.

Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Block all unsupported modes 2008-08-07T13:49:04+00:00 Ivo van Doorn ivdoorn@gmail.com 2008-08-06T14:18:31+00:00 0fc980392e5a06cff34ca7acaac5790bb59528d1 It was possible for unsupported operating modes to be accepted by the add_interface callback function. This patch will block those modes until proper support has been implemented for them. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
It was possible for unsupported operating modes
to be accepted by the add_interface callback function.
This patch will block those modes until proper support
has been implemented for them.

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Disable link tuning in rt2500usb 2008-08-04T19:09:11+00:00 Ivo van Doorn IvDoorn@gmail.com 2008-08-03T21:36:01+00:00 d06193f311102b2c990ec5f66b470ea49ecc73a4 In the legacy rt2570 driver the link tuner was never really called. And now the reason has finally become apparent: It breaks TX capabilities As soon as the device has been associated all following TX frames will be queued in the hardware and never transmitted to the air. Disabling sections of the link tuner did not have the expected result, but completely disabling the link tuner did have the right result (Both of my rt2570 devices came back to life). This should fix Fedora bug: 411481 v2: Fix typos Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
In the legacy rt2570 driver the link tuner was never
really called. And now the reason has finally become
apparent: It breaks TX capabilities

As soon as the device has been associated all following
TX frames will be queued in the hardware and never transmitted
to the air. Disabling sections of the link tuner did not
have the expected result, but completely disabling the
link tuner did have the right result (Both of my rt2570 devices
came back to life).

This should fix Fedora bug: 411481

v2: Fix typos

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Fix compile warning 2008-08-02T08:31:09+00:00 Ivo van Doorn IvDoorn@gmail.com 2008-08-02T08:31:09+00:00 82f97b8d3cb3982ec97e081598c671fab2c321b0 rt2x00usb_vendor_request_large_buff is write-only, so it is safe to make the argument a const. Fixes compile warning: drivers/net/wireless/rt2x00/rt73usb.c: In function 'rt73usb_load_firmware': drivers/net/wireless/rt2x00/rt73usb.c:916: warning: passing argument 5 of 'rt2x00usb_vendor_request_large_buff' discards qualifiers from pointer target typ Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
rt2x00usb_vendor_request_large_buff is write-only, so it is
safe to make the argument a const.

Fixes compile warning:
drivers/net/wireless/rt2x00/rt73usb.c: In function 'rt73usb_load_firmware':
drivers/net/wireless/rt2x00/rt73usb.c:916: warning: passing argument 5 of 'rt2x00usb_vendor_request_large_buff' discards qualifiers from pointer target typ

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
rt2500pci: restoring missing line 2008-08-01T19:31:35+00:00 Peter Chubb peterc@gelato.unsw.edu.au 2008-07-31T00:56:34+00:00 bf4634afd8bb72936d2d56425ec792ca1bfa92a2 In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the released 2.6.26, my RaLink rt2500 card wouldn't associate. Git-bisect led me to this patch: 61486e0f68d1f8966c09b734566a187d42d65c54 rt2x00: Remove ieee80211_tx_control argument from write_tx_desc() I believe that there is a problem with that patch --- it (inadvertantly) removes an extra line of code, that used to set the DATABYTE_COUNT field. This patch reinstates that line, and with it my card works again. Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the
released 2.6.26, my RaLink rt2500 card wouldn't associate.

Git-bisect led me to this patch:

	61486e0f68d1f8966c09b734566a187d42d65c54
	rt2x00: Remove ieee80211_tx_control argument from write_tx_desc()

I believe that there is a problem with that patch --- it
(inadvertantly) removes an extra line of code, that used to set the
DATABYTE_COUNT field.

This patch reinstates that line, and with it my card works again.

Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Sequence counter should be protected in irqsave 2008-08-01T19:31:34+00:00 Ivo van Doorn ivdoorn@gmail.com 2008-07-28T08:21:16+00:00 d4764b29b6e0f1608e397930677928e5a3f62bba The sequence counter can be accessed in IRQ context, which means the lock protecting the counter should be irqsave. To prevent making the entire intf->lock irqsave without reason, create a new lock which only protects the sequence counter. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The sequence counter can be accessed in IRQ context,
which means the lock protecting the counter should
be irqsave. To prevent making the entire intf->lock irqsave
without reason, create a new lock which only protects
the sequence counter.

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Fix VGC lower bound initialization 2008-08-01T19:31:34+00:00 Ivo van Doorn ivdoorn@gmail.com 2008-07-28T08:20:12+00:00 8d8acd46fb7e962ac04baef5a118d431fae6b0f6 When the EEPROM_BBPTUNE_VGC word is valid, we should override EEPROM_BBPTUNE_VGCLOWER field with the BBP value. And we should _not_ do that when EEPROM_BBPTUNE_R17 is valid. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
When the EEPROM_BBPTUNE_VGC word is valid, we should
override EEPROM_BBPTUNE_VGCLOWER field with the BBP
value.

And we should _not_ do that when EEPROM_BBPTUNE_R17 is valid.

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: rt61pci needs another millisecond after firmware upload 2008-08-01T19:31:34+00:00 Ivo van Doorn ivdoorn@gmail.com 2008-07-27T13:06:50+00:00 e6d3e902088ac5da77b074f513e3cb80422ff471 After the hardware has indicated the firmware upload has completed and the device is ready, we should wait another millisecond to make sure the device is really ready to continue. Without this timout, bringing the interface down and up again will fail due to incorrect register initialization. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
After the hardware has indicated the firmware upload has completed
and the device is ready, we should wait another millisecond to
make sure the device is really ready to continue.

Without this timout, bringing the interface down and up again will
fail due to incorrect register initialization.

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Fix partial antenna configuration 2008-08-01T19:31:34+00:00 Ivo van Doorn ivdoorn@gmail.com 2008-07-27T13:06:21+00:00 ada662f3eb6231ab27f5e6366d4e5c395d25edd3 The if-statement to determine the new TX/RX antenna configuration was incomplete. It lacks the general else-clause when the antenna wasn't changed. This is a correct event, since it can occur when only one of the antenna's has been changed or when the new configuration is being forced (like when the interface has just been added). Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The if-statement to determine the new TX/RX antenna
configuration was incomplete. It lacks the general
else-clause when the antenna wasn't changed.

This is a correct event, since it can occur when only
one of the antenna's has been changed or when the new
configuration is being forced (like when the interface
has just been added).

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>