Linux only implements these functions on x86. They return 0 on other
architectures. The FreeBSD implementation calls PHYS_TO_DMAP but this
panics on i386 because it does not have a direct map so return 0 on i386
as well for now. These functions are only used by graphics/drm-*-kmod
to mark the VRAM aperture write-combining but this is also accomplished
by a call to vm_phys_fictitious_reg_range so this change is sufficient
to fix drm-*-kmod on i386 for FreeBSD 14.1.
Reviewed by: kib
Approved by: re (cperciva)
Differential Revision: https://reviews.freebsd.org/D45125
(cherry picked from commit 2ae0f5a4d0931067c672be9a791909f0e32d5a0e)
(cherry picked from commit 2d97bd0639)
set_memory_* is currently implemented using PHYS_TO_DMAP but not all
architectures have a DMAP. Looking at how this function is used the
given address isn't physical but virtual so the PHYS_TO_DMAP call can
simply be removed.
Also cast numpages before shifting it to avoid overflow.
Reviewed by: kib, markj
Approved by: re (cperciva)
Differential Revision: https://reviews.freebsd.org/D45057
(cherry picked from commit 7206f7c619912bdd4d54dd539824733eae50c3a9)
(cherry picked from commit 147ea7d409)
Under Linux, the socket options IP_RECVERR and IPV6_RECVERR are used to
receive socket errors via a dedicated 'error queue' which can be
retrieved via recvmsg(). FreeBSD does not support this functionality.
For IPv4, the sysctl compat.linux.ignore_ip_recverr can be set to 1 to
silently ignore attempts to set IP_RECVERR and return success to the
application, which is wrong, but is required for (among other things)
a functional DNS client in recent versions of glibc.
Add support for ignoring IPV6_RECVERR, controlled by the same sysctl.
This fixes DNS in Linux when using IPv6 resolvers.
Reviewed by: imp, Jose Luis Duran
Pull Request: https://github.com/freebsd/freebsd-src/pull/1118
(cherry picked from commit ca63710d3668cf6f3cb4faf065d8b4eeffa028ad)
Add checks for __counted_by(_x) and __nonstring as and depending
on compiler support enable the attribute/feature.
This is needed to make mtk76 and ath1xk drivers compile.
Sposnored by: The FreeBSD Foundation
Reviewed by: emaste, dim
Differential Revision: https://reviews.freebsd.org/D44587
(cherry picked from commit 2a8c50592f7fce8bceedf004f674a5a9eae0fd46)
We used to call lkpi_wake_tx_queues() for all queues early on in order
to make sure they are ready. Turns out whatever logic in iwlwifi
startup is working correctly these days under LinuxKPI so this is no
longer needed. As the comment indicated the "workaround" did not
always work. Disable it for now.
The second part of the improvement is to properly classify Non-QOS
non-data frames (mgmt and ctl frames for now, unless we have to be
even more careful in the future about certain sub-types) as TID 7/VO.
Contrary to net80211 we must not promote PAE frames.
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43944
(cherry picked from commit 1665ef979d3adab05d178480077674ab5978e4f0)
Given we are passed the lsta in as a function argument there is no
need to re-lookup the sta by ni and possibly not find it.
We know the sta and ni from the lsta and whether it is uploaded to
firmware or not we can check directly from the local lsta flag.
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43965
(cherry picked from commit ac867c20e67423e5019ab90148c387ea127eeffb)
mt76 calls devm_kfree() directly, so alias it to our
lkpi_devm_kmalloc_release() function.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44589
(cherry picked from commit 170c2e0e2bb1b2d9a7661ba729f8264381c9d9d7)
A newer version of iwlwifi requires a return value from napi_schedule();
unclear if the function always should have been bool. Add the bool to test
based on the napi_schedule_prep() result.
Also add napi_is_scheduled() for rtw89.
Sponsored by: The FreeBSD Foundation
Reviewed by: emaste (previous version)
Differential Revision: https://reviews.freebsd.org/D44591
(cherry picked from commit 21761f2ede4ebad13e78112b9409c1f20f946781)
Implement skb_queue_splice_tail_init() and SKB_DATA_ALIGN() as
needed by the mt76 wireless driver.
Sponsord by: The FreeBD Foundation
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D44590
(cherry picked from commit 3d3ec17825a124f0119d76c4d2523d73012fa226)
Add dev_alloc_pages() though it seems a weird KPI, not passing a dev
despite its name. Used by updated wireless driver.
Sponsored by: The FreeBSD Foundation
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D44588
(cherry picked from commit 738c02ba24c66391870067602f1c9c030d5c5e5d)
Just like BITS_TO_LONG() ... used in rtw89.
Sponsored by: The FreeBSD Foundation
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D44603
(cherry picked from commit f674f016c03d49e14f1c651ed088a6f2d01a62ee)
This addresses a -Wunused-but-set-variable warning in the gcc builds.
No functional change intended.
Reported by: Jenkins
(cherry picked from commit 344a04ad2c5e62b2905bc2f8b6f992ae590403fd)
The variable fileid stores the result from kern_kldload() but never gets
used. Since the third parameter `*fileid` of kern_kldload() can be NULL,
this unused variable can be safely removed.
No functional change intended.
Reviewed by: emaste, bz, #linuxkpi
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44583
(cherry picked from commit 317cc829ee227cfdffe7b25125c070112ce0c2f1)
In case of LKPI_80211_HW_CRYPTO we convert from LinuxKPI cipher_suites
to net80211 ic_cryptocaps fields. For WLAN_CIPHER_SUITE_CCMP we
accidentally returned the bit number instead of the shifted value
which leads to ieee80211_crypto_newkey() setting IEEE80211_KEY_SWCRYPT,
which in turned lead to us trying to decode the frame again despite
HW had already done it. This was found out of a discussion in D43634.
Reviewed by: cc, adrian
(cherry picked from commit 906521f8176b13533556d742db4ab28e847b85c0)
Some calls, e.g., action frames cause us to call through all the
way down to firmware from the RX path without any deferral in
net80211.
For LinuxKPI and iwlwifi this goes (with omissions) like this:
lkpi_napi_task -> linuxkpi_ieee80211_rx -> ieee80211_input_mimo ->
sta_input -> ht_recv_action_ba_addba_request ->
lkpi_ic_ampdu_rx_start -> iwl_mvm_mac_ampdu_action ->
iwl_trans_txq_send_hcmd. At that point we are waiting for an
interrupt from the firmware but given the lkpi_napi_task has not
finished (and may have more to dispatch based on budget and what
was received) we will not see the new interrupt/fw response.
With no answer from the firmware, the software timeout in the
driver kills the command and the firmware and issues a complete
restart.
Implement the deferred RX path in LinuxKPI for the moment.
At a later point we should carefully shift this into net80211.
This fixes the hangs for (*ic_ampdu_rx_start)() calls with iwlwifi.
PR: 276083
Reviewed by: cc
(cherry picked from commit 759a996d610d9354aac5c48a6bdc9cedcba2f48b)
hash_add_rcu asserted that the node's prev pointer was NULL in an
attempt to detect addition of a node already on a list, but the caller
is not required to provide a zeroed node.
Reported in https://github.com/freebsd/drm-kmod/issues/282
Reviewed by: bz, manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43645
(cherry picked from commit 7e77089dccd702eb767350a8bd3d20102c4fb591)
Correct skb_queue_tail to queue the buffer at the tail of the skbuff.
The skbuff is a circular doubly-linked list, and we call with a pointer
to the head of the list. Thus queueing before the head gives us a
queueing at the tail.
As a motivating factor, the current behaviour (queueing at the head) was
causing frequent kernel panics from my RTL8822BE wireless card, which
uses the rtw88 driver. Interrupts can cause buffers to be added to the
rtwdev c2h_queue while the queue is being drained in rtw_c2h_work.
Queueing at the head would leave the nascent entry in the linked list
pointing to the old, now freed, memory for the buffer being processed.
When rtw_c2h_work is next called, we try reading this and so panic.
Reviewed by: emaste, bz
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44192
(cherry picked from commit d3befb534b9c8cd80f1b8d75ce6451e3f62b8ba9)
This function is used by netlink(9) only. The netlink(9) taskqueue thread
runs in the vnet of the socket whose request the thread is processing
right now. This is a correct vnet and resetting it to vnet0 is incorrect.
If the function is to be used by any other caller in addition to
netlink(9), it would be caller's responsiblity to provide correct vnet(9).
Reviewed by: melifaro, dchagin
Differential Revision: https://reviews.freebsd.org/D44191
PR: 277286
(cherry picked from commit 2f5a315b307447f91891c96fb23c7333fa406f2f)
Introduce the allocuio() and freeuio() functions to allocate and
deallocate struct uio. This hides the actual allocator interface, so it
is easier to modify the sub-allocation layout of struct uio and the
corresponding iovec array.
Obtained from: CheriBSD
Reviewed by: kib, markj
MFC after: 2 weeks
Sponsored by: CHaOS, EPSRC grant EP/V000292/1
Differential Revision: https://reviews.freebsd.org/D43711
(cherry picked from commit 61cc4830a7b16400efade3d884a59fda6d80d651)
Rename the LSTA lock to LSTA_TXQ lock as that is really what it is and
put down the full set of macros. Replace the init and destroy with the
macro invocation rather than direct code.
Put locking around the txq_ready unset and check. Move the taskq_enqueue
call under lock to be sure we do not call it anymore after txq_ready
got unset.
Leave a comment related to the node reference which is passed into the
TX path on the recvif mbuf pointer.
Fixes: 0936c648ad0ee
PR: 274382 (possibly)
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D43909
(cherry picked from commit fa4e4257943650c0b5f58c01bb0bdfadea61dfb2)
Update the ni/lsta reference cycle, add extra checks and assertions.
This is to accomodate problems we were seeing based on net80211
behaviour (join1() and (*iv_update_bss)() as well as state changes for
new iv_bss nodes during an active session).
This should hopefully help to stabilise behaviour until the underlying
problems gets properly addressed (for this and all other device drivers).
PR: 272607, 273985, 274003
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43753
(cherry picked from commit 0936c648ad0ee5152dc19f261e77fe9c1833fe05)
With firmware based solutions we cannot just jump from an active session
to a new iv_bss node without tearing down state for the old and bringing
up the new node. This likely used to work on softmac based cards/drivers
where one could essentially set the state and fire at will.
We track (*iv_update_bss) calls from net80211 and set a local flag that
we are out of synch and do not allow any further operations up the state
machine until we hit INIT or SCAN. That means someone will take the state
down, clean up firmware state and then we can join again and build up
state.
Apparently this problem has been "known" for a while as native iwm(4) and
others have similar workarounds (though less strict) and can be equally
pestered into bad states. For LinuxKPI all the KASSERTs just massively
brought this problem out. The solution will be some rewrites in net80211.
Until then, try to keep us more stable at least and not die on second
join1() calls triggered by service netif start wlan0 and similar.
PR: 271979, 271988, 275255, 263613, 274003
Sponsored by: The FreeBSD Foundation (2023, partial)
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43725
(cherry picked from commit 2ac8a2189ac6707f48f77ef2e36baf696a0d2f40)
It seems during the initial buildup of the file, the defines were
either mixed or not flagged as "FIXME".
Define the values through to the net80211 definitions and also
annotate them by at least some standards reference.
Fixes: 6b4cac814e
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43658
(cherry picked from commit 53eb2c63c9628f7f19d88d759e1932c10c9f08af)
For iwlwifi(4) d3.c we need another struct in struct ieee80211_key_seq
and related WLAN_KEY_LEN_* defines in.
Reviewed by: cc, emaste
Differential Revision: https://reviews.freebsd.org/D43646
(cherry picked from commit 2f029bf911e29dc46c32ea142daba4f26a2078f4)
When adding the new field link_id to struct ieee80211_key_conf, it
was erroneously placed at the end of the struct; the zero-length
(variable sized) array for the key always needs to stay last.
Resort fields and add hopefully helpful comment to avoid the problem
in the future.
Fixes: adff403fe7
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43635
(cherry picked from commit 828ce22f079df77b3bf52c4cf296959ea66bdc11)
Implement ieee80211_handle_wake_tx_queue() and ieee80211_tx_dequeue_ni()
while looking at the code. They are needed by various wireless drivers.
Introduce an ltxq lock and protect the skbq by that.
This prevents panics due to a race between a driver upcall and
the net80211 tx downcall. While the former should be rcu protected we
cannot rely on that.
It remains questionable if we need to protect further fields there
(with a different lock?).
Also introduce a txq_mtx on the lhw which needs to be further deployed
but we need to come up with a good strategy to not end up with 7 different
locks.
Sponsored by: The FreeBSD Foundation
PR: 274178, 275710
Tested by: cc
(cherry picked from commit eac3646fcdd445297cade756630335e23e92ea13)
Fix defines and structures to use proper types.
Bring in basic ni->sta synchronization, some channel width handling,
and overload the net80211 functions so that we can talk to
driver/firmware to setup parameters. We will likely not need one
or two of those but it is good for tracing currently.
Cover HT and bits of VHT code in LinuxKPI behind apropriate #ifdef
which are currently not enabled (like LKPI_80211_HW_CRYPTO) until
confirmed to work.
Last, IEEE80211_AMPDU_RX_START made some firmware unhappy.
This will allow others to work on it and test as well.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 9fb914634eff85b3b36bcbf39c1faf2967b0aa9e)
Move the net_epoch into net80211 around the if_input calls and out of
the driver (in this first case LinuxKPI). This reduces coverage but
also allows us to alloc in calls like (*ampdu_rx_start) which do not
actually pass data up the stack.
The follow-up commits will revert b65f813c1a,
21c4082de9,
17c328b6ae,
af2441fbc7,
and 6c3e93cb5a for ath.
Sponsored by: The FreeBSD Foundation
Tested by: few (rtwn, ath, iwlwifi, ...)
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D42427
(cherry picked from commit de607e3c230be88f6232b9c9fd6c37199648dc8c)
Start scaling arrays dynamically instead of using MAXCPU, resulting in
extra allocations on startup but reducing the overall memory footprint.
For the static single CPU mask we provide two versions to further save
memory depending on a low or high CPU count system. The threshold to
switch is currently at 128 CPUs on 64bit platforms.
More detailed comments on the implementations can be found in the code.
If I am not wrong on a MAXCPU=65536 system the memory footprint should
roughly go down from 512M to 1.5M for the static single CPU mask.
Submitted by: olce (most of this final version)
Sponsored by: The FreeBSD Foundation
PR: 274316
Differential Revision: https://reviews.freebsd.org/D42345
(cherry picked from commit 488e8a7faca51a71987fbf00cd36cfcd19269db7)
Sort the dev_<loglevel> functions by loglevel order, add the dev_alert()
version and an indentation change.
No functional changes.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D43719
(cherry picked from commit 70617458676eb0b0076aa19657d21f2a9f3b704a)
Amdgpu driver does a lot of memory allocations in FPU-protected sections
of code for certain display cores, e.g. for DCN30. This does not work
on FreeBSD as its malloc function can not be run within a critical
section. Check this condition and temporally exit from FPU-protected
context to workaround issue and reduce source code patching.
Sponsored by: Serenity Cyber Security, LLC
Reviewed by: manu (previous version)
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D42822
(cherry picked from commit c0b8047bdc13040eafb162c4b7b5dba11034ff4b)
acpi_dev_present detects that a given ACPI device is present based on
Hardware ID, Unique ID and Hardware Revision of the device.
Sponsored by: Serenity Cyber Security, LLC
Reviewed by: manu
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42823
(cherry picked from commit 04952a9456e226460d1d95c42ea53861b1133b1a)
It does a Read-Modify-Write operation using clear and set bitmasks on
PCI Express Capability Register at pos. As certain PCI Express
Capability Registers are accessed concurrently in RMW fashion, hence
require locking which is handled transparently to the caller.
Sponsored by: Serenity CyberSecurity, LLC
Reviewed by: manu, bz
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42821
(cherry picked from commit 808ae4e29b6b9c9acc7eab013c5045370df8182a)
We assume that backlight (in Linux term) is always "native".
Also stub acpi_video_register_backlight()
Sponsored by: Serenity Cyber Security, LLC
Reviewed by: manu, bz
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42814
(cherry picked from commit 745067c58514c4323dc16697e19f59dd08a8e963)
and bitmap_shift_right() functions to linux/bitmap.h
They perform calculation of two bitmaps intersection,
copying the contents of u32 array of bits to bitmap and
logical right shifting of the bits in a bitmap.
Sponsored by: Serenity Cyber Security, LLC
Reviewed by: manu
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42812
(cherry picked from commit 5ae2e6f913fa1df5f3262255558b76af05409a09)
Cancel a work not waiting for it to finish.
Sponsored by: Serenity Cyber Security, LLC
Reviewed by: manu, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42811
(cherry picked from commit 1b2f43a7427ebf51561867f6c497833268014512)
