Commit Graph

1799 Commits

Author SHA1 Message Date
Adrian Chadd
3e0d0fcee9 [ath_hal] add a new regdomain flag - I think this means "yes, you can use this
NIC in channel 144 if you're in FCC6."

I have to go figure out more details about this before I enable it..
2016-09-26 02:05:02 +00:00
Adrian Chadd
5b06614ce3 [ath_hal] add a comment for the channel 144 regdomain flag.
I'm .. still trying to figure out what's going on.
2016-09-25 22:17:46 +00:00
Adrian Chadd
85bc19eb22 [ath_hal] Add FCC6_FCCA regulatory domain (0x0014).
Tested:

* TP-Link N900, AR9380, regdomain 0x0014 (FCC6_FCCA).
2016-09-25 22:07:41 +00:00
Andriy Voskoboinyk
887a63246c net80211: remove IEEE80211_RADIOTAP_TSFT field from transmit definitions.
This field may be used for received frames only.

Differential Revision:	https://reviews.freebsd.org/D3826
Differential Revision:	https://reviews.freebsd.org/D3827
2016-09-20 18:53:42 +00:00
Adrian Chadd
5abc0b2590 [ath] set the relevant TOA/TOD locationing bits when trying to do locationing.
* Don't do RTS/CTS - experiments show that we get ACK frames for each of them
  and this ends up causing the timestamps to look all funny.
* Set the HAL_TXDESC_POS bit, so the AR9300 HAL sets up the hardware to return
  location and CSI information.
2016-09-12 04:55:13 +00:00
Adrian Chadd
bd3b336251 [ath] tweak the TX EDMA debugging a bit.
I've used this to debug some amusing issues with the EDMA code.

Tested:

* AR9380, STA mode
* AR9380, TDMA mode (master, slave)
2016-09-12 04:50:40 +00:00
Adrian Chadd
90d3a30a16 [ath_hal] fixes for finer grain timestamping, some 11n macros
* change the HT_RC_2_MCS to do MCS0..23
* Use it when looking up the ht20/ht40 array for bits-per-symbol
* add a clk_to_psec (picoseconds) routine, so we can get sub-microsecond
  accuracy for the math
* .. and make that + clk_to_usec public, so higher layer code that is
  returning clocks (eg the ANI diag routines, some upcoming locationing
  experiments) can be converted to microseconds.

Whilst here, add a comment in ar5416 so i or someone else can revisit the
latency values.
2016-09-09 04:45:25 +00:00
Pedro F. Giffuni
f0be707d74 sys/dev: replace comma with semicolon when pertinent.
Uses of commas instead of a semicolons can easily go undetected. The comma
can serve as a statement separator but this shouldn't be abused when
statements are meant to be standalone.

Detected with devel/coccinelle following a hint from DragonFlyBSD.

MFC after:	1 month
2016-08-09 19:41:46 +00:00
Adrian Chadd
52fe68b878 [ath] update comments. 2016-08-01 00:36:29 +00:00
Adrian Chadd
ffa25bec32 [ath] don't do LDPC, STBC or short-gi for locationing frames.
The 11n duration calculation function in net80211 and the HAL round /up/
the duration calculation for short-gi, so we can't use that.

The 11n duration calculation doesn't know about the extra symbol time
needed for STBC, nor the LDPC encoding duration, so we can't use
that.

This (along with other, local hacks) allow the locationing services to
get down to around 200nS (yes, nanoseconds) of variance when speaking
to a "good" AP.

Tested:

* AR9380, STA mode, local locationing frame hacks
2016-07-19 00:27:17 +00:00
Adrian Chadd
7ff1939db0 [ath] [ath_hal] break out the duration calculation to optionally include SIFS.
The pre-11n calculations include SIFS, but the 11n ones don't.

The reason is that (mostly) the 11n hardware is doing the SIFS calculation
for us but the pre-11n hardware isn't.  This means that we're over-shooting
the times in the duration field for non-11n frames on 11n hardware, which
is OK, if not a little inefficient.

Now, this is all fine for what the hardware needs for doing duration math
for ACK, RTS/CTS, frame length, etc, but it isn't useful for doing PHY
duration calculations.  Ie, given a frame to TX and its timestamp, what
would the end of the actual transmission time be; and similar for an
RX timestamp and figuring out its original length.

So, this adds a new field to the duration routines which requests
SIFS or no SIFS to be included.  All the callers currently will call
it requesting SIFS, so this /should/ be a glorious no-op.  I'm however
planning some future work around airtime fairness and positioning which
requires these routines to have SIFS be optional.

Notably though, the 11n version doesn't do any SIFS addition at the moment.
I'll go and tweak and verify all of the packet durations before I go and
flip that part on.

Tested:

* AR9330, STA mode
* AR9330, AP mode
* AR9380, STA mode
2016-07-15 06:39:35 +00:00
Adrian Chadd
aaf8b608ca [ath] add a new buf flag, marking a buffer as involved with ToA/ToD positioning. 2016-07-08 22:20:35 +00:00
Adrian Chadd
23c4e11be6 [ath_hal] add capability bit for querying/controlling the ToA/ToD positioning code. 2016-07-08 21:37:04 +00:00
Adrian Chadd
5f01bf5405 [ath] include ath_hal accessor macro changes.
I missed this in the previous commit.
2016-07-08 21:35:44 +00:00
Adrian Chadd
515582436a [ath_hal] retire a "long RX desc" flag, store/use the TX/RX timestamp length.
* the code already stored the length of the RX desc, which I never used.
  So, use that and retire the new flag I introduced a while ago.
* Introduce a TX timestamp length field and capability.
2016-07-08 21:34:39 +00:00
Adrian Chadd
155a72b58a [ath_hal] extend the TX/RX descriptor layout to include location/beamforming fields.
* extend the TX timestamp to 32 bits, as the AR5416 and later does a full
  32 bit TX timestamp instead of 15 or 16 bits.
* add RX descriptor fields for PHY uploaded information (coming soon)
* add flags for RX/TX fast timestamp, hardware upload, etc
* add a flag for TX to request ToD/ToA location information.
2016-07-08 19:16:50 +00:00
Adrian Chadd
a7038bd16b [ath] obey the short-GI vap config flag when transmitting.
This makes 'ifconfig wlanX -shortgi' work correctly.

Tested:

* AR9380, STA mode

Approved by:	re (gjb)
2016-07-07 17:22:13 +00:00
Adrian Chadd
359eeea70b [ath] fix comments!
I keep asking myself "what do these fields mean" and so now I've clarified
it for myself.

Tested:

* Reading the comments, going "a-ha!" a couple times.

Approved by:	re (gjb)
2016-06-23 00:54:14 +00:00
Adrian Chadd
4f5ec72aa4 [ath] fix TX throughput for EDMA chips by pushing more into the TX FIFO.
It turns out that getting decent performance requires stacking the TX
FIFO a little more aggressively.

* Ensure that when we complete a frame, we attempt to push a new frame
  into the FIFO so TX is kept as active as it needs to be
* Be more aggressive about batching non-aggregate frames into a single
  TX FIFO slot.  This "fixes" TDMA performance (since we only get one
  TX FIFO slot ungated per DMA beacon alert) but it does this by pushing
  a whole lot of work into the TX FIFO slot.

I'm not /entirely/ pleased by this solution, but it does fix a whole bunch
of corner case issues in the transmit side and fix TDMA whilst I'm at it.
I'll go revisit transmit packet scheduling in ath(4) post 11.

Tested:

* AR9380, STA mode
* AR9580, hostap mode
* AR9380, TDMA client mode

Approved by:	re (hrs)
2016-06-21 15:38:20 +00:00
Adrian Chadd
1a9bf047c2 [ath] fix EDMA TX buffer flags for use when retransmitting frames.
This started showing up when doing lots of aggregate traffic. For TDMA it's
always no-ACK traffic and I didn't notice this, and I didn't notice it
when doing 11abg traffic as it didn't fail enough in a bad way to trigger
this.

This showed up as the fifo depth being < 0.

Eg:

Jun 19 09:23:07 gertrude kernel: ath0: ath_tx_edma_push_staging_list: queued 2 packets; depth=2, fifo depth=1
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1, bf=0xfffffe000385f068, start=1, end=1
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1: FIFO depth is now 0 (1)
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1, bf=0xfffffe0003866fe8, start=0, end=1
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1: FIFO depth is now -1 (0)

So, clear the flags before adding them to a TX queue, so if they're
re-added for the retransmit path it'll clear whatever they were and
not double-account the FIFOEND flag.  Oops.

Tested:

* AR9380, STA mode, 11n iperf testing (~130mbit)

Approved by:	re (delphij)
2016-06-20 02:04:40 +00:00
Adrian Chadd
49236b4e99 [ath] add support for batching frames to the general TX queues.
It turns out the frame scheduling policies (eg DBA_GATED) operate on
a single TX FIFO entry.  ASAP scheduling is fine; those frames always
go out.

DBA-gated sets the TX queue ready when the DBA timer fires, which triggers
a beacon transmit.  Normally this is used for content-after-beacon queue
(CABQ) work, which needs to burst out immediately after a beacon.
(eg broadcast, multicast, etc frames.)  This is a general policy that you
can use for any queue, and Sam's TDMA code uses it.

When DBA_GATED is used and something like say, an 11e TX burst window,
it only operates on a single TX FIFO entry.  If you have a single frame
per TX FIFO entry and say, a 2.5ms long burst window (eg TDMA!) then it'll
only burst a single frame every 2.5ms.  If there's no gating (eg ASAP) then
the burst window is fine, and multiple TX FIFO slots get used.

The CABQ code does pack in a list of frames (ie, the whole cabq) but
up until this commit, the normal TX queues didn't.  It showed up when
I started to debug TDMA on the AR9380 and later.

This commit doesn't fix the TDMA case - that's still broken here, because
all I'm doing here is allowing 'some' frames to be bursting, but I'm
certainly not filling the whole TX FIFO slot entry with frames.
Doing that 'properly' kind of requires me to take into account how long
packets should take to transmit and say, doing 1.5 or something times that
per TX FIFO slot, as if you partially transmit a slot, when it's next
gated it'll just finish that TX FIFO slot, then not advance to the next
one.

Now, I /also/ think queuing a new packet restarts DMA, but you have to
push new frames into the TX FIFO.  I need to experiment some more with
this because if it's really the case, I will be able to do TDMA support
without the egregious hacks I have in my local tree.  Sam's TDMA code
for previous chips would just kick the TXE bit to push along DMA
again, but we can't do that for EDMA chips - we /have/ to push a new
frame into the TX FIFO to restart DMA.  Ugh.

Tested:

* AR9380, STA mode
* AR9380, hostap mode
* AR9580, hostap mode

Approved by:	re (gjb)
2016-06-19 03:45:32 +00:00
Adrian Chadd
b819e1ed19 [ath] don't debug RX EDMA descriptors that are not yet complete.
Approved by:	re@ (gjb)
2016-06-17 17:01:32 +00:00
Adrian Chadd
ef347e56a2 [ath] add a placeholder event for debuggin EDMA TX FIFO push events.
Some later code I'll commit pushes lists of frames into the EDMA TX
FIFO, rather than a single frame at a time.  The CABQ code already
pushes frame lists, but it turns out we should actually be doing it
in general or performance tanks. :(
2016-06-09 22:01:05 +00:00
Adrian Chadd
729ecfbb8e [ath] report node queue overflows.
I need to also update athstats to report this too.
2016-06-09 21:59:36 +00:00
Adrian Chadd
64efe94d06 [ath] remove now unused parameters.
These will move to being part of the driver btcoex stuff I'm working
on, since the HAL doesn't know what to do with them.
2016-06-04 08:56:30 +00:00
Adrian Chadd
8132a45dae [ath_hal] add placeholders for AUDIO stomp for Kite/Kiwi.
It just stomps all; which is enough for some testing.
2016-06-04 07:28:36 +00:00
Adrian Chadd
624fbf7d59 [ath_hal] add BTCOEX_STOMP_AUDIO; delete unused methods. 2016-06-04 07:28:09 +00:00
Adrian Chadd
b28e96d670 [ath] correctly shift the QCA9565 LNA config into the mci config variable.
Tested:

* QCA9565, STA + BT mode
2016-06-02 04:25:54 +00:00
George V. Neville-Neil
90849c3e0d Fix kernel build. Improper definition location of a variable. 2016-06-02 01:59:41 +00:00
Adrian Chadd
bcf5fc498a [ath] commit initial bluetooth coexistence support for the MCI NICs.
This is the initial framework to call into the MCI HAL routines and drive
the basic state engine.

The MCI bluetooth coex model uses a command channel between wlan and
bluetooth, rather than a 2-wire or 3-wire signaling protocol to control things.
This means the wlan and bluetooth chip exchange a lot more information and
signaling, even at the per-packet level.  The NICs in question can share
the input LNA and output PA on the die, so they absolutely can't stomp
on each other in a silly fashion.  It also allows for the bluetooth side
to signal when profiles come and go, so the driver can take appropriate
control.  There's also the possibility of dynamic bluetooth/wlan duty cycle
control which I haven't yet really played with.

It configures things up with a static "wlan wins everything" coexistence,
configures up the available 2GHz channel map for bluetooth, sets a static
duty cycle for bluetooth/wifi traffic priority and drives the basics needed to
keep the MCI HAL code happy.

It doesn't do any actual coexistence except to default to "wlan wins everything",
which at least demonstrates that things do indeed work.  Bluetooth inquiry frames
still trump wifi (including beacons), so that demonstrates things really do
indeed seem to work.

Tested:

* AR9462 (WB222), STA mode + bt
* QCA9565 (WB335), STA mode + bt

TODO:

* .. the rest of coexistence.  yes, bluetooth, not people.  That stuff's hard.
* It doesn't do the initial BT side calibration, which requires a WLAN chip
  reset.  I'll fix up the reset path a bit more first before I enable that.
* The 1-ant and 2-ant configuration bits aren't being set correctly in
  if_ath_btcoex.c - I'll dig into that and fix it in a subsequent commit.
* It's not enabled by default for WB222/WB225 even though I believe it now
  can be - I'll chase that up in a subsequent commit.

Obtained from:	Qualcomm Atheros, Linux ath9k
2016-06-02 00:51:36 +00:00
Adrian Chadd
bd02d46fc2 [ath_hal] add extra MCI definitions used by the later chips (QCA9565/Aphrodite).
Obtained from:	Linux ath9k
2016-06-01 01:43:46 +00:00
Adrian Chadd
d24161cb2a [ath_hal] rename the MCI state info routine.
It's not /really/ "get state".
2016-05-31 16:08:06 +00:00
Adrian Chadd
c3d41e2e4c [ath_hal] add support for setting the azimuth timestamp in the outgoing TX payload.
FYI: This is an unsupported/deprecated feature of the 11n hardware.
2016-05-31 16:07:15 +00:00
Adrian Chadd
e48538dd58 [ath_hal] reserve a HAL_TXDESC_ bit for azimuth TX timestamp requests. 2016-05-31 16:05:54 +00:00
Adrian Chadd
023efcf136 [ath_hal] migrate the bluetooth definitions out from ah.h / ar9300_freebsd_inc.h.
The eventual MCI driver side of things needs the MCI bits to live
in the HAL API so we can get to them.

Tested:

* QCA9565, STA mode + bluetooth
2016-05-31 04:44:00 +00:00
Adrian Chadd
a7236e4903 [ath_hal] add bluetooth coexistence definitions for both legacy and MCI.
The legacy bits are just from ah.h; the MCI bits are from the ar9300
HAL "freebsd" extras.

A subsequent commit will include ah_btcoex.h into ah.h and remove
the older defintions.
2016-05-31 04:35:26 +00:00
Adrian Chadd
ee1623827e [ath] add BTCOEX debug section; modify DPRINTF() to take a no-arg format string.
Tested:

* QCA9565, STA mode
2016-05-31 04:09:17 +00:00
Adrian Chadd
38c4fdf4c6 [ath] add WB335 btcoex for initial testing.
This is like the WB222 coexistence (ie, "MCI", a message bus inside the
chip), and it's currently a cut/paste so I can start using it to flesh
out the differences with WB222.

It doesn't completely /do/ bluetooth coexistence, because it turns out
I need to add some contigmalloc'ed buffers to the btcoex path for this
type of hardware.  I'm putting this work in the "people would like
to see functioning-ish btcoex before FreeBSD-11" bucket because I see
this as "broken".

Tested:

* QCA9535 (WB335) NIC, BT + 2GHz STA
2016-05-28 02:14:24 +00:00
Adrian Chadd
b1940deb18 [ath] convert recent changes over to HAL format.
This is needed to compile the ath tools, that includes this code
to run in userland.

Tested:

* Carambola 2, AR9331, STA mode
2016-05-20 06:06:21 +00:00
Andriy Voskoboinyk
12d532388d ath: refactor/split getchannels() method.
Split getchannels() method in ath_hal/ah_regdomain.c into a subset
of functions for better readability.

Note: due to different internal structure, it cannot use
ieee80211_add_channel*() (however, some parts are done in a
similar manner).

Differential Revision:	https://reviews.freebsd.org/D6139
2016-05-19 23:00:30 +00:00
Pedro F. Giffuni
f6b6084b8e dev/ath: minor spelling fixes in comments.
No functional change.

Reviewed by:	adrian
2016-05-02 19:56:48 +00:00
Adrian Chadd
a039118792 [ath] initialise do_ldpc to 0.
I .. can't believe I missed this.

This showed up because the AP was TX'ing LDPC to an iwm(4) chipset,
which didn't advertise LDPC and doesn't /accept/ LDPC.  Amusingly, all
the two other FreeBSD 11n parts I had tested with (AR9380, Intel 7260)
and I completely forgot to test on ye olde hardware.

That'll teach me.

Tested:

* AR9580 (AP) - Intel 7260 (STA), AR9380 (STA), Intel 6205 (STA)
2016-04-29 18:53:16 +00:00
Adrian Chadd
ce725c8e00 [ath] Add LDPC transmit support.
LDPC adds better transmit reliability if both ends support it.

You in theory can do both STBC and LDPC at the same time.
If I see issues I'll disable it.

* Only enable it if both ends of a connection negotiate it.
* Disable it if any rate is non-11n.
* Count both LDPC TX and STBC TX.

Tested:

* AR9380, STA mode
2016-04-29 01:53:45 +00:00
Adrian Chadd
82525db1eb [ath] turn the BA hardware bug back into a printf().
I saw this happen a couple of times and all I saw was a dump of the
transmit descriptors.  Log the message for now so I can see whta happened.
2016-04-29 01:52:06 +00:00
Adrian Chadd
3c6b488b01 [ath] Add counters for STBC TX and LDPC TX.
This is a big no-op until the TX path changes to enable LDPC TX are
added.
2016-04-29 01:51:27 +00:00
Adrian Chadd
9f3a915030 [ath] add LDPC capability support and LDPC RX support.
This enables LDPC receive support for the AR9300 chips that support it.
It'll announce LDPC support via net80211.

Tested:

* AR9380, STA mode
* AR9331, (to verify the HAL didn't attach it to a chip which
  doesn't support LDPC.)

TODO:

* Add in net80211 machinery to make this configurable at runtime.
2016-04-26 01:37:03 +00:00
Adrian Chadd
f026d6931a [ath] obey the STBC flag setting in iv_flags_ht
Add support for the FHT_STBC_TX flag in iv_flags_ht, so it'll now obey
the per-vap ifconfig stbctx flag.

This means that we can do STBC TX on one vap and not another VAP.
(As well as STBC RX on said vap; that changes the HTCAP announcement.)
2016-04-26 01:34:21 +00:00
Andriy Voskoboinyk
31021a2b4e net80211: replace internal LE_READ_*/LE_WRITE_* macro with system
le*dec / le*enc functions.

Replace net80211 specific macros with system-wide bytestream
encoding/decoding functions:
- LE_READ_2 ->  le16dec
- LE_READ_4 ->  le32dec
- LE_WRITE_2 -> le16enc
- LE_WRITE_4 -> le32enc

+ drop ieee80211_input.h include, where it was included for these
operations only.

Reviewed by:	adrian
Differential Revision:	https://reviews.freebsd.org/D6030
2016-04-20 18:29:30 +00:00
Pedro F. Giffuni
74b8d63dcc Cleanup unnecessary semicolons from the kernel.
Found with devel/coccinelle.
2016-04-10 23:07:00 +00:00
Adrian Chadd
afa4433355 [ath] Only process beacon frames for the IBSS/BSSID if appropriate.
* Don't use arbitrary frames for the average RX RSSI - only frames
  from the current BSSID

* Don't log / do the syncbeacon logic for another BSSID and definitely
  don't do the syncbeacon call if we miss beacons outside of STA mode.

* Don't do the IBSS merge bits if the current node plainly won't ever
  match our current BSS (ie, the IBSS doesn't have to match, but all
  the same bits that we check in ieee80211_ibss_merge() have to match.)

Tested:

* ath(4), AR9380, IBSS mode, surrounded by a lot of IBSS 11ac networks.

Sponsored by:	Eva Automation, Inc.
2016-04-09 00:58:38 +00:00
Adrian Chadd
b8e29e065d [net80211] migrate the time_* macros to ieee80211_* namespace.
It turns out that these will clash very annoyingly with the linux
macros in the linuxkpi layer, so let the wookie^Wlinux win.

The only user that I can find is ath(4), so fix it there too.
2016-03-30 00:44:10 +00:00
John Baldwin
cbc4d2db75 Remove taskqueue_enqueue_fast().
taskqueue_enqueue() was changed to support both fast and non-fast
taskqueues 10 years ago in r154167.  It has been a compat shim ever
since.  It's time for the compat shim to go.

Submitted by:	Howard Su <howard0su@gmail.com>
Reviewed by:	sephe
Differential Revision:	https://reviews.freebsd.org/D5131
2016-03-01 17:47:32 +00:00
Adrian Chadd
b258556759 Fix up the ath(4) device names for QCA chipsets.
Submitted by:	Tobias Kortkamp <t@tobik.me>
2016-02-29 02:40:58 +00:00
Adrian Chadd
17f42e0d6b [ath] remove the inline version of the register access macros.
These are going to be much more efficient on low end embedded systems
but unfortunately they make it .. less convenient to implement correct
bus barriers and debugging.  They also didn't implement the register
serialisation workaround required for Owl (AR5416.)

So, just remove them for now.  Later on I'll just inline the routines
from ah_osdep.c.
2016-01-03 17:58:11 +00:00
Adrian Chadd
fdee6e3bba ... and that would've never worked. Sorry!
(Note: everything I tested on locally has ATH_DEBUG / AH_DEBUG set.)
2016-01-02 18:32:20 +00:00
Adrian Chadd
ef91dbcec6 [ath] add explicit bus barriers.
The ath hal and driver code all assume the world is an x86 or the
bus layer does an explicit bus flush after each operation (eg netbsd.)

However, we don't do that.

So, to be "correct" on platforms like sparc64, mips and ppc (and maybe
ARM, I am not sure), just do explicit barriers after each operation.

Now, this does slow things down a tad on embedded platforms but I'd
rather things be "correct" versus "fast."  At some later point if someone
wishes it to be fast then we should add the barrier calls to the HAL and
driver.

Tested:

* carambola 2 (AR9331.)
2016-01-02 17:14:22 +00:00
Adrian Chadd
ff066b54ec fix ht/40 configuration for ar9331 (hornet).
The synth programming here requires the real centre frequency,
which for HT20 channels is the normal channel, but HT40 is
/not/ the primary channel.  Everything else was using 'freq',
which is the correct centre frequency, but the hornet config
was using 'ichan' to do the lookup which was also the primary
channel.

So, modify the HAL call that does the mapping to take a frequency
in MHz and return the channel number.

Tested:

* Carambola 2, AR9331, tested both HT/20 and HT/40 operation.
2015-11-30 06:26:59 +00:00
Adrian Chadd
2c9b30a91f [ath_hal] use the correct revision information for QCA953x.
This probe/attaches correctly in my local branch and now displays
a useful message:

ath0: <Qualcomm Atheros QCA953x> at mem 0x18100000-0x1811ffff irq 0 on nexus0
...
ath0: AR9530 mac 1280.0 RF5110 phy 0.0
2015-11-28 06:50:09 +00:00
Adrian Chadd
70aca315ac * Add device string for QCA955x (scorpion);
* Add device ID and device string for QCA953x (honeybee).
2015-11-28 00:27:16 +00:00
Adrian Chadd
19b34b5685 wrap in ATH_DEBUG.
Thanks sparc64 build!
2015-11-28 00:14:37 +00:00
Adrian Chadd
20b0b9ea74 [ath] conditionally print out the rate series information if ATH_DEBUG_XMIT is set. 2015-11-27 22:33:40 +00:00
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