- 12 Jun, 2024 31 commits
-
-
Shaul Triebitz authored
This is the first step towards removing the P2P Device MAC. Use ROC (which uses the AUX MAC) for P2P Device discoveribility and action frames. Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240605140556.8c90e457abbd.I8e340759ecb299e05b1809f3d8060429c6cbbd01@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If non-BSS and remain-on-channel (ROC) blocking were to occur simultaneously, they'd step on each other's toes, unblocking when not yet supported. Disentangle these bits, and ROC doesn't need to use the non_bss_link() function then. Fixes: a1efeb82 ("wifi: iwlwifi: mvm: Block EMLSR when a p2p/softAP vif is active") Signed-off-by:
-
Miri Korenblit authored
Stop supporting all FWs older than the max API version. These FW versions were supported since v6.5. Signed-off-by:
-
Miri Korenblit authored
When EMLSR gets unblocked, the current code checks if the last exit was due to an EXIT reason (as opposed to a BLOCKING one), and if so, it does nothing, as in this case a MLO scan was scheduled to run in 30 seconds. But the code doesn't consider the time that passed from the last exit, so if immediately after the exit a blocker occurred (e.g. non-BSS interface), and lasts for more than 30 seconds, then the MLO scan and the following link selection will decide not to enter EMLSR, and when the unblocking event finally happens, the reason is still set to the EXIT one, so it will do nothing, and we will not have the chance to re-enable EMLSR. Fix this by checking also the time that has passed since the last exit, only if it is less than 30 seconds, we can count on the scheduled MLO scan. Note that clearing the reason itself can't be done since it is needed for the EMLSR prevention mechanism. Fixes: 2f33561e ("wifi: iwlwifi: mvm: trigger link selection after exiting EMLSR") Signed-off-by:
-
Yedidya Benshimol authored
This was needed when we had multiple types of transports. Now we only have pcie, so there is no need for this ops. Cleanup the code such as the different trans APIs will call the pcie function directly, instead of calling the callback, and remove struct iwl_trans_ops. Signed-off-by:
Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by:
-
Johannes Berg authored
The TX queue code was mostly moved out to support an internal transport that we were never going to publish, but we're no longer using that. Since we're also going to be dissolving the virtual transport layer entirely, integrate the TX queue code into the PCIe layer. This also has a small kernel of already removing the virtual transport function layer, since iwl_trans_send_cmd() calls iwl_trans_pcie_send_hcmd() directly now, even if that still calls the transport send_cmd method for now, we'll clean it up later. Also, not everything is renamed yet. Signed-off-by:
-
Johannes Berg authored
This needs to include dbg-tlv.h since it uses the value of IWL_FW_INI_ALLOCATION_NUM from that file. Signed-off-by:
-
Johannes Berg authored
This really isn't correct to be in the opmode, do the clamping (and power-of-2 fixup that may be necessary due to this, or even otherwise) in the queue code. Also move down the retrying of the allocation, it should be after all the size fixups, but also it just makes sense, and avoids retrying same-size allocations in the case of the BZ-family A-step workaround. Signed-off-by:
-
Johannes Berg authored
When entering D3 we want to configure skip over DTIM, but it can't use the deflink configuration, that will not even exist. Adjust the code to handle multiple links by taking the min skip, even if we should only have a single active link at this point. Signed-off-by:
-
Miri Korenblit authored
Stop supporting older FWs. Signed-off-by:
-
Miri Korenblit authored
These entries are not used, remove them. Signed-off-by:
-
Emmanuel Grumbach authored
If a user uses iw to connect to a network and we don't have any information about the existing networks, cfg80211 will trigger a scan internally even if the user didn't ask for a scan. This scan is implemented by cfg80211_conn_scan(). This function called rdev_scan() directly without honoring the WIPHY_FLAG_SPLIT_SCAN_6GHZ flag. Use cfg80211_scan instead, this will split the scan if the low level driver asked to. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by:
-
Johannes Berg authored
There's no need to have the always-zero ret variable in the function scope, move it into the inner scope only. Signed-off-by:
-
Johannes Berg authored
When e.g. wpa_supplicant sets only the MLD "sta" authorized state, the code actually applies that change, but then returns an error to userspace anyway because there were no changes to the link station, and no link ID was given. However, it's not incorrect to not have a link ID when wanting to change only the MLD peer ("sta") state, so the code shouldn't require it. To fix this, separate the "new_link" argument out into a new three-state enum, because if modify is called on a link STA only, it should return an error if no link is given or if it doesn't exist. For modify on the MLD "sta", not having a link ID is OK, but if there is one it should be validated. This seems to not have mattered much as wpa_supplicant just prints a message and continues, and the authorized state was already set before this error return. However, in the later code powersave recalculation etc. will be skipped, so that it may result in never allowing powersave on MLO connections. Signed-off-by: -
Avraham Stern authored
Setting a channel with 320 MHz channel width over hwsim results in an array-index-out-of-bounds error. Fix it by adding 320 MHz to hwsim supported channel widths. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
Avraham Stern authored
In NDP ranging, the number of NDP exchanges is not negotiated and thus is not limited by the protocol. Remove the limit on FTMs per burst for trigger based and non trigger based ranging. Signed-off-by:
-
Benjamin Berg authored
On 6 GHz (and also 5 GHz to some degree), only a specific set of center frequencies should be used depending on the channel bandwidth. Verify this is the case on 6 GHz. For 5 GHz, we are more accepting as there are APs that got it wrong historically. Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
Add a regulatory flag to allow VLP AP operation even on channels otherwise marked NO_IR, which may be possible in some regulatory domains/countries. Note that this requires checking also when the beacon is changed, since that may change the regulatory power type. Reviewed-by:
-
Johannes Berg authored
There are two functions exported now, with different settings, refactor to just export a single function that take a struct with different settings. This will make it easier to add more parameters. Reviewed-by:
-
Johannes Berg authored
Add cfg80211_get_6ghz_power_type() to parse the 6 GHz power type from a given set of elements, which is now only inside cfg80211_6ghz_power_type_valid(). Reviewed-by:
-
Johannes Berg authored
To later introduce an override for VLP APs being allowed despite NO-IR flags, which is somewhat similar in construction to being allowed to monitor on disabled channels, refactor the code that checks channel flags to have not a 'monitor' argument but a set of 'permitting' flags that permit the operation without checking for 'prohibited' flags. Reviewed-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Johannes Berg authored
This really shouldn't have been in ieee80211.h, since it doesn't directly represent the spec. Move it to cfg80211 rather than mac80211 since upcoming changes will use it there. Reviewed-by:
-
Johannes Berg authored
This has never been used, and it's really not directly representing the spec, so shouldn't have been here in the first place. Remove it. Reviewed-by:
-
Johannes Berg authored
Use BIT(x) instead of 1<<x, in part because it's mostly missing spaces anyway, in part because it reads nicer. Reviewed-by:
-
Johannes Berg authored
It may be possible to monitor on disabled channels per the can-monitor flag, but evidently I forgot to expose that out to userspace. Fix that. Fixes: a110a3b7 ("wifi: cfg80211: optionally support monitor on disabled channels") Reviewed-by:
-
Baochen Qiang authored
Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. Fixes: c4cbaf79 ("cfg80211: Add support for HE") Signed-off-by:
Baochen Qiang <quic_bqiang@quicinc.com> Link: https://msgid.link/20240606020653.33205-3-quic_bqiang@quicinc.comSigned-off-by:
-
Baochen Qiang authored
rates_996 is mistakenly written as rates_969, fix it. Fixes: c4cbaf79 ("cfg80211: Add support for HE") Signed-off-by:
-
Breno Leitao authored
Commit 3e2f544d ("net: get stats64 if device if driver is configured") moved the callback to dev_get_tstats64() to net core, so, unless the driver is doing some custom stats collection, it does not need to set .ndo_get_stats64. Since this driver is now relying in NETDEV_PCPU_STAT_TSTATS, then, it doesn't need to set the dev_get_tstats64() generic .ndo_get_stats64 function pointer. In this driver specifically, .ndo_get_stats64 basically points to dev_fetch_sw_netstats(). Now it will point to dev_get_tstats64(), which calls netdev_stats_to_stats64() and dev_fetch_sw_netstats(). netdev_stats_to_stats64() seems irrelevant for this driver. Signed-off-by:
Breno Leitao <leitao@debian.org> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://msgid.link/20240607102045.235071-2-leitao@debian.orgSigned-off-by:
-
Breno Leitao authored
With commit 34d21de9 ("net: Move {l,t,d}stats allocation to core and convert veth & vrf"), stats allocation could be done on net core instead of this driver. With this new approach, the driver doesn't have to bother with error handling (allocation failure checking, making sure free happens in the right spot, etc). This is core responsibility now. Move mac80211 driver to leverage the core allocation. Signed-off-by:
-
Johannes Berg authored
Jiazi Li reported that they occasionally see hash table duplicates as evidenced by the WARN_ON() in rb_insert_bss() in this code. It isn't clear how that happens, nor have I been able to reproduce it, but if it does happen, the kernel crashes later, when it tries to unhash the entry that's now not hashed. Try to make this situation more survivable by removing the BSS from the list(s) as well, that way it's fully leaked here (as had been the intent in the hash insert error path), and no longer reachable through the list(s) so it shouldn't be unhashed again later. Link: https://lore.kernel.org/r/20231026013528.GA24122@Jiazi.LiSigned-off-by:
-
Johannes Berg authored
For the EHT EIRP transmit power envelope, the 320 MHz is in the last octet, but if we've copied 4 octets (count == 3), the next one is at index 4 not 5 (count + 2). Fix this, and just hardcode the offset since count is always 3 here. Fixes: 39dc8b8e ("wifi: mac80211: pass parsed TPE data to drivers") Reviewed-by:
-
- 11 Jun, 2024 7 commits
-
-
Jakub Kicinski authored
Jacob Keller says: ==================== Intel Wired LAN Driver Updates 2024-06-03 This series includes miscellaneous improvements for the ice as well as a cleanup to the Makefiles for all Intel net drivers. Andy fixes all of the Intel net driver Makefiles to use the documented '*-y' syntax for specifying object files to link into kernel driver modules, rather than the '*-objs' syntax which works but is documented as reserved for user-space host programs. Jacob has a cleanup to refactor rounding logic in the ice driver into a common roundup_u64 helper function. Michal Schmidt replaces irq_set_affinity_hint() to use irq_update_affinity_hint() which behaves better with user-applied affinity settings. v2: https://lore.kernel.org/r/20240605-next-2024-06-03-intel-next-batch-v2-0-39c23963fa78@intel.com v1: https://lore.kernel.org/r/20240603-next-2024-06-03-intel-next-batch-v1-0-e0523b28f325@intel.com ==================== Link: https://lore.kernel.org/r/20240607-next-2024-06-03-intel-next-batch-v3-0-d1470cee3347@intel.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Michal Schmidt authored
irq_set_affinity_hint() is deprecated. Use irq_update_affinity_hint() instead. This removes the side-effect of actually applying the affinity. The driver does not really need to worry about spreading its IRQs across CPUs. The core code already takes care of that. On the contrary, when the driver applies affinities by itself, it breaks the users' expectations: 1. The user configures irqbalance with IRQBALANCE_BANNED_CPULIST in order to prevent IRQs from being moved to certain CPUs that run a real-time workload. 2. ice reconfigures VSIs at runtime due to a MIB change (ice_dcb_process_lldp_set_mib_change). Reopening a VSI resets the affinity in ice_vsi_req_irq_msix(). 3. ice has no idea about irqbalance's config, so it may move an IRQ to a banned CPU. The real-time workload suffers unacceptable latency. I am not sure if updating the affinity hints is at all useful, because irqbalance ignores them since 2016 ([1]), but at least it's harmless. This ice change is similar to i40e commit d34c54d1 ("i40e: Use irq_update_affinity_hint()"). [1] https://github.com/Irqbalance/irqbalance/commit/dcc411e7bfddSigned-off-by:Michal Schmidt <mschmidt@redhat.com> Reviewed-by:
Sunil Goutham <sgoutham@marvell.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> Signed-off-by:
-
Jacob Keller authored
In ice_ptp_cfg_clkout(), the ice driver needs to calculate the nearest next second of a current time value specified in nanoseconds. It implements this using div64_u64, because the time value is a u64. It could use div_u64 since NSEC_PER_SEC is smaller than 32-bits. Ideally this would be implemented directly with roundup(), but that can't work on all platforms due to a division which requires using the specific macros and functions due to platform restrictions, and to ensure that the most appropriate and fast instructions are used. The kernel doesn't currently provide any 64-bit equivalents for doing roundup. Attempting to use roundup() on a 32-bit platform will result in a link failure due to not having a direct 64-bit division. The closest equivalent for this is DIV64_U64_ROUND_UP, which does a division always rounding up. However, this only computes the division, and forces use of the div64_u64 in cases where the divisor is a 32bit value and could make use of div_u64. Introduce DIV_U64_ROUND_UP based on div_u64, and then use it to implement roundup_u64 which takes a u64 input value and a u32 rounding value. The name roundup_u64 matches the naming scheme of div_u64, and future patches could implement roundup64_u64 if they need to round by a multiple that is greater than 32-bits. Replace the logic in ice_ptp.c which does this equivalent with the newly added roundup_u64. Tested-by:
-
Andy Shevchenko authored
*-objs suffix is reserved rather for (user-space) host programs while usually *-y suffix is used for kernel drivers (although *-objs works for that purpose for now). Let's correct the old usages of *-objs in Makefiles. Reviewed-by:
Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by:
Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
Jeff Johnson authored
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/hfcpci.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/hfcmulti.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/hfcsusb.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/avmfritz.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/speedfax.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/mISDNinfineon.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/w6692.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/netjet.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/mISDNipac.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/mISDNisar.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/mISDN/mISDN_core.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/mISDN/mISDN_dsp.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/mISDN/l1oip.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Signed-off-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240607-md-drivers-isdn-v1-1-81fb7001bc3a@quicinc.comSigned-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski authored
Daniel Borkmann says: ==================== pull-request: bpf-next 2024-06-06 We've added 54 non-merge commits during the last 10 day(s) which contain a total of 50 files changed, 1887 insertions(+), 527 deletions(-). The main changes are: 1) Add a user space notification mechanism via epoll when a struct_ops object is getting detached/unregistered, from Kui-Feng Lee. 2) Big batch of BPF selftest refactoring for sockmap and BPF congctl tests, from Geliang Tang. 3) Add BTF field (type and string fields, right now) iterator support to libbpf instead of using existing callback-based approaches, from Andrii Nakryiko. 4) Extend BPF selftests for the latter with a new btf_field_iter selftest, from Alan Maguire. 5) Add new kfuncs for a generic, open-coded bits iterator, from Yafang Shao. 6) Fix BPF selftests' kallsyms_find() helper under kernels configured with CONFIG_LTO_CLANG_THIN, from Yonghong Song. 7) Remove a bunch of unused structs in BPF selftests, from David Alan Gilbert. 8) Convert test_sockmap section names into names understood by libbpf so it can deduce program type and attach type, from Jakub Sitnicki. 9) Extend libbpf with the ability to configure log verbosity via LIBBPF_LOG_LEVEL environment variable, from Mykyta Yatsenko. 10) Fix BPF selftests with regards to bpf_cookie and find_vma flakiness in nested VMs, from Song Liu. 11) Extend riscv32/64 JITs to introduce shift/add helpers to generate Zba optimization, from Xiao Wang. 12) Enable BPF programs to declare arrays and struct fields with kptr, bpf_rb_root, and bpf_list_head, from Kui-Feng Lee. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (54 commits) selftests/bpf: Drop useless arguments of do_test in bpf_tcp_ca selftests/bpf: Use start_test in test_dctcp in bpf_tcp_ca selftests/bpf: Use start_test in test_dctcp_fallback in bpf_tcp_ca selftests/bpf: Add start_test helper in bpf_tcp_ca selftests/bpf: Use connect_to_fd_opts in do_test in bpf_tcp_ca libbpf: Auto-attach struct_ops BPF maps in BPF skeleton selftests/bpf: Add btf_field_iter selftests selftests/bpf: Fix send_signal test with nested CONFIG_PARAVIRT libbpf: Remove callback-based type/string BTF field visitor helpers bpftool: Use BTF field iterator in btfgen libbpf: Make use of BTF field iterator in BTF handling code libbpf: Make use of BTF field iterator in BPF linker code libbpf: Add BTF field iterator selftests/bpf: Ignore .llvm.<hash> suffix in kallsyms_find() selftests/bpf: Fix bpf_cookie and find_vma in nested VM selftests/bpf: Test global bpf_list_head arrays. selftests/bpf: Test global bpf_rb_root arrays and fields in nested struct types. selftests/bpf: Test kptr arrays and kptrs in nested struct fields. bpf: limit the number of levels of a nested struct type. bpf: look into the types of the fields of a struct type recursively. ... ==================== Link: https://lore.kernel.org/r/20240606223146.23020-1-daniel@iogearbox.netSigned-off-by: -
Jakub Kicinski authored
Merge tag 'wireless-next-2024-06-07' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.11 The first "new features" pull request for v6.11 with changes both in stack and in drivers. Nothing out of ordinary, except that we have two conflicts this time: net/mac80211/cfg.c https://lore.kernel.org/all/20240531124415.05b25e7a@canb.auug.org.au drivers/net/wireless/microchip/wilc1000/netdev.c https://lore.kernel.org/all/20240603110023.23572803@canb.auug.org.au Major changes: cfg80211/mac80211 * parse Transmit Power Envelope (TPE) data in mac80211 instead of in drivers wilc1000 * read MAC address during probe to make it visible to user space iwlwifi * bump FW API to 91 for BZ/SC devices * report 64-bit radiotap timestamp * enable P2P low latency by default * handle Transmit Power Envelope (TPE) advertised by AP * start using guard() rtlwifi * RTL8192DU support ath12k * remove unsupported tx monitor handling * channel 2 in 6 GHz band support * Spatial Multiplexing Power Save (SMPS) in 6 GHz band support * multiple BSSID (MBSSID) and Enhanced Multi-BSSID Advertisements (EMA) support * dynamic VLAN support * add panic handler for resetting the firmware state ath10k * add qcom,no-msa-ready-indicator Device Tree property * LED support for various chipsets * tag 'wireless-next-2024-06-07' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (194 commits) wifi: ath12k: add hw_link_id in ath12k_pdev wifi: ath12k: add panic handler wifi: rtw89: chan: Use swap() in rtw89_swap_sub_entity() wifi: brcm80211: remove unused structs wifi: brcm80211: use sizeof(*pointer) instead of sizeof(type) wifi: ath12k: do not process consecutive RDDM event dt-bindings: net: wireless: ath11k: Drop "qcom,ipq8074-wcss-pil" from example wifi: ath12k: fix memory leak in ath12k_dp_rx_peer_frag_setup() wifi: rtlwifi: handle return value of usb init TX/RX wifi: rtlwifi: Enable the new rtl8192du driver wifi: rtlwifi: Add rtl8192du/sw.c wifi: rtlwifi: Constify rtl_hal_cfg.{ops,usb_interface_cfg} and rtl_priv.cfg wifi: rtlwifi: Add rtl8192du/dm.{c,h} wifi: rtlwifi: Add rtl8192du/fw.{c,h} and rtl8192du/led.{c,h} wifi: rtlwifi: Add rtl8192du/rf.{c,h} wifi: rtlwifi: Add rtl8192du/trx.{c,h} wifi: rtlwifi: Add rtl8192du/phy.{c,h} wifi: rtlwifi: Add rtl8192du/hw.{c,h} wifi: rtlwifi: Add new members to struct rtl_priv for RTL8192DU wifi: rtlwifi: Add rtl8192du/table.{c,h} ... Signed-off-by:
-
- 10 Jun, 2024 2 commits
-
-
David S. Miller authored
Marek Behún says: ==================== Fix changing DSA conduit This series fixes an issue in the DSA code related to host interface UC address installed into port FDB and port conduit address database when live-changing port conduit. The first patch refactores/deduplicates the installation/uninstallation of the interface's MAC address and the second patch fixes the issue. Cover letter for v1 and v2: https://patchwork.kernel.org/project/netdevbpf/cover/20240429163627.16031-1-kabel@kernel.org/ https://patchwork.kernel.org/project/netdevbpf/cover/20240502122922.28139-1-kabel@kernel.org/ ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Marek Behún authored
When changing DSA user interface conduit while the user interface is up, DSA exhibits different behavior in comparison to when the interface is down. This different behavior concerns the primary unicast MAC address stored in the port standalone FDB and in the conduit device UC database. If we put a switch port down while changing the conduit with ip link set sw0p0 down ip link set sw0p0 type dsa conduit conduit1 ip link set sw0p0 up we delete the address in dsa_user_close() and install the (possibly different) address in dsa_user_open(). But when changing the conduit on the fly, the old address is not deleted and the new one is not installed. Since we explicitly want to support live-changing the conduit, uninstall the old address before calling dsa_port_assign_conduit() and install the (possibly different) new address after the call. Because conduit change might also trigger address change (the user interface is supposed to inherit the conduit interface MAC address if no address is defined in hardware (dp->mac is a zero address)), move the eth_hw_addr_inherit() call from dsa_user_change_conduit() to dsa_port_change_conduit(), just before installing the new address. Although this is in theory a flaw in DSA core, it needs not be backported, since there is currently no DSA driver that can be affected by this. The only DSA driver that supports changing conduit is felix, and, as explained by Vladimir Oltean [1]: There are 2 reasons why with felix the bug does not manifest itself. First is because both the 'ocelot' and the alternate 'ocelot-8021q' tagging protocols have the 'promisc_on_conduit = true' flag. So the unicast address doesn't have to be in the conduit's RX filter - neither the old or the new conduit. Second, dsa_user_host_uc_install() theoretically leaves behind host FDB entries installed towards the wrong (old) CPU port. But in felix_fdb_add(), we treat any FDB entry requested towards any CPU port as if it was a multicast FDB entry programmed towards _all_ CPU ports. For that reason, it is installed towards the port mask of the PGID_CPU port group ID: if (dsa_port_is_cpu(dp)) port = PGID_CPU; Therefore no Fixes tag for this change. [1] https://lore.kernel.org/netdev/20240507201827.47suw4fwcjrbungy@skbuf/Signed-off-by:
Marek Behún <kabel@kernel.org> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Tested-by:
-
