This hunk was originally removed as part of "ath9k: Fix IRQ nobody cared
issue with ath9k".
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

 * Add support for AR2417 (include pci id) since my previous patch doesn't sit on top of base.c/ath5k.h anymore.
 * Update module version to 0.6.0

Changes-Licensed-under: ISC
Signed-Off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

 * Fix srev reporting during attach

Changes-Licensed-under: ISC
Signed-Off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

 * Use QUIET mechanism to drain tx buffer on PCU for newer chips
 * Make sure that INTPEND is really 1 and not 0xffffffff while checking for pending interrupts

Changes-Licensed-under: ISC
Signed-Off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

 * Use new SREV values and PHY srevs to identify radio type durring attach

Changes-Licensed-under: ISC
Signed-Off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

One of the spin-on-condition loops in routine do_dummy_tx always exits before
the condition is satisfied. The hardware might be left in an inconsistent
state that might be the cause of the PHY transmission errors seen by some
users.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

 * Update registers
 * Update SREV values and add some PHY srevs
 * Prepare ath5k.h for newer radios etc

 Thanks to Atheros 's HAL source we now know for sure how many parts we have
 and what their SREV values are. We also have some updates on registers. Prepare
 ath5k for some major updates ;-)

 My previous mail had 2 more patches following (git log misusage), sorry for double
 posting ;-(

Changes-Licensed-under: ISC
Signed-Off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

According to the newly-released Atheros HAL code, asserting the
TSF reset bit will toggle a hardware internal state, resulting in a
spurious reset on the next chip reset.  Whenever we force a TSF bit,
write the bit twice to clear the internal signal.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix by disabling rt2x00 rfkill support when rt2x00 is built-in and rfkill has been modularized, and
a similar scheme for the relationship between leds_class and rt2x00..
Also, give a warning to the end-user when rfkill-/leds-support is disabled this way, so that the
end-user has at least some clues on what is going on.

Proper fixing required some general updates of the Kconfig-structure for the rt2x00 driver, whereby
internal configuration symbols had to be moved to after the user-visible configuration symbols.
Signed-off-by: NGertjan van Wingerde <gwingerde@kpnplanet.nl>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch addresses comments from Dan Williams about the patch
committed as "libertas: Improvements on automatic tx power control via
SIOCSIWTXPOW."
Signed-off-by: NAnna Neal <anna@cozybit.com>
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Yet another BCM4306 card with the Bluetooth Coexistence SPROM programming
error has been found.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use correct DMA_MASK: 4964 and 5000 support 36 bit addresses for
pci express memory access.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch enables power save setting from config (iwconfig power)
The sysfs power_level interface is still preserved as it has
mac80211 power implementation is not yet rich enough.
Signed-off-by: NEster Kummer <ester.kummer@intel.com>
Reviewed-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch adds HW bug W/A FH_RCSR_CHNL0_RX_IGNORE_RXF_EMPTY so that we
can enable again interrupt coalescing. It also uses named constants for
open code.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The command

make C=2 CF="-D__CHECK_ENDIAN__" drivers/net/wireless/p54/

generates the following warnings:

.../p54common.c:152:38: warning: incorrect type in argument 1 (different base types)
.../p54common.c:152:38:    expected restricted __be32 const [usertype] *p
.../p54common.c:152:38:    got unsigned int *<noident>
.../p54common.c:184:15: warning: restricted __le32 degrades to integer
.../p54common.c:185:29: warning: cast to restricted __le16
.../p54common.c:309:11: warning: symbol 'p54_rf_chips' was not declared.
		        Should it be static?
.../p54common.c:313:5: warning: symbol 'p54_parse_eeprom' was not declared.
		       Should it be static?
.../p54common.c:620:43: warning: incorrect type in argument 3 (different base types)
.../p54common.c:620:43:    expected unsigned long [unsigned] [usertype] len
.../p54common.c:620:43:    got restricted __le16 [usertype] len
.../p54common.c:780:41: warning: restricted __le16 degrades to integer
.../p54common.c:781:32: warning: restricted __le16 degrades to integer
.../p54common.c:1250:28: warning: incorrect type in argument 2 (different base types)
.../p54common.c:1250:28:    expected unsigned short [unsigned] [usertype] filter_type
.../p54common.c:1250:28:    got restricted __le16 [usertype] filter_type
.../p54common.c:1252:28: warning: incorrect type in argument 2 (different base types)
.../p54common.c:1252:28:    expected unsigned short [unsigned] [usertype] filter_type
.../p54common.c:1252:28:    got restricted __le16 [usertype] filter_type
.../p54common.c:1257:42: warning: incorrect type in argument 2 (different base types)
.../p54common.c:1257:42:    expected unsigned short [unsigned] [usertype] filter_type
.../p54common.c:1257:42:    got restricted __le16
.../p54common.c:1260:42: warning: incorrect type in argument 2 (different base types)
.../p54common.c:1260:42:    expected unsigned short [unsigned] [usertype] filter_type
.../p54common.c:1260:42:    got restricted __le16
.../p54usb.c:228:10: warning: restricted __le32 degrades to integer
.../p54usb.c:228:23: warning: restricted __le32 degrades to integer
.../p54usb.c:228:7: warning: incorrect type in assignment (different base types)
.../p54usb.c:228:7:    expected restricted __le32 [assigned] [usertype] chk
.../p54usb.c:228:7:    got unsigned int
.../p54usb.c:221:8: warning: symbol 'p54u_lm87_chksum' was not declared.
		    Should it be static?

All of the above have been fixed. One question, however, remains: In struct
bootrec, the array "data" is treated in many places as native CPU order, but
it may be little-endian everywhere. As far as I can tell, this driver has only
been used with little-endian hardware.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

An additional BCM4306 has been found with the Bluetooth coexistence
SPROM coding error.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch returns success and empty scan on scans requests that were
rejected because issued too early. The cached bss list from previous
scanning will be returned by mac80211.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This BUG_ON really shouldn't trigger, but if it does, as on my machine,
it leaves you wondering what happened because you won't see it. Let's
instead leak a bit of state and memory and at least make it possible to
report it to the kerneloops project to track it.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The PCMCIA layer obsoleted asking for per device private IRQS some years
ago and all the drivers by inspection correctly use dev_id and handle
shared interrupts [they get em anyway in most PCI bridged PCMCIA/Cardbus]
so can be adjusted.

This gets rid of the various bugs reported where there is spewage about
conflicting irq types and sometimes the driver won't load.

(Note I don't have all of these devices to test each one beyond by inspection)
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When a crypto key is being removed, rt2x00mac should not
reset the key->hw_key_idx value because that will prevent
the driver from removing the correct key from the hardware.

Furthermore ffz() starts counting at 0 instead of 1, so we don't
need to substract 1 from the resulting value.
Signed-off-by: NStephen Blackheath <tramp.enshrine.stephen@blacksapphire.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
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>

Long awaited, hard work. This patch totally cleans up the rate control
API to remove the requirement to include internal headers outside of
net/mac80211/.

There's one internal use in the PID algorithm left for mesh networking,
we'll have to figure out a way to clean that one up and decide how to
do the peer link evaluation, possibly independent of the rate control
algorithm or via new API.

Additionally, ath9k is left using the cross-inclusion hack for now, we
will add new API where necessary to make this work properly, but right
now I'm not expert enough to do it. It's still off better than before.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

TSF adjust is needed only for AP mode when staggered beacons
are used. Since we support only a single interface in IBSS mode,
disable setting the TSF adjust register.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

nexttbtt has to be obtained from the timestamp of the beacon
obtained from mac80211. Fix this.
And <asm/unaligned.h> is not needed anymore.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Also, remove comments that are not relevant anymore.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch removes the HT flags from RXON when moving from HT to legacy.
This avoids keeping those flags set and possibly miss configuring firmware.

If we are configured in HT, fat channel: channel 1 above, and move later
to legacy channel 11, we need to clear the FAT channel control flags in
RXON. If we don't, the firmware will understand this as channel 11 above
which is not possible due to regulatory constraints, leading to firmware
crash.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch addresses comments from Dan Williams about the patch
committed as "libertas: Reduce the WPA key installation time."
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Acked-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

 * Fix bad udelay calls (using > 2000us) in AR5210 code and clean up
 some bits on nic_reset (AR5210 support is still in bad shape)

 Changes-licensed-under: ISC
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds named constants for configuring MIMO power save
chain settings.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Scan need to be delayed only after association to allow EAPOL
exchange. We don't need the delay for IBSS mode.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If the system is misconfigured with CONFIG_RFKILL set but CONFIG_RFKILL_INPUT
not set, the built-in radio LEDs will not work. In the current code, no warning
is issued.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The SIOCSIWSCAN handler is passed data in an iw_point structure. Some
drivers erronously use an iw_param instead.

On 32 bit architectures the difference isn't noticed as the flags
parameter tends to be the only one used by scan handlers and is at the
same offset.

On 64 bit architectures the pointer in the iw_point structure means the
flag parameter is at different offsets in these structures.

Thanks to Jean Tourrilhes for tracking this down for orinoco, and Pavel
Roskin for confirming the fix and identifying other suspect handlers.
Signed-off-by: NDavid Kilroy <kilroyd@googlemail.com>
Acked-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Enabling the MIB interrupts has proven to cause an
interrupt storm after 7 hours of run. We will make use of the
MIB interrupt once we have ANI supported added so for now
to cure this we disable the interrupt.

The interrupt storm can be seen as follows after 7 hours of run
as reported by  Steven Noonan <steven@uplinklabs.net>:

18:28:38          sum   1106.00
18:28:39          sum   1037.62
18:28:40          sum   1069.00
18:28:41          sum   1167.00
18:28:42          sum   1155.00
18:28:43          sum   1339.00
18:28:44          sum  18355.00
18:28:45          sum  17845.45
18:28:46          sum  15285.00
18:28:47          sum  17511.00
18:28:48          sum  17568.69
18:28:49          sum  17704.04
18:28:50          sum  18566.67
18:28:51          sum  18913.13

at 18:28:44 the MIB interrupt kicked off and caused huge
latency which can be seen even on a video he submitted:

http://www.youtube.com/watch?v=4GeCx1gZMpASigned-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

IRQs should be disabled before calling free_irq. Also flush pending
IRQs. Pasted the kernel log message for reference.

kernel: irq 17: nobody cared (try booting with the "irqpoll" option)
kernel:  [<c0252d2c>] __report_bad_irq+0x2e/0x6f
kernel:  [<c0252f22>] note_interrupt+0x1b5/0x207
kernel:  [<c025258b>] ? handle_IRQ_event+0x21/0x48
kernel:  [<c02534cb>] handle_fasteoi_irq+0x8e/0xad
kernel:  [<c0205650>] do_IRQ+0x6c/0x84
kernel:  [<c020425f>] common_interrupt+0x23/0x28
kernel:  [<c034f6f6>] ? acpi_idle_enter_simple+0x198/0x205
kernel:  [<c044686c>] ? menu_select+0x5c/0x78
kernel:  [<c0445a95>] cpuidle_idle_call+0x59/0x89
kernel:  [<c02029d7>] cpu_idle+0xae/0xcf
kernel:  [<c0543102>] rest_init+0x4e/0x50
kernel:  =======================
kernel: handlers:
kernel: [<f88fdd26>] (ath_isr+0x0/0x13a [ath9k])
kernel: Disabling IRQ #17
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Tested-by: NSteven Noonan <steven@uplinklabs.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

akpm: taken from http://bugzilla.kernel.org/show_bug.cgi?id=11587

I bought the wifi dongle trust nw-3100 wich is in fact a zd1211rw.  Its
hardware id was missing in the sources, adding it made it work flawlessly.

Cc: Daniel Drake <dsd@gentoo.org>
Cc: Ulrich Kunitz <kune@deine-taler.de>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Connectivtiy is lost after Group rekeying is done. The keytype
maintained by ath9k is reset when group key is updated. Though
sc_keytype can be reset only for broadcast key the proper fix
would be to use mac80211 provided key type from txinfo during
xmit and get rid of sc_keytype from ath9k ath_softc.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Tested-by: NSteven Noonan <steven@uplinklabs.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit bc19d6e0, which as
Larry Finger reports causes the radio LED on his system to no longer
respond to rfkill switch events.
Reported-by: NLarry Finger <Larry.Finger@lwfinger.net>
Requested-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

  CC [M]  drivers/net/wireless/libertas/wext.o
drivers/net/wireless/libertas/wext.c: In function ‘lbs_get_rts’:
drivers/net/wireless/libertas/wext.c:307: warning: comparison is always
false due to limited range of data type
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use min_t to avoid warnings when the typesafe version is used.

Explicitly cast u64s to unsigned long long when being passed to printk.
Signed-off-by: NDavid Kilroy <kilroyd@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>