Commit Graph

707 Commits

Author SHA1 Message Date
Adrian Chadd
8c01c3dc46 [ath] [ath_hal] Propagate the HAL_RESET_TYPE through to the chip reset; set it during ath_reset()
Although I added the reset type field to ath_hal_reset() years ago,
I never finished adding it both throughout the HALs and in if_ath.c.

This will eventually deprecate the ath_hal force_full_reset option
because it can be requested at the driver layer.

So:

* Teach ar5416ChipReset() and ar9300_chip_reset() about the HAL type
* Use it in ar5416Reset() and ar9300_reset() when doing a full chip reset
* Extend ath_reset() to include the HAL_RESET_TYPE parameter added in the above functions
* Use HAL_RESET_NORMAL in most calls to ath_reset()
* .. but use HAL_RESET_BBPANIC for the BB panics, and HAL_RESET_FORCE_COLD during fatal, beacon miss and other hardware related hangs.

This should be a glorified no-op outside of actual hardware issues.
I've tested things with ath_hal force_full_reset set to 1 for years now,
so I know that feature and a full reset works (albeit much slower than
a warm reset!) and it does unwedge hardware.

The eventual aim is to use this for all the places where the driver
detects a potential hang as well as if long calibration - ie, noise floor
calibration - fails to complete. That's one of the big hardware related
things that causes station mode operation to hang without easy recovery.

Differential Revision:	https://reviews.freebsd.org/D24981
2020-05-25 22:31:45 +00:00
Adrian Chadd
cce6344402 [ath] [ath_rate] Extend ath_rate_sample to better handle 11n rates and aggregates.
My initial rate control code was .. suboptimal.  I wanted to at least get MCS
rates sent, but it didn't do anywhere near enough to handle low signal level links
or remotely keep accurate statistics.

So, 8 years later, here's what I should've done back then.

* Firstly, I wasn't at all tracking packet sizes other than the two buckets
  (250 and 1600 bytes.)  So, extend it to include 4096, 8192, 16384, 32768 and
  65536.  I may go add 2048 at some point if I find it's useful.

  This is important for a few reasons.  First, when forming A-MPDU or AMSDU
  aggregates the frame sizes are larger, and thus the TX time calculation
  is woefully, increasingly wrong.  Secondly, the behaviour of 802.11 channels
  isn't some fixed thing, both due to channel conditions and radios themselves.
  Notably, there was some observations done a few years ago on 11n chipsets
  which noticed longer aggregates showed an increase in failed A-MPDU sub-frame
  reception as you got further along in the transmit time.  It could be due to
  a variety of things - transmitter linearity, channel conditions changing,
  frequency/phase drift, etc - but the observation was to potentially form
  shorter aggregates to improve BER.

* .. and then modify the ath TX path to report the length of the aggregate sent,
  so as the statistics kept would line up with the correct bucket.

* Then on the rate control look-up side - i was also only using the first frame
  length for an A-MPDU rate control lookup which isn't good enough here.
  So, add a new method that walks the TID software queue for that node to
  find out what the likely length of data available is.  It isn't ALL of the
  data in the queue because we'll only ever send enough data to fit inside the
  block-ack window, so limit how many bytes we return to roughly what ath_tx_form_aggr()
  would do.

* .. and cache that in the first ath_buf in the aggregate so it and the eventual
  AMPDU length can be returned to the rate control code.

* THEN, modify the rate control code to look at them both when deciding which bucket
  to attribute the sent frame on.  I'm erring on the side of caution and using the
  size bucket that the lookup is based on.

Ok, so now the rate lookups and statistics are "more correct".  However, MCS rates
are not the same as 11abg rates in that they're not a monotonically incrementing
set of faster rates and you can't assume that just because a given MCS rate fails,
the next higher one wouldn't work better or be a lower average tx time.

So, I had to do a bunch of surgery to the best rate and sample rate math.
This is the bit that's a WIP.

* First, simplify the statistics updates (update_stats()) to do a single pass on
  all rates.
* Next, make sure that each rate average tx time is updated based on /its/ failure/success.
  Eg if you sent a frame with { MCS15, MCS12, MCS8 } and MCS8 succeeded, MCS15 and MCS
  12 would have their average tx time updated for /their/ part of the transmission,
  not the whole transmission.
* Next, EWMA wasn't being fully calculated based on the /failures/ in each of the
  rate attempts.  So, if MCS15, MCS12 failed above but MCS8 didn't, then ensure
  that the statistics noted that /all/ subframes failed at those rates, rather than
  the eventual set of transmitted/sent frames.   This ensures the EWMA /and/ average
  TX time are updated correctly.
* When picking a sample rate and initial rate, probe rates aroud the current MCS
  but limit it to MCS0..7 /for all spatial streams/, rather than doing crazy things
  like hitting MCS7 and then probing MCS8 - MCS8 is basically MCS0 but two spatial
  streams.  It's a /lot/ slower than MCS7.  Also, the reverse is true - if we're at
  MCS8 then don't probe MCS7 as part of it, it's not likely to succeed.
* Fix bugs in pick_best_rate() where I was /immediately/ choosing the highest MCS
  rate if there weren't any frames yet transmitted.  I was defaulting to 25% EWMA and
  .. then each comparison would accept the higher rate.  Just skip those; sampling
  will fill in the details.

So, this seems to work a lot better.  It's not perfect; I'm still seeing a lot of
instability around higher MCS rates because there are bursts of loss/retransmissions
that aren't /too/ bad.  But i'll keep iterating over this and tidying up my hacks.

Ok, so why this still something I'm poking at? rather than porting minstrel_ht?

ath_rate_sample tries to minimise airtime, not maximise throughput.  I have
extended it with an EWMA based on sub-frame success/failures - high MCS rates
that have partially successful receptions still show super short average frame
times, but a /lot/ of retransmits have to happen for that to work.
So for MCS rates I also track this EWMA and ensure that the rates I'm choosing
don't have super crappy packet failures.  I don't mind not getting lower
peak throughput versus minstrel_ht; instead I want to see if I can make "minimise
airtime" work well.

Tested:

* AR9380, STA mode
* AR9344, STA mode
* AR9580, STA/AP mode
2020-05-15 18:51:20 +00:00
Adrian Chadd
41137b0604 [ath_hal] [ath_hal_ar9300] Fix endian macros to work in and out of kernel tree.
Yes, people shouldn't use bitfields in C for structure parsing.
If someone ever wants a cleanup task then it'd be great to remove them
from this vendor code and other places in the ar9285/ar9287 HALs.

Alas, here we are.

AH_BYTE_ORDER wasn't defined and neither were the two values it could be.
So when compiling ath_ee_print_9300 it'd default to the big endian struct
layout and get a WHOLE lot of stuff wrong.

So:

* move AH_BYTE_ORDER into ath_hal/ah.h where it can be used by everyone.
* ensure that AH_BYTE_ORDER is actually defined before using it!

This should work on both big and little endian platforms.
2020-05-12 02:20:27 +00:00
Rebecca Cran
7e03a82b63 ath_hal: fix typo in ath_hal_printf 2020-03-18 03:14:17 +00:00
Adrian Chadd
1bae1560ee [ath_hal] Fix queue bits a bit
Found by PVS Studio: duplicate assignment; add assignment of tqi_compBuf.

Submitted by:	<mizhka@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D20431
2019-05-28 18:05:10 +00:00
Adrian Chadd
a8083b9c0b [ath] [ath_hal] [ath_hal_9300] Extend the start PCU receive to handle resetting ANI.
One of the fun issues with scanning has been how the existing
ANI values were programmed into the hardware when channels were
changed.  If you're on a really crappy channel and ANI has made
you deaf then when you scan you continue to be deaf on all channels.

This code passes in a flag to startpcureceive which in AR5416 and later
is also used to enable ANI.  This allows it to know if it's a normal
operation or a scan operation.

This fixes my situation at home where a temporary spot of a device
going deaf due to interference starts scanning and .. can't hear
anything until I restart.

Now, this isn't the full fix - ideally:

(a) all the ANI config and per-channel information would be migrated
     to the shared HAL stuff and enabled for all of the NICs;
(b) when a station reassociates and some other error conditions
    (like missed beacons, NF calibration failures, etc) a knob
    to reset ANI parameters would likely help recovery.

But hey, I'm committing bits of code again! woo!

Tested:

* AR9344 (2G), STA operation
2019-04-21 02:36:01 +00:00
Adrian Chadd
7fbcfe69e7 [ath_hal] [ath_hal_ar9300] ANI fixes and preparation for userland control.
* The ani function bitmap was being badly used when determining if a command
  could be used.  In hostap modes only a couple of the ANI control parameters
  are enabled.

* The ani function bitmap was not being reset to HAL_ANI_ALL if transitioning
  from AP -> STA.

* Change mrcCckOff to mrcCck - 1 == on, rather than 1 == off.  This matches
  the API used to set the value from userland via the diagnostic API.

* Handle OFDM/CCK noise immunity level commands in ar9300_ani_control().
  These will only come from userland and it will go and program the rest of
  the ANI control parameters with the values in the ANI table.

* Ensure all of the ANI parameters can be tweaked at runtime, even if they're
  disabled.

Tested:

* carambola2 (AR9331), STA/AP modes
2019-03-06 07:54:29 +00:00
Adrian Chadd
dc5c74a6f4 [ath_hal] add extra ANI fields for the AR9300 HAL.
I'm trying to debug why reception upstairs here is so terrible and it
turns out ANI is buggy.  (Which is no surprise, ANI is always buggy.)

Tested:

* Carambola2 (AR9331), STA/AP modes
2019-03-04 06:42:06 +00:00
Adrian Chadd
8a97beff98 [ath_hal] Return failure if noise floor calibration fails.
If we fail noise floor calibration then we may end up with a deaf NIC
which we can't recover without a full chip reset.

Earlier chips seem to get less stuck in this condition versus AR9280/later
and AR9300/later, but whilst here just fix up the AR5212 era chips to also
return NF calibration failures.

This HAL routine would only return failure if the channel was not configured.

This is a no-op until the driver side code for doing resets and the HAL
code for being told about the reset type (and then handling it!) is
implemented.

Tested:

* AR9280, STA mode
* AR2425, STA mode
* AR9380, STA mode
2018-06-08 18:21:57 +00:00
Adrian Chadd
7b1c2c4ec2 [ath_hal] Don't do ANI processing if we've reset.
If we've reset then we can't trust the current state of the ANI tracking,
so just wait until next time.

Tested:

* AR5424, STA mode (2GHz)
2018-06-08 18:15:23 +00:00
Adrian Chadd
a861b06b97 [ath_hal] migrate the shared HAL_RESET_* pieces out into ath_hal.
I'm in the process of reworking how the reset path works with an eye
to better recovery when the chips hang and/or go RF/PHY deaf.
This is the first step in a lot of unification and API changes.
2018-05-25 01:27:39 +00:00
Pedro F. Giffuni
6e778a7efd SPDX: license IDs for some ISC-related files. 2017-12-08 15:57:29 +00:00
Pedro F. Giffuni
718cf2ccb9 sys/dev: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
2017-11-27 14:52:40 +00:00
Wojciech Macek
7108339449 Increase timeout in Atheros HAL
It turned out, that some models of the Atheros PCIe
adapters (e.g. AR983x family) may fail to attach
due to insufficient timeout value.

Submitted by:   Bartosz Szczepanek <bsz@semihalf.com>
Obtained from:  Semihalf
Sponsored by:   Stormshield
Reviewed by:    adrian
Differential revision: https://reviews.freebsd.org/D10903
2017-05-29 09:21:38 +00:00
Adrian Chadd
f46839b9e3 [ath] [ath_hal] retire AH_SUPPORT_AR5416 changing anything.
Yes, the memory bloat is large, but it's 2017 and I'll fix it later
by making it runtime configurable / per-chip configurable if I ever need to.
2017-05-25 04:26:26 +00:00
Adrian Chadd
41059135ce [ath] [ath_hal] (etc, etc) - begin the task of re-modularising the HAL.
In the deep past, when this code compiled as a binary module, ath_hal
built as a module.  This allowed custom, smaller HAL modules to be built.
This was especially beneficial for small embedded platforms where you
didn't require /everything/ just to run.

However, sometime around the HAL opening fanfare, the HAL landed here
as one big driver+HAL thing, and a lot of the (dirty) infrastructure
(ie, #ifdef AH_SUPPORT_XXX) to build specific subsets of the HAL went away.
This was retained in sys/conf/files as "ath_hal_XXX" but it wasn't
really floated up to the modules themselves.

I'm now in a position where for the reaaaaaly embedded boards (both the
really old and the last couple generation of QCA MIPS boards) having a
cut down HAL module and driver loaded at runtime is /actually/ beneficial.

This reduces the kernel size down by quite a bit.  The MIPS modules look
like this:

adrian@gertrude:~/work/freebsd/head-embedded/src % ls -l ../root/mips_ap/boot/kernel.CARAMBOLA2/ath*ko
-r-xr-xr-x  1 adrian  adrian    5076 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_dfs.ko
-r-xr-xr-x  1 adrian  adrian  100588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal.ko
-r-xr-xr-x  1 adrian  adrian  627324 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal_ar9300.ko
-r-xr-xr-x  1 adrian  adrian  314588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_main.ko
-r-xr-xr-x  1 adrian  adrian   23472 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_rate.ko

And the x86 versions, like this:

root@gertrude:/home/adrian # ls -l /boot/kernel/ath*ko
-r-xr-xr-x  1 root  wheel   36632 May 24 18:32 /boot/kernel/ath_dfs.ko
-r-xr-xr-x  1 root  wheel  134440 May 24 18:32 /boot/kernel/ath_hal.ko
-r-xr-xr-x  1 root  wheel   82320 May 24 18:32 /boot/kernel/ath_hal_ar5210.ko
-r-xr-xr-x  1 root  wheel  104976 May 24 18:32 /boot/kernel/ath_hal_ar5211.ko
-r-xr-xr-x  1 root  wheel  236144 May 24 18:32 /boot/kernel/ath_hal_ar5212.ko
-r-xr-xr-x  1 root  wheel  336104 May 24 18:32 /boot/kernel/ath_hal_ar5416.ko
-r-xr-xr-x  1 root  wheel  598336 May 24 18:32 /boot/kernel/ath_hal_ar9300.ko
-r-xr-xr-x  1 root  wheel  406144 May 24 18:32 /boot/kernel/ath_main.ko
-r-xr-xr-x  1 root  wheel   55352 May 24 18:32 /boot/kernel/ath_rate.ko

.. so you can see, not building the whole HAL can save quite a bit.
For example, if you don't need AR9300 support, you can actually avoid
wasting half a megabyte of RAM.  On embedded routers this is quite a
big deal.

The AR9300 HAL can be later further shrunk because, hilariously,
it indeed supports AH_SUPPORT_<xxx> for optionally adding chipset support.
(I'll chase that down later as it's quite a big savings if you're only
building for a single embedded target.)

So:

* Create a very hackish way to load/unload HAL modules
* Create module metadata for each HAL subtype - ah_osdep_arXXXX.c
* Create module metadata for ath_rate and ath_dfs (bluetooth is
  currently just built as part of it)
* .. yes, this means we could actually build multiple rate control
  modules and pick one at load time, but I'd rather just glue this
  into net80211's rate control code.  Oh well, baby steps.
* Main driver is now "ath_main"
* Create an "if_ath" module that does what the ye olde one did -
  load PCI glue, main driver, HAL and all child modules.
  In this way, if you have "if_ath_load=YES" in /boot/modules.conf
  it will load everything the old way and stuff should still work.
* For module autoloading purposes, I actually /did/ fix up
  the name of the modules in if_ath_pci and if_ath_ahb.

If you want to selectively load things (eg on ye cheape ARM/MIPS platforms
where RAM is at a premium) you should:

* load ath_hal
* load the chip modules in question
* load ath_rate, ath_dfs
* load ath_main
* load if_ath_pci and/or if_ath_ahb depending upon your particular
  bus bind type - this is where probe/attach is done.

TODO:

* AR5312 module and associated pieces - yes, we have the SoC side support
  now so the wifi support would be good to "round things out";
* Just nuke AH_SUPPORT_AR5416 for now and always bloat the packet
  structures; this'll simplify other things.
* Should add a simple refcnt thing to the HAL RF/chip modules so you
  can't unload them whilst you're using them.
* Manpage updates, UPDATING if appropriate, etc.
2017-05-25 04:18:46 +00:00
Warner Losh
fbbd9655e5 Renumber copyright clause 4
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.

Submitted by:	Jan Schaumann <jschauma@stevens.edu>
Pull Request:	https://github.com/freebsd/freebsd/pull/96
2017-02-28 23:42:47 +00:00
Adrian Chadd
aa36f34d52 [ath_hal] implement NULL methods for ah_setQuiet for AR5210, AR5211.
Tested:

* "crap, I didn't bring my cardbus collection and T400 with me" compile
  tested.
2017-02-09 23:20:55 +00:00
Adrian Chadd
2bc158cf24 [ath_hal] prepare for CAC quiet time.
To support DFS, the NIC needs to be very quiet during this time.
No transmissions including ACKs are allowed.

This is just the initial HAL glue.
2017-02-03 05:15:08 +00:00
Adrian Chadd
4a3fdd0e13 [ath_hal] add debugging level for spectral scan. 2017-02-02 05:27:27 +00:00
Adrian Chadd
3557b26a4b [ath_hal] note that the CCA configuration setting may be chip-dependent.
I bet it isn't, but who knows - this is making assumptions about the
layout of AR_DIAG.
2017-01-24 22:52:09 +00:00
Adrian Chadd
eee8e3627b [ath_hal] mad, mad hacks to get some semblence of correct HT/40 channels populated.
The HT40 channel population logic was "just" doing pairs of channels starting with
the band entry frequency.  Trouble is, a lot of the rules start way off at 5120MHz,
which isn't a valid 5GHz channel.  Then, eg for HT40U, it would populate:

* (5120,5140)
* (5160,5180)
* (5200,5220)
* (5240,5260)

.. as the HT40U pairs, with the first being the primary channel.  Channel 36
is 5180MHz, and since it's not a primary channel here, it wouldn't populate it.
Then, the next HT40U would be 5200/5220, which is highly wrong.

HT40D had the same problem.

So, this just forces that 5GHz HT40 channels start at channel 36 (5180),
no matter what the band edge says.  This includes eg doing 4.9GHz channels.

This erm, meant that the HT40 channels for the low band was always wrong.

Oops!

Tested:

* AR9380, STA mode
* AR9344 SoC, AP mode

MFC after:	1 week
2017-01-05 04:56:04 +00:00
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
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
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
23c4e11be6 [ath_hal] add capability bit for querying/controlling the ToA/ToD positioning code. 2016-07-08 21:37:04 +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
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
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
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
Pedro F. Giffuni
74b8d63dcc Cleanup unnecessary semicolons from the kernel.
Found with devel/coccinelle.
2016-04-10 23:07:00 +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
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
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
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