LinuxKPI: 802.11: add function to update some rate related fields
Add lkpi_sta_supp_rates() which serves multiple purposes:
(a) build (and update) the supp_rates field on a sta link (deflink only
in our case still),
(b) build and update basic_rates on the vif->bss_conf and print a
warning in case we end up without any basic rate (should not happen
anymore, not even on initial startup sync),
(c) if HT or VHT are supported, then update the relevant br_mask fields
for the current band.
Deal with the various flags which trigger different updates by returning
them so the caller can act upon.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: make lkpi_sta_sync_from_ni() return bss_changes
This is a preparatory change with no functional changes.
Sponosred by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: add/change rate related tracing
Make use of the TRACE_RATES() macro and add various tracing events.
Also adjust some events formerly under TRACEOK to TRACE_RATES().
Ignoring the tracing, no other functional changes.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: consider emulate_chanctx in lkpi_sync_chanctx_cw_from_rx_bw()
Only return early if the bandwidth has not changed and we are not
using emulate_chanctx or the chandef.width already matches the new
bandwidth. Otherwise we have to continue to get all the values
updated.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: adjust timing of sync_from_ni in lkpi_sta_assoc_to_run()
We used to call the (*sta_state) downcall into the driver to set the
sta state to ASSOC. After that we did a lot of sync operations incl.
the lkpi_sta_sync_from_ni() which does a lot of rate and bandwith
adjustments. This sync call needs to happen before we set the sta
to assoc as drivers rely on some of this information, e.g., ht_cap and
vht_cap (and equivalents for later standards) at that point. Moving
this will make, e.g., mt7921 transmit at higher rates than just
basic_rates.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: track bandwidth/rx_nss change in lkpi_sta_sync_from_ni()
In lkpi_sta_sync_from_ni() track the bandwidth and rx_nss at the
beginning so at the end we can diff if they changed in order to generate
the appropriate RC*CHNAGED flags for the (*link_sta_rc_update) downcall.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: initalize br_mask and basic_rates for each vap
During vap creating we inialize most [l]vif related variables.
Add a br_mask (bit rate mask) to the lvif and setup the legacy component
as it seems to be static.
Given we are looping over the bands, also initialize the bss_conf
basic_rates. At this point we only have all bitrates for the band
or the mandatory bitrates for the band available. In order to not
hint usage of possibly unsupported bit rates set it up with the
manadatory bit rates only, which should get us through the mgmt
frames, etc. to get to assoc state. By then we will do updates.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: add 11g check to lkpi_ic_getradiocaps()
Replace an early comment with code and add a (simplified) 11g check.
We make use of the annotated bitrate flags we added (see
lkpi_wiphy_band_annotate()) and check if on the 2GHz band there are
any bitrates which are 11g. Upon the first one found we do set the
IEEE80211_MODE_11G to announce to net80211 that the 2.4Ghz channels
may operate on 11g as well.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: add/improve/correct comments
Adjust/add comments to clarify certain situations.
No functional changes.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: leave a comment for sta->rates (mt7615, ?)
While we currently try to fill most rates places (e.g., basic_rates,
supp_rates, (*set_bitrate_mask)), sta->rates are not populated.
They are likely managed by the 802.11 rate control code (given no
ieee80211_hw_check HAS_RATE_CONTROL), which for use would be net80211,
which will require some extra code just to manage that.
At least Mediatek mt76 (mt7615) driver seems to fall into the category
of this need. See about that once/if we get to it.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
mt76: mt7925: prevent PM from scheduling another delayed work on detach
This duplicates 009d92b25f7c from mt7921 which has the full description.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: introduce TRACE_RATES()
Add a tracing bit for tracing rates related changes introduced in
followup commits.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
x86/ucode.c: supposedly fix i386 compilation
Fixes: 16f21c5af350 ("amd64: there is no reason to copy ucode around in ucode_load_bsp()")
PR: 295926
Submitted by: Martin Birgmeier <d8zNeCFG at aon.at>
MFC after: 3 days
if_fwsubr: remove ARP target hardware address trimming
Per RFC 2734 section 5, the 1394 ARP packet is a fixed 32-octet structure
with no target hardware address field.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D57617
firewire: NULL check on malloc in fw_busreset()
fw_busreset() allocates newrom with M_NOWAIT from interrupt context.
If the allocation fails, crom_load() dereferences a NULL pointer.
Skip the config ROM comparison on allocation failure so the next bus
reset will retry.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D57728
gss_impl.c: Fix a nfsd hang when the kgssapi.ko is loaded, but no gssd
After the conversion to using netlink, the kgssapi had
no way of knowing if the gssd daemon was running.
As such, a boot where the kgssapi is loaded, but the
gssd is not enabled would hang the nfsd for a very
long time. (Many timeouts at 300sec each.)
This patch adds a Null RPC upcall with a 200msec
timeout to check to see if the gssd is running.
If the gssd is not running, the nfsd starts up
(without Kerberos support) with only a 200msec
delay.)
Also, move the svc_svc_nl_create() and svc_reg() calls in gssd.c
to before the daemon() call, so they are guaranteed to have
been done before the nfsd(8) daemon is started by
the rc scripts.
[4 lines not shown]
powerpc/booke: Save watchdog context to "critical" save area
Watchdog interrupt is a "critical" interrupt, so save the correct
registers (CSSRn, into critical save area).
powerpc/pmap: Use variable-sized TID
e6500 core supports 14-bit TIDs (16384), while all earlier cores support
only 8 bit TIDs. Dynamically allocate the tidbusy array at bootstrap
time so that it stays in the TLB1, but is sized appropriately for the
core. With MAXCPU of 32, a e6500 tidbusy would be (8 * 32 * 16384), or
4MB for this array, while e5500 would use (8 * 32 * 256), or 64kB.
powerpc/booke: Extend TID register bits to the max
Some Book-E cores (at least e6500) can have much larger PID fields, up
to 14 bits. Extend the PID mask space to the full space, and future
changes may take advantage of this extended space.
meta.autodep.mk remove extra }
remove extra } from GENDIRDEPS_ENV
more debug output for gendirdeps.mk
Reviewed by: stevek
Differential Revision: https://reviews.freebsd.org/D57727
Source upgrade doc: etcupdate no longer needs -B
Note: We confusingly have the instructions to build the system in the
build manual, the UPDATING file, and the Makefile. These will get out
of sync and will be harmful when they do.
Fixes: ddf6fad0295a ("etcupdate: Make nobuild the default")
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D57644
mem*.3: stop refering to strings
POSIX and the C standard now refer to objects and sequences rather
than confusingly revering to strings.
Also update bcopy(3) and bzero(3).
Reviewed by: emaste
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D57680
uiomove_*: centralize the copy function selection
Add a uiomove_step() for the central set of switch statements which
choose between userspace and kernel and if data is going to or from the
iovec.
Refactor uiomove_fromphys loops to unconditionally free per-iteration
resources and drop gotos.
While here, switch from bcopy to memcpy.
Reviewed by: kib
Suggested by: emaste
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D57688
pmap: prefer memcpy over bcopy
Alter pmap_copy_page(s) to use memcpy rather than the deprecated bcopy.
We'll be adding non-provenance preserving versions for CHERI support and
would like to avoid introducing variants of deprecated APIs just to
maintain symmetry.
Reviewed by: kib
Suggested by: emaste
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D57687
kern_exec.c: explicitly include sys/limits.h for UINT_MAX
While there, remove unneeded manual inclusion of sys/cdefs.h.
Fixes: e1a84b7708c2 ("execve_block(): a mechanism for mutual exclusion with execve() on the process")
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
amd64: do not restore fsbase/gsbase for 32bit processes
There is no WRFSBASE and WRGSBASE 32bit variants at all. As such, the
fsbase and gsbase must always be equal to the bases in the corresponding
segment descriptor, same as on real i386.
If a 32bit program reloads either %fs or %gs using setcontext(9) or
sigreturn(9), restoring bases from the syscall entry time is wrong.
In all other cases, hardware already does the right action when the
segment register is loaded, and the bases for the ufssel/ugssel in GDT
are updated on the context switch.
Reviewed by: markj (previous version)
Tested by: terehovv at mail.ru
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57611
