As indicated in 11db70b6057e there was another panic on key removal
which could no longer be reproduced. As originally assumed the
problem was "hidden" by commit 9763fec11b83 as mentioned in
11db70b6057e.
Said commit had logic inverted and 27bf5c405bf2 fixed that and with
that the possible panic came back.
The problem exists because some code paths out of net80211 are
locked while others are not. This opens a possible race in
net80211 which was tracked by extra logging in
(*iv_key_update_begin)() (log lines shortend):
key_update_begin: tid 100112 vap X nt Y unlocked
key_update_begin: tid 100133 vap X nt Y locked
One thread can be wpa_supplicant, the other is driven from the
driver net80211 taskq.
Further LinuxKPI needs to unlock (conditionally in case the lock
is held) as a downcall to the driver/FW may sleep. This opens up
possibilities for said race even further so that we observe it
more reliably.
This all leads to one thread calling down into the driver/firmware
(unlocked) while the other will get to the same place (after acquiring
the wiphy lock) before the nt re-lock happens and thus state checks
did not catch this either.
For LinuxKPI work around the problem utilizing
(*iv_key_update_begin/end)() and taking the wiphy_lock() there
holding it over the entire operation.
Given we still have to conditionally unlock we need to keep track
from _begin to _end on whether we have to re-lock. The checks for
this need to be done under the wiphy_lock().
While a bool would suffice we use a refcount to make any future
debugging easier.
This isn't the most elegant solution but having the wiphy lock
covering the full operation allows the 2nd thread to later run through
the same code path and find the key gone (which we already checked).
It remains questionable if (*iv_key_update_begin/end)() is the
correct solution (as there are futher callers covering which would
not need the unlock cycle) or if it should be done in the current
code. The former will allow us to cover a full key store which
we will need in case we will implement suspend/resume beyond what
is done in native drivers/net80211 currently, if we will factor
out the crypto locking for good, and fix the inconsistent locking
of the nt (NODE) lock in net80211.
Alternate solutions were discussed on freebsd-wireless today
(2025-03-06, in the thread "Re: HEADS UP! Do not update on main
currently (panic - on boot)").
Sponsored by: The FreeBSD Foundation
X-MFC with: 27bf5c405bf2
Differential Revision: https://reviews.freebsd.org/D49256
(cherry picked from commit b8dfc3ecf7031a0a7764cdb67d85ebe0c03d5d93)
net80211 used MMIC flags for CCMP instead of only for TKIP.
LinuxKPI 802.11 compat code (and later net80211) had a comment about
this. Given LinuxKPI seems to be the only consumer for these flags
currently outside of net80211 itself, clean them up before implementing
TKIP in LinuxKPI after all and before GCMP comes into the tree.
Sponsored by: The FreeBSD Foundation
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D49219
(cherry picked from commit 394a9a5b1c2ad7b679a00c3087c41378abfa74a1)
(cherry picked from commit 5f2893553f3cde7c1529f9ca3987be378a9b7025)
Compile in the VHT compat code by default even though no one will make
use of it yet.
Sponsored by: The FreeBSD Foundation
Tested with: iwlwifi AX210 (NOHT, HT20, HT40, VHT20, VHT40, VHT80)
(cherry picked from commit 2c44f1ff6935e93f7774e526f2f1ab0a2812eab5)
Compile in the HT compat code by default even though no one will make
use of it yet.
Sponsored by: The FreeBSD Foundation
Tested with: iwlwifi AX210 (NOHT, HT20 and HT40)
(cherry picked from commit 75d23d882389e1bb011bda37022aaa17c068cbf8)
If HT is enabled but not using CHW=40 set CHW=20 to make sure we do
not get stuck on any other value.
If VHT and the VHT Operation element Channel Width field is 0
(use 20/40) do not update the bandwidth but stick with what HT selected.
This is better than disabling VHT alltogether for 20/40 and allows us
to work on VHT20 and VHT40 APs it seems.
We will have to do more work to can align with the chanctx or deal with
Operating Mode Notification Action frames in LinuxKPI or net80211.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 3e022a91c91cf1b967d7de7b6fe81c6632fe1207)
For the moment we set dynamic_rx_chains to the rx_nss value which
should be correct given we count from 1 there too and we call
lkpi_get_max_rx_chains() after we synced ht/vht initially already.
Long-term some of these counting bits should be further factored
out into their own functions and used both here and for the sync
code.
This will likely want to change as well once more dyamic
synncronization takes place.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 389265e3ca827ad88b3b8ad787251471161d6634)
Clear IEEE80211_FHT_AMPDU_TX from iv_flags_ht to avoid doing A-MPDU TX.
For Intel we need to support two different variations at least, both
likely needing net80211 surgery first. The good news is that turning
it off in net80211 will make it work for modern iwlwifi/mvm chipsets/fw.
Realtek will need some mac80211 functions to be implemented at least.
Once we've done all and tested one after the other we can remove this
again.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit ac2c7271b7c2624d7cf3af6bdaf82b00323edfd3)
Cleanup chanctx freq1/2 and width settings using the channel from the
net80211 node and the net80211 functions to return the center
frequencies (already doing the math for us or using pre-computed values).
Set the min_def (minimum channel definition) to def (channel definition)
for the moment as it seems to be unused by anything but
iwl_mvm_chanctx_def() to avoid complications.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 90d8e307ff610f20dccffe038353affbad0c374e)
Have a wrapper function dealing with the synchronization for all the
dfferent standards (HT and VHT currently).
In case HT or VHT is not supported make sure to turn the LinuxKPI
"supported" flag off for that. Previously if it was on once it would
never be turned off.
For HT and VHT properly compute the NSS and also set the max_amsdu_len
correctly.
Set the NSS directly in the function (which is called in proper order
for this) rather than passing the results back and do the setting in
the caller. The only thing we need to make sure upfront is that it
remains at least 1 (see f5a58c2da239). This all makes the caller and
code a tiny bit simpler and work better.
There is more synchronization to be done between the chanctx and the
deflink bandwidth, which needs to happen dynamically in case net80211
decides to change that under us but no native driver seems to properly
implement this (if at all).
HT20-only, HT40, and VHT80 are supposed to work for now at least.
VHT160 and VHT80P80 have further debug work to do as it does not yet
seem to be consistently set in all cases to sync from.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit f9c7a07d7f5e1c3694b463423c43051451b61e87)
Make a pass over skbuff.h:
- implement some missing bits,
- sprinkle some const,
- add locking and read/write_once calls as needed to provide
synchronization as expected by Linux,
- fix some typos,
- remove return from void functions,
- adjust tracing macros.
Sponsored by: The FreeBSD Foundation
PR: 283903 (rtw88 skb leak)
Tested by: Guillaume Outters (guillaume-freebsd outters.eu)
Tested by: oleg.nauman gmail.com
Differential Revision: https://reviews.freebsd.org/D49101
(cherry picked from commit 2ab4a41956159e7c974979693cb0b13cf552128e)
net80211 has inconsistent locking when calling into (*ic_ampdu_rx_stop)().
Make use of 054c5ddf587a7 and conditionally check if the caller
locked or not and if locked temporary drop the lock to avoid sleeping
on a non-sleepaable lock during the downcall into the driver.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 65c573e47c40e3f167f3d7e41bd8db40b6b8f91e)
When setting the per-band supp_rates bitfield check for mandatory
rates only. We cannot easily say at that point for 2Ghz whether
11g is supported so assume these days it is not pure-b.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 73cd1c5d44ead3b84cebcc0c24278429afa9e6ec)
Use IEEE80211_CONF_VHT() instead of manually checking if hardware
supports VHT.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 1f73e0ed539d2be48fed70b09e87ecccce4ca869)
Implement cfg80211_chandef_create() to work with HT. Update enum
with HT channel types. When calling the function from LinuxKPI 802.11
code, pass in NL80211_CHAN_HT20 if HT is supported rather than NO_HT.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 11450726d3cf8d76d2113d7cabe995f8ef31ec5a)
We ran into problems with locking the VIF for the lsta tailq on and
off. Switch from a native tailq to the LinuxKPI list.
This allows us to implement the "rcu" part in
linuxkpi_ieee80211_iterate_keys() which we could not before.
Further using either rcu or the wiphy lock we no longer run into
problems with the lock not being sleepable.
The last case was rtw89 debugfs which was doing a sleepable alloc
in the iterator callback of linuxkpi_ieee80211_iterate_stations_atomic().
Sponsored by: The FreeBSD Foundation
(cherry picked from commit a8f735a66130aa737999fad9b3246159099dc9eb)
Rather than just printing the cipher suite as uint32_t hex
(or split into OUI and number) also print a short name.
iwlwifi(4), for example, now prints on startup with HW_CRYPTO on:
unsupported WLAN Cipher Suite 0x000fac | 8 (GCMP)
unsupported WLAN Cipher Suite 0x000fac | 9 (GCMP_256)
unsupported WLAN Cipher Suite 0x000fac | 6 (AES_CMAC)
unsupported WLAN Cipher Suite 0x000fac | 11 (BIP_GMAC_128)
unsupported WLAN Cipher Suite 0x000fac | 12 (BIP_GMAC_256)
Likewise _lkpi_iv_key_set() would now print:
iwlwifi0: _lkpi_iv_key_set: CIPHER SUITE 0xfac02 (TKIP) not supported
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 12a511c844706917e49e24c8d1daa861288aea23)
Implement mac80211 functions ieee80211_iter_keys[_rcu](), and
ieee80211_get_key_rx_seq() (*).
Implement an internal function lkpi_sta_del_keys() to delete keys
when we are leaving RUN (AUTHORIZED) state.
Improve and make work (*) the net80211 vap function pointers
(*iv_key_set)(), (*iv_key_delete)() implementations.
Correct the logic in lkpi_80211_txq_tx_one() and factor most crypto
related bits out into lkpi_hw_crypto_prepare() (*).
(*) We are currently supporting CCMP only. I would hope we will
not have to do full WEP/TKIP support anymore given both are deprecated.
The entire logic remains behind the LKPI_80211_HW_CRYPTO pre-processor
condition and with this commit in addition behind a tunable.
The code is compiled in by default now but the tunable remains off until
wider testing has shown no problems.
I have seen one net80211 triggered panic on shutdown related to deleting
keys which I cannot reproduce anymore and could have been fixed by
9763fec11b83; otherwise we will have to investigate as it shows again.
The dedicated hw crypto tracing option can help in that case with debug
kernels.
Sponsored by: The FreeBSD Foundation
Fixes: b35f6cd066
(cherry picked from commit 11db70b6057e41b259dc2245cd893d5b19179fcc)
Implement the mac80211 (*sta_statistics) to obtain station statistics.
Fix up struct station_info for that.
Add supporting funtions to decode station_info and rate_info_bw fields
to make the output more usable to human beings.
Add a per-VIF (VAP) sysctl to export that information. This is mostly
used for now to see what the driver/fw thinks about its TX rate.
We should later gather this information in different ways and pass it
to net80211 to export it to user space so we can finally have nice
station information (also for the non-AP side).
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 408394185fe9be0c158189b7671bde316ac14ac9)
rtw88 seems to have an skb leak still.
Add a WARN_ONCE to __skb_queue_purge() just to make sure there is no
glitch due to missing locking.
Also add a rolling error reporting for skb allocation failures in
LinuxKPI to gather some more information if possible about queue
states.
This is a corrected version of what was initially part of D48474.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit bcf1d8ee355213eef4a125c0b8518f1cb4f35df4)
(cherry picked from commit 1432e0f20ccde8eaa23d3d3e20fca2989cd344b6)
For now we only return the legacy rate and have two TODOs for HT and
VHT which still need to be implemented as needed.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit a7c19b8a99a604e8940c7475220df5de7e295ffa)
Convert a lot more LinuxKPI rx_status fields to net80211 rx_stats
bits for as much as we can see fit. Factor the entire logic out
into its own function as it got quite long.
Now only net80211 needs to start using more of these values and
report them.
Also fix some related fields and struct definitions in LinuxKPI.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 49010ba706d39fba0d8bc128d96e6122e65eb8ad)
There are cases when we see "rx seq# violation (CCMP)".
Historically these were AHDEMO/IBBS cases (IEEE80211_KEY_NOREPLAY,
see 5d766a09da).
With iwlwifi(4) doing RSS for newer chipsets and us not having any idea
about multiple rx-queues (passed all the way through) leads to the same
problem. An easy way to trigger this is doing an IPv6 all-nodes echo
request. With a sufficient amount of nodes answering the answers will
be hashed to different queues and re-ordering will likely take place
as queues get released individually.
However crypto validation is already done in fw/driver for these cases
and we need to carry the state forward. Add IEEE80211_RX_F_PN_VALIDATED
to indicate that the checks were done passing the information from driver
through LinuxKPI to net80211.
LinuxKPI enforces that a frame was indeed decrypted; otherwise the flag
would be invalid.
This also avoids returning an error and no key from
ieee80211_crypto_decap() and thus avoids dropping the frame.
Sponsored by: The FreeBSD Foundation
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D49029
(cherry picked from commit ec6185c52661d3af0dac6dcc8701fc49fae3e1d9)
Until net80211 will grow proper scan offload with the various options
needed and will allow switching the scan engine try to improve the
situation if we are doing a hw_scan and the device supports
SINGLE_SCAN_ON_ALL_BANDS. In that case create the channel list from
our device information of supported channels rather than from the
net80211 scan list. Filter out currently unsupported bands.
While the general "scan EBUSY" problem remains at least in my local
testing I am seeing a lot more 2 and 5 GHz band results rather than
being stuck on a single band (as was also often the case with iwm for
me in the past).
Tested by: rene (previous version)
(cherry picked from commit c272abc5c6a72881f1252f069d79990201559d1a)
Given the channel struct has an extra bool we cannot assign the
information 1:1 to net80211. While the caps where assigned the
suppoerted mcs sets were not. Fix that.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit ecb2e5f9c30a8c0ae491d07b2300e37eb599c298)
Let the macro take a format string and arguments and
add __func__, __LINE__ to the output.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit a4cdb785bbd7e26cc3f2ed0bb4e5cf7ea83c400b)
Add a print mask for use with %b to aid debugging. It is a lot easier
to read names than numbers.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit f1aeb5d850cf26418fb70a16d1304b92c45b5f1d)
Bring in changes missed during the last driver updates to make HT
compile when enabled.
Sponsored by: The FreeBSD Foundation
Fixes: 7b43f4d064195
(cherry picked from commit 943a19c666d67424cdde6cbcd096f28359b2d314)
Given we have the support in main and stable/14 to load plain firmware
files from /boot/firmware/ make use of that. Switch the order to
try the original unmangled filename and path first before trying any
replacements.
This reduces time and console noise (especially under bootverbose).
Sponsored by: The FreeBSD Foundation
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47682
(cherry picked from commit 30d2f84ef2cba12c67c62a9fe4e1d8e22cf27bf9)
Bring in the LinuxKPI 802.11 compat bits which are altering
the mac80211 KPI.
* In struct ieee80211_bss_conf chandef -> chanreq.
* Various struct ieee80211_ops gained a link_id arguemnt,
stop gained a suspend flag.
* Various functions gained a link_id argument.
* ieee80211_tx_status() was renamed to ieee80211_tx_status_skb()
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 7b43f4d064195bcf66816cb9fe350a1392fe24ce)
In 886653492945f we added checks for packets to only go out if the
station is known to the firmware (amongst others) as there are
implications in drivers.
Unfortunately rtw88 does not support the mac80211 (*sta_state)() KPI
but only the fallback (*sta_add/remove)() in which case the station is
only added to firmware when going from AUTH to ASSOC. That means we
had no chance to get authenticated anymore.
PR: 283142, 274382
Fixes: 886653492945f (make sure we can send DISASSOC or DEAUTH frames)
Tested by: imb protected-networks.net, oleg.nauman gmail.com
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48161
(cherry picked from commit 2372f8cc640c2f4ab82831e6ac0e27ab6c18321a)
Bump the vnode use count, not its hold count. This fixes a panic triggered
by fstatat(..., AT_EMPTY_PATH) on DRM device nodes, which happens to be
what glxinfo(1) from Ubuntu Jammy is doing.
PR: kern/274538
Reviewed By: kib (earlier version), olce
Differential Revision: https://reviews.freebsd.org/D47391
(cherry picked from commit fc595a6b76642dfdfdb8e6f9b9bbc734e95fb59c)
Annotate lkpi_ic_recv_action(), lkpi_ic_send_action(), and
lkpi_ic_ampdu_enable() with HT specifc debug logging as we only hook
them up currently for debug tracing but later should not need them
anymore.
Start the implementation for lkpi_ic_addba_request(),
lkpi_ic_addba_response(), and lkpi_ic_addba_stop().
Improve the implementation of lkpi_ic_ampdu_rx_start() and
lkpi_ic_ampdu_rx_stop().
Sponsored by: The FreeBSD Foundation (commit)
(cherry picked from commit 310743c4ccc545d58401cb9fb7761432e12a9fb5)
If a LinuxkPI base wireless driver does not support the (*ampdu_action)()
ieee80211_ops function for offloading parts to firmware there is no
reason for us to hook into the net80211 callbacks either but simply
to let software (net80211) handle this.
Sponsored by: The FreeBSD Foundation (commit)
(cherry picked from commit 86bc7259d3d558495511a0a23d137b4a6cd030f3)
The changes from 4aff4048 were based on net80211 which is still using
if_private.h details. Adjust the code to no longer depend on internal
details of ifnet. We also switch the "check"-functionn from if_init to
if_transmit which we can query. Given we do have a per-vif eventhandler
we could do without that check but would still need to check
if_getflags() for IFF_UP.
Sponsored by: The FreeBSD Foundation
Reported by: jhibbits
Fixes: 4aff4048
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D47490
(cherry picked from commit edab5a280e0b4a53d0f3e34957075c7efe048e8d)
Bring ing the LinuxKPI 802.11 compat bits which are not altering
the mac80211 ops KPI.
* Add various functions for driver updates.
* Add functions (some compat code to I assume cleanup some
mac80211 ops) emulating chanctx changes doing (*config) updates.
* Adjust structs and defines.
* Deal with an enum growing more than 32 bits in printf.
* Add a mtx to struct wiphy which is exposed to the drivers.
Handle initialization and destruction for now.
* Implementation of wiphy_work and wiphy_delayed_work.
* Set was_assoc for deassoc/deauth in prep_tx_info.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit ac1d519c01ca8beb59f27962c7052d09a03f72c8)
Update rcu_dereference_{check,protected}() to call the check and log
once if it fails and if the RCU debug sysctl is turned on.
Also add proper checks for conditions passed in to these functions.
For that implement linux_rcu_read_lock_held() (lots of help from wulf).
(While here also remove extraneous extern for function prototypes).
Update lockdep_is_held() to always be an inline function with argument
annotation so that we do no longer have unused variables
in callers which only call lockdep_is_held().
Sponsored by: The FreeBSD Foundation
Reviewed by: wulf
Differential Revision: https://reviews.freebsd.org/D46842
(cherry picked from commit 5c92f84bb607c692ce4fa762a7a3c4b86a2fa281)
PCI_IRQ_LEGACY was added in 366d68f283 (likely) for rtw88 only.
The define now got renamed and I cannot find any other use but
rtw88 and rtw89.
We keep the old name as comapt while driver updates are in
progress enabling it defining LINUXKPI_VERSION for the two drivers.
Sponsored by; The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46822
(cherry picked from commit 157e93e0e8138fbaa6ab5d5b20b0c23f903667a6)
Add alloc_netdev_dummy() which is needed by an updated rtw88 driver.
Given we already call linuxkpi_init_dummy_netdev() ourselves allow the
setup function to be NULL to not initialize and start a tasq td twice.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46802
(cherry picked from commit 105331f658e2f14fb4daa64dcd076c7369505295)
rtw89 TX path was faulting in linuxkpi_ieee80211_next_txq() due to a
"double scheduling" check in linuxkpI_ieee80211_schedule_txq() being
incorrect:
the next pointer may be NULL there if the element is the last in the
tailq, so correctly check tqe_prev. Without the fix we may have queued
the same element to the tailq twice, and because it was the last element
and had a NULL tqe_next, that NULL value would get propogated into
another node's tqe_prev on removal, and other such nastiness.
With this rtw89 no longer panics.
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D47006
(cherry picked from commit 41b746e05231b44c87f3a3087a7fe29966af6d0f)
Native Linux implementation sets this as a maximum between 1 and
ht/vht/eht rx SS'es, FreeBSD does the same, but uses 0 as a minimum,
which leads setting it to 0 if we're not in ht/vht case.
This 0 was breaking rtw89 driver, when it was trying to determine
SS number by subtracting 1 from rx_nss and passing the value to the
hardware.
After this patch rtw89 association and simple ping work reliably,
but more work is needed to make the driver robust with heavy traffic
(iperf3) and being long idle.
Reviewed by: bz
Sponsored by: Future Crew LLC
Differential Revision: https://reviews.freebsd.org/D46528
(cherry picked from commit f5a58c2da23930ee4870f2eb54788f4669b9aa33)
As a consequence lkpi_ieee80211_ifalloc() now does not fail. Remove
unneeded NULL check.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D45852
(cherry picked from commit 7bcb1228558b4325fab39616e2e3b2573a9e7da6)
Allow a user to change the "ether" address by ifconfig while a VAP is
not UP. Compared to net80211 (given we have no callback) we register
an eventhandler per-vif (a global one would force us to use hacks to
derive if a vap is indeed also a lkpi_80211 vif).
Sponsored by: The FreeBSD Foundation
PR: 277356
Tested by: lwhsu
Differential Revision: https://reviews.freebsd.org/D46121
(cherry picked from commit 4aff4048f5b1b6ab0b905726853ba6083e37cc37)
We have TRACE in one place and TRACE-RX in another. Spell it
"TRACE-RX: %s: ..." everywhere. Helps with pattern matching.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45818
(cherry picked from commit bd206a6f4a87214ae8c1b32f1051b07362080361)
If IEEE80211 debugging is turned on in kernel configs also turn on
LinuxKPI 802.11 and SKB debugging (sysctls) to have them available.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45820
(cherry picked from commit 59d262fe969af5a8a83f0ccd7586c9bd2c8fb1f3)
In order to allow the allocator to change in the future move it into
the implementation file from being an inline function in the header.
While here factor out the size calculation and add a comment as-to why
this is done. We will need the size (_s) in the future to make a
decision on how to allocate.
Sponsored by: The FreeBSD Foundation
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D45815
(cherry picked from commit 1f7df757017404011732196e65981d9325f7a89f)
disable hdmi_audio_infoframe_pack_for_dp function for now as it depends
on not imported yet drm sources and is not used by drm-kmod.
Reviewed by: manu
Sponsored by: Serenity CyberSecurity, LLC
Differential Revision: https://reviews.freebsd.org/D46224
(cherry picked from commit c89d94ad5d95fd15e891b2723caae8a6104ee153)
If the resource was allocated with want_iomap_res flag set.
Sponsored by: Serenity CyberSecurity, LLC
MFC after: 1 week
Reviewed by: manu, bz
Differential Revision: https://reviews.freebsd.org/D45905
(cherry picked from commit 14fc33ea3a0571ca70e609b6f9e67db39f7c6140)
pci_iomap_range creates a virtual mapping cookie for a PCI BAR.
As compared with pci_iomap it got extra offset parameter.
Sponsored by: Serenity CyberSecurity, LLC
MFC after: 1 week
Reviewed by: manu, bz
Differential Revision: https://reviews.freebsd.org/D45904
(cherry picked from commit fcc350c375f776318d0da8021109631492ab9261)
