summaryrefslogtreecommitdiffstats
path: root/sys/dev/ath
Commit message (Collapse)AuthorAgeFilesLines
* Call the WMAC DDR flush before handling an interrupt for theadrian2015-07-041-1/+9
| | | | | | | | Atheros AHB (internally) connected MAC. TODO: * verify the interrupt was for us before doing the DDR flush.
* Wake up the hardware before doing anything in sysctl.adrian2015-07-041-48/+231
| | | | | | | | | | | | | | | | | | 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
* Use device_printf() instead of if_printf(). No functional changes.glebius2015-05-295-80/+94
|
* Change three methods in struct ieee80211com, namely ic_updateslot,glebius2015-05-251-10/+9
| | | | | | | | ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com, not to the ifnet. Sponsored by: Netflix Sponsored by: Nginx, Inc.
* Set ic_softc in all 802.11 drivers. Not required right now, but will beglebius2015-05-251-0/+1
| | | | | | | used quite soon. Sponsored by: Netflix Sponsored by: Nginx, Inc.
* Begin plumbing ieee80211_rx_stats through the receive path.adrian2015-05-253-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Make net80211 drivers supply their device name to the net80211 layer, soglebius2015-05-251-0/+1
| | | | | | | that the latter doesn't need to go through struct ifnet to get their name. Sponsored by: Netflix Sponsored by: Nginx, Inc.
* CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than tenjkim2015-05-221-1/+1
| | | | | | | | | | 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
* Return the correct HAL data type for HAL_DIAG_ANI_STATS.adrian2015-04-062-20/+10
| | | | | | | | | | | | | 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.
* Use the HAL API for returning ar5212AniState, rather than just dumpingadrian2015-04-012-3/+24
| | | | AniState itself.
* Start the process of migrating the ANI statistics out of the HALs and intoadrian2015-04-014-4/+48
| | | | | | | | | | | | | | | | 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.
* Move the HAL channel survey support out to be in the top-level HAL,adrian2015-03-298-30/+58
| | | | | | | | | | | | 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.
* Add a new field to HAL_ANISTATS - the extension channel busy count.adrian2015-03-291-0/+1
| | | | | 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.
* Fix more ticks wrapping bugs exposed by the ticks wrapping bug check.adrian2015-03-291-3/+3
| | | | | | | | | | | | | | 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
* Fix a long-standing bug with the early MAC address initialisation path,adrian2015-03-291-1/+5
| | | | | | | | | | | | | 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.
* Update if_ath(4) to check for "hint.ath.X.macaddr" for an override MAC address.adrian2015-03-281-2/+58
| | | | | | 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.
* Lay some groundwork for having this stuff hang off of AHB rather thanadrian2015-03-021-3/+16
| | | | | | | | 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.
* Move the lock destruction/creation to earlier in the process - ifadrian2015-02-141-15/+20
| | | | | | | | | | 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.
* Cast everything to something longer than 32 bits so the sample maskadrian2015-01-281-1/+1
| | | | | | | | | | | | 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
* Print out the final_rix if there's a problem.adrian2015-01-281-2/+2
|
* Add a new HAL capability - required to compile the updated AR9300adrian2015-01-281-1/+2
| | | | HAL i have lying about.
* Oops; correctly reload the CCA registers with the uncapped valueadrian2015-01-171-1/+2
| | | | | | | | | 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
* Until there's a full MCI implementation - just implement a placeholderadrian2015-01-171-0/+68
| | | | | | | | | | | | | | | | | | | 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
* Add bluetooth MCI coexistence HAL methods - used for AR9462 and AR9565 NICs.adrian2015-01-161-0/+12
| | | | | | | | | | | It's found, amongst other things, in the Acer Chromebook (Intel) devices. Tested: * AR9462 (WB222) Obtained from: Qualcomm Atheros
* Check the right value correctly.adrian2015-01-161-1/+1
| | | | Thanks to clang for pointing out this silliness.
* Bump the valid GPIO range for rfkill up from 8 to 16.adrian2014-12-231-1/+9
| | | | | | | | 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>
* Fix the following -Werror warning from clang 3.5.0, while building thedim2014-11-231-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Convert the callouts back to using mutexes.adrian2014-11-151-10/+4
| | | | | | | | 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
* Migrate the callouts from using mutex locks to being mpsafe withadrian2014-11-141-9/+23
| | | | | | the locks being held by the callers. Kill callout_drain() and use callout_stop().
* Add a missing file from the last commit.adrian2014-09-301-0/+669
| | | | Noticed by: jhibbits
* Add initial support for the AR9485 CUS198 / CUS230 variants.adrian2014-09-3017-11/+232
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO.adrian2014-09-203-83/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Mechanically convert to if_inc_counter().glebius2014-09-183-10/+12
|
* Shut down RX before TX - in theory, this should make the chip less likelyadrian2014-08-232-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Bump the HAL_REGRANGE fields from 16 bit to 32 bit.adrian2014-08-092-6/+7
| | | | | | | | 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.
* Add two new debug mark entries for chip power configuration.adrian2014-08-091-0/+3
|
* an isn't used, so eliminate it.imp2014-08-081-2/+0
|
* Remove ia64.marcel2014-07-072-4/+2
| | | | | | | | | | | | | | | | | 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
* Pull in r267961 and r267973 again. Fix for issues reported will follow.hselasky2014-06-283-10/+5
|
* Revert r267961, r267973:gjb2014-06-273-5/+10
| | | | | | | | | | 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
* Extend the meaning of the CTLFLAG_TUN flag to automatically check ifhselasky2014-06-273-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add casts to have it compile on amd64 without complaining aboutadrian2014-05-071-6/+9
| | | | | | | | mismatched types. Tested: * AR9280, TDMA slave, amd64.
* There's no need to be this paranoid - ni is deferenced before thisadrian2014-05-071-1/+1
| | | | | | point. Coverity ID: CID 1211937
* Modify the RX path to keep the previous RX descriptor around once it'sadrian2014-05-063-17/+122
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* Wake up the hardware before calling ath_mode_init() in the ioctl() path.adrian2014-05-051-0/+2
| | | | | | Tested: * AR5416, STA + powersave
* Break out the multicast programming into its own hardware specificadrian2014-05-051-6/+30
| | | | | | | | | | | | | | | | 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
* Quieten the RX/TX descriptor and FIFO setup debugging.adrian2014-05-052-14/+21
| | | | | | Tested: * AR9485, STA mode
* Add Atheros AR1111 support to the HAL.adrian2014-05-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add tracking for self-generated frames when the VAP is in sleep state.adrian2014-05-023-11/+112
| | | | | | | | | | | | | | | | | | | 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
* * Modify the beacon interval in debugging to be ni_intval, not 102400adrian2014-04-301-13/+17
| | | | | | | | * Be paranoid about avoiding divide-by-zero. Tested: * AR9380, STA mode
OpenPOWER on IntegriCloud