summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-03-11vboxsf: Add __nonstring annotations for unterminated stringsKees Cook1-2/+1
When a character array without a terminating NUL character has a static initializer, GCC 15's -Wunterminated-string-initialization will only warn if the array lacks the "nonstring" attribute[1]. Mark the arrays with __nonstring to and correctly identify the char array as "not a C string" and thereby eliminate the warning. This effectively reverts the change in 4e7487245abc ("vboxsf: fix building with GCC 15"), to add the annotation that has other uses (i.e. warning if the string is ever used with C string APIs). Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 [1] Cc: Hans de Goede <hdegoede@redhat.com> Cc: Brahmajit Das <brahmajit.xyz@gmail.com> Cc: Christian Brauner <brauner@kernel.org> Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Kees Cook <kees@kernel.org> Link: https://lore.kernel.org/r/20250310222530.work.374-kees@kernel.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-03-11net: switchdev: Convert blocking notification chain to a raw oneAmit Cohen1-7/+18
A blocking notification chain uses a read-write semaphore to protect the integrity of the chain. The semaphore is acquired for writing when adding / removing notifiers to / from the chain and acquired for reading when traversing the chain and informing notifiers about an event. In case of the blocking switchdev notification chain, recursive notifications are possible which leads to the semaphore being acquired twice for reading and to lockdep warnings being generated [1]. Specifically, this can happen when the bridge driver processes a SWITCHDEV_BRPORT_UNOFFLOADED event which causes it to emit notifications about deferred events when calling switchdev_deferred_process(). Fix this by converting the notification chain to a raw notification chain in a similar fashion to the netdev notification chain. Protect the chain using the RTNL mutex by acquiring it when modifying the chain. Events are always informed under the RTNL mutex, but add an assertion in call_switchdev_blocking_notifiers() to make sure this is not violated in the future. Maintain the "blocking" prefix as events are always emitted from process context and listeners are allowed to block. [1]: WARNING: possible recursive locking detected 6.14.0-rc4-custom-g079270089484 #1 Not tainted -------------------------------------------- ip/52731 is trying to acquire lock: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0 but task is already holding lock: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock((switchdev_blocking_notif_chain).rwsem); lock((switchdev_blocking_notif_chain).rwsem); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by ip/52731: #0: ffffffff84f795b0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x727/0x1dc0 #1: ffffffff8731f628 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x790/0x1dc0 #2: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0 stack backtrace: ... ? __pfx_down_read+0x10/0x10 ? __pfx_mark_lock+0x10/0x10 ? __pfx_switchdev_port_attr_set_deferred+0x10/0x10 blocking_notifier_call_chain+0x58/0xa0 switchdev_port_attr_notify.constprop.0+0xb3/0x1b0 ? __pfx_switchdev_port_attr_notify.constprop.0+0x10/0x10 ? mark_held_locks+0x94/0xe0 ? switchdev_deferred_process+0x11a/0x340 switchdev_port_attr_set_deferred+0x27/0xd0 switchdev_deferred_process+0x164/0x340 br_switchdev_port_unoffload+0xc8/0x100 [bridge] br_switchdev_blocking_event+0x29f/0x580 [bridge] notifier_call_chain+0xa2/0x440 blocking_notifier_call_chain+0x6e/0xa0 switchdev_bridge_port_unoffload+0xde/0x1a0 ... Fixes: f7a70d650b0b6 ("net: bridge: switchdev: Ensure deferred event delivery on unoffload") Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Tested-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20250305121509.631207-1-amcohen@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11Merge branch 'net-ti-icssg-prueth-add-native-mode-xdp-support'Paolo Abeni5-113/+541
Meghana Malladi says: ==================== net: ti: icssg-prueth: Add native mode XDP support This series adds native XDP support using page_pool. XDP zero copy support is not included in this patch series. Patch 1/3: Replaces skb with page pool for Rx buffer allocation Patch 2/3: Adds prueth_swdata struct for SWDATA for all swdata cases Patch 3/3: Introduces native mode XDP support v3: https://lore.kernel.org/all/20250224110102.1528552-1-m-malladi@ti.com/ ==================== Link: https://patch.msgid.link/20250305101422.1908370-1-m-malladi@ti.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11net: ti: icssg-prueth: Add XDP supportRoger Quadros3-15/+355
Add native XDP support. We do not support zero copy yet. Signed-off-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Signed-off-by: Meghana Malladi <m-malladi@ti.com> Link: https://patch.msgid.link/20250305101422.1908370-4-m-malladi@ti.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11net: ti: icssg-prueth: introduce and use prueth_swdata struct for SWDATARoger Quadros4-26/+54
We have different cases for SWDATA (skb, page, cmd, etc) so it is better to have a dedicated data structure for that. We can embed the type field inside the struct and use it to interpret the data in completion handlers. Signed-off-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Signed-off-by: Meghana Malladi <m-malladi@ti.com> Link: https://patch.msgid.link/20250305101422.1908370-3-m-malladi@ti.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11net: ti: icssg-prueth: Use page_pool API for RX buffer allocationRoger Quadros4-90/+150
This is to prepare for native XDP support. The page pool API is more faster in allocating pages than __alloc_skb(). Drawback is that it works at PAGE_SIZE granularity so we are not efficient in memory usage. i.e. we are using PAGE_SIZE (4KB) memory for 1.5KB max packet size. Signed-off-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Signed-off-by: Meghana Malladi <m-malladi@ti.com> Link: https://patch.msgid.link/20250305101422.1908370-2-m-malladi@ti.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11wifi: iwlwifi: don't warn when if there is a FW errorMiri Korenblit1-1/+4
iwl_trans_reclaim is warning if it is called when the FW is not alive. But if it is called when there is a pending restart, i.e. after a FW error, there is no need to warn, instead - return silently. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231427.ba3d90b22c25.I9332506af1997faefcf0bdb51d98d5e874051722@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: iwlwifi: bump minimum API version in BZ/SC to 93Miri Korenblit2-2/+2
Stop supporting older FWs. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231427.73e962ca3e6c.I942fa8cafc1791b9330ad18e2599fae11d7b3336@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: iwlwifi: bump FW API to 98 for BZ/SC/DR devicesMiri Korenblit3-6/+6
Start supporting API versions 97 and 98 for those devices. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231427.55b5455795aa.I333f1e7fa31f9da1d40f668660c1e25b93ff469e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: iwlwifi: mvm: Fix bit size calculation in iwl_dbgfs_tas_get_status_readPagadala Yesu Anjaneyulu1-5/+3
Corrected the bit size calculation in the for_each_set_bit macro in the iwl_dbgfs_tas_get_status_read(). The previous implementation used sizeof(dyn_status), which only accounts for the number of bytes. This has been updated to TAS_DYNA_STATUS_MAX to ensure the loop iterates over the correct number of valid bits in dyn_status. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231427.65d373e4a10e.If2cea63035333b07849e5a2c2a4f5dc5c5239595@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: iwlwifi: w/a FW SMPS mode selectionDaniel Gabay3-1/+20
The FW is now responsible of determining the SMPS mode. If the user disabled power save in a certain vif, we send the vif-level power command to clear out the POWER_FLAGS_POWER_MANAGEMENT_ENA_MSK bit for that vif. But erroneously, the FW checks DEVICE_POWER_FLAGS_POWER_SAVE_ENA_MSK in the device-level command to determine the SMPS mode. To W/A this, send also the device-level command when the power save of a vif changes, and disable power save if there is any vif that has power save disabled. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231427.7bf205efa027.I2c793ff1fc2a6779a95faaee1ded348100fd97f1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: iwlwifi: fix debug actions orderJohannes Berg1-5/+5
The order of actions taken for debug was implemented incorrectly. Now we implemented the dump split and do the FW reset only in the middle of the dump (rather than the FW killing itself on error.) As a result, some of the actions taken when applying the config will now crash the device, so we need to fix the order. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231427.6de7fa8e63ed.I40632c48e2a67a8aca05def572a934b88ce7934b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: iwlwifi: mark Br device not integratedJohannes Berg1-2/+0
This is a discrete device, don't mark it as integrated. This also means we cannot set the LTR delay. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231427.9bb69393fcc9.I197129383e5441c8139cbb0e810ae0b71198a37c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: iwlwifi: Add new TAS disable reason for invalid table sourcePagadala Yesu Anjaneyulu2-0/+5
The new reason is added to the iwl_tas_statically_disabled_reason enum and the corresponding message is updated in the iwl_dbgfs_tas_get_status_read(). Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231427.5e1272ef3508.I24f668ae716bee20cba15fdc73c3363693bbaf73@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: iwlwifi: mvm: cleanup of TAS structure and enumsPagadala Yesu Anjaneyulu2-40/+27
Removed mvm prefix from the following structures and enum names: 1. struct iwl_tas_status_per_mac 2. struct iwl_tas_status_resp 3. enum iwl_tas_dyna_status 4. enum iwl_tas_statically_disabled_reason As these structures and enums are not specific to mvm. Replaced TAS_LMAC_BAND_LB, TAS_LMAC_BAND_HB, and TAS_LMAC_BAND_UHB macros with a generic BAND macro, as these macros are not specific to TAS. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231427.59144bee9987.Ic2678dcb5afdacc2ca234d4aa4901e7e1f6e8dbb@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: iwlwifi: fix print for ECKVEmmanuel Grumbach1-1/+1
The print was obviously wrong. We are handling ECKV and not WRDD in this function. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231426.e006c6b21432.I318fed724709f9ee7a0c369e1cf5e1038ddd546a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: iwlwifi: fix the ECKV UEFI variable nameEmmanuel Grumbach2-5/+7
This UEFI variable name was badly named. Fix its name and also use the right GUID to find it: we need to use the BT_WIFI (a.k.a. Common) GUID. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231426.78c998d0fa71.I2bc9d72c1dc2c4d7028f0265634a940c2fadbbb5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: iwlwifi: add support for BE213Emmanuel Grumbach4-7/+29
Add the BE213 device. This is just like BE211 but with a limitation on the bandwidth. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308231426.f02f4d7fc73b.Idaf000dd311358e3b50a511f4efc1cc720abd58b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: mac80211: set WMM in ML reconfigurationJohannes Berg1-0/+1
In the per-STA profiles for added links in multi-link reconfiguration the WMM element should be included. Fix that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.59902f783420.I362c3101d3f523a8db37c16cd7b5f573d76a36e6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: mac80211: don't include MLE in ML reconf per-STA profileJohannes Berg2-1/+3
In the multi-link reconfiguration frame, the per-STA profile for added links shouldn't include the multi-link element. Set the association ID to an invalid value, so it doesn't erroneously match the link ID if that happens to be zero. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.8e5be244c70f.I3472cd5c347814ee3600869a88488997bcd43224@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: mac80211: fix ML reconf reset in disconnectJohannes Berg1-4/+4
If disconnecting while ML reconfiguration is in progress, the data isn't freed because the reset call is too late, after the vif already switches to non-MLD. Move the call to fix that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.abaea69cde42.I7e6b35731ded94fc2d68a2d4ecf81873712c268e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: mac80211: Notify cfg80211 about added link addressesIlan Peer1-1/+4
When ML reconfiguration is done and new links are added, update cfg80211 with the addresses of the newly added links. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.0c6bf8b1bef3.I2aa16801f07321a580dd7dce4a074a3486f627f1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: cfg80211: Update the link address when a link is addedIlan Peer2-0/+5
When links are added, update the wireless device link addresses based on the information provided by the driver. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.d694a9125aba.I79b010ea9aab47893e4f22c266362fde30b7f9ac@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: mac80211: fix warning on disconnect during failed ML reconfJohannes Berg1-1/+1
If multi-link reconfiguration fails, we can disconnect with a local link already allocated but the BSS entry not assigned yet, which leads to a warning in cfg80211. Add a check to avoid the warning. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.699bd9cbabe5.I599d5ff69092a65e916e2acd25137ae9df8debe8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: mac80211: fix userspace_selectors corruptionJohannes Berg1-8/+6
Spotted during code review, the selectors need to be large enough for a 128-bit bitmap, not a single unsigned long, otherwise we have stack corruption. We should also allow passing selectors from userspace, but that should be a separate change. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.8f1bcf96a504.Ibeb8970c82a30c97279a4cc4e68faca5df1813a5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: mac80211_hwsim: Fix MLD address translationIlan Peer1-6/+8
Do address translations only between shared links. It is possible that while an non-AP MLD station and an AP MLD station have shared links, the frame is intended to be sent on a link which is not shared (for example when sending a probe response). Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.1aa461270bb6.Ic21592e1b1634653f02b80628cb2152f6e9de367@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: mac80211: allow 320 MHz FTM measurementsAvraham Stern1-1/+2
Add 320 MHz to the list of allowed bandwidths for FTM measurements. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.91f4cbe66817.I9205c585fca6a54a2c5a9e4db98c7781bd1fc4e1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: cfg80211: improve supported_selector documentationJohannes Berg2-5/+5
Improve the documentation for supported BSS selectors to make it more precise. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.ba402ff47314.I502b56111b62ea0be174ae76bd03684ae1d4aefb@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: mac80211: fix U-APSD check in ML reconfigurationJohannes Berg1-5/+4
If U-APSD isn't enabled by us, then IEEE80211_STA_UAPSD_ENABLED won't be set, but the AP can still support it in that case. Only require U-APSD from the AP if we enabled it, don't require it to be disabled on the AP if we didn't. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.b4674be12a38.I01959e448c6a2a3e8bc5d561bbae9e8d2cca616a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: cfg80211: allow IR in 20 MHz configurationsAnjaneyulu5-25/+46
Some regulatory bodies doesn't allow IR (initiate radioation) on a specific subband, but allows it for channels with a bandwidth of 20 MHz. Add a channel flag that indicates that, and consider it in cfg80211_reg_check_beaconing. While on it, fix the kernel doc of enum nl80211_reg_rule_flags and change it to use BIT(). Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Co-developed-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com> Signed-off-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.d3ab352a73ff.I8a8f79e1c9eb74936929463960ee2a324712fe51@changeid [fix typo] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: mac80211: mlme: support extended MLD capa/ops in assocJohannes Berg2-2/+32
Support passing the value from userspace on to the AP in the association and ML link reconfiguration requests. We may need to also add a driver value to or in with the field, but for now have no feature that is controlled by the driver. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.2e555beb0a76.I623f59023b47ec202fc0c7520f2b5f575b439927@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: cfg80211: allow setting extended MLD capa/opsJohannes Berg4-1/+31
Some extended MLD capabilities and operations bits (currently the "BTM MLD Recommendataion For Multiple APs Support" bit) may depend on userspace capabilities. Allow userspace to pass the values for this field that it supports to the association and link reconfiguration operations. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20250308225541.bd52078b5f65.I4dd8f53b0030db7ea87a2e0920989e7e2c7b5345@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11wifi: cfg80211: move link reconfig parameters into a structJohannes Berg9-65/+67
Add a new struct cfg80211_ml_reconf_req to collect the link reconfiguration parameters. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250308225541.0cf299c1fdd0.Id1a3b1092dc52d0d3731a8798522fdf2e052bf0b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-11Merge branch 'enic-enable-32-64-byte-cqes-and-get-max-rx-tx-ring-size-from-hw'Paolo Abeni17-259/+545
Satish Kharat via says: ==================== enic: enable 32, 64 byte cqes and get max rx/tx ring size from hw This series enables using the max rx and tx ring sizes read from hw. For newer hw that can be up to 16k entries. This requires bigger completion entries for rx queues. This series enables the use of the 32 and 64 byte completion queues entries for enic rx queues on supported hw versions. This is in addition to the exiting (default) 16 byte rx cqes. Signed-off-by: Satish Kharat <satishkh@cisco.com> ==================== Link: https://patch.msgid.link/20250304-enic_cleanup_and_ext_cq-v2-0-85804263dad8@cisco.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11enic: get max rq & wq entries supported by hw, 16K queuesSatish Kharat7-24/+39
Enables reading the max rq and wq entries supported from the hw. Enables 16k rq and wq entries on hw that supports. Co-developed-by: Nelson Escobar <neescoba@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Co-developed-by: John Daley <johndale@cisco.com> Signed-off-by: John Daley <johndale@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Link: https://patch.msgid.link/20250304-enic_cleanup_and_ext_cq-v2-8-85804263dad8@cisco.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11enic: cleanup of enic wq request completion pathSatish Kharat3-61/+52
Cleans up the enic wq request completion path needed for 16k wq size support. Co-developed-by: Nelson Escobar <neescoba@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Co-developed-by: John Daley <johndale@cisco.com> Signed-off-by: John Daley <johndale@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Link: https://patch.msgid.link/20250304-enic_cleanup_and_ext_cq-v2-7-85804263dad8@cisco.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11enic: added enic_wq.c and enic_wq.hSatish Kharat7-117/+138
Moves wq related function to enic_wq.c. Prepares for a cleaup of enic wq code path. Co-developed-by: Nelson Escobar <neescoba@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Co-developed-by: John Daley <johndale@cisco.com> Signed-off-by: John Daley <johndale@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Link: https://patch.msgid.link/20250304-enic_cleanup_and_ext_cq-v2-6-85804263dad8@cisco.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11enic: remove unused function cq_enet_wq_desc_decSatish Kharat1-7/+0
Removes cq_enet_wq_desc_dec, not needed anymore. Co-developed-by: Nelson Escobar <neescoba@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Co-developed-by: John Daley <johndale@cisco.com> Signed-off-by: John Daley <johndale@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Link: https://patch.msgid.link/20250304-enic_cleanup_and_ext_cq-v2-5-85804263dad8@cisco.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11enic: enable rq extended cq supportSatish Kharat5-29/+150
Enables getting from hw all the supported rq cq sizes and uses the highest supported cq size. Co-developed-by: Nelson Escobar <neescoba@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Co-developed-by: John Daley <johndale@cisco.com> Signed-off-by: John Daley <johndale@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Link: https://patch.msgid.link/20250304-enic_cleanup_and_ext_cq-v2-4-85804263dad8@cisco.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11enic: enic rq extended cq definesSatish Kharat2-0/+75
Adds the defines for 32 and 64 byte receive queue completion queue descriptors. Adds devcmd define to get rq cq descriptor size/s supported by hw. Co-developed-by: Nelson Escobar <neescoba@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Co-developed-by: John Daley <johndale@cisco.com> Signed-off-by: John Daley <johndale@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Link: https://patch.msgid.link/20250304-enic_cleanup_and_ext_cq-v2-3-85804263dad8@cisco.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11enic: enic rq code reorgSatish Kharat4-39/+106
Separates enic rx path from generic vnic api. Removes some complexity of doign enic callbacks through vnic api in rx. This is in preparation for enabling enic extended cq which applies only to enic rx path. Co-developed-by: Nelson Escobar <neescoba@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Co-developed-by: John Daley <johndale@cisco.com> Signed-off-by: John Daley <johndale@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Link: https://patch.msgid.link/20250304-enic_cleanup_and_ext_cq-v2-2-85804263dad8@cisco.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-11enic: Move function from header file to c fileSatish Kharat2-81/+84
Moves cq_enet_rq_desc_dec from cq_enet_desc.h to enic_rq.c. This is in preparation for enic extended completion queue enabling. Co-developed-by: Nelson Escobar <neescoba@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Co-developed-by: John Daley <johndale@cisco.com> Signed-off-by: John Daley <johndale@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Link: https://patch.msgid.link/20250304-enic_cleanup_and_ext_cq-v2-1-85804263dad8@cisco.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-10Merge branch 'mptcp-pm-code-reorganisation'Jakub Kicinski7-2025/+2038
Matthieu Baerts says: ==================== mptcp: pm: code reorganisation Before this series, the PM code was dispersed in different places: - pm.c had common code for all PMs. - pm_netlink.c was initially only about the in-kernel PM, but ended up also getting exported common helpers, callbacks used by the different PMs, NL events for PM userspace daemon, etc. quite confusing. - pm_userspace.c had userspace PM only code, but it was using "specific" in-kernel PM helpers according to their names. To clarify the code, a reorganisation is suggested here, only by moving code around, and small helper renaming to avoid confusions: - pm_netlink.c now only contains common PM generic Netlink code: - PM events: this code was already there - shared helpers around Netlink code that were already there as well - shared Netlink commands code from pm.c - pm_kernel.c now contains only code that is specific to the in-kernel PM. Now all functions are either called from: - pm.c: events coming from the core, when this PM is being used - pm_netlink.c: for shared Netlink commands - mptcp_pm_gen.c: for Netlink commands specific to the in-kernel PM - sockopt.c: for the exported counters per netns - pm.c got many code from pm_netlink.c: - helpers used from both PMs and not linked to Netlink - callbacks used by different PMs, e.g. ADD_ADDR management - some helpers have been renamed to remove the '_nl' prefix, and some have been marked as 'static'. - protocol.h has been updated accordingly: - some helpers no longer need to be exported - new ones needed to be exported: they have been prefixed if needed. The code around the PM is now less confusing, which should help for the maintenance in the long term, and the introduction of a PM Ops. This will certainly impact future backports, but because other cleanups have already done recently, and more are coming to ease the addition of a new path-manager controlled with BPF (struct_ops), doing that now seems to be a good time. Also, many issues around the PM have been fixed a few months ago while increasing the code coverage in the selftests, so such big reorganisation can be done with more confidence now. Note that checkpatch, when used with --max-line-length=80, will complain about lines being over the 80 limits, but these warnings were already there before moving the code around. Also, patch 1 is not directly related to the code reorganisation, but it was a remaining cleanup that we didn't upstream before, because it was conflicting with another patch that has been sent for inclusion to the net tree. ==================== Link: https://patch.msgid.link/20250307-net-next-mptcp-pm-reorg-v1-0-abef20ada03b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-10mptcp: pm: move Netlink PM helpers to pm_netlink.cMatthieu Baerts (NGI0)3-123/+117
Before this patch, the PM code was dispersed in different places: - pm.c had common code for all PMs, but also Netlink specific code that will not be needed with the future BPF path-managers. - pm_netlink.c had common Netlink code. To clarify the code, a reorganisation is suggested here, only by moving code around, and small helper renaming to avoid confusions: - pm_netlink.c now only contains common PM Netlink code: - PM events: this code was already there - shared helpers around Netlink code that were already there as well - shared Netlink commands code from pm.c - pm.c now no longer contain Netlink specific code. - protocol.h has been updated accordingly: - mptcp_nl_fill_addr() no longer need to be exported. The code around the PM is now less confusing, which should help for the maintenance in the long term. This will certainly impact future backports, but because other cleanups have already done recently, and more are coming to ease the addition of a new path-manager controlled with BPF (struct_ops), doing that now seems to be a good time. Also, many issues around the PM have been fixed a few months ago while increasing the code coverage in the selftests, so such big reorganisation can be done with more confidence now. No behavioural changes intended. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250307-net-next-mptcp-pm-reorg-v1-15-abef20ada03b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-10mptcp: pm: split in-kernel PM specific codeMatthieu Baerts (NGI0)3-1405/+1411
Before this patch, the PM code was dispersed in different places: - pm.c had common code for all PMs - pm_netlink.c was supposed to be about the in-kernel PM, but also had exported common Netlink helpers, NL events for PM userspace daemons, etc. quite confusing. To clarify the code, a reorganisation is suggested here, only by moving code around to avoid confusions: - pm_netlink.c now only contains common PM Netlink code: - PM events: this code was already there - shared helpers around Netlink code that were already there as well - more shared Netlink commands code from pm.c will come after - pm_kernel.c now contains only code that is specific to the in-kernel PM. Now all functions are either called from: - pm.c: events coming from the core, when this PM is being used - pm_netlink.c: for shared Netlink commands - mptcp_pm_gen.c: for Netlink commands specific to the in-kernel PM - sockopt.c: for the exported counters per netns - (while at it, a useless 'return;' spot by checkpatch at the end of mptcp_pm_nl_set_flags_all, has been removed) The code around the PM is now less confusing, which should help for the maintenance in the long term. This will certainly impact future backports, but because other cleanups have already done recently, and more are coming to ease the addition of a new path-manager controlled with BPF (struct_ops), doing that now seems to be a good time. Also, many issues around the PM have been fixed a few months ago while increasing the code coverage in the selftests, so such big reorganisation can be done with more confidence now. No behavioural changes intended. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250307-net-next-mptcp-pm-reorg-v1-14-abef20ada03b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-10mptcp: pm: move generic PM helpers to pm.cMatthieu Baerts (NGI0)3-468/+467
Before this patch, the PM code was dispersed in different places: - pm.c had common code for all PMs - pm_netlink.c was supposed to be about the in-kernel PM, but also had exported common helpers, callbacks used by the different PMs, NL events for PM userspace daemon, etc. quite confusing. - pm_userspace.c had userspace PM only code, but using specific in-kernel PM helpers To clarify the code, a reorganisation is suggested here, only by moving code around, and (un)exporting functions: - helpers used from both PMs and not linked to Netlink - callbacks used by different PMs, e.g. ADD_ADDR management - some helpers have been marked as 'static' - protocol.h has been updated accordingly - (while at it, a needless if before a kfree(), spot by checkpatch in mptcp_remove_anno_list_by_saddr(), has been removed) The code around the PM is now less confusing, which should help for the maintenance in the long term. This will certainly impact future backports, but because other cleanups have already done recently, and more are coming to ease the addition of a new path-manager controlled with BPF (struct_ops), doing that now seems to be a good time. Also, many issues around the PM have been fixed a few months ago while increasing the code coverage in the selftests, so such big reorganisation can be done with more confidence now. No behavioural changes intended. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250307-net-next-mptcp-pm-reorg-v1-13-abef20ada03b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-10mptcp: pm: move generic helper at the topMatthieu Baerts (NGI0)1-27/+27
In prevision to another change importing all generic PM helpers from pm_netlink.c to there. No behavioural changes intended. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250307-net-next-mptcp-pm-reorg-v1-12-abef20ada03b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-10mptcp: pm: export mptcp_remote_addressMatthieu Baerts (NGI0)2-8/+11
In a following commit, the 'remote_address' helper will need to be used from different files. It is then exported, and prefixed with 'mptcp_', similar to 'mptcp_local_address'. No behavioural changes intended. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250307-net-next-mptcp-pm-reorg-v1-11-abef20ada03b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-10mptcp: pm: worker: split in-kernel and common tasksMatthieu Baerts (NGI0)3-20/+30
To make it clear what actions are in-kernel PM specific and which ones are not and done for all PMs, e.g. sending ADD_ADDR and close associated subflows when a RM_ADDR is received. The behavioural is changed a bit: MPTCP_PM_ADD_ADDR_RECEIVED is now treated after MPTCP_PM_ADD_ADDR_SEND_ACK and MPTCP_PM_RM_ADDR_RECEIVED, but that should not change anything in practice. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250307-net-next-mptcp-pm-reorg-v1-10-abef20ada03b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-10mptcp: pm: avoid calling PM specific code from coreMatthieu Baerts (NGI0)4-7/+12
When destroying an MPTCP socket, some userspace PM specific code was called from mptcp_destroy_common() in protocol.c. That feels wrong, and it is the only case. Instead, the core now calls mptcp_pm_destroy() from pm.c which is now in charge of cleaning the announced addresses list, and ask the different PMs to do extra cleaning if needed, e.g. the userspace PM, if used, will clean the local addresses list. While at it, the userspace PM specific helper has been prefixed with 'mptcp_userspace_pm_' like the other ones. No behavioural changes intended. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250307-net-next-mptcp-pm-reorg-v1-9-abef20ada03b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 18:47:48 +0300