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
* RX frames with short-GI can be either HT or VHT
* Add placeholders for RX VHT rate, PHY type, etc
Differential Revision: https://reviews.freebsd.org/D47902
In the ACPI attachment add support for the pcib_request_feature method.
This uses the common _OSC handling.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48048
In the ACPI attachment support the ACPI_IVAR_HANDLE ivar. While here
use the common ivar function to support the common ivars.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48047
Allow this to be called from attachments to allow more ivars to be
implemented.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48046
In pci_host_generic.c use a switch statement rather than a series
of if statements.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48045
This will be used by pci_host_generic_acpi.c so needs to be in a
common location.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48044
The commit to introduce TCP_USE_DDP support had a couple of bugs that
broke support for zerocopy receive via aio_read(). First, the length
and offset arguments to mk_update_tcb_for_ddp() were reversed which
prevented DDP from working. Second, the AIO state in the toep was
initialized too late when the first aio_read() request was queued.
Reported by: Harshavardhan Tanneru @ Chelsio
Fixes: eba13bbc37 cxgbe: Support TCP_USE_DDP on offloaded TOE connections
MFC after: 1 week
Sponsored by: Chelsio Communications
The termios layer wants some level of guarantee that we've actually
submitted param changes to the hardware when our functions return, so we
need to do a little more waiting to avoid violating those guarantees.
This is especially important as some hardware has some minimum timing
specifications around this stuff, and without being less asynchronous
the software dealing with these devices can't reasonably operate the
hardware without more excessive delays than they should need.
More specifically, we make sure that:
- The command to start transfers is finished before we toggle DTR/RTS
- The status_change command finishes before we return, which may change
some fields in the softc that we need for a subsequent call into
usb_serial
- cfg_param finishes before we re-enable transfers, and we ensure that
RTS is appropriately toggled before we return to userland
This has been observed to fix some flakiness in connecting to some
ESP32 devices.
Tested by: kenrap from Libera
Reviewed by: imp, kib
Differential Revision: https://reviews.freebsd.org/D47952
ucom_queue_command will issue commands for open/close, then wait on them
to be finished. In the spirit of playing it safe, allow
ucom_queue_command's wait to be interrupted in case the usb process gets
jammed up waiting on the hardware -- we can at least recover the user
thread that initiated it, even if we can't recover the usb process.
Reviewed by: imp, kib
Differential Revision: https://reviews.freebsd.org/D47951
There's only one error that we can get back right now, but future
changes will add some more cases that we need to watch out for. Start
by returning errors and propagating them back.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D47950
- Only two of these tunables are used for RATELIMIT without
TCP_OFFLOAD.
- Mark t4_tmr_idx_ofld and t4_pktc_idx_ofld static.
- Move hw.cxgbe.cop_managed_offloading under hw.cxgbe.toe since it is
specific to TOE.
Reviewed by: np
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D47765
- When handling notify acknowledge from target code for task abort
request, not only send abort to the firmware, but also delete the
ATIO private data associated with the command. It is required for
proper tag reuse, allowing new "conflicting" commands to be passed
to the target. CTL was already fixed to handle that right, instead
of delaying them in restart queue of the driver.
- When target finally aborts the command (which it should have
done before the notify ack) we should not send another abort to
the firmware. Since we already sent the abort and deleted ATIO
private data above, just return successful completion here, doing
nothing. Since the tag can be reused by that time, we can not
rely on its uniqueness, so when searching to the ATIO private data
compare also the aborted CCB pointer in addition to the tag.
- Fix BA_RJT sending in isp_acknak_abts(). While it should be
rare, teach the code to send error responses for ABTS requests.
MFC after: 2 weeks
When aborting command waiting in restart queue remove it from the
queue before freeing it. This should fix NULL dereference panics
we saw on some very busy system.
MFC after: 2 weeks
When GPIOBUS_PIN_SETFLAGS fails we called gpiobus_free_ivars to clean
up the contents of the ivar, then would free the ivar. This lead to a
use-after-free as the ivar had already been set on the child so
gpiobus_child_deleted would try to free it again.
Fix this by removing the early cleanup and letting
gpiobus_child_deleted handle it.
Fixes: c9e880c0ce ("gpiobus: Use a bus_child_deleted method to free ivars for children")
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47670
net80211 node ni_chw currently encodes the channel width as Mhz number.
LinuxKPI 802.11 uses enum ieee80211_sta_rx_bw for the same.
Rather than keeping the "20" and "40" throughout the code (eventually
expanded to 80/160/320) switch them over to use the enum throughout
and add a print mask for debug output. While designed as bitmask it
is not supposed to be used as such; the bitmask is only used to be
able to use %b with a print mask.
Once we get to 320Mhz channel widths we would otherwise also need to
extend the uint8_t in struct ieee80211_node; making
enum ieee80211_sta_rx_bw __packed allows us for three more channel
widths without breaking the KBI (if we were not to use %b with a
print_mask but use a lookup function for the string we could extend
it for a long time).
Sponsored by: The FreeBSD Foundation
MFC after: 14 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D47891
Normally the reply to destroy_server() releases the listen context but
it is not called when the adapter is suspended. Release the context
right away in that case.
MFC after: 1 week
Sponsored by: Chelsio Communications
After discussion with the rtlwifi maintainers, it looks like this
path isn't even used.
(And it's part of the firmware rate control path which we currently
don't enable for other reasons.)
Differential Revision: https://reviews.freebsd.org/D47938
This is needed to be able to successfully transmit VHT frames.
Locally tested:
* RTL8821AU, STA mode (with the rest of VHT work to actually test VHT)
Differential Revision: https://reviews.freebsd.org/D47899
The VHT rate power array wasn't populated, and it needs to be in order
to use VHT rates.
The vendor driver reuses the HT40 values for VHT rates.
Differential Revision: https://reviews.freebsd.org/D47898
In preparation for the VHT TX power programming, refactor out the
CCK, OFDM and HT programming into their own routines.
Locally tested:
* RTL8821AU, STA mode
* expand the ridx field all the way through 4x4 11n (MCS0..MCS31)
* and then expand it through VHT 4x4 (MCS0..9 for each stream)
* add accessor macros to check if the rate is HT, VHT
* use accessor macros to check if the rate is HT rather than
comparing it against OFDM54 or RIDX_HT_MCS(0); the values
aobve HT MCS will be VHT, and we don't want to trigger on those!
* add a couple of appropriate TODO VHT bits in the TX path
Locally tested:
* RTL8192CU, STA mode
* RTL8188EU, STA mode
* RTL8821AU, STA mode
* RTL8192EU, STA mode
Differential Revision: https://reviews.freebsd.org/D47896
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
HT40 works fine in 2GHz and 5GHz modes in both 1 and 2 stream
scenarios, so just enable it here.
Differential Revision: https://reviews.freebsd.org/D47874
Using ieee80211_ht_check_tx_ht40() means that not only the
bss and node channel are checked, but the ni_chw value is also
now correctly checked.
Differential Revision: https://reviews.freebsd.org/D47862
The drivers have been disconnected from the build since the removal of
the SOCFPGA kernel configs.
Reviewed by: manu, imp, andrew
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D47885
The TSF64 extension involves at least 3 reads from TSF registers
(R92C_TSFTR(0), R92C_TSFTR(1), R92C_TSFTR(2)) which are 4 byte
control transfers. They take up valuable USB link time.
It's likely much less expensive for PCIe adapters. At some point
it may be worthwhile enabling it by default just for those.
With this disabled, the only USB traffic that I see during
normal data operation are bulk TX/RX data transfers for 802.11
packets, and on NICs w/ net80211 rate control, the control register
space read/writes for TX completion. (And that will also need
addressing.)
This is the difference between 15mbit TCP RX and 30mbit TCP RX
on the 11n NICs, and around 40 to 50mbit TCP RX on the 11ac NICs
in HT40 and VHT80.
Locally tested:
* RTL8188EU, STA mode
* RTL8192CU, STA mode
* RTL8192EU, STA mode
* RTL8811AU, STA mode
* RTL8821AU, STA mode
Differential Revision: https://reviews.freebsd.org/D47861
This option stems from a bunch of issues a long time ago where HT40
support on some NICs is unstable - likely because we're not setting
up the RF/baseband correctly.
In any case, it doesn't need to be conditionally compiled anymore.
Leave it in, leave it off by default, and various chipset initialisation
paths can decide whether to enable it themselves.
Reviewed by: emaste
All of the supported NICs should support this.
Locally tested:
* RTL8192CU, STA mode
* RTL8192EU, STA mode
* RTL8821AU, STA mode
* RTL8812AU, STA mode
Differential Revision: https://reviews.freebsd.org/D47776
I noticed that on RTL8812AU/RTL8821AU receiving VHT frames that
I'd occasionally see frames missing the last 4 bytes. I can
easily reproduce it with a ping sweep and fast (10ms) between frames.
There's also a report of an earlier NIC (RTL8188EU) doing the same
thing with HT frames but not with OFDM (11g) frames.
After a bunch of poking, it turns out a driver where things DID work
properly for the other report kept FCS enabled, and trimmed it from
the frame before pushing it up to the network layer.
I did the same and it also worked fine.
The other solution was to disable PHYSTATUS notifications, but then
we'd get no per packet RX notifications (RX rate, RSSI, etc.)
Locally tested:
* RTL8192EU, STA mode (HT)
* RTL8812AU, STA mode (HT, VHT)
* RTL8821AU, STA mode (HT, VHT)
Differential Revision: https://reviews.freebsd.org/D47775
* Add support for 80MHz channels during IQ calibration
* Correct the RAID flags for 1 and 2 stream VHT - the later ones
are for 2GHz VHT and then 3/4 stream VHT
* Add VHT to the RAID calculation for when we eventually transmit
VHT rates.
Obtained from: Linux rtw88 (https://github.com/lwfinger/rtw88)
Differential Revision: https://reviews.freebsd.org/D47774
* use ieee80211_ht_get_node_ampdu_density() now instead of the
vap->iv_ampdu_density, so the correct density is used in AP/IBSS/mesh
modes.
* MAX_AGG controls how many frames are to be sent in an A-MPDU.
It maps to ((MAX_AGG * 2) + 1) == npackets. 0x1f (31) means
64 packets. So, instead of hard-coding 0x1f, use the negotiated
block-ack window size.
Differential Revision: https://reviews.freebsd.org/D47766
Use the new net80211 routines rather than rolling our own.
(The first version of this diff landed a previous version of what was
reviewed, so this brings it up to what was finally accepted in the
review.)
Differential Revision: https://reviews.freebsd.org/D47751
Reviewed by: bz
RME HDSPE AIO sound cards support different sensitivity levels at the
analog input, and different gain levels for the analog line and phones
outputs. Expose these settings as sysctl tunables.
Test Plan:
The following tests on hardware should be performed if possible:
- Phones output volume changes according to sysctl setting
(caution, still extremely loud).
- Create loop to feedback the line output to line input, recording the
sound played.
- Iterate through input signal levels and observe volume changes in
recorded audio.
- Iterate through output signal levels and observe volume changes in
recorded audio.
Reviewed by: br, christos
Differential Revision: https://reviews.freebsd.org/D47412
