- 23 Oct, 2023 11 commits
-
-
Johannes Berg authored
We can delete any that we want to remove, but we can't recreate the links as they already exist. Fixes: 170cd6a6 ("wifi: mac80211: add netdev per-link debugfs data and driver hook") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230928172905.3d0214838421.I512a0ff86f631ff42bf25ea0cb2e8e8616794a94@changeidSigned-off-by:
-
Benjamin Berg authored
If the association command fails then the authentication is still valid and it makes sense to keep it alive. Otherwise, we would currently get into an inconsistent state because mac80211 on the one hand is disconnected but on the other hand the state is not entirely cleared and a new authentication could not continue. Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Signed-off-by:
-
Gregory Greenman authored
Start supporting API version 84 for new devices. Signed-off-by:
-
Johannes Berg authored
We don't (yet) send the IGTK down to the firmware, but when we do it needs to be with the broadcast station ID, not the multicast station ID. Same for the BIGTK, which we may send already if firmware advertises it (but it doesn't yet.) Fixes: a5de7de7 ("wifi: iwlwifi: mvm: enable TX beacon protection") Signed-off-by:
-
Johannes Berg authored
We can't really know easily if a BIGTK will be used, but in case firmware supports BIGTK it also supports the very easy IGTK use (nothing to do on the host), and requires that we program both IGTK and BIGTK to be able to use the BIGTK. Thus, change the condition here to set the keys in firmware (both IGTK/BIGTK) if BIGTK is supported. Signed-off-by:
-
Avraham Stern authored
In case of MLD operation the station should be removed using the mld api. Fixes: fd940de7 ("wifi: iwlwifi: mvm: FTM responder MLO support") Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
Johannes Berg authored
We define the same bit twice, remove the less precise definition and use the better one instead. Signed-off-by:
-
Johannes Berg authored
There's a race when the device is unbound (maybe because the module is unloaded) while the opmode start hasn't finished yet. The complete(request_firmware_complete) after the opmode start was meant (and commented accordingly) to prevent this problem, but it's not sufficient when the opmode module is loaded after the firmware load already completed, which happens regularly now because firmware load doesn't require userspace, unlike module load. Fix this by using the existing opmode registration mutex to protected the start/stop flows against each other properly. Signed-off-by:
-
Johannes Berg authored
These retries aren't going to succeed if the device was deemed dead and needs to be unbound/rebound/... to be recovered; skip the retries in that case. Signed-off-by:
-
Johannes Berg authored
If iwl_pcie_gen2_apm_init() fails, we should propagate the error code up, rather than ignoring it. Signed-off-by:
-
Avraham Stern authored
The management frames protection flag is always set when the station is not yet authorized. However, it was not cleared after association even if the association did not use MFP. As a result, all public action frames are not parsed by fw (which will cause FTM to fail, for example). Update the station MFP flag after the station is authorized. Fixes: 4c8d5c8d ("wifi: iwlwifi: mvm: tell firmware about per-STA MFP enablement") Signed-off-by:
-
- 19 Oct, 2023 13 commits
-
-
Ajay Singh authored
Enabling KASAN and running some iperf tests raises some memory issues with vmm_table: BUG: KASAN: slab-out-of-bounds in wilc_wlan_handle_txq+0x6ac/0xdb4 Write of size 4 at addr c3a61540 by task wlan0-tx/95 KASAN detects that we are writing data beyond range allocated to vmm_table. There is indeed a mismatch between the size passed to allocator in wilc_wlan_init, and the range of possible indexes used later: allocation size is missing a multiplication by sizeof(u32) Fixes: 40b717bf ("wifi: wilc1000: fix DMA on stack objects") Cc: stable@vger.kernel.org Signed-off-by:
Ajay Singh <ajay.kathat@microchip.com> Signed-off-by:
Alexis Lothoré <alexis.lothore@bootlin.com> Reviewed-by:
Michael Walle <mwalle@kernel.org> Reviewed-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231017-wilc1000_tx_oops-v3-1-b2155f1f7bee@bootlin.com
-
Dmitry Antipov authored
Since there is no chip-specific code behind 'chk_switch_dmdp()', there is no need to maintain function pointer in 'struct rtl_hal_ops' and relevant common code may be simplified. Compile tested only. Signed-off-by:
Dmitry Antipov <dmantipov@yandex.ru> Acked-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Dmitry Antipov authored
Since 'fill_fake_txdesc()' is actually implemented for rtl8192cu only but never used, there is no need to maintain function pointer in 'struct rtl_hal_ops' and 'rtl92cu_fill_fake_txdesc()' may be dropped. Compile tested only. Signed-off-by:
-
Dmitry Antipov authored
Since 'pre_fill_tx_bd_desc()' is actually used for rtl8192ee only, there is no need to maintain function pointer in 'struct rtl_hal_ops', and 'rtl92ee_pre_fill_tx_bd_desc()' may be converted to static. Compile tested only. Signed-off-by:
-
Cheng-Chieh Hsieh authored
We need this register setting only for the software DCFO(digital carrier frequency offset) compensation so we move it to the proper position to prevent the incorrect setting. Signed-off-by:
Cheng-Chieh Hsieh <cj.hsieh@realtek.com> Signed-off-by:
-
Cheng-Chieh Hsieh authored
DCFO tracking compensate the CFO (carrier frequency offset) by digital hardware that provides fine CFO estimation. Although the avg_cfo which is a coarse information becomes zero, still we need DCFO tracking to compensate the residual CFO. However, the original flow skips the case when avg_cfo is zero, so we fix it to have expected performance. Signed-off-by:
-
Cheng-Chieh Hsieh authored
The register address used for CFO(carrier frequency offset) tracking is different from WiFi 7 series, so we change the way to access it. And we refine the flow of CFO tracking to compatible all WiFi 7 and 6 ICs. Signed-off-by:
-
Ping-Ke Shih authored
The register fields of BSS color map and valid bit are in the same register for existing chips, but coming WiFi 7 chips define another register to set valid bit, so add a field to chip_info to reuse the code. Signed-off-by:
-
Chung-Hsuan Hung authored
Change naming to disambiguate the functions because their names are common and not clear about the purpose. Not change logic at all. These functions are to control baseband AGC while BT coexists with WiFi. Among these functions, ctrl_btg_bt_rx is used to control AGC related settings, which is affected by BT RX, while BT shares the same path with wifi; ctrl_nbtg_bt_tx is used to control AGC settings under non-shared path condition, which is affected by BT TX. Signed-off-by:
Chung-Hsuan Hung <hsuan8331@realtek.com> Signed-off-by:
-
Chin-Yen Lee authored
Sometimes firmware may enter strange state or infinite loop due to unknown bug, and then it will lead critical function fail, such as sending H2C command or changing power mode. In these abnormal states, we add more debug information, including hardware register status, to help further investigation. Signed-off-by:
Chin-Yen Lee <timlee@realtek.com> Signed-off-by:
-
Chin-Yen Lee authored
The coming dump function for FW malfunction will add a function to dump registers to reflect status. However, if we are not debugging the mechanism, we don't print anything, so avoid reading registers by checking debug mask to reduce IO. Signed-off-by:
-
Dmitry Antipov authored
Remove set but otherwise unused 'sleep_ms', 'last_action', 'state' and 'last_slept' members of 'struct rtl_ps_ctl' (these seems to be a leftovers from some older code) and adjust 'rtl_swlps_wq_callback()' accordingly. Compile tested only. Signed-off-by:
-
Randy Dunlap authored
This is a kconfig warning in a randconfig when CONFIG_PCI is not set: WARNING: unmet direct dependencies detected for SSB_EMBEDDED Depends on [n]: SSB [=y] && SSB_DRIVER_MIPS [=y] && SSB_PCICORE_HOSTMODE [=n] Selected by [y]: - BCM47XX_SSB [=y] && BCM47XX [=y] This is caused by arch/mips/bcm47xx/Kconfig's symbol BCM47XX_SSB selecting SSB_EMBEDDED when CONFIG_PCI is not set. This warning can be prevented by altering SSB_EMBEDDED to allow for PCI=n or the former SSB_PCICORE_HOSTMODE. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by:
Michael Büsch <m@bues.ch> Cc: linux-wireless@vger.kernel.org Cc: Kalle Valo <kvalo@kernel.org> Signed-off-by:
-
- 18 Oct, 2023 16 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxJakub Kicinski authored
Saeed Mahameed says: ==================== mlx5-updates-2023-10-10 1) Adham Faris, Increase max supported channels number to 256 2) Leon Romanovsky, Allow IPsec soft/hard limits in bytes 3) Shay Drory, Replace global mlx5_intf_lock with HCA devcom component lock 4) Wei Zhang, Optimize SF creation flow During SF creation, HCA state gets changed from INVALID to IN_USE step by step. Accordingly, FW sends vhca event to driver to inform about this state change asynchronously. Each vhca event is critical because all related SW/FW operations are triggered by it. Currently there is only a single mlx5 general event handler which not only handles vhca event but many other events. This incurs huge bottleneck because all events are forced to be handled in serial manner. Moreover, all SFs share same table_lock which inevitably impacts each other when they are created in parallel. This series will solve this issue by: 1. A dedicated vhca event handler is introduced to eliminate the mutual impact with other mlx5 events. 2. Max FW threads work queues are employed in the vhca event handler to fully utilize FW capability. 3. Redesign SF active work logic to completely remove table_lock. With above optimization, SF creation time is reduced by 25%, i.e. from 80s to 60s when creating 100 SFs. Patches summary: Patch 1 - implement dedicated vhca event handler with max FW cmd threads of work queues. Patch 2 - remove table_lock by redesigning SF active work logic. * tag 'mlx5-updates-2023-10-10' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net/mlx5e: Allow IPsec soft/hard limits in bytes net/mlx5e: Increase max supported channels number to 256 net/mlx5e: Preparations for supporting larger number of channels net/mlx5e: Refactor mlx5e_rss_init() and mlx5e_rss_free() API's net/mlx5e: Refactor mlx5e_rss_set_rxfh() and mlx5e_rss_get_rxfh() net/mlx5e: Refactor rx_res_init() and rx_res_free() APIs net/mlx5e: Use PTR_ERR_OR_ZERO() to simplify code net/mlx5: Use PTR_ERR_OR_ZERO() to simplify code net/mlx5: fix config name in Kconfig parameter documentation net/mlx5: Remove unused declaration net/mlx5: Replace global mlx5_intf_lock with HCA devcom component lock net/mlx5: Refactor LAG peer device lookout bus logic to mlx5 devcom net/mlx5: Avoid false positive lockdep warning by adding lock_class_key net/mlx5: Redesign SF active work to remove table_lock net/mlx5: Parallelize vhca event handling ==================== Link: https://lore.kernel.org/r/20231014171908.290428-1-saeed@kernel.orgSigned-off-by:Jakub Kicinski <kuba@kernel.org>
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. We expect both hi.data.modename and hi.data.drivername to be NUL-terminated based on its usage with sprintf: | sprintf(hi.data.modename, "%sclk,%smodem,fclk=%d,bps=%d%s", | bc->cfg.intclk ? "int" : "ext", | bc->cfg.extmodem ? "ext" : "int", bc->cfg.fclk, bc->cfg.bps, | bc->cfg.loopback ? ",loopback" : ""); Note that this data is copied out to userspace with: | if (copy_to_user(data, &hi, sizeof(hi))) ... however, the data was also copied FROM the user here: | if (copy_from_user(&hi, data, sizeof(hi))) Considering the above, a suitable replacement is strscpy_pad() as it guarantees NUL-termination on the destination buffer while also NUL-padding (which is good+wanted behavior when copying data to userspace). Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90Signed-off-by:
Justin Stitt <justinstitt@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20231016-strncpy-drivers-net-hamradio-baycom_epp-c-v2-1-39f72a72de30@google.comSigned-off-by:
-
Jakub Kicinski authored
Jiri moved version to legacy specs in commit 0f07415e ("netlink: specs: don't allow version to be specified for genetlink"). Update the documentation. Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20231016214540.1822392-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
I recently cleaned up specs to not specify enum-as-flags when target enum is already defined as flags. YNL Python library did not convert flags, unfortunately, so this caused breakage for Stan and Willem. Note that the nlspec.py abstraction already hides the differences between flags and enums (value vs user_value), so the changes are pretty trivial. Fixes: 0629f22e ("ynl: netdev: drop unnecessary enum-as-flags") Reported-and-tested-by:
Willem de Bruijn <willemb@google.com> Reported-and-tested-by:
Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/all/ZS10NtQgd_BJZ3RU@google.com/ Link: https://lore.kernel.org/r/20231016213937.1820386-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Russell King says: ==================== net: remove last of the phylink validate methods and clean up This four patch series removes the last of the phylink MAC .validate methods which can be found in the Freescale fman driver. fman has a requirement that half duplex may not be supported in RGMII mode, which is currently handled in its .validate method. In order to keep this functionality when removing the .validate method, we need to replace that with equivalent functionality, for which I propose the optional .mac_get_caps method in the first patch. The advantage of this approach over the .validate callback is that MAC drivers only have to deal with the MAC_* capabilities, and don't need to call back into phylink functions to do the masking of the ethtool linkmodes etc - which then becomes internal to phylink. This can be seen in the fourth patch where we make a load of these methods static. ==================== Link: https://lore.kernel.org/r/ZS1Z5DDfHyjMryYu@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
Remove exports for phylink_caps_to_linkmodes(), phylink_get_capabilities(), phylink_validate_mask_caps() and phylink_generic_validate(). Also, as phylink_generic_validate() is no longer called, we can remove its implementation as well. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qsPkK-009wip-W9@rmk-PC.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
The MAC .validate() method is no longer used, so remove it from the phylink_mac_ops structure, and remove the callsite in phylink_validate_mac_and_pcs(). Signed-off-by:
-
Russell King (Oracle) authored
Convert fman to use the .mac_get_caps() method rather than the .validate() method. Signed-off-by:
Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/E1qsPkA-009wid-Kv@rmk-PC.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
Provide a new method, mac_get_caps() to get the MAC capabilities for the specified interface mode. This is for MACs which have special requirements, such as not supporting half-duplex in certain interface modes, and will replace the validate() method. Signed-off-by:
-
Jakub Kicinski authored
Recent FW interface update bumped the size of struct hwrm_func_cfg_input above 128B which is the max some devices support. Probe on Stratus (BCM957452) with FW 20.8.3.11 fails with: bnxt_en ...: Unable to reserve tx rings bnxt_en ...: 2nd rings reservation failed. bnxt_en ...: Not enough rings available. Once probe is fixed other errors pop up: bnxt_en ...: Failed to set async event completion ring. This is because __hwrm_send() rejects requests larger than bp->hwrm_max_ext_req_len with -E2BIG. Since the driver doesn't actually access any of the new fields, yet, trim the length. It should be safe. Similar workaround exists for backing_store_cfg_input. Although that one mins() to a constant of 256, not 128 we'll effectively use here. Michael explains: "the backing store cfg command is supported by relatively newer firmware that will accept 256 bytes at least." To make debugging easier in the future add a warning for oversized requests. Fixes: 754fbf60 ("bnxt_en: Update firmware interface to 1.10.2.171") Reviewed-by:
Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231016171640.1481493-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Johannes Nixdorf says: ==================== bridge: Add a limit on learned FDB entries Introduce a limit on the amount of learned FDB entries on a bridge, configured by netlink with a build time default on bridge creation in the kernel config. For backwards compatibility the kernel config default is disabling the limit (0). Without any limit a malicious actor may OOM a kernel by spamming packets with changing MAC addresses on their bridge port, so allow the bridge creator to limit the number of entries. Currently the manual entries are identified by the bridge flags BR_FDB_LOCAL or BR_FDB_ADDED_BY_USER, atomically bundled under the new flag BR_FDB_DYNAMIC_LEARNED. This means the limit also applies to entries created with BR_FDB_ADDED_BY_EXT_LEARN but none of BR_FDB_LOCAL or BR_FDB_ADDED_BY_USER, e.g. ones added by SWITCHDEV_FDB_ADD_TO_BRIDGE. Link to the corresponding iproute2 changes: https://lore.kernel.org/r/20230919-fdb_limit-v4-1-b4d2dc4df30f@avm.de v4: https://lore.kernel.org/r/20230919-fdb_limit-v4-0-39f0293807b8@avm.de/ v3: https://lore.kernel.org/r/20230905-fdb_limit-v3-0-7597cd500a82@avm.de/ v2: https://lore.kernel.org/netdev/20230619071444.14625-1-jnixdorf-oss@avm.de/ v1: https://lore.kernel.org/netdev/20230515085046.4457-1-jnixdorf-oss@avm.de/ ==================== Link: https://lore.kernel.org/r/20231016-fdb_limit-v5-0-32cddff87758@avm.deSigned-off-by:
-
Johannes Nixdorf authored
Add a suite covering the fdb_n_learned and fdb_max_learned bridge features, touching all special cases in accounting at least once. Acked-by:
Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by:
Johannes Nixdorf <jnixdorf-oss@avm.de> Link: https://lore.kernel.org/r/20231016-fdb_limit-v5-5-32cddff87758@avm.deSigned-off-by:
-
Johannes Nixdorf authored
Set any new attributes added to br_policy to be parsed strictly, to prevent userspace from passing garbage. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20231016-fdb_limit-v5-4-32cddff87758@avm.deSigned-off-by:
-
Johannes Nixdorf authored
The previous patch added accounting and a limit for the number of dynamically learned FDB entries per bridge. However it did not provide means to actually configure those bounds or read back the count. This patch does that. Two new netlink attributes are added for the accounting and limit of dynamically learned FDB entries: - IFLA_BR_FDB_N_LEARNED (RO) for the number of entries accounted for a single bridge. - IFLA_BR_FDB_MAX_LEARNED (RW) for the configured limit of entries for the bridge. The new attributes are used like this: # ip link add name br up type bridge fdb_max_learned 256 # ip link add name v1 up master br type veth peer v2 # ip link set up dev v2 # mausezahn -a rand -c 1024 v2 0.01 seconds (90877 packets per second # bridge fdb | grep -v permanent | wc -l 256 # ip -d link show dev br 13: br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 [...] [...] fdb_n_learned 256 fdb_max_learned 256 Signed-off-by: -
Johannes Nixdorf authored
A malicious actor behind one bridge port may spam the kernel with packets with a random source MAC address, each of which will create an FDB entry, each of which is a dynamic allocation in the kernel. There are roughly 2^48 different MAC addresses, further limited by the rhashtable they are stored in to 2^31. Each entry is of the type struct net_bridge_fdb_entry, which is currently 128 bytes big. This means the maximum amount of memory allocated for FDB entries is 2^31 * 128B = 256GiB, which is too much for most computers. Mitigate this by maintaining a per bridge count of those automatically generated entries in fdb_n_learned, and a limit in fdb_max_learned. If the limit is hit new entries are not learned anymore. For backwards compatibility the default setting of 0 disables the limit. User-added entries by netlink or from bridge or bridge port addresses are never blocked and do not count towards that limit. Introduce a new fdb entry flag BR_FDB_DYNAMIC_LEARNED to keep track of whether an FDB entry is included in the count. The flag is enabled for dynamically learned entries, and disabled for all other entries. This should be equivalent to BR_FDB_ADDED_BY_USER and BR_FDB_LOCAL being unset, but contrary to the two flags it can be toggled atomically. Atomicity is required here, as there are multiple callers that modify the flags, but are not under a common lock (br_fdb_update is the exception for br->hash_lock, br_fdb_external_learn_add for RTNL). Reviewed-by:
-
Johannes Nixdorf authored
In preparation of the following fdb limit for dynamically learned entries, allow fdb_create to detect that the entry was added by the user. This way it can skip applying the limit in this case. Reviewed-by:
-
