It /looks/ like there's some weirdness in initial frame send after
the chip programming / channel change. Linux rtl8xxxu has no sleeps
here, instead it just retries the auth frame a few times.
My guess is there's some sequencing going on here between finishing
the programming, doing a calibration run and then sending the initial
frame.
Instead of doing sleeps on every write during the RF channel change,
this 10ms sleep at the end is enough to reliably associate in my
test environment (12-core intel laptop, USB-3 port.) It's not
required for an earlier 2-core haswell laptop w/ USB-3.
See the PR for more information.
PR: kern/247528
Differential Revision: https://reviews.freebsd.org/D48517
The Linux rtl8xxxu driver has more delays in the RF read and write
path.
It looks like for writes it's ensuring the hardware is out of
power save and that the transition has properly occured.
And it looks for reads that it wants a delay after some bit setting,
likely some shifting into the RF register space is occuring with
a bit set/clear to trigger a load.
See rtl8xxxu_write_rfreg() and rtl8xxxu_read_rfreg() for more
information.
Differential Revision: https://reviews.freebsd.org/D48512
Obtained from: Linux rtl8xxxu
The RTL8192EU NIC (on older USB 2/USB 3 ports, not on newer
USB 3 ports, that still needs to be fixed!) will attach, scan,
associate fine. However, restarting wpa_supplicant results in the
NIC hanging until you disconnect it.
It turns out early in the power_on sequence - BUT only after a
power_off - the NIC would suddenly stop responding to any USB
transfers. It doesn't require the MCU to be available for USB
transfers - the hardware itself does that - so something had to be
going very sideways.
I traced it down to these steps during the power_off sequence.
They don't exist in the Linux rtl8xxxu driver, and there are commits
earlier in their RTL8192EU bring-up that suggest the author was
facing similar power sequencing / re-sequencing issues.
This likely won't fix the actual channel programming /
power sequencing / deafness issues on later USB-3 ports.
There are other commits / fixes in the rtl8xxxu driver related to
RTL8192EU bring-up that we don't have.
Differential Revision: https://reviews.freebsd.org/D48428
Obtained from: Linux rtl8xxxu driver
When a SYS_RES_IOPORT resource crosses a pci_host_generic bridge, it
is translated into a memory access for an associated range, so use
SYS_RES_MEMORY for the resource allocated from the parent.
Tested by: markj
Differential Revision: https://reviews.freebsd.org/D44207
Commit 27b932e32f ("sound: Safely remove channel from list in one
pass") optimized CHN_REMOVE_SAFE() to perform almost equally to
CHN_REMOVE(), so we can turn CHN_REMOVE_SAFE() into CHN_REMOVE() without
fears of performance regressions, while also being more robust.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48249
The CHN_REMOVE_SAFE() macro did two traversals of the channel list to
remove a channel, one to check whether the channel is an element of the
list, and a second traversal through SLIST_REMOVE(). Reduce this to one
traversal, while still preventing a NULL dereference in case the channel
in question is not present in the list.
While here, rename the macro arguments to something more descriptive.
MFC after: 1 week
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D48207
Main goal is to have a unit test, with sample test data that is verified
against the current macro implementation of pcm sample read and write
functions. With a test in place, we can proceed on a planned refactoring
of the sample read and write code, and confidently check the new code
for regressions.
Implementation of the unit test itself has to avoid any cast or
conversion affected by endianness, to make the tests compatible with all
machine architectures.
MFC after: 1 week
Reviewed by: christos, markj
Differential Revision: https://reviews.freebsd.org/D48330
This includes the port of a driver originally from OpenBSD, later
ported to NetBSD by the author:
* The umb(4) kernel driver
* The umbctl(8) companion tool
This driver supports USB network devices implementing the
Mobile Broadband Interface Model (MBIM), often found in modern
(internal) USB models for 4G/LTE mobile broadband access.
It is currently limited to IPv4.
umbctl has to be used to display or set MBIM cellular modem
interface parameters (4G/LTE).
Differential Revision: https://reviews.freebsd.org/D48167
Approved by: adrian, zlei
Sponsored by: FreeBSD Foundation
PR: kern/263783
Submitted by: Pierre Pronchery <khorben@defora.org>
This is a flag to be used to disable >1 antenna support, even if
the radio supports it.
Also populate sku_cap_11n_enable, which indicates HT is available.
It's a no-op right now; it's one of the requirements for properly
configuring HT support and transmit/receive antenna configurations.
Obtained from: OpenBSD (at a6e25c727a2214219715b51ba6af2221d7e0d674, 22-Oct-2021)
Differential Revision: https://reviews.freebsd.org/D48210
Reviewed by: bz
These are from an earlier version of the driver (22-Oct-2021) which
I started to sync against back in 2021.
These pull in the rest of the VHT and HT rates.
Since that driver has functioning 802.11n support, it makes a good
intermediary checkpoint.
Locally tested:
* 7260, STA mode, 11g and 11a modes
Differential Revision: https://reviews.freebsd.org/D48209
Obtained from: OpenBSD (at a6e25c727a2214219715b51ba6af2221d7e0d674, 22-Oct-2021)
This driver prefers connection speed over sas port speed. On stable/13
branch the stack-allocated CCB is not cleared thus the cam layer may
report weird speed on boot.
```
da0: <VMware Virtual disk 2.0> Fixed Direct Access SPC-4 SCSI device
da0: 4294967.295MB/s transfers
```
-current and stable/14 have the change [1] which clears stack-allocated
CCB thus are not affected, but I want -current and stable/14 to have this
fix in to reduce drift between branches.
1. ec5325dbca cam: make sure to clear even more CCBs allocated on the stack
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D48438
This flag was introduced to ignore bad firmware values. These were
present in older versions of EDK-II that many devices (both Ampere and
Amazon) used. QEMU also used this value, but fixed it. But since it's
tied to the firmware bug not the device name ID it doesn't make sense to
have it flagged there.
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47947
Some veresions of EDK-II and QEMU reported the wrong values for the
register shift and the region I/O size. Detect those and set it to the
correct values. In general, anything other than a shift of 2 and a
regio width of 4 (bytes, or 32 bits) is a mistake. However, allow
for overrides in the future by only overriding the buggy values.
Otherwise, we will fail to boot.
PR: 282936
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47946
Although there's no RTS/CTS rate control available yet, the support
is enough to enable firmware rate control for experimenting.
This won't be enabled by default - users will need to set a tunable
before loading the driver (eg kenv dev.rtwn.0.ratectl=2) but it is
enough for experimentation, feedback and continued work.
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48143
Reviewed by: bz, emaste
* refactor out the r92c path protection (RTS/CTS) decision
* handle firmware rate control being enabled - if DRVRATE isn't
set then the RTSRATE field is ignored and instead RRSR/INIRTS
registers are used (and the firmware/hardware will do RTS
rate adaptation / retry.)
* when making protection decisions with firmware rate control,
default to the channel mode rather than rate index.
This works on RTL8192CU both with firmware rate control and driver
rate control.
Locally tested:
* RTL8192CU, STA - firmware and net80211 rate control
Differential Revision: https://reviews.freebsd.org/D48142
Refactor out the datarate setup and short preamble setup.
These will eventually be slightly different based on whether
firmware rate control is being performed or not.
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48141
The NIC/firmware initialises the initial RTS/CTS rate to something
high, like OFDM48. That's not going to be very reliable.
It's not a problem right now as we program in the RTS/CTS value
to use in the TX descriptor setup path based on the control rate
for the given frame TX rate, and like the INIDATA/driver rate
stuff in the TX descriptor, the TX descriptor RTS/CTS rate overrides
the INIRTS rate.
However when it's time to flip on firmware based rate control,
the initial rate needs to not be OFDM48. Yes, the firmware and
hardware does have some rate retry schedule for RTS/CTS frames,
but there's no point in wasting short retries trying to do OFDM48
based RTS/CTS setup.
Add some warning logging if there are no basic or RTS/CTS rates
available, and leave things at default. If this happens in
production for someone then it would be good to know and what
the rate mask was.
Locally tested:
* RTL8192CU, STA mode (with/without firmware rate control enabled locally)
Differential Revision: https://reviews.freebsd.org/D48140
nda(4) has its own shutdown handler that runs at SHUTDOWN_PRI_DEFAULT
that calls ndaflush() that could run after the nvmf handler. Instead,
give a the flush a chance to run before the graceful shutdown of the
controller.
While here, be a bit more defensive in the post-sync case and shutdown
the consumers (sim and /dev/nvmeXnY devices) before destroying the
queue pairs so that if any requests are submitted after the post-sync
handler they fail gracefully instead of trying to use a destroyed
queue pair.
Reported by: Sony Arpita Das <sonyarpitad@chelsio.com>
Sponsored by: Chelsio Communications
<assert.h> now has a usable definition, so we don't need to shim it out
in the nvmf header anymore.
Reviewed by: emaste, jhb
Differential Revision: https://reviews.freebsd.org/D48078
Implement the small amount of MD code required; copied from arm/arm64.
One tweak is made to cpufreq_dt itself: if the opp-shared property is
missing, but there is only one CPU, then we can still attach. This is
relevant for the single-core Allwinner D1.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48124
Some RISC-V CPUs contain a "monitor core" with limited functionality (no
MMU). These cores appear in some device trees, but we don't run the
kernel on them; in early CPU start-up code we skip them, and they have
no impact on mp_ncpu. It seems the new trend is to mark these monitor
cores with a 'status' property of 'disabled'.
However, we still instantiate an ofw_cpu pseudo device for the disabled
core. This is generally harmless, but there is an impact when attempting
to attach the cpufreq_dt driver. It counts more OFW CPU devices (unit
number) than logical CPUs (mp_ncpus), and therefore fails to attach for
the last logical CPU.
The solution is to check the status property in ofw_cpu_probe(), and
fail if the core is marked "disabled". This is subject to the same
exception already in ofw_cpu_early_foreach(); that is, if a disabled CPU
has an 'enable-method' property, it can be used by the kernel.
Reviewed by: andrew, jrtc27
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48123
Mainly, to avoid repeating the list of architectures, #define HAS_CLK.
Further, split the clk code into a helper function, which is a stub in
the !HAS_CLK case. This aids in overall legibility.
While here, add one separating whitespace, again for legibility.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48149
The canonical name is __riscv, not __riscv__. Newer compilers no longer
emit the latter.
This re-enables finding the nominal frequency from the CPU's clock.
I checked, and there are no remaining mistakes like this in the tree.
Reviewed by: jrtc27, imp, jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48122
Add the generic USB drivers and FDT glue to the build.
Make small tweaks to the aw_usbphy and aw_musb drivers for the Allwinner
D1.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48126
ifconfig down/up cycles was not working. Fix that which is required
to support MTU changes. Now doing ifconfig enic0 mtu 3000 for example
works. If the MTU is changes in the VIC HW configuration, that is not
reflected in and the OS reports the default 1500. I need to look at
that but changing it via ifconfig works. So this is different then
what Linux does.
Change TX interrupt allocation to be in this driver. Change the admin
interrupt count to 2. This make multiple queues work but need to be
done as pairs so if the VIC has more TX or RX queues setup in the
VIC configuration it will use the lesser value.
While updating the TX interrupt also add support for devcmd2.
Enable checksum offloading.
PR: 282095
In commit a97f683fe3 I didn't add code to remove the vmmctl device
when vmm.ko is unloaded, so it would persist and prevent vmm.ko from
being re-loaded.
Extend vmmdev_cleanup() to destroy the vmmctl cdev. Also call
vmmdev_cleanup() if vmm_init() fails.
Reviewed by: corvink, andrew
Fixes: a97f683fe3 ("vmm: Add a device file interface for creating and destroying VMs")
Differential Revision: https://reviews.freebsd.org/D48269
Although the transmit path doesn't yet support VHT rates (because
the rate control and rate representation in net80211 doesn't yet
know about VHT rates) the NIC will receive VHT frames but only
transmit HT frames.
Locally tested:
* RTL8812AU, STA mode
Differential Revision: https://reviews.freebsd.org/D48103
Aborting ATIO while its CTIOs are in progress makes impossible to
handle their completions, making them stuck forever. Detect this
case by checking ctcnt counter and if so instead of aborting just
mark the ATIO as dead to block any new CTIOs. It is not perfect
since the task id can not be reused for some more time, but not
as bad as the task stuck forever.
MFC after: 1 week
Aborting ATIO while its CTIOs are in progress makes impossible to
handle their completions, making them stuck forever. Detect this
case by checking ctcnt counter and if so instead of aborting just
mark the ATIO as dead to block any new CTIOs. It is not perfect
since the task id can not be reused for some more time, but not
as bad as the task stuck forever.
MFC after: 1 week
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
