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
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
