|
Revision tags: release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0 |
|
| #
718cf2cc |
| 27-Nov-2017 |
Pedro F. Giffuni <[email protected]> |
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
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.
show more ...
|
|
Revision tags: release/10.4.0, release/11.1.0 |
|
| #
41059135 |
| 25-May-2017 |
Adrian Chadd <[email protected]> |
[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 mod
[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.
show more ...
|
|
Revision tags: release/11.0.1, release/11.0.0, release/10.3.0 |
|
| #
7a79cebf |
| 27-Aug-2015 |
Gleb Smirnoff <[email protected]> |
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 li
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.
show more ...
|
|
Revision tags: release/10.2.0 |
|
| #
ba2c1fbc |
| 08-Aug-2015 |
Adrian Chadd <[email protected]> |
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
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.
show more ...
|
| #
79d2c5e8 |
| 07-Aug-2015 |
Gleb Smirnoff <[email protected]> |
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 devi
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
show more ...
|
| #
76e6fd5d |
| 29-May-2015 |
Gleb Smirnoff <[email protected]> |
Use device_printf() instead of if_printf(). No functional changes.
|
| #
06c746ed |
| 28-Jan-2015 |
Adrian Chadd <[email protected]> |
Print out the final_rix if there's a problem.
|
|
Revision tags: release/10.1.0, release/9.3.0, release/10.0.0 |
|
| #
76039bc8 |
| 26-Oct-2013 |
Gleb Smirnoff <[email protected]> |
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 po
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.
show more ...
|
|
Revision tags: release/9.2.0, release/8.4.0 |
|
| #
ee563d63 |
| 27-Feb-2013 |
Adrian Chadd <[email protected]> |
I give up - just throw the EWMA update into the normal update_stats() routine.
There were still corner cases where the EWMA update stats are being called on a rix which didn't have an intermediary s
I give up - just throw the EWMA update into the normal update_stats() routine.
There were still corner cases where the EWMA update stats are being called on a rix which didn't have an intermediary stats update; thus no packets were counted against it. Sigh.
This should fix the crashes I've been seeing on recent -HEAD.
show more ...
|
| #
38fda926 |
| 26-Feb-2013 |
Adrian Chadd <[email protected]> |
Update the EWMA statistics for each intermediary rate as well as the final rate.
This fixes two things:
* The intermediary rates now also have their EWMA values changed; * The existing code was usi
Update the EWMA statistics for each intermediary rate as well as the final rate.
This fixes two things:
* The intermediary rates now also have their EWMA values changed; * The existing code was using the wrong value for longtries - so the EWMA stats were only adjusted for the first rate and not subsequent rates in a MRR setup.
TODO:
* Merge the EWMA updates into update_stats() now..
show more ...
|
|
Revision tags: release/9.1.0 |
|
| #
bf57b7b2 |
| 31-Oct-2012 |
Adrian Chadd <[email protected]> |
I've had some feedback that CCK rates are more reliable than MCS 0 in some very degenerate conditions.
However, until ath_rate_form_aggr() is taught to not form aggregates if ANY selected rate is no
I've had some feedback that CCK rates are more reliable than MCS 0 in some very degenerate conditions.
However, until ath_rate_form_aggr() is taught to not form aggregates if ANY selected rate is non-MCS, this can't yet be enabled.
So, just add a comment.
show more ...
|
| #
e69db8df |
| 17-Sep-2012 |
Adrian Chadd <[email protected]> |
Improve performance of the Sample rate algorithm on 802.11n networks.
* Don't treat high percentage failures as "sucessive failures" - high MCS rates are very picky and will quite happily "fade" f
Improve performance of the Sample rate algorithm on 802.11n networks.
* Don't treat high percentage failures as "sucessive failures" - high MCS rates are very picky and will quite happily "fade" from low to high failure % and back again within a few seconds. If they really don't work, the aggregate will just plain fail.
* Only sample MCS rates +/- 3 from the current MCS. Sample will back off quite quickly, so there's no need to sample _all_ MCS rates between a high MCS rate and MCS0; there may be a lot of them.
* Modify the smoothing rate to be 75% rather than 95% - it's more adaptive but it comes with a cost of being slightly less stable at times. A per-node, hysterisis behaviour would be nicer.
show more ...
|
| #
f6fd8c7a |
| 27-Aug-2012 |
Adrian Chadd <[email protected]> |
Improve the sample rate logging.
|
| #
a055e7ce |
| 15-Aug-2012 |
Konstantin Belousov <[email protected]> |
Fix build
|
| #
193bfa21 |
| 15-Aug-2012 |
Adrian Chadd <[email protected]> |
Extend the sample mask from 32 bits to 64 bits.
This is required to support > MCS15 as more than 32 bit rate entries are suddenly available.
This is quite messy - instead of doing typecasts at each
Extend the sample mask from 32 bits to 64 bits.
This is required to support > MCS15 as more than 32 bit rate entries are suddenly available.
This is quite messy - instead of doing typecasts at each mask operation, this should be migrated to use a macro and have that do the typecast.
show more ...
|
| #
9f579ef8 |
| 01-Aug-2012 |
Adrian Chadd <[email protected]> |
Fix a case of "mis-located braces".
PR: kern/170302
|
| #
af017101 |
| 31-Jul-2012 |
Adrian Chadd <[email protected]> |
Allow 802.11n hardware to support multi-rate retry when RTS/CTS is enabled.
The legacy (pre-802.11n) hardware doesn't support this - although the AR5212 era hardware supports MRR, it doesn't have al
Allow 802.11n hardware to support multi-rate retry when RTS/CTS is enabled.
The legacy (pre-802.11n) hardware doesn't support this - although the AR5212 era hardware supports MRR, it doesn't have all the bits needed to support MRR + RTS/CTS. The AR5416 and later support a packet duration and RTS/CTS flags per rate scenario, so we should support it.
Tested:
* AR9280, STA
PR: kern/170302
show more ...
|
| #
be4f96a6 |
| 20-Jul-2012 |
Adrian Chadd <[email protected]> |
Introduce a rate table TLV so rate table statistics consumers know how to map rix -> rate code.
|
| #
2d20d655 |
| 20-Jul-2012 |
Adrian Chadd <[email protected]> |
Add a per-node rate control routine for each rate control module.
For now, the only module implement is 'sample', and that's only partially implemented. The main issue here with reusing this struct
Add a per-node rate control routine for each rate control module.
For now, the only module implement is 'sample', and that's only partially implemented. The main issue here with reusing this structure in userland is that it uses 'rix' everywhere, which requires the userland code to have access to the current HAL rate table.
For now, this is a very large work in progress.
Specific details:
* The rate control information is per-node at the moment and wrapped in a TLV, to ease parsing and backwards compatibility. * .. but so I can be slack for now, the userland statistics are just a copy of the kernel-land sample node state. * However, for now use a temporary copy and change the rix entries to dot11rate entries to make it slightly easier to eyeball.
Problems:
* The actual rate information table is unfortunately indexed by rix and it doesn't contain a rate code. So the userland side of this currently has no way to extract out a mapping.
TODO:
* Add a TLV payload to dump out the rate control table mapping so 'rix' can be turned into a dot11 / MCS rate. * .. then remove the temporary copy.
show more ...
|
| #
c312fb4a |
| 24-Jun-2012 |
Adrian Chadd <[email protected]> |
In a complete lack of foresight on my part, my previous commit broke the assumption that ath_softc doesn't change size based on build time configuration.
I picked up on this because suddenly radar s
In a complete lack of foresight on my part, my previous commit broke the assumption that ath_softc doesn't change size based on build time configuration.
I picked up on this because suddenly radar stuff didn't work; and although the ath_dfs code was setting sc_dodfs=1, the main ath driver saw sc_dodfs=0.
So for now, include opt_ath.h in driver source files. This seems like the sane thing to do anyway.
I'll have to do a pass over the code at some later stage and turn the radiotap TX/RX structs into malloc'ed memory, rather than in-line inside of ath_softc. I'd rather like to keep ath_softc the same layout regardless of configuration parameters.
Pointy hat to: adrian
show more ...
|
|
Revision tags: release/8.3.0 |
|
| #
cc86f1ea |
| 26-Feb-2012 |
Adrian Chadd <[email protected]> |
Add in some debugging code to check whether the current rate table has been bait-and-switched from the rate control code.
This will avoid the panic that I saw and will avoid sending invalid rates (e
Add in some debugging code to check whether the current rate table has been bait-and-switched from the rate control code.
This will avoid the panic that I saw and will avoid sending invalid rates (eg 11a/11g OFDM rates when in 11b, on 11b-only NICs (AR5211)) where the rate table is not "big".
It also will point out situations where this occurs for the 11n NICs which will have sufficiently large rate tables that "invalid rix" doesn't occur.
I'll try to follow this up with a commit that adds a current operating mode check. The "rix" is only relevant to the current operating mode and rate table.
PR: kern/165475
show more ...
|
| #
ec3dec2f |
| 09-Nov-2011 |
Adrian Chadd <[email protected]> |
Fix the compile to work when IEEE80211_DEBUG isn't defined.
Sponsored by: Hobnob, Inc.
|
| #
eb6f0de0 |
| 08-Nov-2011 |
Adrian Chadd <[email protected]> |
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices.
This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices.
This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch.
Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this.
In summary:
TX path:
* queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock.
Rate control:
* Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates.
Misc:
* Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future.
Known issues:
* There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained.
* Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs.
* There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang".
* Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out.
* HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete.
* The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches.
* .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted.
Because of this, ATH_ENABLE_11N is still not enabled by default.
Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros
show more ...
|
| #
87acb7d5 |
| 08-Nov-2011 |
Adrian Chadd <[email protected]> |
Some cosmetic fixes to ath_rate_sample.
* Use 64 bit integer types for the sample rate statistics. When TX'ing 11n aggregates, a 32 bit counter will overflow in a few hours due to the high packe
Some cosmetic fixes to ath_rate_sample.
* Use 64 bit integer types for the sample rate statistics. When TX'ing 11n aggregates, a 32 bit counter will overflow in a few hours due to the high packet throughput.
* Create a default label of "" rather than defaulting to "Mb" - that way if a rate hasn't yet been selected, it won't say "-1 Mb".
Sponsored by: Hobnob, Inc.
show more ...
|
| #
36958948 |
| 18-May-2011 |
Adrian Chadd <[email protected]> |
Modify the sample rate control algorithm to only select/sample HT rates for HT nodes.
|