Get closer to what the ralink driver does by setting the rf register 13
to tx_power2 during channel switch.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Disable HT40 support for now as it causes rx problems with HT40 capable
11n APs (when mac80211 enables HT40, rx is completely disfunctional).

Once the rt2800 HT code is capable of using HT40 we should enable the
flag again.

I only tested this patch with a rt305x SoC device, nevertheless the
patch disables HT40 also on PCI and USB rt2800 devices.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All commands to the target are disabled when the device
is unplugged, but a normal module unload has to be
differentiated from this case, as we could still receive
data in the RX endpoint. Fix this by checking if the
device is attached or not.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

My patch "ath9k_htc: Handle WMI timeouts properly" introduced
a race condition in WMI command processing. The last issued command
should be stored _before_ issuing a WMI command. Not doing this
would result in the WMI event IRQ dropping correct command responses
as invalid.

Fix this race by storing the command id correctly.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Completion of WMI commands take a longer time
on some platforms. Increase the timeout value
to handle this.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When handling the REGIN callback, processing
the incoming data first should be the preferred
mode of operation. Allocation of a new SKB may fail,
in which case, the URB will not be resubmitted.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

So, apparently there is a USB reboot command
that the target accepts. Using this instead of
usb_reset_device() fixes the issue of "descriptor read error"
that pops up on repeated load/unload.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In the TX callback, the HTC layer has to pass the
priv pointer that was registered during service initialization.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There is no reason to disable the PHY Error / MIB counters
when the module is being unloaded.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes a code segment in configpciepowersave()
to make use of multiple register writes.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the USB device has been unplugged, there is
no point in trying to send commands to the target.
Fix this by denying all WMI commands in such a case.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch simplifies URB management for transmission,
by removing the 'FLUSH' variable (which is not needed,
since we can determine if the URB has been killed by
looking at the URB status), and also handling the STOP
case properly.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes a recently introduced use-after-free regression
from "p54pci: prevent stuck rx-ring on slow system".

Hans de Goede reported a use-after-free regression:
>BUG: unable to handle kernel paging request at 6b6b6b6b
>IP: [<e122284a>] p54p_check_tx_ring+0x84/0xb1 [p54pci]
>*pde = 00000000
>Oops: 0000 [#1] SMP
>EIP: 0060:[<e122284a>] EFLAGS: 00010286 CPU: 0
>EIP is at p54p_check_tx_ring+0x84/0xb1 [p54pci]
>EAX: 6b6b6b6b EBX: df10b170 ECX: 00000003 EDX: 00000001
>ESI: dc471500 EDI: d8acaeb0 EBP: c098be9c ESP: c098be84
> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>Process swapper (pid: 0, ti=c098a000 task=c09ccfe0 task.ti=c098a000)
>Call Trace:
> [<e1222b02>] ? p54p_tasklet+0xaa/0xb5 [p54pci]
> [<c0440568>] ? tasklet_action+0x78/0xcb
> [<c0440ed3>] ? __do_softirq+0xbc/0x173

Quote from comment #17:
"The problem is the innocent looking moving of the tx processing to
 after the rx processing in the tasklet. Quoting from the changelog:
  This patch does it the same way, except that it also prioritize
  rx data processing, simply because tx routines *can* wait.

 This is causing an issue with us referencing already freed memory,
 because some skb's we transmit, we immediately receive back, such
 as those for reading the eeprom (*) and getting stats.

 What can happen because of the moving of the tx processing to after
 the rx processing is that when the tasklet first runs after doing a
 special skb tx (such as eeprom) we've already received the answer
 to it.

 Then the rx processing ends up calling p54_find_and_unlink_skb to
 find the matching tx skb for the just received special rx skb and
 frees the tx skb.

 Then after the processing of the rx skb answer, and thus freeing
 the tx skb, we go process the completed tx ring entires, and then
 dereference the free-ed skb, to see if it should free free-ed by
 p54p_check_tx_ring()."

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=583623Bug-Identified-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The sta->last_tx_rate is traditionally updated just before transmitting a
frame based on information from the rate control algorithm. However, for
hardware drivers with IEEE80211_HW_HAS_RATE_CONTROL this is not performed,
as the rate control algorithm is not executed, and because the used rate is
not known before the frame has actually been transmitted.

This causes atleast a fixed 1Mb/s to be reported to user space. A few other
instances of code also rely on this information.

Fix this by setting the sta->last_tx_rate in tx_status handling. There, look
for last rates entry set by the driver, and use that as value for
sta->last_tx_rate.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Our offset handling becomes even a little more hackish now. For some reason I
do not understand all offsets as inrelative. It assumes base offset is 0x1000
but it will work for now as we make offsets relative anyway by removing base
0x1000. Should be cleaner however.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Attempting to read registers that don't exist on the SSB bus can cause
hangs on some boxes.  At least some b43 devices are 'in the wild' that
don't have SPROMs at all.  When the SSB bus support loads, it attempts
to read these (non-existant) SPROMs and causes hard hangs on the box --
no console output, etc.

This patch adds some intelligence to determine whether or not the SPROM
is present before attempting to read it.  This avoids those hard hangs
on those devices with no SPROM attached to their SSB bus.  The
SSB-attached devices (e.g. b43, et al.) won't work, but at least the box
will survive to test further patches. :-)
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Michael Buesch <mb@bu3sch.de>

When I updated this from the corresponding
userspace library, an annotation error crept
in -- this variable needs to be annotated as
little endian. No effect on code generation.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes ar5416Addac_9160 and ar5416Addac_9160 const
I guess we skipped them long ago.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When IEEE80211_HW_CONNECTION_MONITOR is configured by the driver, starting
of ieee80211_sta_conn_mon_timer should be prevented, as it is then not needed.

This is currently partially the case. As it seems, when a probe-response is
received from the AP the timer is still restarted, thus restarting the host
based connection keep-alive mechanism. These probe-responses happen at least
when scanning while associated.

Fix this by preventing starting of the ieee80211_sta_conn_mon_timer in the
ieee80211_rx_mgmt_probe_resp function.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Supported only for single stream rates by the hardware
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AR9300 based hardware can 3x3 MCS rates, this should be set in the
HT capabilities.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of increasing bits_per_symbol for supporting more streams, keep
it single-stream only and multiply the values by the numer of streams.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Include MCS0-31 and also add SGI for HT20. This makes it
possible to support more different rate combinations with
newer hardware.

Based on a patch by Selvam. T.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds the first element of survey data, the noise floor figure.
Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds the survey function to both mac80211 itself and to mac80211_hwsim.
For the latter driver, we simply invent some noise level.A real driver which
cannot determine the real channel noise MUST NOT report any noise, especially
not a magically conjured one :-)
Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When I set up multiple VAPs with ath9k, I encountered an issue that
the traffic may be lost after a while.

The detailed phenomenon is
1. After a while the clients connected to one of these VAPs will get
into a state that no broadcast/multicast packets can be transfered
successfully while the unicast packets can be transfered normally.
2. Minutes latter the unitcast packets transfer will fail as well,
because the ARP entry is expired and it can't be freshed due to the
broadcast trouble.

It's caused by the group key overwritten and someone discussed this
issue in ath9k-devel maillist before, but haven't work out a fix yet.

I referred the method in madwifi, and made a patch for ath9k.
The method is to set the high bit of the sender(AP)'s address, and
associated that mac and the group key. It requires the hardware
supports multicast frame key search. It seems true for AR9160.

Not sure whether it's the correct way to fix this issue. But it seems
to work in my test. The patch is attached, feel free to revise it.
Signed-off-by: NDaniel Yingqiang ma <yma.cool@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Applied common sense, no info from the manufacturer:

(0x8516, 0x2070) is RT2070
(0x8516, 0x2770) is RT2770
(0x8516, 0x2870) is RT2870
[...]
Signed-off-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

One HT debugging printk is missing a newline,
add it.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Orinoco should be endian clean, so enable the checking.
Signed-off-by: NDavid Kilroy <kilroyd@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of using a local function.
Signed-off-by: NDavid Kilroy <kilroyd@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>