Deleting a child explicitly before calling bus_generic_detach is now
redundant, so remove those calls and rely on bus_generic_detach to
delete children instead.
Differential Revision: https://reviews.freebsd.org/D47961
This provides better semantics as a standalone DEVMETHOD for
device_attach as bus drivers should remove child devices they created
as part of detach cleanup. The implementation calls
bus_detach_children() first to permit child devices an opportunity to
veto the detach operation. If that succeeds, device_delete_children()
is used to delete the child devices.
This requires fixing various drivers that were deleting devices
explicitly (via a device_t pointer cached in the softc) after calling
bus_generic_detach to stop doing that and just rely on
bus_generic_detach to remove child devices.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47959
This is simpler and more robust in the face of potential double-frees
(e.g. if called after bus_generic_detach which will delete devices in
a future commit).
Reviewed by: manu, imp
Differential Revision: https://reviews.freebsd.org/D47958
These drivers perform additional teardown steps in between detaching
child devices and deleting child devices.
Differential Revision: https://reviews.freebsd.org/D47957
The firmware version isn't enough; different firmware is loaded
for different revisions of a given chip. So print out the file too;
it'll make handling reports much easier.
Differential Revision: https://reviews.freebsd.org/D48067
Reviewed by: emaste
* remove the hard-coded ridx values in rate2ridx(), use the RIDX
defines for CCK/OFDM rates
* Add a placeholder rtwn_ctl_vhtrate() which returns the dot11rate
control rate to use for the given VHT rate index. Since net80211
currently doesn't have any VHT PHY tables, there's no mapping for
us to leverage so just return OFDM 12M for now.
* Use the new macro to convert rate index to MCS rate
* Add a printf() in rate2ridx if it's passed a HT/VHT rate.
Differential Revision: https://reviews.freebsd.org/D48098
Reviewed by: bz
This register (array) controls the initial rate to use for each
MACID. There's no need to set it if firmware rate control is enabled -
it'll actually be under firmware control (and we can read it back to
see what choices the firmware is making.)
Locally tested:
* RTL8188EU, STA
* RTL8192CU, STA
* RTL8192EU, STA
Differential Revision: https://reviews.freebsd.org/D48094
Reviewed by: bz
The RTL8188E firmware doesn't have the "full" offload firmware
rate control. Instead, the vendor driver has a bunch of logic
in the driver for rate probing and selection.
Part of this is the periodic TX report - which uploads a summary
of multi-rate retries and drops per MAC. Using it drastically
cuts down on the TX notifications - it's fired from a timer
(defaulting to ~ 1.6 seconds) and is a single receive frame in
the normal bulk RX path.
I've not ported / reimplemented the whole vendor driver rate adaption
code - instead, I'm just using the normal net80211 rate control APIs.
It seems to behave OK - I get 25-30mbit down and 20mbit up using TCP/
speedtest.
Locally tested:
* RTL8188EU, STA mode
Differential Revision: https://reviews.freebsd.org/D48088
Reviewed by: fuz, bz
Obtained from: https://github.com/lwfinger/rtl8188eu/blob/master/hal/Hal8188ERateAdaptive.c
Add support to read/write the MAC/PHY registers.
Hide it behind RTWN_DEBUG.
This doesn't cover the RF registers as they require a different
IO path, but I haven't yet debugged the RF paths.
Locally tested:
* RTL8192CU, STA
* RTL8188EU, STA
* RTL8812AU / RTL8821AU, STA
Differential Revision: https://reviews.freebsd.org/D48084
Reviewed by: bz
I've reviewed all of the linux vendor and upstream drivers.
This SEQ_SEL field isn't a mask and doesn't ever look like it
it was; instead this bit is set to tag QoS data frames.
In fact, it effectively was set to 0 for STA frames and potentially 1
for broadcast/multicast frames as the STA macid of 0 and broadcast/
multicast macid of 1 maps to that. In AP modes it would be tagged
based on bit 0.
So, bring it in line with the vendor and linux drivers.
Locally tested:
* RTL8192CU, STA, hostap
* RTL8188EU, STA
* RTL8192EU, STA
Differential Revision: https://reviews.freebsd.org/D48092
For requests that handoff queues from userspace to the kernel as well
as the request to fetch reconnect parameters from the kernel, switch
from using flat structures to nvlists. In particular, this will
permit adding support for additional transports in the future without
breaking the ABI of the structures.
Note that this is an ABI break for the ioctls used by nvmf(4) and
nvmft(4). Since this is only present in main I did not bother
implementing compatability shims.
Inspired by: imp (suggestion on a different review)
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48230
Most pci controllers will just have a single reg for the config space,
but others (e.g., on Apple Silicon) may have more following that to
describe, e.g., controller port space. Bump the "ranges" rid space up
to avoid overriding these other memory resources.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D43921
In function ocs_scsi_recv_tmf, print instance_index rather than
the pointer itself to avoid printing out kernel pointer to user space.
PR: 238659
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
Reviewed-by: imp
My previous commit meant that APPFCS wasn't enabled during monitor
mode and likely other corner cases.
Ensure it stays on at all times.
This, amusingly, fixes monitor mode in RTL8812AU/RTL8821AU - without it,
I don't see HT/VHT frames in monitor mode but I can still receive them
in normal STA mode.
Differential Revision: https://reviews.freebsd.org/D48112
The resource list entry needs to be looked up using rman_get_* prior
to releasing the resource.
Fixes: 9dbf5b0e68 new-bus: Remove the 'rid' and 'type' arguments from BUS_RELEASE_RESOURCE
unless the dev.acpi_ibm.0.handlerevents sysctl is set to process
them internally. The default for the latter is to ignore them,
so passing to evdev(4) is enabled by default.
Reviewed by: wulf, imp
Tested on: Lenovo Thinpad X11 Carbon 7Th Gen
Differential Revision: https://reviews.freebsd.org/D48174
The pmc_md_{intialize, finalize} routines rely on a machine-dependent
structure to register the appropriate PMC interrupt handler. However,
the vendor-specific routines that allocate this structure may return
NULL for unsupported hardware, leading to a panic when the hwpmc module
gets loaded. This patch adds additional checks that fix this issue.
Reported by: Michael Butler (imb@protected-networks.net)
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D48168
Wrong signedness of usage value results in inverted range check in hmt(4)
driver that allows out of bound array access leading to panic.
Reported by: many
Sponsored by: Future Crew, LLC
Obtained from: NetBSD
NetBSD PR: kern/53605
PR: 274014, 282592
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
Add the missing bus_add_child DEVMETHOD. This is needed for the RPi5
running with a MMCCAM kernel and the worproject/rpi5-uefi to avoid a
kernel panic on boot when SDIO tries to attach to a 'Intel Bay Trail'
controller.
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D48152
The rate control message was doing 11g+11n without 11b rates, but
the TX descriptor setup supports also falling back on 11b rates
when doing multi-rate retry / per-descriptor rate control.
So, line them up. They're not exactly the same as the TX path
supports pure-N and pure-G modes which the rate control configuration
does not, but there'll need to be a lot more work on supporting
those operating modes anyway (around things like self-generated
frame rate control/masks, beacon config, RTS/CTS selection, etc.)
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48081
Reviewed by: bz
I'm unable to reproduce the original problem with my RTL8192CU USB
devices with the current codebase and I can't find any reference
to what this power register is doing - I see it defined in drivers,
but it's not described or used anywhere.
This reverts 7f74097165 -
rtwn_usb(4): fix Tx instability with RTL8192CU chipsets
In any case being able to do higher rate RTS/CTS is beneficial.
Local testing:
* rtl8192cu, STA mode, TX/RX testing
PR: 233949
Differential Revision: https://reviews.freebsd.org/D48026
Reviewed by: imp
I noticed during testing that the MAC was generating MCS7 ACKs and
MCS7 block-ACK frames in response to MCS frames from its peer.
This is very suboptimal - it means that unless you're very close
to your peer (in this case a 2GHz AP), you'll end up failing a lot
of ACKs.
Linux faced the opposite problem in rtl8xxxu - the rate set being
programmed in here included a lot MORE rates, including MCS 0->7
and OFDM 6M->54M. This meant that they were INTENTIONALLY telling
the hardware to transmit at higher rates, and their fix was to
mask out the higher rates so self-generated frames don't try the
high rates at all.
Now, I am not sure why I'm not seeing any OFDM or HT basic rates.
We don't mark any OFDM / HT rates as basic in net80211 (in
ieee80211_phy.c) so I'm going to need to go and do a review of the
standard to see what's up. Additionally, the HT rate set that we
populate isn't tagging any of the HT rates as IEEE80211_RATE_BASIC,
so the code I added for now is a no-op.
So:
* Extend rtwn_get_rates() and its consumers to populate the HT rateset
with basic rates if they're provided
* Add a default 2GHz / 5GHz mask, inspired by linux, applied over the
basic rates provided.
* Make sure there's at least an OFDM rate (for 2G/5G) rate available if
the peer node is HT, which avoids the MAC defaulting to MCS7 when
generating ACK/block-ACK.
* Add register definitions for INIDATA/INIRTS, which set the default
data rate when the driver doesn't specify the initial data / RTS/CTS
rates in the TX descriptor.
* Leave a comment about why I've modified the mask from Linux.
Locally tested:
* RTL8192CU, STA mode
* RTL8188EU, STA mode
* RTL8192EU, STA mode
* RTL8812AU, STA mode
Differential Revision: https://reviews.freebsd.org/D48019
Reviewed by: bz
Driver defined all flow context actions in MLX5_FLOW_CONTEXT_ACTION_*,
no need to duplicate them with mlx5_rule_fwd_action.
Sponsored by: NVidia networking
MFC after: 1 week
The 32 bit bitmap is enough for CCK/OFDM rates and MCS0..15, but
won't work for > MCS15, nor VHT rates.
So, break out the legacy rates and HT rates.
* break the rates and htrates out
* document which calls are looking up basic rates and which care
about the rates themselves
* ensure the rate bitmap passed into the rate control firmware call
(which isn't enabled yet!) is capped at 28 bits so they don't
set the mode field.
Differential Revision: https://reviews.freebsd.org/D47993
Reviewed by: bz, imp
This should be a *9 rather than a *10 so higher stream MCS rates
(eg comparing MCS0 and MCS8) that have slightly longer average transmit
times (but better burst transmit times) get considered.
This mirrors what the later code does when considering if a rate
change is needed.
Locally tested:
* AR9280, AP mode
* AR9380, AP mode
Differential Revision: https://reviews.freebsd.org/D47988
Reviewed by: imp
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
* Refactor out the TX power register register dump - it's done in
a couple places and it makes sense to refactor it.
* Condense the output into a few lines per transmit chain. It's
very long with the 8 and 16 MCS rates, and it made it difficult
to eyeball what's going on when tweaking TX power.
Differential Revision: https://reviews.freebsd.org/D47986
Reviewed by: bz, imp
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
This apparently kicks off TX power level self-calibration, which
can't hurt.
Locally tested:
* RTL8812AU, STA
* RTL8821AU, STA
Obtained from: Linux rtw88
Differential Revision: https://reviews.freebsd.org/D47978
Reviewed by: bz, imp
Otherwise this matches any two-character status except for ok.
Fixes: e5e94d2de9 ("Expand OpenFirmware API with ofw_bus_node_status_okay method")
MFC after: 1 week
This is identical to AON clocks. The only difference is
BUS_PASS_ORDER_LAST which was needed for some reason. This has clocks
needed by PCIe controller driver.
Reviewed by: mhorne
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47920
This patch adds some SYS clocks for StarFive JH7110. They are necessary
for getting STG clocks and PCIe driver working.
Reviewed by: mhorne
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47981
Avoids usage of arp_ifinit() and if_foreach_addr_type(). The former
isn't encouraged to be used in drivers and the latter is about to
change to not expose struct ifaddr.
Reviewed by: royger, ehem_freebsd_m5p.com
Differential Revision: https://reviews.freebsd.org/D48053
Change POOL_NEXT_SIZE define value from 0 to BIT(30), since this define
is used to request the available maximum sized flow table, and zero doesn't
make sense for it, whereas many places in the driver use zero explicitly
expecting the smallest table size possible but instead due to this
define they end up allocating the biggest table size unawarely.
Sponsored by: NVidia networking
Align the code of fdb steering with flow steering core
and add missing parts in namespace initialization and
in prio logic
PR: 281714
Sponsored by: NVidia networking
Register the PCINT handler using the nmi_{register, remove}_handler
interfaces (introduced in D46421) in preparation for hwt(4)'s
Intel Processor Trace backend. No functional change intended.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D47989
This patch refactors the Performance Counter interrupt setup code to
allow sharing the interrupt line between multiple drivers.
More specifically, Performance Counter interrupts are used by both
hwpmc(4) and hwt(4)'s upcoming Intel Processor Trace backend.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D46420
* add a register value for the R92C_FPGA0_POWER_SAVE register
* add the field names and mask
* add a mask for the 40MHz upper/lower bits in R92C_RMRR; I think
I need to debug and overhaul the 20/40MHz config path to get 40MHz
working right.
Local testing:
* rtl8188eu, sta mode
* rtl8192cu, sta mode
