| Age | Commit message (Collapse) | Author |
|---|
|
for_each_netdev_dump() can be used with RCU protection,
no need for rtnl if we are going to use dev_hold()/dev_put().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20240207153514.3640952-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In commit 759ab1edb56c ("net: store netdevs in an xarray")
Jakub added net->dev_by_index to map ifindex to netdevices.
We can get rid of the old hash table (net->dev_index_head),
one patch at a time, if performance is acceptable.
This patch removes unpleasant code to something more readable.
As a bonus, /proc/net/dev gets netdevices sorted by their ifindex.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20240207165318.3814525-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The convention is to not use the "inline" keyword for functions in C
files, but to let the compiler choose.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20240206112927.4134375-2-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The convention is to not use "inline" functions in C files, and let the
compiler decide whether to inline or not.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20240206112927.4134375-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Recently, handshake_req_destroy_test1 started failing:
Expected handshake_req_destroy_test == req, but
handshake_req_destroy_test == 0000000000000000
req == 0000000060f99b40
not ok 11 req_destroy works
This is because "sock_release(sock)" was replaced with "fput(filp)"
to address a memory leak. Note that sock_release() is synchronous
but fput() usually delays the final close and clean-up.
The delay is not consequential in the other cases that were changed
but handshake_req_destroy_test1 is testing that handshake_req_cancel()
followed by closing the file actually does call the ->hp_destroy
method. Thus the PTR_EQ test at the end has to be sure that the
final close is complete before it checks the pointer.
We cannot use a completion here because if ->hp_destroy is never
called (ie, there is an API bug) then the test will hang.
Reported by: Guenter Roeck <linux@roeck-us.net>
Closes: https://lore.kernel.org/netdev/ZcKDd1to4MPANCrn@tissot.1015granger.net/T/#mac5c6299f86799f1c71776f3a07f9c566c7c3c40
Fixes: 4a0f07d71b04 ("net/handshake: Fix memory leak in __sock_create() and sock_alloc_file()")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/170724699027.91401.7839730697326806733.stgit@oracle-102.nfsv4bat.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Cross-merge networking fixes after downstream PR.
No conflicts.
Adjacent changes:
drivers/net/ethernet/stmicro/stmmac/common.h
38cc3c6dcc09 ("net: stmmac: protect updates of 64-bit statistics counters")
fd5a6a71313e ("net: stmmac: est: Per Tx-queue error count for HLBF")
c5c3e1bfc9e0 ("net: stmmac: Offload queueMaxSDU from tc-taprio")
drivers/net/wireless/microchip/wilc1000/netdev.c
c9013880284d ("wifi: fill in MODULE_DESCRIPTION()s for wilc1000")
328efda22af8 ("wifi: wilc1000: do not realloc workqueue everytime an interface is added")
net/unix/garbage.c
11498715f266 ("af_unix: Remove io_uring code for GC.")
1279f9d9dec2 ("af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Currently ieee80211_csa_finish() function finalizes CSA by scheduling a
finalizing worker using the deflink. With MLO, there is a need to do it
on a given link basis.
Pass link ID of the link on which CSA needs to be finalized.
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-6-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add changes to start a channel switch as well as finalize it on link basis
in order to support CSA with MLO as well.
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-5-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In order to support CSA with MLO, there is a need to handle the functions
ieee80211_set_csa_beacon() and ieee80211_set_after_csa_beacon() on a per
link basis.
Implement this by making the function argument accept the the link data
instead of the sdata.
Currently, deflink would only be passed. Proper link data will be passed in
a subsequent patch.
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-4-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Currently, function to update beacon counter uses deflink to fetch
the beacon and then update the counter. However, with MLO, there is
a need to update the counter for the beacon in a particular link.
Add support to use link_id in order to fetch the beacon from a particular
link data during beacon update counter.
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-3-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Currently, during channel switch, no link id information is passed down.
In order to support channel switch during Multi Link Operation, it is
required to pass link id as well.
Add changes to pass link id in the channel_switch cfg80211_ops.
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-2-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The new Wi-Fi Standard (IEEE Std 802.11-2020 9.4.2.160) specifies that
the Wide Bandwidth Channel Switch (WBCS) Element subfields have the same
definitions as VHT operation information if the operating band is not
S1G.
The problem comes when the BSS is in 6 GHz band, the STA parses the WBCS
Element by ieee80211_chandef_vht_oper(), which checks the capabilities for
HT/VHT mode, not HE/EHT mode.
This patch refactors STA CSA parsing flow so that the corresponding
capabilities can be checked. Also, it adds the way to use op_class in ECSA
Element to build a new chandef.
In summary, the new steps for STA to handle CSA event are:
1. build the new chandef from one of the CSA-related (Sub)Elements in
following order,
- Bandwidth Indication (Sub)Element
- Wide Bandwidth Channel Switch (Sub)Element
- Operating class in Extended Channel Switch Announcement Element
- Channel Switch Announcement Element
2. convert the new chandef into operation information according to the
operating band in order to check if the new chandef fits STA's
capabilities.
3. downgrade the bandwidth until current bandwidth is not disabled.
Co-developed-by: Money Wang <money.wang@mediatek.com>
Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
Link: https://msgid.link/20231222010914.6521-3-michael-cy.lee@mediatek.com
[rebase on top of the changes with struct ieee80211_conn_settings,
prefer leXY_encode_bits()]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This utility is used in STA CSA handling. The op_class in the ECSA
Element can be converted into chandef.
Co-developed-by: Money Wang <money.wang@mediatek.com>
Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
Link: https://msgid.link/20231222010914.6521-2-michael-cy.lee@mediatek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Some drivers may (notably mt76 does) not set up sband->band
before registering, and cfg80211 will fill it in later. But
since the HT/HE capability check mac80211 required it to be
initialized already, otherwise failing things. This really
isn't necessary though since the code is iterating the list
of bands, and has the 'band' variable available. Fix it to
not require the sband->band to be initialized already.
Fixes: f04d2c247e04 ("wifi: mac80211: disallow drivers with HT wider than HE")
Reported-by: Bert Karwatzki <spasswolf@web.de>
Debugged-by: Bert Karwatzki <spasswolf@web.de>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218466
Link: https://msgid.link/20240207115920.43cbedffb5c3.I4968e12275a3f95926e3f3ccae81e50f23fe4d4d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This was added earlier, add kernel-doc for it.
Link: https://msgid.link/20240206134555.6354b0ac8610.Ib90d3651834c556b73697388f59bd396a1f6f9b0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The vif pointer at least looks like it can actually be NULL
in some cases such as the monitor-mode vif, causing static
checkers to complain with the immediate derefence. In these
cases the sta pointer will also be NULL, but clarify it in
the code anyway.
Link: https://msgid.link/20240131164910.60066625a239.Idfb6a5a9876f9f631eae760055e1c4018259a971@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This could be used e.g. for temporarily sending quiet
(mode=1 in CSA/ECSA), or updating bandwidth. This is
also useful for testing, since it's something that an
AP may do and the client needs to be prepared. Simply
allow it.
Link: https://msgid.link/20240129203544.ef7258d5790d.Idafe22e41621757458d4960659b9621853f7104d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Convert ieee80211_ie_build_eht_cap() to the SKB-put function
style, renaming it to ieee80211_put_eht_cap().
Link: https://msgid.link/20240129202041.ece9769e3c94.Ibd17bea6311f0c7ba56f6c1803fa3208abaaebb9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Convert ieee80211_ie_build_he_cap() to the SKB-put function
style, renaming it to ieee80211_put_he_cap().
Link: https://msgid.link/20240129202041.e6ef888980d9.Ied9e014314b5d27611e693e3d4cb63bdc8d7de17@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This code got really big, move it to a new file.
Pure code move.
Link: https://msgid.link/20240129202041.7f27f7c895e4.I0adfc28bd656a4d44c2bf47966277eecf56cbaa0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The building of elements is really mess, and really the only
reason we're not doing it in SKBs in the first place is that
the scan code in ieee80211_build_preq_ies() doesn't.
Convert ieee80211_build_preq_ies() to use an SKB internally
so that we can gradually convert other things to ..._put_*()
style interfaces.
Link: https://msgid.link/20240129202041.c3a8e3c2cc99.I9d9920858c30ae5154719783933de0d7bc2a2cb9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Make this a new-style "put" function, and change the
parameters to pass more information directly, this
makes it usable also for the MLME code.
Link: https://msgid.link/20240129202041.f604a03bd728.I8c798ea45b8479ac9982e77d0378af11a09ccdaf@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We don't need to use the write function here since we already
have an SKB, so use ieee80211_put_he_6ghz_cap() with the SMPS
mode taken from the link we're using.
Link: https://msgid.link/20240129202041.6454ac78ff8c.I7152e3c27645105478c68d40ca493feb27cac6bf@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The term 'IE' isn't really in use in the spec, and I want
to rework all of this to use SKBs as the primary method
for building elements. Rename this one already.
Link: https://msgid.link/20240129202041.b8064a4e73b5.I8d2f4526562029107c6414c6cda378b300b1b0b0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When limiting a station's supported bandwidth while connecting,
also limit various other HE capabilities according to the bandwidth
needed for them.
Link: https://msgid.link/20240129202041.34be99efca25.I02a695961bc6aadd37768b17c50fcdec4427d460@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If intending to associate with a lower bandwidth, remove capabilities
related to 320 MHz from the EHT capabilities element. Also change the
EHT MCS-NSS set accordingly: if just reducing 320->160 or similar the
format doesn't change, just cut off the last bytes. If changing from
higher bandwidth to 20 MHz only EHT STA, adjust the format.
Note that this also requires adjusting the caller in mlme.c since the
data written can now be shorter than it determined. We need to clean
all that up. Since the other callers pass NULL for the conn limit, we
don't need to change things there.
Link: https://msgid.link/20240129202041.b5f6df108c77.I0d8ea04079c61cb3744cc88625eeaf0d4776dc2b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We don't need to pass the iftype there, we already have it
in the sdata. Simplify this code.
Link: https://msgid.link/20240129202041.5890eb1d4184.Ibce7e5abcc7887630da03ac2263d8004ec541418@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
There really shouldn't be a basic multi-link element in any
per-STA profile in an association response, it's not clear
what that would really mean. Refuse connecting in this case
since the AP isn't following the spec.
Link: https://msgid.link/20240129200652.23f1e3b337f1.Idd2e43cdbfe3ba15b3e9b8aeb54c8115587177a0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Let the element parsing function return what kind of error
was encountered, as a bitmap, even if nothing currently
checks for which specific error it was, we'll use it later.
Link: https://msgid.link/20240129200652.1a69f2a31ec7.I55b86561d64e7ef1504c73f6f2813c33030c8136@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If the vif is an MLD then it may receive multicast from
different links, and should drop those frames according
to the SN. Implement that.
Link: https://msgid.link/20240129200456.693b77d14b44.I491846f2bea0058c14eab6422962c10bfae9b675@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This will also be useful for MLO duplicate multicast
detection, but add it already here and use it in one
place that trivially converts.
Link: https://msgid.link/20240129200456.f0ff49c80006.I850d2785ab1640e56e262d3ad7343b87f6962552@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Aloka originally suggested that puncturing should be part of
the chandef, so that it's treated correctly. At the time, I
disagreed and it ended up not part of the chandef, but I've
now realized that this was wrong. Even for clients, the RX,
and perhaps more importantly, CCA configuration needs to take
puncturing into account.
Move puncturing into the chandef, and adjust all the code
accordingly. Also add a few tests for puncturing in chandef
compatibility checking.
Link: https://lore.kernel.org/linux-wireless/20220214223051.3610-1-quic_alokad@quicinc.com/
Suggested-by: Aloka Dixit <quic_alokad@quicinc.com>
Link: https://msgid.link/20240129194108.307183a5d2e5.I4d7fe2f126b2366c1312010e2900dfb2abffa0f6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This pointer can change here since the SKB can change, so we
actually later open-coded IEEE80211_SKB_CB() again. Reload
the pointer where needed, so the monitor-mode case using it
gets fixed, and then use info-> later as well.
Cc: stable@vger.kernel.org
Fixes: 531682159092 ("mac80211: fix VLAN handling with TXQs")
Link: https://msgid.link/20240131164910.b54c28d583bc.I29450cec84ea6773cff5d9c16ff92b836c331471@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Instead of calculating the new primary 40/80/160 MHz
center frequency here, use the new helper function from
cfg80211.
Link: https://msgid.link/20240129194108.eb59d6433d18.I74b745f0d1a32e779fb25d50c56407be7c35b840@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Simplify cfg80211_chandef_compatible() a bit by switching
c1 and c2 around so that c1 is always the narrower one
(once they're not identical or narrow/S1G). Then we can
just check the various primary channels and exit with the
wider one (c2), or NULL.
Also refactor the primary 40/80/160 function to not have
all the calculations hard-coded, and use a wrapper around
it to check primary 40/80/160 compatibility.
While at it, add some kunit tests for this functionality.
Also expose the new cfg80211_chandef_primary_freq() to
drivers, mac80211 will use it.
Link: https://msgid.link/20240129194108.be3e6eccaba3.I8399c2ff1435d7378e5837794cb5aa6dd2ee1416@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
It doesn't look like we can get into this code, but make it
more robust and declare two S1G chandefs to be incompatible
unless they're identical.
Link: https://msgid.link/20240129194108.b28fb0644a8c.I9297ada5cf1baf00dbbdf8fcffd1806883489fc9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add a new inline helper function to ieee80211.h to
extract the disabled subchannels bitmap from an EHT
operation element, and use that in mac80211 where
we do that.
Link: https://msgid.link/20240129194108.d9f50dcec8d0.I8b08cbc2490a734fafcce0fa0fc328211ba6f10b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Upcoming patches will move the puncturing bitmap into the
chandef, so chandef validation will need to check for correct
puncturing. Purely move the code first so later changes are
easier to review.
Link: https://msgid.link/20240129194108.1ca184427c76.I077deb8d52c4648eac145b63f88b6c5a3b920ddc@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Due to the earlier restructuring we now mostly ignore
the channel configuration in the association response,
apart from the HT/VHT checks we had.
Don't do that, but parse it and update, also dropping the
association if the AP changed its mode in the response.
Link: https://msgid.link/20240129194108.b3efa5eae60c.I1b70c9fd56781b22cdfdca55d34d69f7d0733e31@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
EHT requires that stations are able to participate in
wider bandwidth OFDMA, i.e. parse downlink OFDMA and
uplink OFDMA triggers when they're not capable of (or
not connected at) the (wider) bandwidth that the AP
is using. This requires hardware configuration, since
the entity responsible for parsing (possibly hardware)
needs to know the AP bandwidth.
To support this, change the channel request to have
the AP's bandwidth for clients, and track that in the
channel context in mac80211. This means that the same
chandef might need to be split up into two different
contexts, if the APs are different. Interfaces other
than client are not participating in OFDMA the same
way, so they don't request any AP setting.
Note that this doesn't introduce any API to split a
channel context, so that there are cases where this
might lead to a disconnect, e.g. if there are two
client interfaces using the same channel context, e.g.
both 160 MHz connected to different 320 MHz APs, and
one of the APs switches to 160 MHz.
Note also there are possible cases where this can be
optimised, e.g. when using the upper or lower 160 Mhz,
but I haven't been able to really fully understand the
spec and/or hardware limitations.
If, for some reason, there are no hardware limits on
this because the OFDMA (downlink/trigger) parsing is
done in firmware and can take the transmitter into
account, then drivers can set the new flag
IEEE80211_VIF_IGNORE_OFDMA_WIDER_BW on interfaces to
not have them request any AP bandwidth in the channel
context and ignore this issue entirely. The bss_conf
still contains the AP configuration (if any, i.e. EHT)
in the chanreq.
Link: https://msgid.link/20240129194108.d3d5b35dd783.I939d04674f4ff06f39934b1591c8d36a30ce74c2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In the channel context code we have quite a few instances
of nested loops iterating the interfaces and then links.
Add a new for_each_sdata_link() macro and use it. Also,
since it's easier, convert all the loops and a few other
places away from RCU as we now hold the wiphy mutex
everywhere anyway.
This does cause a little bit more work (such as checking
interface types for each link of an interface rather than
not iterating links in some cases), but that's not a huge
issue and seems like an acceptable trade-off, readability
is important too.
Link: https://msgid.link/20240129194108.7240829bd96d.I5ccbb8dd019cbcb5326c85d76121359225d6541a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
For channel contexts, mac80211 currently uses the cfg80211
chandef struct (control channel, center freq(s), width) to
define towards drivers and internally how these behave. In
fact, there are _two_ such structs used, where the min_def
can reduce bandwidth according to the stations connected.
Unfortunately, with EHT this is longer be sufficient, at
least not for all hardware. EHT requires that non-AP STAs
that are connected to an AP with a lower bandwidth than it
(the AP) advertises (e.g. 160 MHz STA connected to 320 MHz
AP) still be able to receive downlink OFDMA and respond to
trigger frames for uplink OFDMA that specify the position
and bandwidth for the non-AP STA relative to the channel
the AP is using. Therefore, they need to be aware of this,
and at least for some hardware (e.g. Intel) this awareness
is in the hardware. As a result, use of the "same" channel
may need to be split over two channel contexts where they
differ by the AP being used.
As a first step, introduce a concept of a channel request
('chanreq') for each interface, to control the context it
requests. This step does nothing but reorganise the code,
so that later the AP's chandef can be added to the request
in order to handle the EHT case described above.
Link: https://msgid.link/20240129194108.2e88e48bd2e9.I4256183debe975c5ed71621611206fdbb69ba330@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The last caller of this with a NULL argument was related to
the non-chanctx code, so we can now remove this odd logic.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129194108.bad8ec1e76c8.I12287452f42c54baf75821e75491cf6d021af20a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
There are still surprisingly many non-chanctx drivers, but in
mac80211 that code is a bit awkward. Simplify this by having
those drivers assign 'emulated' ops, so that the mac80211 code
can be more unified between non-chanctx/chanctx drivers. This
cuts the number of places caring about it by about 15, which
are scattered across - now they're fewer and no longer in the
channel context handling.
Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In the code we currently check for support 80+80, 160
and 320 channel widths, but really the way this should
be (and is otherwise) handled is that we compute the
highest channel bandwidth given there, and then cut it
down to what we support. This is also needed for wider
bandwidth OFDMA support.
Change the code to remove this limitation and always
parse the highest possible channel width.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129194108.d06f85082e29.I47e68ed3d97b0a2f4ee61e5d8abfcefc8a5b9c08@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Rewrite the station-side connection handling. The connection
flags (IEEE80211_DISABLE_*) are rather confusing, and they're
not always maintained well. Additionally, for wider-bandwidth
OFDMA support we need to know the precise bandwidth of the AP,
which is currently somewhat difficult.
Rewrite this to have a 'mode' (S1G/legacy/HT/...) and a limit
on the bandwidth. This is not entirely clean because some of
those modes aren't completely sequenced (as this assumes in
some places), e.g. VHT doesn't exist on 2.4 GHz, but HE does.
However, it still simplifies things and gives us a good idea
what we're operating as, so we can parse elements accordingly
etc.
This leaves a FIXME for puncturing, this is addressed in a
later patch.
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129194108.9451722c0110.I3e61f4cfe9da89008e1854160093c76a1e69dc2a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Most devices now do duration calculations, so we don't hit
this code at all any more. Clearly the approach of warning
at compile time here when new bands are added didn't work,
the new bands were just added with "TODO". Clean it up, it
won't matter for new bands since they'll just not have any
need to calculate durations in software.
While at it, also clean up and unify the code a bit.
Link: https://msgid.link/20240129194108.70a97bd69265.Icdd8b0ac60a382244466510090eb0f5868151f39@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for net:
1) Narrow down target/match revision to u8 in nft_compat.
2) Bail out with unused flags in nft_compat.
3) Restrict layer 4 protocol to u16 in nft_compat.
4) Remove static in pipapo get command that slipped through when
reducing set memory footprint.
5) Follow up incremental fix for the ipset performance regression,
this includes the missing gc cancellation, from Jozsef Kadlecsik.
6) Allow to filter by zone 0 in ctnetlink, do not interpret zone 0
as no filtering, from Felix Huettner.
7) Reject direction for NFT_CT_ID.
8) Use timestamp to check for set element expiration while transaction
is handled to prevent garbage collection from removing set elements
that were just added by this transaction. Packet path and netlink
dump/get path still use current time to check for expiration.
9) Restore NF_REPEAT in nfnetlink_queue, from Florian Westphal.
10) map_index needs to be percpu and per-set, not just percpu.
At this time its possible for a pipapo set to fill the all-zero part
with ones and take the 'might have bits set' as 'start-from-zero' area.
From Florian Westphal. This includes three patches:
- Change scratchpad area to a structure that provides space for a
per-set-and-cpu toggle and uses it of the percpu one.
- Add a new free helper to prepare for the next patch.
- Remove the scratch_aligned pointer and makes AVX2 implementation
use the exact same memory addresses for read/store of the matching
state.
netfilter pull request 24-02-08
* tag 'nf-24-02-08' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
netfilter: nft_set_pipapo: remove scratch_aligned pointer
netfilter: nft_set_pipapo: add helper to release pcpu scratch area
netfilter: nft_set_pipapo: store index in scratch maps
netfilter: nft_set_rbtree: skip end interval element from gc
netfilter: nfnetlink_queue: un-break NF_REPEAT
netfilter: nf_tables: use timestamp to check for set element timeout
netfilter: nft_ct: reject direction for ct id
netfilter: ctnetlink: fix filtering for zone 0
netfilter: ipset: Missing gc cancellations fixed
netfilter: nft_set_pipapo: remove static in nft_pipapo_get()
netfilter: nft_compat: restrict match/target protocol to u16
netfilter: nft_compat: reject unused compat flag
netfilter: nft_compat: narrow down revision to unsigned 8-bits
====================
Link: https://lore.kernel.org/r/20240208112834.1433-1-pablo@netfilter.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Not sure how this happened or how nothing complained, but
this variable already exists in the outer function scope
with the same value (and the SKB isn't changed either.)
Remove the extra one.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This got unused when the tracing was converted to dynamic
strings, so the define can be removed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
