HP & LP queue depth and rx status length.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AR9003 supports extended DMA (EDMA), this comes with some
bells and whistles on top of the legacy DMA that we are used
to. Mark AR9003 and later chips EDMA capable.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.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>

ANI is still being debugged on AR9003 by our systems team
so it should not yet be enabled yet. When ANI will be
enabled all ANI functionality is expected to be enabled
so fill the ANI functionality to all for AR9003 for now
as well.

Cc: Enis Akay <Enis.Akay@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.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>

This allows us to add SREV checks on these helpers.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This add stubs for PHY support for the AR9003 hardware family.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Also, clean up and reorganize the AR9287 macro to have better
ordering. We won't add the PCI ID to the supported device list
until we have some functional code for it.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The PLL control computation used to program the AR_RTC_PLL_CONTROL
register varies between our harware so just add a private callback for it.
AR9003 will use its own callback.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.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>

This is not required for the AR9003 family.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The PHY split is easier done in a few steps. First move
the RF ops to the private ops and rename them accordingly.
We split PHY stuff up first for the AR5008 and AR9002
families. There are some callbacks that AR9002 share
with the AR5008 familiy so we set those first, if AR9002
has some different callbacks it will override them upon
hardware init.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is used only once by ath9k_hw_process_ini() to
write an array of phy registers through REG_WRITE_ARRAY(),
but we already call REG_WRITE_ARRAY() multiple times
on the same caller so just remove this pointless wrapper.
We'll eventually just move the ath9k_hw_process_ini()
caller as an callback to abstract away between different
hardware families.

Although this change is subtle I should note that this
does change the delay pattern on writing the next series
of registers. REG_WRITE_ARRAY() uses a counter for each
register write and does a udelay(1) every 64 writes. By
removing this call it means that the counter is processed
for all the iniBB_RfGain registers and is incremented
on ath9k_hw_process_ini(), before this the after the call
ath9k_hw_write_regs() was made the register counter was
kept at the same index number prior to the call.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AR9003 does not have a reset control for AHB.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.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>

This is not a stable code fix as this register is not used anywhere.
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 will be the first device supported of the AR9003
family. AR9300 1.0 hardware exists but it is not going to
be sold anywhere so we completely skip its support.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k supports the AR5008, AR9001 and AR9002 family of Atheros
chipsets, all 802.11n. The new breed of 802.11n chips, the
AR9003 family will be supported as well soon. To help with its
support we're going to add a few callbacks for hardware routines
which differ considerably instead of adding branch checks for
the revision at runtime.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes two warnings below after unplugging ar9271 usb device:
	-one is a kernel warning[1]
	-another is a lockdep warning[2]

The root reason is that __skb_queue_purge can't be executed in hardirq
context, so the patch forks ath9k_skb_queue_purge(ath9k version of _skb_queue_purge),
which frees skb with dev_kfree_skb_any which can be run in hardirq
context safely, then prevent the lockdep warning and kernel warning after
unplugging ar9271 usb device.

[1] kernel warning
[  602.894005] ------------[ cut here ]------------
[  602.894005] WARNING: at net/core/skbuff.c:398 skb_release_head_state+0x71/0x87()
[  602.894005] Hardware name: 6475EK2
[  602.894005] Modules linked in: ath9k_htc ath9k ath9k_common ath9k_hw ath bridge stp llc sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table kvm_intel kvm arc4 ecb mac80211 snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep thinkpad_acpi snd_pcm snd_timer hwmon iTCO_wdt snd e1000e pcspkr i2c_i801 usbhid iTCO_vendor_support wmi cfg80211 yenta_socket rsrc_nonstatic pata_acpi snd_page_alloc soundcore uhci_hcd ohci_hcd ehci_hcd usbcore i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: ath]
[  602.894005] Pid: 2506, comm: ping Tainted: G        W  2.6.34-rc3-wl #20
[  602.894005] Call Trace:
[  602.894005]  <IRQ>  [<ffffffff8104a41c>] warn_slowpath_common+0x7c/0x94
[  602.894005]  [<ffffffffa022f398>] ? __skb_queue_purge+0x43/0x4a [ath9k_htc]
[  602.894005]  [<ffffffff8104a448>] warn_slowpath_null+0x14/0x16
[  602.894005]  [<ffffffff813269c1>] skb_release_head_state+0x71/0x87
[  602.894005]  [<ffffffff8132829a>] __kfree_skb+0x16/0x81
[  602.894005]  [<ffffffff813283b2>] kfree_skb+0x7e/0x86
[  602.894005]  [<ffffffffa022f398>] __skb_queue_purge+0x43/0x4a [ath9k_htc]
[  602.894005]  [<ffffffffa022f560>] __hif_usb_tx+0x1c1/0x21b [ath9k_htc]
[  602.894005]  [<ffffffffa022f73c>] hif_usb_tx_cb+0x12f/0x154 [ath9k_htc]
[  602.894005]  [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
[  602.894005]  [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd]
[  602.894005]  [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd]
[  602.894005]  [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd]
[  602.894005]  [<ffffffffa00fa5ae>] ? ehci_irq+0x2f/0x1d4 [ehci_hcd]
[  602.894005]  [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
[  602.894005]  [<ffffffff810a6d18>] ? __rcu_process_callbacks+0x7a/0x2df
[  602.894005]  [<ffffffff810a47a4>] ? handle_fasteoi_irq+0x22/0xd2
[  602.894005]  [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore]
[  602.894005]  [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f
[  602.894005]  [<ffffffff813285ce>] ? skb_release_data+0xc9/0xce
[  602.894005]  [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2
[  602.894005]  [<ffffffff8100c4fb>] handle_irq+0x88/0x91
[  602.894005]  [<ffffffff8100baed>] do_IRQ+0x63/0xc9
[  602.894005]  [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c
[  602.894005]  [<ffffffff813ba993>] ret_from_intr+0x0/0x16
[  602.894005]  <EOI>  [<ffffffff811095fe>] ? __delete_object+0x5a/0xb1
[  602.894005]  [<ffffffff813ba5f5>] ? _raw_write_unlock_irqrestore+0x47/0x7e
[  602.894005]  [<ffffffff813ba5fa>] ? _raw_write_unlock_irqrestore+0x4c/0x7e
[  602.894005]  [<ffffffff811095fe>] __delete_object+0x5a/0xb1
[  602.894005]  [<ffffffff81109814>] delete_object_full+0x25/0x31
[  602.894005]  [<ffffffff813a60c0>] kmemleak_free+0x26/0x45
[  602.894005]  [<ffffffff810ff517>] kfree+0xaa/0x149
[  602.894005]  [<ffffffff81323fb7>] ? sock_def_write_space+0x84/0x89
[  602.894005]  [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c
[  602.894005]  [<ffffffff813285ce>] skb_release_data+0xc9/0xce
[  602.894005]  [<ffffffff813282a2>] __kfree_skb+0x1e/0x81
[  602.894005]  [<ffffffff813283b2>] kfree_skb+0x7e/0x86
[  602.894005]  [<ffffffff81354245>] ip_flush_pending_frames+0x4d/0x5c
[  602.894005]  [<ffffffff81370c1f>] raw_sendmsg+0x653/0x709
[  602.894005]  [<ffffffff81379e31>] inet_sendmsg+0x54/0x5d
[  602.894005]  [<ffffffff813207a2>] ? sock_recvmsg+0xc6/0xdf
[  602.894005]  [<ffffffff813208c1>] sock_sendmsg+0xc0/0xd9
[  602.894005]  [<ffffffff810e13b4>] ? might_fault+0x68/0xb8
[  602.894005]  [<ffffffff810e13fd>] ? might_fault+0xb1/0xb8
[  602.894005]  [<ffffffff8132a1c3>] ? copy_from_user+0x2f/0x31
[  602.894005]  [<ffffffff8132a5b3>] ? verify_iovec+0x54/0x91
[  602.894005]  [<ffffffff81320d41>] sys_sendmsg+0x1da/0x241
[  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
[  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
[  602.894005]  [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150
[  602.894005]  [<ffffffff813ba27d>] ? _raw_spin_unlock_irq+0x56/0x63
[  602.894005]  [<ffffffff8103d3cb>] ? finish_task_switch+0xa4/0xc9
[  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
[  602.894005]  [<ffffffff810357fe>] ? need_resched+0x23/0x2d
[  602.894005]  [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150
[  602.894005]  [<ffffffff813b9750>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[  602.894005]  [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
[  602.894005] ---[ end trace 91ba2d8dc7826839 ]---

[2] lockdep warning
[  169.363215] ======================================================
[  169.365390] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
[  169.366334] 2.6.34-rc3-wl #20
[  169.366872] ------------------------------------------------------
[  169.366872] khubd/78 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[  169.366872]  (clock-AF_INET){++.?..}, at: [<ffffffff81323f51>] sock_def_write_space+0x1e/0x89
[  169.366872]
[  169.366872] and this task is already holding:
[  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...}, at: [<ffffffffa03715b0>] hif_usb_stop+0x24/0x53 [ath9k_htc]
[  169.366872] which would create a new lock dependency:
[  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...} -> (clock-AF_INET){++.?..}
[  169.366872]
[  169.366872] but this new dependency connects a HARDIRQ-irq-safe lock:
[  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...}
[  169.366872] ... which became HARDIRQ-irq-safe at:
[  169.366872]   [<ffffffff810772d5>] __lock_acquire+0x2c6/0xd2b
[  169.366872]   [<ffffffff8107866d>] lock_acquire+0xec/0x119
[  169.366872]   [<ffffffff813b99bb>] _raw_spin_lock+0x40/0x73
[  169.366872]   [<ffffffffa037163d>] hif_usb_tx_cb+0x5e/0x154 [ath9k_htc]
[  169.366872]   [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
[  169.366872]   [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd]
[  169.366872]   [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd]
[  169.366872]   [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd]
[  169.366872]   [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
[  169.366872]   [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore]
[  169.366872]   [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f
[  169.366872]   [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2
[  169.366872]   [<ffffffff8100c4fb>] handle_irq+0x88/0x91
[  169.366872]   [<ffffffff8100baed>] do_IRQ+0x63/0xc9
[  169.366872]   [<ffffffff813ba993>] ret_from_intr+0x0/0x16
[  169.366872]   [<ffffffff8130f6ee>] cpuidle_idle_call+0xa7/0x115
[  169.366872]   [<ffffffff81008c4f>] cpu_idle+0x68/0xc4
[  169.366872]   [<ffffffff813a41e0>] rest_init+0x104/0x10b
[  169.366872]   [<ffffffff81899db3>] start_kernel+0x3f1/0x3fc
[  169.366872]   [<ffffffff818992c8>] x86_64_start_reservations+0xb3/0xb7
[  169.366872]   [<ffffffff818993c4>] x86_64_start_kernel+0xf8/0x107
[  169.366872]
[  169.366872] to a HARDIRQ-irq-unsafe lock:
[  169.366872]  (clock-AF_INET){++.?..}
[  169.366872] ... which became HARDIRQ-irq-unsafe at:
[  169.366872] ...  [<ffffffff81077349>] __lock_acquire+0x33a/0xd2b
[  169.366872]   [<ffffffff8107866d>] lock_acquire+0xec/0x119
[  169.366872]   [<ffffffff813b9d07>] _raw_write_lock_bh+0x45/0x7a
[  169.366872]   [<ffffffff8135cf14>] tcp_close+0x165/0x34d
[  169.366872]   [<ffffffff8137aced>] inet_release+0x55/0x5c
[  169.366872]   [<ffffffff81321350>] sock_release+0x1f/0x6e
[  169.366872]   [<ffffffff813213c6>] sock_close+0x27/0x2b
[  169.366872]   [<ffffffff8110dd45>] __fput+0x125/0x1ca
[  169.366872]   [<ffffffff8110de04>] fput+0x1a/0x1c
[  169.366872]   [<ffffffff8110adc9>] filp_close+0x68/0x72
[  169.366872]   [<ffffffff8110ae80>] sys_close+0xad/0xe7
[  169.366872]   [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b

(Trimmed at the "other info that might help us debug this" line in
the interest of brevity... -- JWL)
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Acked-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In ath9k-htc register out path, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.

This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In ath9k-htc register in path, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.

This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In ath9k_hif_usb_alloc_rx_urbs, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.

This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skbs allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Don't modify ah->iniModes, it's supposed to be constant.  Instead, apply
the fixup when the data is written to the registers.

Change ath9k_hw_init_eeprom_fix() to only determine whether the fixup is
needed.

This allows similteneous support for AR9220 cards that need AR_AN_TOP2
fixup (such as Ubiquiti SR71-12) and those that don't need it (D-Link
DWA-552 rev A2).
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Messages that are generated by the HTC layer
don't have any TX callback endpoints assigned to them.
Consequently, the allocated SKBs are never freed.

Fix this issue by handling this case in the HTC layer
itself.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

hif_usb_regout_cb() frees the given URB, which is
borked by design. Use an anchor to simplify URB
management.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The maximum number of packets in a single buffer in
stream mode is 10. The driver currently uses 8 - which
caused stack corruption, in the absence of any kind
of OOB checking.

Fixing this to the correct value of 10 fixes the module
unload issue.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Tested-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

RX URBs are automatically freed when the reference
count drops to zero - this currently doesn't happen when
usb_kill_anchored_urbs() is called during unload.

Fix this by dropping the reference count by one during
initial submission.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use a spin lock to prevent concurrent access
to variables dealing with RX stream mode handling.
Currently, no protection is implemented - which
causes problems in RX.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFrans Pop <elendil@planet.nl>
Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds support for a modified newer version of AR9285
chipsets.
Signed-off-by: NVivek Natarajan <vnatarajan@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>

For USB devices, this check is invalid.
Remove the check so that new product IDs can be added.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This can be used to store the bus types ( AHB/PCI/USB ).
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

commits 8e6f5aa2 and
db1a052b accidentally introduced
compile errors that happens when ath9k debug is not enabled.
This patch fixes the declaration of the inline stubs to resolve this.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ah->mask_reg was used to hold different data throughout the driver.
ath9k_hw_init_interrupt_masks() used it to save the value written to
AR_IMR.  ath9k_hw_set_interrupts() used it to hold the interrupt mask as
defined in enum ath9k_int.  Those masks differ in many bits.

Use ah->imask instead of ah->mask_reg in ath9k_hw_set_interrupts() and
ath9k_hw_updatetxtriglevel().  That's what the code was meant to do.
ah->imask is initialized in ath9k_start(), so we don't need to
initialize it from ah->mask_reg.

Once it's done, ah->mask_reg becomes write-only, so it's replaced with a
local variable in ath9k_hw_init_interrupt_masks().
Signed-off-by: NPavel Roskin <proski@gnu.org>
Reported-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add ah variable in the functions that didn't have it and used sc->imask.
Replace sc->sc_ah with ah in those functions.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>