net: wireless: Remove useless return variables

This patch remove variables that are initialized with a constant,
are never updated, and are only used as parameter of return.
Return the constant instead of using a variable.

wl_cfg80211.c verified by compilation only.
phy/phy_cmn.c unverified.

The coccinelle script that find and fixes this issue is:
// <smpl>
@@
type T;
constant C;
identifier ret;
@@
- T ret = C;
... when != ret
    when strict
return
- ret
+ C
;
// </smpl>

Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
cw1200: Remove useless return variables

This patch remove variables that are initialized with a constant,
are never updated, and are only used as parameter of return.
Return the constant instead of using a variable.

Verified by compilation only.

The coccinelle script that find and fixes this issue is:
// <smpl>
@@
type T;
constant C;
identifier ret;
@@
- T ret = C;
... when != ret
    when strict
return
- ret
+ C
;
// </smpl>

Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtl818x_pci: make RSSI code more readable

remove the if-else chains and use switch-case to make code more
readable and avoiding long lines that broke in several lines

Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtl818x_pci: provide dBm signal information for rtl8185

This patch makes the driver report signal information for rtl8185
boards using dBm instead of unspecified unit.
Rtl8180 remains untouched.

I did some tests to confirm the correctness of the measure performed
by the board and it seems reasonably correct.

The test setup has been made by connecting an AP with coax and
RF attenuators to the card antenna port.

In order to get a reference measure I tried with several cards with
different chipset I own. I found that many gave different results, and
I finally selected two cards that gave me consistent results to use
as reference: AR9271 and Prism54-usb (isl3887 with Frisbee radio).

Using this references I compared the RSSI information with my rtl8185
and I repeated tests with three different attenuation values, increasing
attenuation by 10dB each step.
I made only relative measures, making NO assumption about source power.

CCK measures seem very close to my references, OFDM are a little bit
less precise but, considering that these cards are not measuring
instrumentation, IMHO this is still fairly good.

CCK measures (1Mbps beacons)

 ATTENUATOR 1
p54usb:    -58dBm
ath9k_htc: -59dBm
rtl8185:   -59dBm

 ATTENUATOR 2
p54usb:    -67dBm
ath9k_htc: -68dBm
rtl8185:   -70dBm

 ATTENUATOR 3
p54usb:    -78dBm
ath9k_htc: -79dBm
rtl8185:   -79dBm

OFDM measures (54Mbps ping)

 ATTENUATOR 1
p54usb:    -58dBm
ath9k_htc: -57dBm
rtl8185:   -62dBm

 ATTENUATOR 2
p54usb:    -68dBm
rtl8185:   -71dBm

Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtl818x_pci: fix possible RX descriptor invalid data read

RX descriptor data must be read only if the descriptor has been fully
updated by HW.
There is a "ownership" flag in the descriptor itself to test this.

The driver code contains a read for the "ownership" flag and, after
it, other read access for descriptor data.

This is in DMA coherent memory, that is _not_ guaranteed to be immune
to instruction reordering, thus it is possible that the descriptor
data is read _before_ the "ownership" flag.

This can theoretically lead to a DMA/CPU race that may end up with the
driver reading the data when it is still not valid, and the "ownership"
bit just after enough time that the HW make the whole descriptor valid.
The driver will in this case believe the data is valid, but it will use
the invalid data read earlier.

In order to avoid this, this patch adds a rmb() to force the "ownership"
bit read to be issued before other descriptor data reads are attempted.

Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
b43: drop B43_DEFAULT_CHANNEL

It was never used, b43_switch_channel is always called with hw_value
(from mac80211) or whatever get_default_chan returns.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
b43: b43_op_config: drop check for core change

There aren't devices with multiple 802.11 cores supported by b43.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
b43: b43_op_config: use IEEE80211_CONF_CHANGE_CHANNEL

This is tiny optimization and grouping band/channel ops.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
b43: PHY: don't force default channel during init

PHY may need to be re-initialized during runtime (e.g. on band switch).

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
b43: b43_op_config: set channel info before switching band

Band switching code needs to know what channel we switch to.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
b43: store current channel using struct cfg80211_chan_def

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
b43: PHY: drop own channel_freq (get it from chandef when needed)

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
b43: PHY: drop is_40mhz (get width info from chandef)

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
b43: PHY: drop channel_type (we can get this info from chandef)

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
net: wireless: libertas: cmd.c: Cleaning up uninitialized variables

There is a risk that the variable will be used without being initialized.

This was largely found by using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
net: wireless: rt2x00: rt2x00mac.c: Cleaning up uninitialized variables

There is a risk that the variable will be used without being initialized.

This was largely found by using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
net: wireless: rtlwifi: rtl8192de: phy.c: Cleaning up uninitialized variable

There is a risk that the variables will be used without being initialized.
Have also moved variable to the part of the code where it is used.

This was largely found by using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mwifiex: Remove custom world regulatory domain

A custom regulatory domain was introduced in this commit:
cc0ba0d mwifiex: support custom world regulatory domain

The commit description says that it was introduced because the world
regulatory domain does not include channels 52-64 and 100-140. These
channels are described in the world regulatory domain now, so we can
drop this custom regulatory domain.

Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: change beaconing locking

This patch is needed for further changes to keep global variables
consistent when changing beaconing on diffrent vif's.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: change beaconing setup on RT2800

As reported by Matthias, on 5572 chip, even if we clear up TXWI
of corresponding beacon, hardware still try to send it or do other
action that increase power consumption peak up to 1A.

To avoid the issue, setup beaconing dynamically by configuring offsets
of currently active beacons and MAC_BSSID_DW1_BSS_BCN_NUM variable,
which limit number of beacons that hardware will try to send.

Reported-by: Matthias Fend <Matthias.Fend@wolfvision.net>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>