Replace various void * / int argument combinations with common structures:
- ieee80211_ratectl_tx_status for *_tx_complete();
- ieee80211_ratectl_tx_stats for *_tx_update();
While here, improve amrr_tx_update() for a bit:
1. In case, if receiver is not known (typical for Ralink USB drivers),
refresh Tx rate for all nodes on the interface.
2. There was a misuse:
- otus(4) sends non-decreasing counters (as originally intended);
- but ural(4), rum(4) and run(4) are using 'read & clear' registers
to obtain statistics for some period of time (and those 'last period'
values are used as arguments for tx_update()). If arguments are not big
enough, they are just discarded after the next call.
Fix: move counting into *_tx_update()
(now otus(4) will zero out all node counters after every tx_update() call)
Tested with:
- Intel 3945BG (wpi(4)), STA mode.
- WUSB54GC (rum(4)), STA / HOSTAP mode.
- RTL8188EU (urtwn(4)), STA mode.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D8037
This trips me up whenever I'm fooling around with partially supported
NICs that fail to fully attach or initialise - the firmware gets loaded
and references, but something fails - and the firmware references
aren't cleaned up.
After perusing the PHY-LP code (don't ask why; honest) I discovered that
it /has/ 5GHz support - but it's not ever used. I found one NIC - a
BCM4312 w/ pci id 0x4315 - which advertised dual-band PHY-LP support.
Turns out it works.
Whilst here, move up the support bit logging code so I can use it
to debug this.
Tested:
* BCM4312 (pci id 0x4315); 5GHz STA operation
* convert phy_getinfo() to take a "gmode" flag, rather than the siba
TGSHIGH flags and then check for 2GHz. This should ensure that
gmode is set correctly even on DUALPHY NICs.
* move the siba_powerup() call and the TGSHIGH decoding into a
call to bwn_is_bus_siba(), and return an error if it's called
on anything else. We don't yet do anything else, but when we do..
Tested:
* BCM4322, 11a STA
That pops up in the rev 5xx / 6xx microcode on the later cores
(4312, 4322.) I'm not sure why this is happening yet and I'll
dig into it, but Linux b43 does the same thing.
* Add the new TX/RX frame formats;
* Use the right TX/RX format based on the frame info;
* Disable the 5xx firmware check, since now it should
somewhat work (but note, we don't yet use it unless
you manually add ucode11/initvals11 from the 5.x driver
to bwn-kmod-firmware;
* Misc: update some comments/debugging now I know what's
actually going on.
Tested:
* BCM4321MC, STA mode, both 4xx and 666 firmware, DMA mode
TODO:
* The newer firmware ends up logging "warn: firmware state (0)";
not sure yet what's going on there. But, yes, it still works.
I'm committing this via a BCM4321MC, 11a station, firmware
rev 666.
Obtained from: Linux b43 (TX/RX descriptor format for 5xx)
* always allocate maximum size txhdr entries
* set the right rx header offset/framesize based on firmware
This still isn't what's completely required for fw 598 support; there's
more to come.
Tested:
* Apple BCM94321MC 11abgn NIC, 11a STA mode, firmware version 4xx.
Obtained from: DragonflyBSD (txhdr entry sizing), fw 598 RX header size (linux b43)
This is an updated version of D6140.
Tested:
* BCM4321 11abgn, STA mode (11a)
Submitted by: avos
Differential Revision: https://reviews.freebsd.org/D6140
* DUALPHY in TGSHIGH tells us there's a phy that is dualband, rather than
two separate PHYs/MACs (which we almost but don't quite yet support.)
Use it.
* Add the BCM4322 PCI ID to the list of devices we don't override.
This means the 2g/5g flags are preserved, and thus we get 5GHz
operation (with N-PHY, of course.)
Tested:
* BCM4311, STA mode (11bg)
* BCM4312, STA mode (11bg)
* BCM4321, STA mode (11abg)
Sponsored by: Palm Springs
N-PHY and later require a lot more plcp specific setup for the PHY
to know what to transmit. I've been spoilt by the atheros, intel
and realtek parts where you don't have to hand-assemble the PLCP
but .. well, apparently Broadcom require a lot more work.
This, and PHY-N itself, was the last major missing bit to get 11a
OFDM transmit to work. Without this, CCK transmit worked but
OFDM transmit would always fail (with stat.phy_err set to 0x80.)
I have no idea what 0x80 is, and I went mad reading the broadcom
vendor driver to try and figure it out.
Tested:
* BCM4312 (PHY-LP)
* BCM4321 (PHY-N), 11a, 11bg.
Set phy-full-init always to 1 for now; PHY-N supports being able to do
partial init for things like fast channel changes but I'm going to
ignore it all.
* Log the per-completion status out if requested
* If we get a PHY failure, the retrycnt is set to 0 and ack=0, so
the logic was incorrect. So, for ack=0, ensure we don't log
a retrycnt of 0 (or rate control breaks) or a negative retrycnt
(or rate control also breaks.)
Tested:
* BCM4321 (11abgn N-PHY), BCM4312 (LP-PHY)
* Ensure we set 20MHz wide channels (hard-coded) for PHY-N.
* Change the core rese tto take a flag saying "gmode" vesus uint32_t
flags. This is important for BCMA support where the "gmode" bit
is different.
* Refactor out the mac-phy clock reset routine (usde by PHY-N).
Tested:
* BCM4321 (PHY-N), BCM4312 (PHY-LP)
TODO:
* Checkpoint test on PHY-G hardware, just to check.
Different versions of firmware have different requirments for TX/RX
packet layouts (and other things, of course.) Currently the driver
checks between 3xx and 4xx firmware by using the BWN_ISOLDFMT() macro,
which doesn't take into account the 5xx firmware (which I think I need
for the HT and N series PHY chips. I'll know when I do the port.)
BWN_HDRSIZE() also needs to learn about the 5xx series firmware
as well.
So:
* add a firmware version enum
* populate it based on the firmware version we read at load time
* don't finish loading if the firmware is the 5xx firmware; any
code using BWN_ISOLDFMT or BWN_HDRSIZE needs updating (most notably
the TX and RX bits.)
Then, for RX RSSI:
* write down and reimplement the b43 rssi calculation method;
* use it for the correct PHYs (which are all the ones we support);
* do the RSSI calculation before radiotap, not after.
Tested:
* Broadcom BCM4312, STA mode
Obtained from: Linux b43 (careful writing and reimplementing; lots of integer math..)
This is an initial work in progress to use the replacement bhnd
bus code for devices which support it.
* Add manpage updates for bhnd, bhndb, siba
* Add kernel options for bhnd, bhndbus, etc
* Add initial support in if_bwn_pci / if_bwn_mac for using bhnd
as the bus transport for suppoted NICs
* if_bwn_pci will eventually be the PCI bus glue to interface to bwn,
which will use the right backend bus to attach to, versus direct
nexus/bhnd attachments (as found in embedded broadcom devices.)
The PCI glue defaults to probing at a lower level than the bwn glue,
so bwn should still attach as per normal without a boot time tunable set.
It's also not fully fleshed out - the bwn probe/attach code needs to be
broken out into platform and bus specific things (just like ath, ath_pci,
ath_ahb) before we can shift the driver over to using this.
Tested:
* BCM4311, STA mode
* BCM4312, STA mode
Submitted by: Landon Fuller <landonf@landonf.org>
Differential Revision: https://reviews.freebsd.org/D6191
* Add a debug print for the xmit completion status fields.
Yes, I like staring at a stream of DWORDS.
* Set the retrycnt to the number of full frame retries for now;
I'll figure out how to factor rts/cts failures into it when
I figure out what the difference is.
It's -1 because it's not "retries", it's "tries".
It now passes the youtube test.
Tested:
* BCM4312, STA mode
I noticed that it'd associate fine, but it'd quickly stop exchanging traffic.
Receive was okay, but transmit just failed.
Then I went "wlandebug +rate". I discovered it started at 36M OFDM, and then
quickly rose to 54M, which then showed 0% transmit success.
Then, I dug into how the completion path works. We are reading 'ack=0'
in the TX status side, so .. then I discovered we were only processing the
TX completion status /if/ ack=1. So, we'd only ever count successes;
we'd never count failures, and thus the rate control code thought
everything was a-ok.
We also have to set retrycnt to something non-zero so it indeed does
bring the rate down upon failure.
So:
* Delete the rate control completion code from the tx completion
routine, it's just duplicate and never worked. Putting it behind
'if (status->ack) was pointless.
* Move it to the PIO and DMA completion routines which actually
do free the node reference and mbuf. We know at that point
what the status is, so do it there.
* Fake a retrycnt of 1 for now, so we at least count failures.
Also:
* Start adding comments about weird stuff I find with rate selection.
In this instance, we shouldn't be selecting a fallback rate that
doesn't match the currently configured mode (11a, 11b, 11g, etc.)
This isn't perfect - AMRR does try 54mbit and takes a few packets
before it figures out it's a bad idea - but it's better than nothing.
This makes the bwn(4) driver actually useful for the first time since
I've tried using it - and that dates back to 2011. I've resisted
successfully until now.
Tested:
* Broadcom BCM4312 802.11b/g Wireless, STA mode
WLAN (chipid 0x4312 rev 15) PHY (analog 6 type 5 rev 1) RADIO (manuf 0x17f ver 0x2062 rev 2)
TODO:
* See if the fallback rate actually /is/ working
* Question my own sanity over touching this driver in the first place.
Falling back from 6MB OFDM to 5MB CCK (a) may not work well in the
11bg PHYs, (b) won't work at all if you're 11g only, and (c) plainly
won't work for the 11a PHY.
So, don't do that!
Tested:
* BCM4312 802.11b/g Wireless, STA mode
WLAN (chipid 0x4312 rev 15) PHY (analog 6 type 5 rev 1) RADIO (manuf 0x17f ver 0x2062 rev 2)
* Break out the 'g' phy code;
* Break out the debugging bits into a separate source file, since
some debugging prints are done in the phy code;
* Make some more chip methods in if_bwn.c public.
This brings the size of if_bwn.c down to 6,805 lines which is now
approaching managable.
This (and eventually migrating the other PHY code out) is in preparation
for adding the 11n PHY. No, the 11ac PHY (for the BCM4260 softmac part) isn't
yet open source, so we can't grow that. Yet.
This trims ~3,700 lines of code from if_bwn.c, bringing it down to a slightly
less crazy sounding 10,446 lines of code.
No functional change, only trivial cases are done in this sweep,
Drivers that can get further enhancements will be done independently.
Discussed in: freebsd-current
taskqueue_enqueue() was changed to support both fast and non-fast
taskqueues 10 years ago in r154167. It has been a compat shim ever
since. It's time for the compat shim to go.
Submitted by: Howard Su <howard0su@gmail.com>
Reviewed by: sephe
Differential Revision: https://reviews.freebsd.org/D5131
