#
332303 |
|
08-Apr-2018 |
emaste |
MFC ath(4) potential memory disclosure fixes
[1] r327499: ath: fix memory disclosure from ath_btcoex_ioctl
The ath_btcoex_ioctl handler allocated a buffer without M_ZERO and returned it to userland without writing to it.
The device has permissions only for root so this is not urgent, and the fix can be MFCd and considered for a future EN.
[2] r327500: ath: fix possible memory disclosures in ioctl handlers
Apply the fix from r327499 to additional ioctl handlers.
[3] r327529: ath: fix possible memory disclosure in ioctl handler
Submitted by: Domagoj Stolfa <domagoj.stolfa@gmail.com> [1,3] Reported by: Ilja van Sprundel <ivansprundel@ioactive.com> [1,2] Reviewed by: adrian [1] Sponsored by: The FreeBSD Foundation
|
#
331722 |
|
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes.
Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes.
Requested by: gjb (re)
|
#
330897 |
|
14-Mar-2018 |
eadler |
Partial merge of the SPDX changes
These changes are incomplete but are making it difficult to determine what other changes can/should be merged.
No objections from: pfg
|
#
302408 |
|
07-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
301307 |
|
04-Jun-2016 |
adrian |
[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.
|
#
301186 |
|
02-Jun-2016 |
adrian |
[ath] correctly shift the QCA9565 LNA config into the mci config variable.
Tested:
* QCA9565, STA + BT mode
|
#
301181 |
|
01-Jun-2016 |
adrian |
[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
|
#
300896 |
|
28-May-2016 |
adrian |
[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
|
#
277277 |
|
16-Jan-2015 |
adrian |
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
|
#
257176 |
|
26-Oct-2013 |
glebius |
The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare to this event, adding if_var.h to files that do need it. Also, include all includes that now are included due to implicit pollution via if_var.h
Sponsored by: Netflix Sponsored by: Nginx, Inc.
|
#
251742 |
|
14-Jun-2013 |
adrian |
Add in an initial WB225 (AR9485 + AR3012 BT) combo profile.
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)
|
#
251606 |
|
10-Jun-2013 |
adrian |
Add another comment about WB195 (AR9285+AR3011) when using ASPM.
|
#
251487 |
|
07-Jun-2013 |
adrian |
Bring over the initial static bluetooth coexistence configuration for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC.
The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285.
The code in if_ath_btcoex.c sets up the initial hardware mapping and coexistence configuration. There's nothing special about it - it's static; it doesn't try to configure bluetooth / MAC traffic priorities or try to figure out what's actually going on. It's enough to stop basic bluetooth traffic from causing traffic stalls and diassociation from the wireless network.
To use this code, you must have the above NIC. No, it won't work for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards.
Then you set a kernel hint before boot or before kldload, where 'X' is the unit number of your AR9285 NIC:
# kenv hint.ath.X.btcoex_profile=wb195
This will then appear in your boot messages:
[100482] athX: Enabling WB195 BTCOEX
This code is going to evolve pretty quickly (well, depending upon my spare time) so don't assume the btcoex API is going to stay stable.
In order to use the bluetooth side, you must also load in firmware using ath3kfw and the binary firmware file (ath3k-1.fw in my case.)
Tested:
* AR9280, no interference * WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries were enough to cause traffic stalls and disassociations. This has stopped with the btcoex profile code.
TODO:
* Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence is enabled. No, I don't know why. It's likely some kind of bug to do with the AR3011 sending bluetooth coexistence signals whilst the device is asleep. Since we don't actually sleep the MAC just yet, it shouldn't be a problem. That said, to be totally correct:
+ ASPM should be disabled - upon attach and wakeup + The PCIe powersave HAL code should never be called
Look at what the ath9k driver does for inspiration.
* Add WB197 (AR9287+AR3012) support * Add support for the AR9485, which is another combo like the AR9285 * The later NICs have a different signaling mechanism between the MAC and the bluetooth device; I haven't even begun to experiment with making that HAL code work. But it should be a lot more automatic.
* The hardware can do much more interesting traffic weighting with bluetooth and wifi traffic. None of this is currently used. Ideally someone would code up something to watch the bluetooth traffic GPIO (via an interrupt) and then watch it go high/low; then figure out what the bluetooth traffic is and adjust things appropriately.
* If I get the time I may add in some code to at least track this stuff and expose statistics. But it's up to someone else to experiment with the bluetooth coexistence support and add the interesting stuff (like "real" detection of bulk, audio, etc bluetooth traffic patterns and change wifi parameters appropriately - eg, maximum aggregate length, transmit power, using quiet time to control TX duty cycle, etc.)
|