src-test2/sys/dev/ath, branch release/10.0.0FreeBSD source treehttps://cgit-dev.freebsd.org/src-test2/atom?h=release%2F10.0.02013-10-08T11:28:59ZAdd channel survey support to the AR5212 HAL.2013-10-08T11:28:59ZAdrian Chaddadrian@FreeBSD.org2013-10-08T11:28:59Zurn:sha1:0a2cefc676074563cc10c2fad63208e9a87ecbe4
The AR5212 series of MACs implement the same channel counters as the
later 11n chips - except, of course, the 11n specific counter (extension
channel busy.)
This allows users of these NICs to use 'athsurvey' to see how busy their
current channel is.
Tested:
* AR5212, AR2413 NICs, STA mode
Approved by: re@ (gleb)
Use the new ieee80211_tx_complete() function.2013-08-27T14:39:37ZAdrian Chaddadrian@FreeBSD.org2013-08-27T14:39:37Zurn:sha1:e95f34242c7949d36b2477c311cdde6790e43a68Log the MAC address of the node in question rather than the pointer.2013-08-17T01:14:28ZAdrian Chaddadrian@FreeBSD.org2013-08-17T01:14:28Zurn:sha1:272a8ab68adf8add5345ba5b61d55bb7667229d1Don't log anything if npkts == 0.2013-06-29T19:57:57ZAdrian Chaddadrian@FreeBSD.org2013-06-29T19:57:57Zurn:sha1:25245548325110c1c173e72d7f564ac1af3af761
This occurs at RX DMA start, even though the RX FIFO has plenty of
space. I'll go figure out why, but this shouldn't cause people to
be spammed by these messages.
Extend the AHB code to work on chips besides the AR9130.2013-06-26T04:58:25ZAdrian Chaddadrian@FreeBSD.org2013-06-26T04:58:25Zurn:sha1:30be7dd9c93c9113cc18c4417287b37a176c2eae
The AHB code:
* hard coded the AR9130 device id;
* assumes a 4k flash calibration space.
This code now extends this:
* hint.ath.X.eepromsize now overrides the eeprom range, instead of 4k
* hint.ath.X.device_id and hint.ath.X.vendor_id can now be overridden.
Tested:
* AR9330 board (Carambola 2)
Add a HAL local routine to map the 2GHz channel frequency to an IEEE2013-06-26T04:46:03ZAdrian Chaddadrian@FreeBSD.org2013-06-26T04:46:03Zurn:sha1:03f2665670d4832c865184fb3d3ec7b5eede70ae
channel.
There's some HAL code in the AR9300 HAL that requires a back-mapping
and using the net80211 code isn't appropriate here.
Add in an initial WB225 (AR9485 + AR3012 BT) combo profile.2013-06-14T08:18:17ZAdrian Chaddadrian@FreeBSD.org2013-06-14T08:18:17Zurn:sha1:8d6235fb66f65f0e32b9d41dc2fee3e816a4f0fc
This hasn't yet been tested as unfortunately the AR3012 I have doesn't
have the "real" firmware on it; it shipped with the cut down HCI firmware
that only understands enough to accept a new firmware image.
* Linux ath9k (GPIO constants)
Initial AR9485/AR933x 1x1 LNA diversity work.2013-06-14T03:42:10ZAdrian Chaddadrian@FreeBSD.org2013-06-14T03:42:10Zurn:sha1:0f0eebe793c5bb52b04971ead536604360596408
* Add the LNA configuration table entries for AR933x/AR9485
* Add a chip-dependent LNA signal level delta in the startup path
* Add a TODO list for the stuff I haven't yet ported over but
I haven't.
Tested:
* AR9462 with LNA diversity enabled
Set the antenna "config group" field.2013-06-12T15:18:10ZAdrian Chaddadrian@FreeBSD.org2013-06-12T15:18:10Zurn:sha1:de98311f505eae0a97c28362e57b816a46245978
The reference HAL pushes a config group parameter to the driver layer
to inform it which particular chip behaviour to implement.
This particular value tags it as an AR9285.
Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver.2013-06-12T14:52:57ZAdrian Chaddadrian@FreeBSD.org2013-06-12T14:52:57Zurn:sha1:216ca2346fff3a53770769146cf8a59a3f8c7b95
The AR9485 chip and AR933x SoC both implement LNA diversity.
There are a few extra things that need to happen before this can be
flipped on for those chips (mostly to do with setting up the different
bias values and LNA1/LNA2 RSSI differences) but the first stage is
putting this code into the driver layer so it can be reused.
This has the added benefit of making it easier to expose configuration
options and diagnostic information via the ioctl API. That's not yet
being done but it sure would be nice to do so.
Tested:
* AR9285, with LNA diversity enabled
* AR9285, with LNA diversity disabled in EEPROM