Commit Graph

1688 Commits

Author SHA1 Message Date
Adrian Chadd
94a88508a5 [ath] listen to all beacons in IBSS and software beacon miss.
I added MYBEACON support a while ago to listen to beacons that are only
for your configured BSSID.  For AR9380 and later NICs this results in
a lot less chip wakeups in station mode as it then only shows you beacons
that are destined to you.

However in IBSS mode you really do want to hear all beacons so you can do
IBSS merges.  Oops.

So only use MYBEACON for STA + not-scanning, and just use BEACON for
the other modes it used to use BEACON for.

This doesn't completely fix IBSS merges though - there are still some
conditions to chase down and fix.
2015-11-25 18:24:49 +00:00
Adrian Chadd
b45de1ebcd [ath] migrate ioctl and busdma memory operations out into separate source files.
This should be a big no-op pass; and reduces the size of if_ath.c.

I'm hopefully soon going to take a whack at the USB support for ath(4)
and this'll require some reuse of the busdma memory code.
2015-11-24 03:42:58 +00:00
Renato Botelho
1ce017241b Fix kernel build, broken in r290612
Approved by:	adrian
2015-11-09 20:22:59 +00:00
Adrian Chadd
f50e4ebf6a ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.
Right now the only way to force a cold reset is:

* The HAL itself detects it's needed, or
* The sysctl, setting all resets to be cold.

Trouble is, cold resets take quite a bit longer than warm resets.

However, there are situations where a cold reset would be nice.
Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results,
etc.

The vendor HAL has a separate method to set the reset reason (which is
how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path
why it occured.  This is almost but not quite the same; I may eventually
unify both approaches in the future.

This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC)
and type (eg do COLD.)  None of the HAL code uses it yet though;  that'll
come later.

It also is a big no-op in each HAL - I need to go teach each of the HALs
about cold/warm reset through this path.
2015-11-09 15:59:42 +00:00
Adrian Chadd
dccb3981eb ath(4) - reflect whether this is a full or fast channel change.
It's no longer "outdoor."
2015-11-07 00:51:51 +00:00
Adrian Chadd
da4552abb0 ath(4) - don't try to free buffers / return an error if we've committed
to transmit the buffer.

ath_tx_start() may manipulate/reallocate the mbuf as part of the DMA
code, so we can't expect the mbuf can be returned back to the caller.
Now, the net80211 ifnet work changed the semantics slightly so
if an error is returned here, the mbuf/reference is freed by the
caller (here, it's net80211.)

So, once we reach ath_tx_start(), we never return failure.  If we fail
then we still return OK and we free the mbuf/noderef ourselves, and
we increment OERRORS.
2015-11-03 21:11:30 +00:00
Adrian Chadd
d957a93abe net80211: move ieee80211_free_node() call on error from ic_raw_xmit() to ieee80211_raw_output().
This doesn't free the mbuf upon error; the driver ic_raw_xmit method is still
doing that.

Submitted by:	<s3erios@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D3774
2015-10-12 04:55:20 +00:00
Adrian Chadd
d07be335a0 net80211: separate mbuf cleanup from ieee80211_fragment()
* Create ieee80211_free_mbuf() which frees a list of mbufs.
* Use it in the fragment transmit path and ath / uath transmit paths.
* Call it in xmit_pkt() if the transmission fails; otherwise fragments
  may be leaked.

This should be a big no-op.

Submitted by:	<s3erios@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D3769
2015-10-12 03:27:08 +00:00
Adrian Chadd
dc809fc15f Flip on fast frames support for AR5416 and AR9300 series NICs.
This was off because the net80211 aggregation code was using the same
state pointers for both fast frames and ampdu tx support which led to some
pretty unfortunate panic-y behaviour.

Now that net80211 doesn't panic, let's flip this back on.

It doesn't (yet) do the horrific sounding thing of A-MPDU aggregates
of fast frames; that'll come next.  It's a pre-requisite to supporting
AMSDU + AMPDU anyway, which actually speeds things up quite considerably
(think packing lots of little ACK frames into a single AMSDU.)

Tested:

* QCA955x SoC, AP mode
* AR5416, STA mode
* AR9170, STA mode (with local fast frame patches)
2015-10-10 00:13:45 +00:00
Kevin Lo
8aabf601d1 Remove the unnecessary cast. 2015-10-05 05:24:16 +00:00
Adrian Chadd
210ab3c258 net80211: drop ieee80211_beacon_offsets parameter from ieee80211_beacon_alloc() and ieee80211_beacon_update()
Submitted by:	<s3erios@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D3659
2015-10-03 22:12:25 +00:00
Adrian Chadd
bc813c40bf net80211: drop redundant 3rd parameter from iv_key_set().
The MAC can be fetched from the key struct.

I added the ndis updates to make it compile.

Submitted by:	<s3erios@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D3657
2015-10-03 21:48:27 +00:00
Adrian Chadd
b94ab33751 Remove the references to the TX IC lock - i ended up solving this
using net80211 to seralise encap+xmit, so now it's a non-issue.
2015-09-29 03:37:17 +00:00
Adrian Chadd
0cf00015be net80211: include one copy of struct ieee80211_beacon_offsets into ieee80211vap
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D3658
2015-09-22 06:34:07 +00:00
Adrian Chadd
d6166def28 net80211 & wireless drivers: remove duplicate defines (noop)
* IEEE80211_DIR_DSTODS(wh) -> IEEE80211_IS_DSTODS(wh).
* N(a) -> nitems(a).
* Remove LE_READ_2(p)/LE_READ_4(p) definitions (and include ieee80211_input.h instead).
* <drvname>_TXOP_TO_US(txop) -> IEEE80211_TXOP_TO_US(txop).
* Put IEEE80211_RV(v) into ieee80211_proto.h and remove local RV(v) definitions.

Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D3705
2015-09-22 02:44:59 +00:00
Gleb Smirnoff
7a79cebfba Replay r286410. Change KPI of how device drivers that provide wireless
connectivity interact with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
  the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
  driver about any changes: number of wlan(4) interfaces, number of them
  in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
  driver experiences errors and can not attribute them to any specific
  interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
  now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann,
Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in
testing.

Reviewed by:	adrian
Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-08-27 08:56:39 +00:00
Adrian Chadd
3797bf0896 Remove most of the references of ifp->if_softc and replace with
references to ic->ic_softc.

This is in preparation for gleb's ifnet work.

Tested:

* ath(4), STA mode
* ath(4), hostap mode
* make universe
2015-08-17 02:04:11 +00:00
Adrian Chadd
ba2c1fbc03 Revert the wifi ifnet changes until things are more baked and tested.
* 286410
* 286413
* 286416

The initial commit broke a variety of debug and features that aren't
in the GENERIC kernels but are enabled in other platforms.
2015-08-08 01:10:17 +00:00
Gleb Smirnoff
79d2c5e857 Change KPI of how device drivers that provide wireless connectivity interact
with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
  the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
  driver about any changes: number of wlan(4) interfaces, number of them
  in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
  driver experiences errors and can not attribute them to any specific
  interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
  now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:

https://wiki.freebsd.org/projects/ifnet/net80211

Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.

Differential Revision:	D2655, D2740
Sponsored by:	Nginx, Inc.
Sponsored by:	Netflix
2015-08-07 11:43:14 +00:00
Adrian Chadd
70c81b2077 Add a hack-around to this fatal taskqueue running whilst the NIC
is detaching.

This mostly fixes a panic - the reset path shouldn't run whilst
the NIC is being torn down.

It's not locked, so it's "mostly" ok, but most of the rest of
the driver doesn't read sc->invalid with sensible locking. Grr.

The real solution is to cleanly tear down taskqueues in the detach/suspend
phase, but ..
2015-08-05 21:22:25 +00:00
Adrian Chadd
35aae619d7 Call the WMAC DDR flush before handling an interrupt for the
Atheros AHB (internally) connected MAC.

TODO:

* verify the interrupt was for us before doing the DDR flush.
2015-07-04 03:07:28 +00:00
Adrian Chadd
52f5515397 Wake up the hardware before doing anything in sysctl.
This stops the panics that occur on MIPS platforms when doing say,
'sysctl dev.ath.0' whilst the MAC is asleep.  The MIPS platform is
rather unforgiving in getting power-save register access wrong and you
will get all kinds of odd failures if you don't have things woken
up at the right times.

Tested:

* QCA9558 (TP-Link Archer C7 v2)
* AR9331 (Carambola 2)

.. with no VAPs configured and ath0 down (thus the MAC is definitely
   asleep.)

PR:		kern/201117
2015-07-04 02:59:30 +00:00
Gleb Smirnoff
76e6fd5d6c Use device_printf() instead of if_printf(). No functional changes. 2015-05-29 14:35:16 +00:00
Gleb Smirnoff
272f6ade9b Change three methods in struct ieee80211com, namely ic_updateslot,
ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com,
not to the ifnet.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 19:53:29 +00:00
Gleb Smirnoff
59686fe935 Set ic_softc in all 802.11 drivers. Not required right now, but will be
used quite soon.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 18:50:26 +00:00
Adrian Chadd
c79f192c09 Begin plumbing ieee80211_rx_stats through the receive path.
Smart NICs with firmware (eg wpi, iwn, the new atheros parts, the intel 7260
series, etc) support doing a lot of things in firmware.  This includes but
isn't limited to things like scanning, sending probe requests and receiving
probe responses.  However, net80211 doesn't know about any of this - it still
drives the whole scan/probe infrastructure itself.

In order to move towards suppoting smart NICs, the receive path needs to
know about the channel/details for each received packet.  In at least
the iwn and 7260 firmware (and I believe wpi, but I haven't tried it yet)
it will do the scanning, power-save and off-channel buffering for you -
all you need to do is handle receiving beacons and probe responses on
channels that aren't what you're currently on.  However the whole receive
path is peppered with ic->ic_curchan and manual scan/powersave handling.
The beacon parsing code also checks ic->ic_curchan to determine if the
received beacon is on the correct channel or not.[1]

So:

* add freq/ieee values to ieee80211_rx_stats;
* change ieee80211_parse_beacon() to accept the 'current' channel
  as an argument;
* modify the iv_input() and iv_recv_mgmt() methods to include the rx_stats;
* add a new method - ieee80211_lookup_channel_rxstats() - that looks up
  a channel based on the contents of ieee80211_rx_stats;
* if it exists, use it in the mgmt path to switch the current channel
  (which still defaults to ic->ic_curchan) over to something determined
  by rx_stats.

This is enough to kick-start scan offload support in the Intel 7260
driver that Rui/I are working on.  It also is a good start for scan
offload support for a handful of existing NICs (wpi, iwn, some USB
parts) and it'll very likely dramatically improve stability/performance
there.  It's not the whole thing - notably, we don't need to do powersave,
we should not scan all channels, and we should leave probe request sending
to the firmware and not do it ourselves.  But, this allows for continued
development on the above features whilst actually having a somewhat
working NIC.

TODO:

* Finish tidying up how the net80211 input path works.
  Right now ieee80211_input / ieee80211_input_all act as the top-level
  that everything feeds into; it should change so the MIMO input routines
  are those and the legacy routines are phased out.

* The band selection should be done by the driver, not by the net80211
  layer.

* ieee80211_lookup_channel_rxstats() only determines 11b or 11g channels
  for now - this is enough for scanning, but not 100% true in all cases.
  If we ever need to handle off-channel scan support for things like
  static-40MHz or static-80MHz, or turbo-G, or half/quarter rates,
  then we should extend this.

[1] This is a side effect of frequency-hopping and CCK modes - you
    can receive beacons when you think you're on a different channel.
    In particular, CCK (which is used by the low 11b rates, eg beacons!)
    is decodable from adjacent channels - just at a low SNR.
    FH is a side effect of having the hardware/firmware do the frequency
    hopping - it may pick up beacons transmitted from other FH networks
    that are in a different phase of hopping frequencies.
2015-05-25 16:37:41 +00:00
Gleb Smirnoff
c8550c0278 Make net80211 drivers supply their device name to the net80211 layer, so
that the latter doesn't need to go through struct ifnet to get their name.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 13:51:13 +00:00
Jung-uk Kim
fd90e2ed54 CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten
years for head.  However, it is continuously misused as the mpsafe argument
for callout_init(9).  Deprecate the flag and clean up callout_init() calls
to make them more consistent.

Differential Revision:	https://reviews.freebsd.org/D2613
Reviewed by:	jhb
MFC after:	2 weeks
2015-05-22 17:05:21 +00:00
Adrian Chadd
03ab093569 Return the correct HAL data type for HAL_DIAG_ANI_STATS.
I .. stupidly added code to return HAL_ANI_STATS to HAL_DIAG_ANI_STATS.
I discovered this in a noisy environment when the returned values were
enough to .. well, make everything terrible.

So - restore functionality.

Tested:

* AR5416 (uses the AR5212 HAL), in a /very/ noisy 2GHz environment.
  Enough to trigger ANI to get upset and generate useful data.
2015-04-06 01:12:53 +00:00
Adrian Chadd
b3ab2271b9 Use the HAL API for returning ar5212AniState, rather than just dumping
AniState itself.
2015-04-01 04:56:22 +00:00
Adrian Chadd
a9e86008ae Start the process of migrating the ANI statistics out of the HALs and into
the top-level HAL.

The athstats program is blindly using a copy of the ar5212 ANI stats structure
to pull out ANI statistics/state and this is problematic for the AR9300
HAL.

So:

* Define HAL_ANI_STATS and HAL_ANI_STATE
* Use HAL_ANI_STATS inside the AR5212 HAL

This commit doesn't (yet) convert the ar5212AniState -> HAL_ANI_STATE when
exporting it to userland; that'll come in the next commit.
2015-04-01 03:42:46 +00:00
Adrian Chadd
b0602bec18 Move the HAL channel survey support out to be in the top-level HAL,
rathe than private in each HAL module.

Whilst here, modify ath_hal_private to always have the per-channel
noisefloor stats, rather than conditionally.  This just makes
life easier in general (no strange ABI differences between different
HAL compile options.)

Add a couple of methods (clear/reset, add) rather than using
hand-rolled versions of things.
2015-03-29 21:50:21 +00:00
Adrian Chadd
5f63869372 Add a new field to HAL_ANISTATS - the extension channel busy count.
This is only used by the AR9300 HAL for now - but just be careful if
you decide to recompile the kernel with NO_CLEAN=1.
2015-03-29 21:45:48 +00:00
Adrian Chadd
9bbfde1eb9 Fix more ticks wrapping bugs exposed by the ticks wrapping bug check.
This symptom is "calibrations don't ever run", which may cause some
pretty spectacularly bad behaviour in noisy environments or with longer
uptimes.

Thanks to dtrace to make it easy to check if specific non-inlined functions
are getting called by things like the ANI and calibration HAL methods.
Grr.

Tested:

* AR9380, STA mode
2015-03-29 21:41:05 +00:00
Adrian Chadd
9cecaef7d6 Fix a long-standing bug with the early MAC address initialisation path,
which showed up after I started changing addresses this early.

It turns out that there's some other malarky going on behind the scenes
in the HAL and merely setting the net80211/ifp mac address this early
isn't enough.  If the MAC is set from kenv at attach time, the HAL
also needs to be programmed early.

Without this, the VAP wouldn't work enough for finishing association -
probe requests would be fine as they're broadcast, but association
request would fail.
2015-03-29 06:05:00 +00:00
Adrian Chadd
240b1f1dca Update if_ath(4) to check for "hint.ath.X.macaddr" for an override MAC address.
This is used by the AR71xx platform code to choose a local MAC based on
the "board MAC address", versus whatever potentially invalid/garbage
values are stored in the Atheros calibration data.
2015-03-28 23:41:23 +00:00
Adrian Chadd
0d327de13d Lay some groundwork for having this stuff hang off of AHB rather than
the CPU nexus.

* Add ahb as a possible bus attachment
* Lay a comment down to remind me or whoever else ends up trying
  to debug why the EEPROM isn't mapped in as to what's going on.
2015-03-02 02:14:44 +00:00
Adrian Chadd
35a32b0476 Move the lock destruction/creation to earlier in the process - if
interrupts are enabled and the NIC is awake (think: loading a module)
then there's a not-quite-zero window where we'll get an interrupt
for the device before the attach method is called to finish setting
up the hardware.

Since I grab locks in ath_intr() to check various things, the locks
need to be ready much earlier.
2015-02-14 18:14:45 +00:00
Adrian Chadd
d5d2dbef65 Cast everything to something longer than 32 bits so the sample mask
doesn't get truncated to 32 bits.

Without this, 3x3 NICs transmitting at an MCS rate whose rix (rate
index) in the rate table is > 31 end up returning errors, as the
sample rate code doesn't think the rate is set in the rate table.

Tested:

* AR9380, STA, speaking 3x3 to an AP
2015-01-28 04:44:42 +00:00
Adrian Chadd
06c746edad Print out the final_rix if there's a problem. 2015-01-28 04:42:40 +00:00
Adrian Chadd
99f46e36f1 Add a new HAL capability - required to compile the updated AR9300
HAL i have lying about.
2015-01-28 04:02:56 +00:00
Adrian Chadd
30696562d3 Oops; correctly reload the CCA registers with the uncapped value
in prep for the next NF calibration pass.

Totally missing braces.  Damn you C.

Submitted by:	Sascha Wildner <swildner@dragonflybsd.org>
MFC after:	1 week
2015-01-17 07:33:02 +00:00
Adrian Chadd
e21928d3c3 Until there's a full MCI implementation - just implement a placeholder
MCI bluetooth coexistence method for WB222.

The rest of MCI requires a bunch more work, including adding a DMA buffer
for the MCI hardware to bounce messages in/out of and handling MCI
interrupts.  But the more important part here is telling the HAL
the btcoex is enabled and MCI is in use so it configures the correct
initial bluetooth parameters in the wireless NIC and configures
things like bluetooth traffic weights and such.

So, this at least gets the HAL to do some of the right things in
configuring the inital bluetooth coexistence stuff, but doesn't
actually do full btcoex.  That'll take.. some effort.

Tested:

* AR9462 (WB222), STA mode
2015-01-17 00:02:18 +00:00
Adrian Chadd
335b1a6beb Add bluetooth MCI coexistence HAL methods - used for AR9462 and AR9565 NICs.
It's found, amongst other things, in the Acer Chromebook (Intel)
devices.

Tested:

* AR9462 (WB222)

Obtained from:	Qualcomm Atheros
2015-01-16 23:47:42 +00:00
Adrian Chadd
3b48f36ef6 Check the right value correctly.
Thanks to clang for pointing out this silliness.
2015-01-16 01:52:26 +00:00
Adrian Chadd
70bd9518f1 Bump the valid GPIO range for rfkill up from 8 to 16.
AR5416 and later NICs have more than 8 (Well, more than 6) GPIO pins.
So to support rfkill on these NICs we need to bump this up or the
rfkill GPIO pin may get reset to the wrong value.

Noticed by: Anthony Jenkins <scoobi_doo@yahoo.com>
2014-12-23 18:48:45 +00:00
Dimitry Andric
d41b89cca5 Fix the following -Werror warning from clang 3.5.0, while building the
ath kernel module:

sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: error: taking the absolute value of unsigned type 'unsigned int' has no effect [-Werror,-Wabsolute-value]
                if (abs(lp[0] * EEP_SCALE - target) < EEP_DELTA) {
                    ^
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a)         __builtin_abs(_a)
                        ^
sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: note: remove the call to '__builtin_abs' since unsigned values cannot be negative
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a)         __builtin_abs(_a)
                        ^
1 error generated.

This warning occurs because both lp[0] and target are unsigned, so the
subtraction expression is also unsigned, and calling abs() is a no-op.

However, the intention was to look at the absolute difference between
the two unsigned quantities.  Introduce a small static function to
clarify what we're doing, and call that instead.

Reviewed by:	adrian
MFC after:	3 days
Differential Revision: https://reviews.freebsd.org/D1212
2014-11-23 18:31:55 +00:00
Adrian Chadd
adcdc8f290 Convert the callouts back to using mutexes.
I did this wrong - I should've included a state flag for each callout
to see if it was supposed to run or not.  I didn't do that.
Instead, just use mutexes anyway.

Suggested by: jhb
2014-11-15 01:18:49 +00:00
Adrian Chadd
7707f31dc5 Migrate the callouts from using mutex locks to being mpsafe with
the locks being held by the callers.

Kill callout_drain() and use callout_stop().
2014-11-14 04:26:26 +00:00
Adrian Chadd
1b65908ea7 Add a missing file from the last commit.
Noticed by: jhibbits
2014-09-30 05:50:34 +00:00
Adrian Chadd
9389d5a95e Add initial support for the AR9485 CUS198 / CUS230 variants.
These variants have a few differences from the default AR9485 NIC,
namely:

* a non-default antenna switch config;
* slightly different RX gain table setup;
* an external XLNA hooked up to a GPIO pin;
* (and not yet done) RSSI threshold differences when
  doing slow diversity.

To make this possible:

* Add the PCI device list from Linux ath9k, complete with vendor and
  sub-vendor IDs for various things to be enabled;
* .. and until FreeBSD learns about a PCI device list like this,
  write a search function inspired by the USB device enumeration code;
* add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this
  to initialise its local driver parameters upon attach;
* copy these parameters over in the AR9300 HAL;
* don't default to override the antenna switch - only do it for
  the chips that require it;
* I brought over ar9300_attenuation_apply() from ath9k which is cleaner
  and easier to read for this particular NIC.

This is a work in progress.  I'm worried that there's some post-AR9380
NIC out there which doesn't work without the antenna override set as
I currently haven't implemented bluetooth coexistence for the AR9380
and later HAL.  But I'd rather have this code in the tree and fix it
up before 11.0-RELEASE happens versus having a set of newer NICs
in laptops be effectively RX deaf.

Tested:

* AR9380 (STA)
* AR9485 CUS198 (STA)

Obtained from:	Qualcomm Atheros, Linux ath9k
2014-09-30 03:19:29 +00:00
Adrian Chadd
17bb5fd106 Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO.
The original code was .. well, slightly more than incorrect.

It showed up as stalled RX queues if the NIC needed to be frequently
reinitialised (eg during scans.)

This is inspired by work done by Matt Dillon over at the DragonflyBSD
project.

So:

* track when EDMA RX has been stopped and when the MAC has been reset;
* re-initialise the ring only after a reset;
* track whether RX has been stopped/started - just for debugging now;
* don't bother with the RX EOL stuff for EDMA - we don't need the
  interrupt at all.  We also don't need to disable/enable the interrupt
  or start DMA - once new frames are pushed into the ring via the
  normal RX path, it'll just restart RX DMA on its own.

Tested:

* AR9380, STA mode
* AR9380, AP mode
* AR9485, STA mode
* AR9462, STA mode
2014-09-20 01:22:17 +00:00
Gleb Smirnoff
2127b2e232 Mechanically convert to if_inc_counter(). 2014-09-18 20:47:39 +00:00
Adrian Chadd
062cf7d90a Shut down RX before TX - in theory, this should make the chip less likely
to get upset.

The Qualcomm Atheros reference design code goes through significant
hacks to shut down RX before TX.  It doesn't even try do do it in the
driver - it actually makes the DMA stop routines in the HAL shut down
RX before shutting down TX.

So, to make this work for chips that aren't the AR9380 and later, do
it in the driver.  Shuffle the TX stop/drain HAL calls to be called
*after* the RX stop HAL call.

Tested:

* AR5413 (STA)
* AR5212 (STA)
* AR5416 (STA)
* AR9380 (STA)
* AR9331 (AP)
* AR9341 (AP)

TODO:

* test ar92xx series NIC and the AR5210/AR5211, in case there's something
  even odder about those.
2014-08-23 18:55:51 +00:00
Adrian Chadd
fad86101e5 Bump the HAL_REGRANGE fields from 16 bit to 32 bit.
The AR9380 and later chips have a 128KiB register window, so the register
read diag api needs changing.

The tools are about to be updated as well.  No, they're not backwards
compatible.
2014-08-09 18:15:28 +00:00
Adrian Chadd
d77c4024e5 Add two new debug mark entries for chip power configuration. 2014-08-09 09:13:10 +00:00
Warner Losh
c737a387f5 an isn't used, so eliminate it. 2014-08-08 11:47:23 +00:00
Marcel Moolenaar
e7d939bda2 Remove ia64.
This includes:
o   All directories named *ia64*
o   All files named *ia64*
o   All ia64-specific code guarded by __ia64__
o   All ia64-specific makefile logic
o   Mention of ia64 in comments and documentation

This excludes:
o   Everything under contrib/
o   Everything under crypto/
o   sys/xen/interface
o   sys/sys/elf_common.h

Discussed at: BSDcan
2014-07-07 00:27:09 +00:00
Hans Petter Selasky
af3b2549c4 Pull in r267961 and r267973 again. Fix for issues reported will follow. 2014-06-28 03:56:17 +00:00
Glen Barber
37a107a407 Revert r267961, r267973:
These changes prevent sysctl(8) from returning proper output,
such as:

 1) no output from sysctl(8)
 2) erroneously returning ENOMEM with tools like truss(1)
    or uname(1)
 truss: can not get etype: Cannot allocate memory
2014-06-27 22:05:21 +00:00
Hans Petter Selasky
3da1cf1e88 Extend the meaning of the CTLFLAG_TUN flag to automatically check if
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.

Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.

MFC after:	2 weeks
Sponsored by:	Mellanox Technologies
2014-06-27 16:33:43 +00:00
Adrian Chadd
e3665aee04 Add casts to have it compile on amd64 without complaining about
mismatched types.

Tested:

* AR9280, TDMA slave, amd64.
2014-05-07 19:07:45 +00:00
Adrian Chadd
add58488d2 There's no need to be this paranoid - ni is deferenced before this
point.

Coverity ID:	 CID 1211937
2014-05-07 07:57:50 +00:00
Adrian Chadd
67aaf73997 Modify the RX path to keep the previous RX descriptor around once it's
used.

It turns out that the RX DMA engine does the same last-descriptor-link-
pointer-re-reading trick that the TX DMA engine.  That is, the hardware
re-reads the link pointer before it moves onto the next descriptor.
Thus we can't free a descriptor before we move on; it's possible the
hardware will need to re-read the link pointer before we overwrite
it with a new one.

Tested:

* AR5416, STA mode

TODO:

* more thorough AP and STA mode testing!
* test on other pre-AR9380 NICs, just to be sure.
* Break out the RX descriptor grabbing bits from the RX completion
  bits, like what is done in the RX EDMA code, so ..
* .. the RX lock can be held during ath_rx_proc(), but not across
  packet input.
2014-05-06 01:15:42 +00:00
Adrian Chadd
4b734a1c84 Wake up the hardware before calling ath_mode_init() in the ioctl() path.
Tested:

* AR5416, STA + powersave
2014-05-05 17:06:40 +00:00
Adrian Chadd
e5bd159ed5 Break out the multicast programming into its own hardware specific
call, which assumes the hardware is awake.

Turn ath_update_mcast() into a routine that's only called from the
net80211 layer - and it forces the hardware awake first.

This fixes a LOR from the EDMA RX path which calls ath_mode_init()
with the RX lock held - the driver lock can't also be grabbed.
This path assumes that the ath_mode_init() callers all wake up
the NIC first.

Tested:

* AR9485, STA mode, powersave
2014-05-05 08:12:21 +00:00
Adrian Chadd
516a0ac28b Quieten the RX/TX descriptor and FIFO setup debugging.
Tested:

* AR9485, STA mode
2014-05-05 08:00:50 +00:00
Adrian Chadd
9a4cf01f45 Add Atheros AR1111 support to the HAL.
This seems to probe/attach as an AR9485 and thus nothing else besides
adding the device id seems to be required.

ath0: <Atheros AR1111> mem 0xf4800000-0xf487ffff irq 19 at device 0.0 on pci5
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 RX streams; 1 TX streams
ath0: AR9485 mac 576.1 RF5110 phy 1926.8
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000

The NIC I have here is a 1 antenna, 2GHz only device.

Thankyou to Jim Thompson <jim@netgate.com> for the AR1111 NIC.

Tested:

* AR1111 (pretending not to be an AR9485, but failing miserably);
  STA mode with powersave.

Relnotes:	yes
Sponsored by:	Netgate
2014-05-05 07:58:05 +00:00
Adrian Chadd
7d567ed66f Add tracking for self-generated frames when the VAP is in sleep state.
The hardware can generate its own frames (eg RTS/CTS exchanges, other
kinds of 802.11 management stuff, especially when it comes to 802.11n)
and these also have PWRMGT flags.  So if the VAP is asleep but the
NIC is in force-awake for some reason, ensure that the self-generated
frames have PWRMGT set to 1.

Now, this (like basically everything to do with powersave) is still
racy - the only way to guarantee that it's all actually consistent
is to pause transmit and let it finish before transitioning the VAP
to sleep, but this at least gets the basic method of tracking and
updating the state debugged.

Tested:

* AR5416, STA mode
* AR9380, STA mode
2014-05-02 00:48:09 +00:00
Adrian Chadd
8cc3f9c9e1 * Modify the beacon interval in debugging to be ni_intval, not 102400
* Be paranoid about avoiding divide-by-zero.

Tested:

* AR9380, STA mode
2014-04-30 02:44:07 +00:00
Adrian Chadd
f5c30c4e8d Bring over some initial power save management support, reset path
fixes and beacon programming / debugging into the ath(4) driver.

The basic power save tracking:

* Add some new code to track the current desired powersave state; and
* Add some reference count tracking so we know when the NIC is awake; then
* Add code in all the points where we're about to touch the hardware and
  push it to force-wake.

Then, how things are moved into power save:

* Only move into network-sleep during a RUN->SLEEP transition;
* Force wake the hardware up everywhere that we're about to touch
  the hardware.

The net80211 stack takes care of doing RUN<->SLEEP<->(other) state
transitions so we don't have to do it in the driver.

Next, when to wake things up:

* In short - everywhere we touch the hardware.
* The hardware will take care of staying awake if things are queued
  in the transmit queue(s); it'll then transit down to sleep if
  there's nothing left.  This way we don't have to track the
  software / hardware transmit queue(s) and keep the hardware
  awake for those.

Then, some transmit path fixes that aren't related but useful:

* Force EAPOL frames to go out at the lowest rate.  This improves
  reliability during the encryption handshake after 802.11
  negotiation.

Next, some reset path fixes!

* Fix the overlap between reset and transmit pause so we don't
  transmit frames during a reset.
* Some noisy environments will end up taking a lot longer to reset
  than normal, so extend the reset period and drop the raise the
  reset interval to be more realistic and give the hardware some
  time to finish calibration.
* Skip calibration during the reset path.  Tsk!

Then, beacon fixes in station mode!

* Add a _lot_ more debugging in the station beacon reset path.
  This is all quite fluid right now.
* Modify the STA beacon programming code to try and take
  the TU gap between desired TSF and the target TU into
  account.  (Lifted from QCA.)

Tested:

* AR5210
* AR5211
* AR5212
* AR5413
* AR5416
* AR9280
* AR9285

TODO:

* More AP, IBSS, mesh, TDMA testing
* Thorough AR9380 and later testing!
* AR9160 and AR9287 testing

Obtained from:	QCA
2014-04-30 02:19:41 +00:00
Adrian Chadd
ce3f9a8950 * Only update ah_powerMode if we're setting the chip sleep state.
Some code will appear soon that is actually setting the chip powerstate
  separate from the self-generated frames power state.
* Allow the AR5416 family chips to actually have the power state changed
  from the self generated state change.

Tested (STA mode):

* AR5210
* AR5211
* AR5412
* AR5413
* AR5416
* AR9285
2014-04-30 02:03:13 +00:00
Adrian Chadd
a4e6347b86 Note that the AR5416 and later hardware supports the MYBEACON RX filter. 2014-04-27 23:37:03 +00:00
Adrian Chadd
dd7b232e39 * Add a new capability which returns whether the hardware supports
the MYBEACON RX filter (only receive beacons which match the BSSID)
  or all beacons on the current channel.

* Add the relevant RX filter entry for MYBEACON.

Tested:

* AR5416, STA
* AR9285, STA

TODO:

* once the code is in -HEAD, just make sure that the code which uses it
  correctly sets BEACON for pre-AR5416 chips.

Obtained from:	QCA, Linux ath9k
2014-04-27 23:36:44 +00:00
Adrian Chadd
ee6325ab56 Program the AR_TSFOOR_THRESHOLD register with a default lifted from
the QCA HAL.

This fires off an interrupt if the TSF from the AP / IBSS peer is
wildly out of range.  I'll add some code to the ath(4) driver soon
which makes use of this.

TODO:

* verify this didn't break TDMA!
2014-04-27 23:35:05 +00:00
Adrian Chadd
3e9b8fe01b Fix the AR_SLEEP1 and AR_SLEEP2 definitions. Oops!
Tested:

* AR9285, STA
* AR5416, STA

Obtained from:	QCA, Linux ath9k
2014-04-27 23:33:37 +00:00
Adrian Chadd
552c550628 Do a read-after-write to ensure the interrupt register update is flushed
to the hardware.

The QCA HAL has a comment noting that if this isn't done, modifications
to AR_IMR_S2 before AR_IMR is flushed may produce spurious interrupts.

Obtained from:	QCA
2014-04-27 23:31:42 +00:00
Adrian Chadd
db23679569 Fix the AR5211 power mode tracking stuff.
Tested:

* AR5211, STA mode
2014-04-24 23:11:36 +00:00
Adrian Chadd
9b34359b11 Fix the AR5210 HAL code to store the association ID and restore it
upon reset.

Tested:

* AR5210, STA mode
2014-04-24 23:11:18 +00:00
Adrian Chadd
151e9d2bb6 Fix ah_powerMode to be set at the correct place for the AR5210.
Tested:

* AR5210, STA mode
2014-04-24 23:10:24 +00:00
Adrian Chadd
656380e725 Wrap the rate control re-init code in a lock, to serialise it with
concurrent updates from any completing transmits in other threads.

This was exposed when doing power save work - net80211 is constantly
doing reassociations and it's causing the rate control state to get
blanked out.  This could cause the rate control code to assert.

This should be MFCed to stable/10 as it's a stability fix.

Tested:

* AR5416, STA

MFC after:	7 days
2014-04-23 05:19:45 +00:00
Adrian Chadd
f172ef758e Rewrite the cleanup code to, well, actually work right.
The existing cleanup code was based on the Atheros reference driver
from way back and stuff that was in Linux ath9k.  It turned out to be ..
rather silly.

Specifically:

* The whole method of determining whether there's hardware-queued frames
  was fragile and the BAW would never quite work right afterwards.

* The cleanup path wouldn't correctly pull apart aggregate frames in the
  queue, so frames would not be freed and the BAW wouldn't be correctly
  updated.

So to implement this:

* Pull the aggregate frames apart correctly and handle each separately;
* Make the atid->incomp counter just track the number of hardware queued
  frames rather than try to figure it out from the BAW;
* Modify the aggregate completion path to handle it as a single frame
  (atid->incomp tracks the one frame now, not the subframes) and
  remove the frames from the BAW before completing them as normal frames;
* Make sure bf->bf_next is NULled out correctly;
* Make both aggregate session and non-aggregate path frames now be
  handled via the incompletion path.

TODO:

* kill atid->incomp; the driver tracks the hardware queued frames
  for each TID and so we can just use that.

This is a stability fix that should be merged back to stable/10.

Tested:

* AR5416, STA

MFC after:	7 days
2014-04-21 06:07:08 +00:00
Adrian Chadd
1771c64935 * Modify the debugging output from pause/resume to note the TID and STA
MAC
* Now that the paused < 0 bugs have been identified, make the DPRINTF()
  a device_printf() again.  Anything else that shows up here needs to be
  fixed immediately.

Tested:

* AR5416, STA mode

MFC after:	7 days
2014-04-21 02:09:14 +00:00
Adrian Chadd
706bb44485 Make sure bf_next is NULL'ed out when we're completing up an aggregate
frame through the cleanup path.

Whilst here, fix the indenting for something I messed up.

Tested:

* AR5416, STA mode
2014-04-21 02:05:51 +00:00
Adrian Chadd
59fbb5304d Fix a cleanup hang if cleanup gets called _during_ an active cleanup.
During power save testing I noticed that the cleanup code is being
called during a RUN->RUN state transition.  It's because the net80211
stack is treating that (for reasons I don't quitey know yet) as a
reassociation and this calls the node cleanup code.  The reason it's
seeing a RUN->RUN transition is because during active power save
stuff it's possible that the RUN->SLEEP and SLEEP->RUN transitions
happen so quickly that the deferred net80211 vap state code
"loses" a transition, namely the intermediary SLEEP transition.

So, this was causing the node reassociation code to sometimes be called
twice in quick succession and this would result in ath_tx_tid_cleanup()
to be called again.  The code calling it would always call pause, and
then only call resume if the TID didn't have "cleanup_inprogress" set.
Unfortunately it didn't check if it was already set on entry, so it
would pause but not call resume.  Thus, paused would be called more
than once (once before each entry into ath-tx_tid_cleanup()) but resume
would only be called once when the cleanup state was finished.

This doesn't entirely fix all of the issues seen in the cleanup path
but it's a necessary first step.

Since this is a stability fix, it should be merged to stable/10 at some
point.

Tested:

* AR5416, STA mode

MFC after:	7 days
2014-04-21 01:02:49 +00:00
Adrian Chadd
6ed22fae0a Add a function to check whether the given register can be accessed whilst
the chip is asleep.

It's AR5416 and later specific; I'll add a HAL method to generalise it
later.

Tested:

* AR5416, STA mode
2014-04-09 03:51:05 +00:00
Adrian Chadd
42fdd8e726 Add some debugging and forcing of the BAW to match what the current
tracked BAW actually is.

The net80211 code that completes a BAR will set tid->txa_start (the
BAW start) to whatever value was called when sending the BAR.
Now, in case there's bugs in my driver code that cause the BAW
to slip along, we should make sure that the new BAW we start
at is actually what we currently have it at, not what we've sent.

This totally breaks the specification and so this stays a printf().
If it happens then I need to know and fix it.

Whilst here, add some debugging updates:

* add TID logging to places where it's useful;
* use SEQNO().
2014-04-08 07:14:14 +00:00
Adrian Chadd
8ec9220e81 Don't do continue inside the scheduler loop; we really need to check
if we've hit the end of the list and cycled around to the first
node again.

Obtained from:	DragonflyBSD
2014-04-08 07:10:52 +00:00
Adrian Chadd
1f7373066f Correct the actual definition of ath_tx_tid_filt_comp_single() to
match how it's used.

This is another bug that led to aggregate traffic hanging because
the BAW tracking stopped being accurate.  In this instance, a filtered
frame that exceeded retries would return a non-error, which would
mean the caller would never remove it from the BAW.  But it wouldn't
be added to the filtered list, so it would be lost forever.  There'd
thus be a hole in the BAW that would never get transmitted and
this leads to a traffic hang.

Tested:

* Routerstation Pro, AR9220 AP
2014-04-08 07:08:59 +00:00
Adrian Chadd
c5d230ab42 Add a comment explaining the obvious. 2014-04-08 07:01:27 +00:00
Adrian Chadd
a3fd3b1429 Don't resume a TID on each filtered frame completion - only do it if
we did suspend it.

The whole suspend/resume TID queue thing is supposed to be a matched
reference count - a subsystem (eg addba negotiation, BAR transmission,
filtered frames, etc) is supposed to call pause() once and then resume()
once.

ath_tx_tid_filt_comp_complete() is called upon the completion of any
filtered frame, regardless of whether the driver had aleady seen
a filtered frame and called pause().

So only call resume() if tid->isfiltered = 1, which indicates that
we had called pause() once.

This fixes a seemingly whacked and different problem - traffic hangs.

What was actually going on:

* There'd be some marginal link with crappy behaviour, causing filtered
  frames and BAR TXing to occur;
* A BAR TX would occur, setting the new BAW (block-ack window) to seqno n;
* .. and pause() would be called, blocking further transmission;
* A filtered frame completion would occur from the hardware, but with
  tid->isfiltered = 0 which indiciates we haven't actually marked
  the queue yet as filtered;
* ath_tx_tid_filt_comp_complete() would call resume(), continuing
  transmission;
* Some frames would be queued to the hardware, since the TID is now no
  longer paused;
* .. and if some make it out and ACked successfully, the new BAW
  may be seqno n+1 or more;
* .. then the BAR TX completes and sets the new seqno back to n.

At this point the BAW tracking would be loopy because the BAW
start was modified but the BAW ring buffer wasn't updated in lock
step.

Tested:

* Routerstation Pro + AR9220 AP
2014-04-08 07:00:43 +00:00
Adrian Chadd
f857fb4fa3 Also set the AR5212 HAL power mode tracking in the right spot.
Tested:

* D-Link DWL-G650 NIC (AR2413), STA mode
2014-03-22 03:36:07 +00:00
Adrian Chadd
6fc621c22c Throw the flush messages behind ATH_DEBUG_RESET as well.
These are needed to diagnose TX hangs that I and hiren are seeing.
Without it, the only way we'll see debugging is by having ATH_DEBUG_SW_TX
enabled and that is going to be very, very spammy.

ATH_DEBUG_RESET is fine; it's only going to be done during stuck beacon
situations in AP mode.

Whilst I'm here, and now that it's behind debugging, let's just disable
the "print only one" conditional.  I'll eventually make it more tunable.

Tested:

* AR9220, hostap mode.
2014-03-20 23:16:58 +00:00
Adrian Chadd
517dfcb126 Add some debugging code to print out if registers are touched whilst the
device is asleep.

This doesn't avoid logging errors for things that are actually OK to
access whilst the chip is asleep (eg, the RTC registers (0x7000->0x70ff
on the AR5416 and later.)

But, this is a pretty good indicator if things are accessed incorrectly.

Tested:

* AR5416, STA
2014-03-20 05:10:17 +00:00
Adrian Chadd
bd369abaac Shuffle ah_powerMode to be in a sane spot for the given power operation.
This way the state changes from sleep->awake before the registers are poked
and from awake->sleep after the registers are poked.

This way spurious warnings aren't printed by my (to be committed)
debugging code.

Tested:

* AR5416, STA
2014-03-20 05:08:31 +00:00
Adrian Chadd
410302eb58 Don't call ath_init() inside the lock.
Yes, this means that sc_invalid is slightly racy, but there are other
issues here which need fixing.

This fixes a source of eventual LORs - ath_init() grabs ATH_LOCK to do
work and releases it before it calls ieee80211_start_all().
ieee80211_start_all() will grab the net80211 comlock to iterate over
the VAPs.

TODO:

* .. I should just migrate the ieee80211_start_all() work to a
  deferred task so it can be done later; it doesn't have to be
  immediately done.

Tested:

* AR5416, STA mode
2014-03-20 04:47:34 +00:00
Adrian Chadd
8a67b42a74 Migrate the chip power mode status to public ath_hal, rather than the
private per-chip HAL.

This allows the ah_osdep.[ch] code to check whether the power state is
valid for doing chip programming.

It should be a no-op for normal driver work but it does require a
clean kernel/module rebuild, as the size of HAL structures have changed.

Now, this doesn't track whether the hardware is ACTUALLY awake,
as NETWORK_SLEEP wakes the chip up for a short period when traffic
is received.  This doesn't actually set the power mode to AWAKE, so
we have to be careful about how we touch things.

But it's enough to start down the path of implementing station mode
chipset power savings, as a large part of the silliness is making
sure the chip is awake during periodic calibration / ANI and
random places where transmit may be occuring.  I'd rather not a repeat
of debugging power save on ath9k, where races with calibration
and transmit path stuff took a couple years to shake out.

Tested:

* AR5416, STA mode
2014-03-10 06:03:35 +00:00
Rui Paulo
a2be2710b4 Call ieee80211_dump_pkt() based on IFF_DUMPPKTS().
MFC after:	3 days
2014-03-08 19:35:31 +00:00
Hiren Panchasara
92389b2759 PicoStation M2HP presents reg domain 0x2a which is not found in atheros or linux
reference code. Add this workaround for now.

Reviewed by:	adrian
2014-02-23 18:07:17 +00:00
Kevin Lo
5945b5f5ab Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED.
The origin of WEP comes from IEEE Std 802.11-1997 where it defines
whether the frame body of MAC frame has been encrypted using WEP
algorithm or not.
IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates
whether the frame is protected by a cryptographic encapsulation
algorithm.

Reviewed by:	adrian, rpaulo
2014-01-08 08:06:56 +00:00