According to the rtl8812au reference driver, this seems to control
the bandwidth used by lower-bandwidth frames when transmitted in
a higher bandwidth channel. For example, transmitting a 20MHz frame
on an 80MHz channel (eg in hostap mode) is doable, but you may want
to at least duplicate the RTS/CTS exchange across all four 20MHz
subchannels, AND perhaps duplicate the 20MHz frame.
I haven't fired this up with a spectrum analyser to see what the
result is.
The vendor driver doesn't bother with this and it doesn't change
performance. My guess is that for modes like AP mode we MAY wantto
be able to control the RTS/CTS bandwidth choices rather than letting
the firmare do it, but we're not there yet.
The rtl8812au code in hal/rtl8812a_xmit.c:SCMapping_8812() has
the gory details, but then the one place it's used just has it
commented out and 0 (ie "do not care") is always programmed in.
Differential Revision: https://reviews.freebsd.org/D48113
Obtained from: https://github.com/lwfinger/rtl8812au
Reviewed by: bz
ipv6 flow tables were not connected to previous FS tables.
Created an additional table to serve as IPsec RX root.
This table has 2 rules for redirecting the received packets
to ipv4/ipv6 based on the IP family in the packet header.
Sponsored by: NVidia networking
If the passed in rate is a VHT rate, use rtwn_ctl_vhtrate() to
find a suitable rate for RTS/CTS.
Differential Revision: https://reviews.freebsd.org/D48295
Reviewed by: bz, cy, emaste
It uses the same audio codec as 12th gen (PCI ID 0x0002).
Actually everything is the same, except the CPU.
Signed-off-by: Daniel Schaefer <dhs@frame.work>
Fix a copy-and-paste error in acpi_pcib_request_feature where the
child device was passed into acpi_pcib_osc rather than the pcib
device.
Reviewed by: garga, jhb
Fixes: ba1904937d ("acpica: Extract _OSC parsing to a common file")
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48285
We claim to support Active State Power Management, but don't appear to
do anything different in the kernel when it's enabled other than tell
the firmware we do.
This breaks VMware Fusion on Apple Silicon when it's enabled as it
expects the kernel to enable the ports. As it is reported to be needed
on some x86 servers keep it enabled there, but disable on non-x86
architectures.
Reported by: kp, tuexen
Reviewed by: tuexen, mav, imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48303
When doing firmware rate control there will be situations where
the rate being passed in needs to actually override the rate
control selection. So add a flag to the descriptor setup path
to indicate that indeed this particular rate should be forced,
rather than rely on the firmware rate control.
This is currently a no-op as firmware rate control isn't working
in-tree, but it is working for me locally with other changes.
Without this, there's no way to force low rates for management,
DHCP traffic, and to allow fixed rate via "ifconfig wlanX ucastrate Y"
to function.
Locally tested:
* RTL8192CU, STA mode (firmware and driver/net80211 rate control)
Differential Revision: https://reviews.freebsd.org/D48100
Reviewed by: bz, gavin
If the driver attach path adds the VHT flag then add the 20/40/80 MHz
VHT channels.
This is a no-op right now as nothing is enabling it.
Differential Revision: https://reviews.freebsd.org/D48097
Reviewed by: bz
Call bus_generic_detach first and return any error. Remove no longer
needed individual device_delete_child calls.
Differential Revision: https://reviews.freebsd.org/D47970
While here, check for errors from bus_generic_detach and move it to
the start of detach if necessary.
Differential Revision: https://reviews.freebsd.org/D47969
In some cases, move the call to bus_generic_detach earlier so that any
detach failures from child devices do not leave the parent device
partially detached.
Differential Revision: https://reviews.freebsd.org/D47966
Use bus_generic_detach to detach and delete all child devices instead
of several explicit calls to device_delete_child.
Differential Revision: https://reviews.freebsd.org/D47965
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
