#
9efd2154 |
| 13-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: create a new HAL routine for enabling STA mode beacon processing
For some NICs (notably the rtl8192cu that I'm working on) the firmware rate adaptation requires beacon processing to be enabled
rtwn: create a new HAL routine for enabling STA mode beacon processing
For some NICs (notably the rtl8192cu that I'm working on) the firmware rate adaptation requires beacon processing to be enabled.
Instead of making assumptions in the if_rtwn beacon routines (and honestly all of that should be in the HAL too), create a HAL method for enabling/disabling beacon processing specifically in STA mode.
Since this isn't necessarily required for all NICs (notably the RTL8188E NICs, where some will do firmware rate control and some will require driver rate control), only enable it for the RTL8192CU and RT8192EU.
The RTL8188E and RTL8812/RTL8821 just have no-op routines for now.
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48066 Reviewed by: bz
show more ...
|
#
0ea7f8ca |
| 08-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: try enforcing net80211 regulatory / txpower limits for 11n chips
This is an attempt to reverse engineer what the actual transmit power calculations are doing and apply net80211 limits on them.
rtwn: try enforcing net80211 regulatory / txpower limits for 11n chips
This is an attempt to reverse engineer what the actual transmit power calculations are doing and apply net80211 limits on them. It doesn't look as simple as just applying the check at the end - there are plenty of places where offsets are calculated between different PHY modes and 1 / 2 antenna MCS transmit rates.
There are also some places where the offset being added is negative, so handle the potential underflow so when things hit 0, they don't just wrap and cause the maximum transmit power into the registers.
This is being done to aide in power/performance debugging - if there are issues with the transmit power being wrongly calculated and are too high, the output waveform will be distorted and it will effect performance. Being able to drop the transmit power by a few dB here and there can quickly identify if this is happening (because suddenly higher MCS rates / OFDM rates suddenly work better!)
I've tested each NIC through the transmit power values from 0 dBm to 30dBm via ifconfig (and they're all capped far before that, normally around 20-25dBm) and they're not underflowing.
Locally tested:
* RTL8192CU, STA * RTL8192EU, STA * RTL8188EU, STA
Differential Revision: https://reviews.freebsd.org/D47987 Reviewed by: bz, imp
show more ...
|
#
b71805e9 |
| 07-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: add APIs for setting transmit power
The RTL8188/RTL8192/RTL8821/RTL8812 NICs all seem happy to have their transmit power changed at runtime - and it does seem to do what's expected - the trans
rtwn: add APIs for setting transmit power
The RTL8188/RTL8192/RTL8821/RTL8812 NICs all seem happy to have their transmit power changed at runtime - and it does seem to do what's expected - the transmit power level does change.
So, add the API call here, even though it's all currently no-ops. A follow-up commit will land changes for the chipsets to both limit transmit power to the configured / regulatory limit AND allow reconfiguration at runtime.
Differential Revision: https://reviews.freebsd.org/D47979 Reviewed by: bz, imp
show more ...
|
#
b59017c5 |
| 04-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: add placeholder for the per-MACID rate report
Some chipsets (such as the RTL8188E) have firmware which supports a second kind of TX report - instead of a per-packet TX report, it can generate
rtwn: add placeholder for the per-MACID rate report
Some chipsets (such as the RTL8188E) have firmware which supports a second kind of TX report - instead of a per-packet TX report, it can generate a per-MACID summary of packet success/failure counters.
This would be helpful for those chips to cut back on the USB traffic to get rate control feedback for the driver based rate control we're currently using.
This is a no-op; it just gets the pieces in place for future work.
Differential Revision: https://reviews.freebsd.org/D47894
show more ...
|
Revision tags: release/14.2.0, release/13.4.0, release/14.1.0, release/13.3.0, release/14.0.0 |
|
#
685dc743 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0 |
|
#
b3f3786e |
| 02-Jan-2019 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
rtwn_pci(4): add support for RTL8188EE chipset.
Initially based on https://reviews.freebsd.org/D15692; later deduplicated and improved a bit (Tx reports, IQ calibration support).
Submitted by: Farh
rtwn_pci(4): add support for RTL8188EE chipset.
Initially based on https://reviews.freebsd.org/D15692; later deduplicated and improved a bit (Tx reports, IQ calibration support).
Submitted by: Farhan Khan <khanzf@gmail.com> MFC after: 4 days Relnotes: yes Differential Revision: https://reviews.freebsd.org/D15692
show more ...
|