Felix Fietkau [Wed, 9 Oct 2024 08:25:52 +0000 (10:25 +0200)]
wifi: mac80211: filter on monitor interfaces based on configured channel
When a monitor interface has an assigned channel (only happens with the
NO_VIRTUAL_MONITOR feature), only pass packets received on that channel.
This is useful for monitoring on multiple channels at the same time using
multiple monitor interfaces.
Felix Fietkau [Wed, 9 Oct 2024 08:25:50 +0000 (10:25 +0200)]
wifi: mac80211: add support for the monitor SKIP_TX flag
Do not pass locally sent packets to monitor interfaces with this flag set.
Skip processing tx packets on the status call entirely if no monitor
interfaces without this flag are present.
Felix Fietkau [Wed, 9 Oct 2024 08:25:48 +0000 (10:25 +0200)]
wifi: mac80211: add flag to opt out of virtual monitor support
This is useful for multi-radio devices that are capable of monitoring on
multiple channels simultanenously. When this flag is set, each monitor
interface is passed to the driver individually and can have a configured
channel.
The vif mac address for non-active monitor interfaces is cleared, in order
to allow the driver to tell them apart from active ones.
Felix Fietkau [Wed, 9 Oct 2024 08:25:45 +0000 (10:25 +0200)]
wifi: cfg80211: report per wiphy radio antenna mask
With multi-radio devices, each radio typically gets a fixed set of antennas.
In order to be able to disable specific antennas for some radios, user space
needs to know which antenna mask bits are assigned to which radio.
Felix Fietkau [Wed, 9 Oct 2024 08:25:42 +0000 (10:25 +0200)]
wifi: cfg80211: add option for vif allowed radios
This allows users to prevent a vif from affecting radios other than the
configured ones. This can be useful in cases where e.g. an AP is running
on one radio, and triggering a scan on another radio should not disturb it.
Changing the allowed radios list for a vif is supported, but only while
it is down.
While it is possible to achieve the same by always explicitly specifying
a frequency list for scan requests and ensuring that the wrong channel/band
is never accidentally set on an unrelated interface, this change makes
multi-radio wiphy setups a lot easier to deal with for CLI users.
By itself, this patch only enforces the radio mask for scanning requests
and remain-on-channel. Follow-up changes build on this to limit configured
frequencies.
Benjamin Berg [Tue, 8 Oct 2024 04:25:25 +0000 (07:25 +0300)]
wifi: iwlwifi: do not warn about a flush with an empty TX queue
When resuming it can happen that the TX queue is flushed even though it
is entirely empty. This is completely fine and should not be causing an
error level log message.
Miri Korenblit [Tue, 8 Oct 2024 04:25:23 +0000 (07:25 +0300)]
wifi: iwlwifi: mvm: remove unneeded check
When checking if extra LTF should be disabled, we don't need to check the
the HW revision.
sband_eht_cap will be NULL if eht_capa::has_eht is false,
and that will be the case for the HWs that don't support EHT.
Benjamin Berg [Tue, 8 Oct 2024 04:25:18 +0000 (07:25 +0300)]
wifi: iwlwifi: mvm: log information about HW restart completion
It can happen that more errors occur after a firmware assertion. In that
case, having another log message after the restart has completed makes
it easier to see which errors where still part of the restart flow.
Johannes Berg [Mon, 7 Oct 2024 12:00:57 +0000 (15:00 +0300)]
wifi: mac80211: chan: calculate min_def also for client mode
In order to deal with (temporary) bandwidth reductions to/from
the AP such as the upcoming RX OMI changes, modify the min_def
calculation to also not take the chanreq width into account in
client mode. This normally changes nothing as the AP bandwidth
will be the same as the channel request's width. In the RX OMI
changes, however, the code will reduce the bandwidth for only
the AP STA, since the OMI is only to that, and TDLS STAs are
unaffected. Using the min_def for this case simplifies RX OMI
a lot.
Johannes Berg [Mon, 7 Oct 2024 12:00:54 +0000 (15:00 +0300)]
wifi: mac80211: call rate_control_rate_update() for link STA
In order to update the right link information, call the update
rate_control_rate_update() with the right link_sta, and then
pass that through to the driver's sta_rc_update() method. The
software rate control still doesn't support it, but that'll be
skipped by not having a rate control ref.
Since it now operates on a link sta, rename the driver method.
Johannes Berg [Mon, 7 Oct 2024 12:00:53 +0000 (15:00 +0300)]
wifi: mac80211: allow rate_control_rate_init() for links
Andrei previously fixed an issue in the client where the NSS
for links other than the primary/assoc/deflink isn't set. The
same issue appears to exist on the AP side, because there's
only a call to rate_control_rate_init() for the deflink, and
not any other links.
Rework the code a bit to do rate_control_rate_init() for links,
even if it really doesn't work with software rate control yet,
it does other things as well.
Also add rate_control_rate_init_all_links() to actually do it
properly when moving to ASSOC state in cfg80211.
Change the explicit call to ieee80211_sta_init_nss() to instead
be rate_control_rate_init() now in the client code, but also
add a call to rate_control_rate_init() when a link is added in
AP mode and the STA is already associated.
This should fix the NSS initialization issue, and perhaps pave
the way for actual software rate scaling a bit, in case anyone
cares in the future, but that of course needs a lot more than
just the init call.
We still need to fix the rate control _update_ as well, and the
sta_rc_update() driver method especially, but that will be in a
different patch.
ieee80211_find_80211h_pwr_constr and ieee80211_find_cisco_dtpc don't
need the pointer to struct ieee80211_sub_if_data *sdata. Remove it and
it'll be one step closer to handle the power constraints per-link.
wifi: mac80211: make bss_param_ch_cnt available for the low level driver
Drivers may need to track this. Make it available for them, and maintain
the value when beacons are received.
When link X receives a beacon, iterate the RNR elements and update all
the links with their respective data.
Track the link id that updated the data so that each link can know
whether the update came from its own beacon or from another link.
In case, the update came from the link's own beacon, always update the
updater link id.
The purpose is to let the low level driver know if a link is losing its
beacons. If link X is losing its beacons, it can still track the
bss_param_ch_cnt and know where the update came from.
Johannes Berg [Mon, 7 Oct 2024 12:00:46 +0000 (15:00 +0300)]
wifi: cfg80211: disallow SMPS in AP mode
In practice, userspace hasn't been able to set this for many
years, and mac80211 has already rejected it (which is now no
longer needed), so reject SMPS mode (other than "OFF" to be
a bit more compatible) in AP mode. Also remove the parameter
from the AP settings struct.
Kalle Valo [Thu, 17 Oct 2024 17:21:22 +0000 (20:21 +0300)]
Merge tag 'rtw-next-2024-10-10' of https://github.com/pkshih/rtw
rtw-next patches for v6.13
No big change at this point. Regular development and fixes are listed:
rtl8xxxu:
- correct beaconing for the case of STA + AP
rtw88:
- consolidate parser of RX descriptor as preparation to support coming
chips
rtw89:
- update BT-coexistence to improve user experience for RTL8852BE and
RTL8852BE-VT
- correct RTL8922AE RF calibration timeout time and print out firmware
log
- set proper PCI EQ value for RTL8852CE and RTL8922AE
- adjust to support MLO continuously
cw1200_queue_requeue_all() has been unused since it was added in 2013 by commit a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets")
wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()
Replace one-element array with a flexible-array member in `struct
mwifiex_ie_types_wildcard_ssid_params` to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):
[ 356.775250] ------------[ cut here ]------------
[ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)
[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]
The "(size 6)" above is exactly the length of the SSID of the network
this device was connected to. The source of the warning looks like:
There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this
struct, but it already didn't account for the size of the one-element
array, so it doesn't need to be changed.
Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241007222301.24154-1-alpernebiyasak@gmail.com
Marek Vasut [Thu, 3 Oct 2024 13:24:17 +0000 (15:24 +0200)]
wifi: wilc1000: Set MAC after operation mode
It seems it is necessary to set WILC MAC address after operation mode,
otherwise the MAC address of the WILC MAC is reset back to what is in
nvmem. This causes a failure to associate with AP after the WILC MAC
address was overridden by userspace.
AP still indicates SA with original MAC address from nvmem without this patch:
"
nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=60:01:23:45:67:89 bssid=ff:ff:ff:ff:ff:ff ...
^^^^^^^^^^^^^^^^^
"
Fixes: 83d9b54ee5d4 ("wifi: wilc1000: read MAC address from fuse at probe") Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241003132504.52233-1-marex@denx.de
Remove set but otherwise unused 'adhoc_is_link_sensed' and
'assoc_resp_ht_param' members of 'struct mwifiex_private' and
simplify related code in 'mwifiex_ret_802_11_associate()'.
Compile tested only.
Ajay Singh [Fri, 4 Oct 2024 11:44:16 +0000 (13:44 +0200)]
wifi: wilc1000: Add WILC3000 support
Add support for the WILC3000 chip. The chip is similar to WILC1000,
except that the register layout is slightly different and it does
not support WPA3/SAE.
Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com> Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Tested-on: WILC1000SD 07 SDIO WILC_WIFI_FW_REL_16_1_2
Tested-on: WILC1000SD 07 SPI WILC_WIFI_FW_REL_16_1_2
Tested-on: WILC3000 A SDIO WILC_WIFI_FW_REL_16_1_1
Tested-on: WILC3000 A SPI WILC_WIFI_FW_REL_16_1_1 Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241004114551.40236-7-marex@denx.de
Marek Vasut [Fri, 4 Oct 2024 11:44:15 +0000 (13:44 +0200)]
wifi: wilc1000: Register wiphy after reading out chipid
Register wiphy after reading out chipid, so the chipid can be
used to determine chip features and not advertise WPA3/SAE
support to userspace on WILC3000. Note that wilc_netdev_cleanup()
will deregister the wiphy in fail path.
Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Tested-on: WILC1000SD 07 SDIO WILC_WIFI_FW_REL_16_1_2
Tested-on: WILC3000 A SDIO WILC_WIFI_FW_REL_16_1_1 Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241004114551.40236-6-marex@denx.de
Marek Vasut [Fri, 4 Oct 2024 11:44:13 +0000 (13:44 +0200)]
wifi: wilc1000: Fill in missing error handling
Add error handling to chip_wakeup() and propagate the errors throughout
the entire driver. Add error handling to acquire_bus()/release_bus() and
host_sleep_notify()/host_wakeup_notify() functions as a result as well.
Fill the error handling to all call sites.
Marek Vasut [Fri, 4 Oct 2024 11:44:12 +0000 (13:44 +0200)]
wifi: wilc1000: Fold chip_allow_sleep()/chip_wakeup() into wlan.c
Neither chip_allow_sleep()/chip_wakeup() is used outside of wlan.c .
Make both functions static and remove both the exported symbol and
entries from wlan.h .
Make chip_allow_sleep() return error code in preparation for the
follow up patches.
Move acquire_bus() and release_bus() to avoid forward declaration
of chip_allow_sleep()/chip_wakeup().
Marek Vasut [Fri, 4 Oct 2024 11:44:11 +0000 (13:44 +0200)]
wifi: wilc1000: Clean up usage of wilc_get_chipid()
Reduce the use of wilc_get_chipid(), use cached chip ID wherever
possible. Remove duplicated partial chip ID read implementations
from the driver. Update wilc_get_chipid() to always read the chip
ID out of the hardware and update the cached chip ID, and make it
return a proper return value instead of a chipid. Call wilc_get_chipid()
early to make the cached chip ID available to various sites using
is_wilc1000() to access the cached chip ID.
Document compatible string for the WILC3000 chip. The chip is similar
to WILC1000, except that the register layout is slightly different and
it does not support WPA3/SAE.
Marek Vasut [Thu, 26 Sep 2024 19:50:55 +0000 (21:50 +0200)]
wifi: wilc1000: Keep slot powered on during suspend/resume
The WILC3000 can suspend and enter low power state. According to local
measurements, the WILC3000 consumes the same amount of power if the slot
is powered up and WILC3000 is suspended, and if the WILC3000 is powered
off. Use the former option, keep the WILC3000 powered up as that allows
for things like WoWlan to work.
Note that this is tested on WILC3000 only, not on WILC1000 .
Yan Zhen [Fri, 20 Sep 2024 02:59:17 +0000 (10:59 +0800)]
wifi: rt2x00: convert comma to semicolon
To ensure code clarity and prevent potential errors, it's advisable
to employ the ';' as a statement separator, except when ',' are
intentionally used for specific purposes.
Chin-Yen Lee [Fri, 4 Oct 2024 06:54:08 +0000 (14:54 +0800)]
wifi: rtw89: wow: do not configure CPU IO to receive packets for old firmware
The older firmware of 8852A and 8852B can't receive packets via
CPU IO function and will lead to WoWLAN fail if calling it.
So use firmware feature to distinguish.
Ching-Te Ku [Thu, 3 Oct 2024 10:51:40 +0000 (18:51 +0800)]
wifi: rtw89: coex: Add function to reorder Wi-Fi firmware report index
To parsing firmware report correctly, driver need to re-order the report
index to match with different chips and different Wi-Fi firmware version.
Use wrong index to parse the report will lead the coexistence run into
wrong mechanism.
Some Bluetooth device will make up connection as PAN link, though the
connection is idle, it will still report the PAN link is active. The
coexistence mechanism will enable TDMA to protect the PAN, it makes
Wi-Fi throughput degrade at least 50%. But the link is idle, don't
need so much bandwidth. Add TDMA case to let Wi-Fi can do traffic 80%
bandwidth.
Ching-Te Ku [Thu, 3 Oct 2024 10:51:38 +0000 (18:51 +0800)]
wifi: rtw89: coex: Reorder Bluetooth info related logic
Reorder Bluetooth firmware related event index, it should be the same
with Wi-Fi firmware definition. To fix coexistence can not recognize
Bluetooth PAN(Personal area network) profile correctly, modified the
related logic.
Ching-Te Ku [Thu, 3 Oct 2024 10:51:37 +0000 (18:51 +0800)]
wifi: rtw89: coex: Update priority setting for Wi-Fi is scanning
Update coexistence priority setting for Wi-Fi scanning channel, the new
setting will allow Wi-Fi do RX while Bluetooth audio is not busy. Forced
to set new TDMA policy while RF calibration request come, to make sure
the calibration can do well, and switch to normal setting while the
calibration is done. Remove the code that no longer use.
Johannes Berg [Wed, 9 Oct 2024 06:59:14 +0000 (08:59 +0200)]
Merge net-next/main to resolve conflicts
The wireless-next tree was based on something older, and there
are now conflicts between -rc2 and work here. Merge net-next,
which has enough of -rc2 for the conflicts to happen, resolving
them in the process.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Tarun Alle [Mon, 7 Oct 2024 06:39:43 +0000 (12:09 +0530)]
net: phy: microchip_t1: SQI support for LAN887x
Add support for measuring Signal Quality Index for LAN887x T1 PHY.
Signal Quality Index (SQI) is measure of Link Channel Quality from
0 to 7, with 7 as the best. By default, a link loss event shall
indicate an SQI of 0.
====================
net: phy: marvell-88q2xxx: Enable auto negotiation for mv88q2110
This series enables auto negotiation for the mv88q2110 device.
Previously this feature have been disabled for mv88q2110, while enabled
for other devices supported by this driver.
The initial driver implementation states this is due to the
configuration sequence provided by the vendor did not work. By comparing
the initialization sequence of other devices this driver supports and
the out-of-tree PHY driver for mv88q2110 found in the Renesas BSP [1]
I was able to figure out a working configuration.
As I have no access to the datasheets of either of these devices it
would be super if someone who has could sanity check the initialization
sequence.
With this series I'm able to auto negotiate both 1000Mbps and 100Mbps
links without issue.
# ethtool eth0
Settings for eth0:
Supported ports: [ ]
Supported link modes: 100baseT1/Full
1000baseT1/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 100baseT1/Full
1000baseT1/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 100baseT1/Full
1000baseT1/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred master
master-slave status: slave
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Link detected: yes
SQI: 15/15
And the performance is good too. Without this change I was not able to
manually configure a 1000Mbps link, only 100Mbps ones. So this gives a
huge performance boost for my use-case.
Patch 1/3 and 2/3 are preparation patches that align and move functions
around as the mv88q2110 code paths can now reuses much of what is done
for mv88q2220. While patch 3/3 adds the new initialization sequence and
removes the auto negotiation limit for mv88q2110.
net: phy: marvell-88q2xxx: Enable auto negotiation for mv88q2110
The initial marvell-88q2xxx driver only supported the Marvell 88Q2110
PHY without auto negotiation support. The reason documented states that
the provided initialization sequence did not to work. Now a method to
enable auto negotiation have been found by comparing the initialization
of other supported devices and an out-of-tree PHY driver.
Perform the minimal needed initialization of the PHY to get auto
negotiation working and remove the limitation that disables the auto
negotiation feature for the mv88q2110 device.
With this change a 1000Mbps full duplex link is able to be negotiated
between two mv88q2110 and the link works perfectly. The other side also
reflects the manually configure settings of the master device.
# ethtool eth0
Settings for eth0:
Supported ports: [ ]
Supported link modes: 100baseT1/Full
1000baseT1/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 100baseT1/Full
1000baseT1/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 100baseT1/Full
1000baseT1/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred master
master-slave status: slave
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Link detected: yes
SQI: 15/15
Before this change I was not able to manually configure 1000Mbps link,
only a 100Mpps link so this change providers an improvement in
performance for this device.
net: phy: marvell-88q2xxx: Make register writer function generic
In preparation to adding auto negotiation support to mv88q2110 move and
rename the helper function used to write an array of register values to
the PHY.
Just as for mv88q2220 devices this helper will be needed to for the
initial configuration of the mv88q2110 to support auto negotiation.
The function is moved verbatim, there is no change in behavior.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Dimitri Fedrau <dima.fedrau@gmail.com> Tested-by: Stefan Eichenberger <eichest@gmail.com> Link: https://patch.msgid.link/20241005112412.544360-3-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: marvell-88q2xxx: Align soft reset for mv88q2110 and mv88q2220
The soft reset implementations for mv88q2110 and mv88q2220 differ as the
later need to consider that auto negation is supported on mv88q2220
devices. In preparation of enabling auto negotiation on mv88q2110 merge
the two rest functions into a device generic one.
The mv88q2220 behavior is kept as is but extended to wait for the reset
bit to be clears before continuing, as was done previously on mv88q2220.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Dimitri Fedrau <dima.fedrau@gmail.com> Tested-by: Stefan Eichenberger <eichest@gmail.com> Link: https://patch.msgid.link/20241005112412.544360-2-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Andrew Kreimer [Sun, 6 Oct 2024 13:08:29 +0000 (16:08 +0300)]
fsl/fman: Fix a typo
Fix a typo in comments: bellow -> below.
Reported-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Kreimer <algonell@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241006130829.13967-1-algonell@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Daniel Golle [Fri, 4 Oct 2024 16:18:16 +0000 (17:18 +0100)]
net: phy: aquantia: allow forcing order of MDI pairs
Despite supporting Auto MDI-X, it looks like Aquantia only supports
swapping pair (1,2) with pair (3,6) like it used to be for MDI-X on
100MBit/s networks.
When all 4 pairs are in use (for 1000MBit/s or faster) the link does not
come up with pair order is not configured correctly, either using
MDI_CFG pin or using the "PMA Receive Reserved Vendor Provisioning 1"
register.
Normally, the order of MDI pairs being either ABCD or DCBA is configured
by pulling the MDI_CFG pin.
However, some hardware designs require overriding the value configured
by that bootstrap pin. The PHY allows doing that by setting a bit in
"PMA Receive Reserved Vendor Provisioning 1" register which allows
ignoring the state of the MDI_CFG pin and another bit configuring
whether the order of MDI pairs should be normal (ABCD) or reverse
(DCBA). Pair polarity is not affected and remains identical in both
settings.
Introduce property "marvell,mdi-cfg-order" which allows forcing either
normal or reverse order of the MDI pairs from DT.
If the property isn't present, the behavior is unchanged and MDI pair
order configuration is untouched (ie. either the result of MDI_CFG pin
pull-up/pull-down, or pair order override already configured by the
bootloader before Linux is started).
Forcing normal pair order is required on the Adtran SDG-8733A Wi-Fi 7
residential gateway.
Daniel Golle [Fri, 4 Oct 2024 16:18:05 +0000 (17:18 +0100)]
dt-bindings: net: marvell,aquantia: add property to override MDI_CFG
Usually the MDI pair order reversal configuration is defined by
bootstrap pin MDI_CFG. Some designs, however, require overriding the MDI
pair order and force either normal or reverse order.
Add property 'marvell,mdi-cfg-order' to allow forcing either normal or
reverse order of the MDI pairs.
Petr Machata [Mon, 7 Oct 2024 16:26:09 +0000 (18:26 +0200)]
selftests: mlxsw: sch_red_core: Lower TBF rate
The RED test uses a pair of TBF shapers. The first to get predictably-sized
stream of traffic, and second to get a 100% saturated chokepoint. To this
chokepoint it injects individual packets. Because the chokepoint is
saturated, these additional packets go straight to the backlog. This allows
the test to check RED behavior across various queue sizes.
The shapers are rated at 1Gbps, for historical reasons (before mlxsw
supported TBF offload, the test used port speed to create the chokepoints).
Machines with a low-power CPU may have trouble consistently generating
1Gbps of traffic, and the test then spuriously fails.
Instead, drop the rate to 200Mbps (Spectrum has a guaranteed shaper rate
granularity of 200Mbps, so anything lower is not guaranteed to work well).
Because that means fewer packets will be mirrored in the ECN-mark test,
adjust the passing condition accordingly.
Petr Machata [Mon, 7 Oct 2024 16:26:08 +0000 (18:26 +0200)]
selftests: mlxsw: sch_red_core: Send more packets for drop tests
This test works by injecting into a port with a maxed-out queue a couple
packets and checks if a corresponding number of packets were dropped. This
has worked well on Spectrum<4, but on Spectrum-4 it has been noisy. This
is in line with the observation that on Spectrum-4, queue size tends to
fluctuate more. A handful of packets could then still be accepted to the
queue even though it was nominally full just recently.
In order to accommodate this behavior, send many more packets. The buffer
can fit N extra packets, but not N% packets. This therefore allows us to
set wider absolute margins, while actually narrowing them relatively.
Petr Machata [Mon, 7 Oct 2024 16:26:07 +0000 (18:26 +0200)]
selftests: mlxsw: sch_red_core: Sleep before querying queue depth
The qdisc stats are taken from the port's periodic HW stats, which are
updated once a second. We try to accommodate the latency by using busywait
in build_backlog().
The issue in that seems to be that when do_mark_test() builds the backlog,
it makes the decision whether to send more packets based on the first
instance of the queue depth stat exceeding the current value, when in fact
more traffic is on the way and the queue depth would increase further. This
leads to failures in TC 1 of mark-mirror test, where we see the following
failure:
Backlog fluctuates on Spectrum-4 much more than on <4. In practice we can
sample queue depth values going from about -12% to about +7% of the
configured RED limit. The test which checks the queue size has a limit of
+-10%, and as a result often fails. We attempted to fix the issue by
busywaiting for several seconds hoping to get within the bounds, but that
still proved to be too noisy (or the wait time would be impractically
long). Unfortunately we have to bump the value tolerance from 10% to 15%,
which in this patch do.
Backlog fluctuates on Spectrum-4 much more than on <4. Increasing the
desired backlog seems to help, as the constant fluctuations do not overlap
into the territory where packets are marked.
Jason Xing [Sat, 5 Oct 2024 22:26:09 +0000 (07:26 +0900)]
net-timestamp: namespacify the sysctl_tstamp_allow_data
Let it be tuned in per netns by admins.
Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20241005222609.94980-1-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
There's no need for "future" extensions in an internal
struct, and we don't need a u32 for flags, use just a
u8. Also remove the unused IW_DESCR_FLAG_WAIT flag.
Johannes Berg [Mon, 7 Oct 2024 19:35:25 +0000 (21:35 +0200)]
wifi: remove iw_public_data from struct net_device
Given the previous patches, we no longer need the
struct iw_public_data etc., it's only used by the
old Intel drivers (and ps3_gelic creates it but
then doesn't use it). Remove all of that, including
the pointer in struct net_device.
Johannes Berg [Mon, 7 Oct 2024 18:26:56 +0000 (20:26 +0200)]
staging: don't recommend using lib80211
No longer document drivers should switch to lib80211,
they really should never have done that. While at it,
also remove the recommendation to use cfg80211, if it
switches to mac80211 then it implicitly uses cfg80211
but doesn't need to do anything about that, normally.
Johannes Berg [Mon, 7 Oct 2024 18:26:55 +0000 (20:26 +0200)]
wifi: ipw2x00/lib80211: move remaining lib80211 into libipw
There's already much code in libipw that used to be shared
with more drivers, but now with the prior cleanups, those old
Intel ipw2x00 drivers are also the only ones using whatever is
now left of lib80211. Move lib80211 entirely into libipw.
Johannes Berg [Mon, 7 Oct 2024 18:26:54 +0000 (20:26 +0200)]
staging: rtl8192e: delete the driver
This driver is using lib80211 and any driver that plans to ever
leave staging should never have done that, so remove the driver
to enable cleaning up lib80211 into libipw inside the old Intel
drivers.
Dmitry Kandybka [Thu, 3 Oct 2024 09:59:12 +0000 (12:59 +0300)]
wifi: nl80211: remove redundant null pointer check in coalescing
In 'cfg80211_free_coalesce', '&coalesce->rules[i]' is a pointer
to VLA member of 'struct cfg80211_coalesce' and should never be NULL,
so redundant check may be dropped.
I think this is correct, but I haven't tested it seriously.
Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
projects / thirdparty / kernel / linux.git / log
