summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-15net: hns3: use seq_file for files in fd/ in debugfsJijie Shao
This patch use seq_file for the following nodes: fd_tcam/fd_counter Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250714061037.2616413-9-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15net: hns3: use seq_file for files in reg/ in debugfsJijie Shao
This patch use seq_file for the following nodes: bios_common/ssu/igu_egu/rpu/ncsi/rtc/ppp/rcb/tqp/mac/dcb Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250714061037.2616413-8-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15net: hns3: use seq_file for files in mac_list/ in debugfsYonglong Liu
This patch use seq_file for the following nodes: uc/mc Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250714061037.2616413-7-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15net: hns3: use seq_file for files in tm/ in debugfsJian Shen
Use seq_file for files in debugfs. This is the first modification for reading in hclge_debugfs.c. This patch use seq_file for the following nodes: tm_nodes/tm_priority/tm_qset/tm_map/tm_pg/tm_port/tc_sch_info/ qos_pause_cfg/qos_pri_map/qos_dscp_map/qos_buf_cfg Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250714061037.2616413-6-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15net: hns3: use seq_file for files in common/ of hns3 layerJijie Shao
This patch use seq_file for the following nodes: dev_info/coalesce_info/page_pool_info Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250714061037.2616413-5-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15net: hns3: use seq_file for files in queue/ in debugfsJian Shen
This patch use seq_file for the following nodes: rx_queue_info/queue_map Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250714061037.2616413-4-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15net: hns3: clean up the build warning in debugfs by use seq fileJian Shen
Arnd reported that there are two build warning for on-stasck buffer oversize. As Arnd's suggestion, using seq file way to avoid the stack buffer or kmalloc buffer allocating. Reported-by: Arnd Bergmann <arnd@kernel.org> Closes: https://lore.kernel.org/all/20250610092113.2639248-1-arnd@kernel.org/ Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250714061037.2616413-3-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15net: hns3: remove tx spare info from debugfs.Jijie Shao
The tx spare info in debugfs is not very useful, and there are related statistics available for troubleshooting. This patch removes the tx spare info from debugfs. Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250714061037.2616413-2-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15ipv6: mcast: Remove unnecessary null check in ip6_mc_find_dev()Yue Haibing
These is no need to check null for idev before return NULL. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250714081732.3109764-1-yuehaibing@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15net: stmmac: intel: populate entire system_counterval_t in get_time_fn() ↵Markus Blöchl
callback get_time_fn() callback implementations are expected to fill out the entire system_counterval_t struct as it may be initially uninitialized. This broke with the removal of convert_art_to_tsc() helper functions which left use_nsecs uninitialized. Initially assign the entire struct with default values. Fixes: f5e1d0db3f02 ("stmmac: intel: Remove convert_art_to_tsc()") Cc: stable@vger.kernel.org Signed-off-by: Markus Blöchl <markus@blochl.de> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250713-stmmac_crossts-v1-1-31bfe051b5cb@blochl.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15don't open-code kernel_accept() in rds_tcp_accept_one()Al Viro
rds_tcp_accept_one() starts with a pretty much verbatim copy of kernel_accept(). Might as well use the real thing... That code went into mainline in 2009, kernel_accept() had been added in Aug 2006, the copyright on rds/tcp_listen.c is "Copyright (c) 2006 Oracle", so it's entirely possible that it predates the introduction of kernel_accept(). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Link: https://patch.msgid.link/20250713180134.GC1880847@ZenIV Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15Merge tag 'linux-can-fixes-for-6.16-20250715' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2025-07-15 Brett Werling's patch for the tcan4x5x glue code driver fixes the detection of chips which are held in reset/sleep and must be woken up by GPIO prior to communication. * tag 'linux-can-fixes-for-6.16-20250715' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: tcan4x5x: fix reset gpio usage during probe ==================== Link: https://patch.msgid.link/20250715101625.3202690-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15bnxt: move bnxt_hsi.h to include/linux/bnxt/hsi.hAndy Gospodarek
This moves bnxt_hsi.h contents to a common location so it can be properly referenced by bnxt_en, bnxt_re, and bnge. Signed-off-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20250714170202.39688-1-gospo@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15usb: net: sierra: check for no status endpointOliver Neukum
The driver checks for having three endpoints and having bulk in and out endpoints, but not that the third endpoint is interrupt input. Rectify the omission. Reported-by: syzbot+3f89ec3d1d0842e95d50@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/686d5a9f.050a0220.1ffab7.0017.GAE@google.com/ Tested-by: syzbot+3f89ec3d1d0842e95d50@syzkaller.appspotmail.com Fixes: eb4fd8cd355c8 ("net/usb: add sierra_net.c driver") Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://patch.msgid.link/20250714111326.258378-1-oneukum@suse.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-15ice: check correct pointer in fwlog debugfsMichal Swiatkowski
pf->ice_debugfs_pf_fwlog should be checked for an error here. Fixes: 96a9a9341cda ("ice: configure FW logging") Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-15ice: add NULL check in eswitch lag checkDave Ertman
The function ice_lag_is_switchdev_running() is being called from outside of the LAG event handler code. This results in the lag->upper_netdev being NULL sometimes. To avoid a NULL-pointer dereference, there needs to be a check before it is dereferenced. Fixes: 776fe19953b0 ("ice: block default rule setting on LAG interface") Signed-off-by: Dave Ertman <david.m.ertman@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-15ethernet: intel: fix building with large NR_CPUSArnd Bergmann
With large values of CONFIG_NR_CPUS, three Intel ethernet drivers fail to compile like: In function ‘i40e_free_q_vector’, inlined from ‘i40e_vsi_alloc_q_vectors’ at drivers/net/ethernet/intel/i40e/i40e_main.c:12112:3: 571 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) include/linux/rcupdate.h:1084:17: note: in expansion of macro ‘BUILD_BUG_ON’ 1084 | BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096); \ drivers/net/ethernet/intel/i40e/i40e_main.c:5113:9: note: in expansion of macro ‘kfree_rcu’ 5113 | kfree_rcu(q_vector, rcu); | ^~~~~~~~~ The problem is that the 'rcu' member in 'q_vector' is too far from the start of the structure. Move this member before the CPU mask instead, in all three drivers. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: David S. Miller <davem@davemloft.net> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-15Merge tag 'soc-fixes-6.16-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "There are 18 devicetree fixes for three arm64 plaforms: Qualcomm Snapdragon, Rockchips and NXP i.MX. These get updated to more correctly describe the hardware, fixing issues with: - real-time clock on Snapdragon based laptops - SD card detection, PCI probing and HDMI/DDC communication on Rockchips - ethernet and SPI probing on certain i.MX based boards - a regression with the i.MX watchdog Aside from the devicetree fixes, there are two additional fixes for the merged ASPEED LPC snoop driver that saw some changes in 6.16, and one additional driver enabled in arm64 defconfig to fix CPU frequency scaling" * tag 'soc-fixes-6.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (21 commits) arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always on soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled soc: aspeed: lpc-snoop: Cleanup resources in stack-order arm64: dts: imx95: Correct the DMA interrupter number of pcie0_ep arm64: dts: rockchip: Add missing fan-supply to rk3566-quartz64-a arm64: dts: rockchip: use cs-gpios for spi1 on ringneck arm64: dts: add big-endian property back into watchdog node arm64: dts: imx95-15x15-evk: fix the overshoot issue of NETC arm64: dts: imx95-19x19-evk: fix the overshoot issue of NETC arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5 arm64: dts: imx8mp-venice-gw74xx: fix TPM SPI frequency arm64: dts: imx8mp-venice-gw73xx: fix TPM SPI frequency arm64: dts: imx8mp-venice-gw72xx: fix TPM SPI frequency arm64: dts: imx8mp-venice-gw71xx: fix TPM SPI frequency arm64: dts: qcom: x1e80100: describe uefi rtc offset arm64: dts: qcom: sc8280xp-x13s: describe uefi rtc offset arm64: defconfig: Enable Qualcomm CPUCP mailbox driver arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi 4B arm64: dts: rockchip: Add cd-gpios for sdcard detect on Cool Pi CM5 arm64: dts: rockchip: Adjust the HDMI DDC IO driver strength for rk3588 ...
2025-07-15Merge tag 'hid-for-linus-2025071501' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Benjamin Tissoires: - one warning cleanup introduced in the last PR (Andy Shevchenko) - a nasty syzbot buffer underflow fix co-debugged with Alan Stern (Benjamin Tissoires) * tag 'hid-for-linus-2025071501' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: selftests/hid: add a test case for the recent syzbot underflow HID: core: do not bypass hid_hw_raw_request HID: core: ensure __hid_request reserves the report ID as the first byte HID: core: ensure the allocated report buffer can contain the reserved report ID HID: debug: Remove duplicate entry (BTN_WHEEL)
2025-07-15selftests: net: increase inter-packet timeout in udpgro.shPaolo Abeni
The mentioned test is not very stable when running on top of debug kernel build. Increase the inter-packet timeout to allow more slack in such environments. Fixes: 3327a9c46352 ("selftests: add functionals test for UDP GRO") Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/b0370c06ddb3235debf642c17de0284b2cd3c652.1752163107.git.pabeni@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15PM: sleep: Update power.completion for all devices on errorsRafael J. Wysocki
After commit aa7a9275ab81 ("PM: sleep: Suspend async parents after suspending children"), the following scenario is possible: 1. Device A is async and it depends on device B that is sync. 2. Async suspend is scheduled for A before the processing of B is started. 3. A is waiting for B. 4. In the meantime, an unrelated device fails to suspend and returns an error. 5. The processing of B doesn't start at all and its power.completion is not updated. 6. A is still waiting for B when async_synchronize_full() is called. 7. Deadlock ensues. To prevent this from happening, update power.completion for all devices on errors in all suspend phases, but do not do it directly for devices that are already being processed or are waiting for the processing to start because in those cases it may be necessary to wait for the processing to actually complete before updating power.completion for the device. Fixes: aa7a9275ab81 ("PM: sleep: Suspend async parents after suspending children") Fixes: 443046d1ad66 ("PM: sleep: Make suspend of devices more asynchronous") Closes: https://lore.kernel.org/linux-pm/e13740a0-88f3-4a6f-920f-15805071a7d6@linaro.org/ Reported-and-tested-by: Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://patch.msgid.link/6191258.lOV4Wx5bFT@rjwysocki.net
2025-07-15PM: suspend: clean up redundant filesystems_freeze/thaw() handlingZihuan Zhang
The recently introduced support for freezing filesystems during system suspend included calls to filesystems_freeze() in both suspend_prepare() and enter_state(), as well as calls to filesystems_thaw() in both suspend_finish() and the Unlock path in enter_state(). These are redundant. Moreover, calling filesystems_freeze() twice, from both suspend_prepare() and enter_state(), leads to a black screen and makes the system unable to resume in some cases. Address this as follows: - filesystems_freeze() is already called in suspend_prepare(), which is the proper and consistent place to handle pre-suspend operations. The second call in enter_state() is unnecessary and so remove it. - filesystems_thaw() is invoked in suspend_finish(), which covers successful suspend/resume paths. In the failure case, add a call to filesystems_thaw() only when needed, avoiding the duplicate call in the general Unlock path. This change simplifies the suspend code and avoids repeated freeze/thaw calls, while preserving correct ordering and behavior. Fixes: eacfbf74196f ("power: freeze filesystems during suspend/resume") Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Link: https://patch.msgid.link/20250712030824.81474-1-zhangzihuan@kylinos.cn [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-15PM: suspend: Drop a misplaced pm_restore_gfp_mask() callRafael J. Wysocki
The pm_restore_gfp_mask() call added by commit 12ffc3b1513e ("PM: Restrict swap use to later in the suspend sequence") to suspend_devices_and_enter() is done too early because it takes place before calling dpm_resume() in dpm_resume_end() and some swap-backing devices may not be ready at that point. Moreover, dpm_resume_end() called subsequently in the same code path invokes pm_restore_gfp_mask() again and calling it twice in a row is pointless. Drop the misplaced pm_restore_gfp_mask() call from suspend_devices_and_enter() to address this issue. Fixes: 12ffc3b1513e ("PM: Restrict swap use to later in the suspend sequence") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/2810409.mvXUDI8C0e@rjwysocki.net [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-15Merge tag 'iwlwifi-next-2025-07-15' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== iwlwifi features, notably - cleanup of unsupported APIs - add a API range per RF - transport layer cleanups - a few small fixes ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15Merge tag 'iwlwifi-fixes-2025-07-15' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== iwlwifi-fixes - missing unlock in error path - Avoid FW assert on bad command values - fix kernel panic due to incorrect index calculation ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15Merge branch 'net-mctp-improved-bind-handling'Paolo Abeni
Matt Johnston says: ==================== net: mctp: Improved bind handling This series improves a couple of aspects of MCTP bind() handling. MCTP wasn't checking whether the same MCTP type was bound by multiple sockets. That would result in messages being received by an arbitrary socket, which isn't useful behaviour. Instead it makes more sense to have the duplicate binds fail, the same as other network protocols. An exception is made for more-specific binds to particular MCTP addresses. It is also useful to be able to limit a bind to only receive incoming request messages (MCTP TO bit set) from a specific peer+type, so that individual processes can communicate with separate MCTP peers. One example is a PLDM firmware update requester, which will initiate communication with a device, and then the device will connect back to the requester process. These limited binds are implemented by a connect() call on the socket prior to bind. connect() isn't used in the general case for MCTP, since a plain send() wouldn't provide the required MCTP tag argument for addressing. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> ==================== Link: https://patch.msgid.link/20250710-mctp-bind-v4-0-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Add bind lookup testMatt Johnston
Test the preference order of bound socket matches with a series of test packets. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-8-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Test conflicts of connect() with bind()Matt Johnston
The addition of connect() adds new conflict cases to test. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-7-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Allow limiting binds to a peer addressMatt Johnston
Prior to calling bind() a program may call connect() on a socket to restrict to a remote peer address. Using connect() is the normal mechanism to specify a remote network peer, so we use that here. In MCTP connect() is only used for bound sockets - send() is not available for MCTP since a tag must be provided for each message. The smctp_type must match between connect() and bind() calls. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-6-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Use hashtable for bindsMatt Johnston
Ensure that a specific EID (remote or local) bind will match in preference to a MCTP_ADDR_ANY bind. This adds infrastructure for binding a socket to receive messages from a specific remote peer address, a future commit will expose an API for this. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-5-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Add test for conflicting bind()sMatt Johnston
Test pairwise combinations of bind addresses and types. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-4-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Treat MCTP_NET_ANY specially in bind()Matt Johnston
When a specific EID is passed as a bind address, it only makes sense to interpret with an actual network ID, so resolve that to the default network at bind time. For bind address of MCTP_ADDR_ANY, we want to be able to capture traffic to any network and address, so keep the current behaviour of matching traffic from any network interface (don't interpret MCTP_NET_ANY as the default network ID). Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-3-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Prevent duplicate bindsMatt Johnston
Disallow bind() calls that have the same arguments as existing bound sockets. Previously multiple sockets could bind() to the same type/local address, with an arbitrary socket receiving matched messages. This is only a partial fix, a future commit will define precedence order for MCTP_ADDR_ANY versus specific EID bind(), which are allowed to exist together. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-2-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: mctp_test_route_extaddr_input cleanupMatt Johnston
The sock was not being released. Other than leaking, the stale socket will conflict with subsequent bind() calls in unrelated MCTP tests. Fixes: 46ee16462fed ("net: mctp: test: Add extaddr routing output test") Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-1-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15can: tcan4x5x: fix reset gpio usage during probeBrett Werling
Fixes reset GPIO usage during probe by ensuring we retrieve the GPIO and take the device out of reset (if it defaults to being in reset) before we attempt to communicate with the device. This is achieved by moving the call to tcan4x5x_get_gpios() before tcan4x5x_find_version() and avoiding any device communication while getting the GPIOs. Once we determine the version, we can then take the knowledge of which GPIOs we obtained and use it to decide whether we need to disable the wake or state pin functions within the device. This change is necessary in a situation where the reset GPIO is pulled high externally before the CPU takes control of it, meaning we need to explicitly bring the device out of reset before we can start communicating with it at all. This also has the effect of fixing an issue where a reset of the device would occur after having called tcan4x5x_disable_wake(), making the original behavior not actually disable the wake. This patch should now disable wake or state pin functions well after the reset occurs. Signed-off-by: Brett Werling <brett.werling@garmin.com> Link: https://patch.msgid.link/20250711141728.1826073-1-brett.werling@garmin.com Cc: Markus Schneider-Pargmann <msp@baylibre.com> Fixes: 142c6dc6d9d7 ("can: tcan4x5x: Add support for tcan4552/4553") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-15wifi: iwlwifi: Fix botched indexing conversionVille Syrjälä
The conversion from compiler assisted indexing to manual indexing wasn't done correctly. The array is still made up of __le16 elements so multiplying the outer index by the element size is not what we want. Fix it up. This causes the kernel to oops when trying to transfer any significant amount of data over wifi: BUG: unable to handle page fault for address: ffffc900009f5282 PGD 100000067 P4D 100000067 PUD 1000fb067 PMD 102e82067 PTE 0 Oops: Oops: 0002 [#1] SMP CPU: 1 UID: 0 PID: 99 Comm: kworker/u8:3 Not tainted 6.15.0-rc2-cl-bisect3-00604-g6204d5130a64-dirty #78 PREEMPT Hardware name: Dell Inc. Latitude E5400 /0D695C, BIOS A19 06/13/2013 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] RIP: 0010:iwl_trans_pcie_tx+0x4dd/0xe60 [iwlwifi] Code: 00 00 66 81 fa ff 0f 0f 87 42 09 00 00 3d ff 00 00 00 0f 8f 37 09 00 00 41 c1 e0 0c 41 09 d0 48 8d 14 b6 48 c1 e2 07 48 01 ca <66> 44 89 04 57 48 8d 0c 12 83 f8 3f 0f 8e 84 01 00 00 41 8b 85 80 RSP: 0018:ffffc900001c3b50 EFLAGS: 00010206 RAX: 00000000000000c1 RBX: ffff88810b180028 RCX: 00000000000000c1 RDX: 0000000000002141 RSI: 000000000000000d RDI: ffffc900009f1000 RBP: 0000000000000002 R08: 0000000000000025 R09: ffffffffa050fa60 R10: 00000000fbdbf4bc R11: 0000000000000082 R12: ffff88810e5ade40 R13: ffff88810af81588 R14: 000000000000001a R15: ffff888100dfe0c8 FS: 0000000000000000(0000) GS:ffff8881998c3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900009f5282 CR3: 0000000001e39000 CR4: 00000000000426f0 Call Trace: <TASK> ? rcu_is_watching+0xd/0x40 ? __iwl_dbg+0xb1/0xe0 [iwlwifi] iwlagn_tx_skb+0x8e2/0xcb0 [iwldvm] iwlagn_mac_tx+0x18/0x30 [iwldvm] ieee80211_handle_wake_tx_queue+0x6c/0xc0 [mac80211] ieee80211_agg_start_txq+0x140/0x2e0 [mac80211] ieee80211_agg_tx_operational+0x126/0x210 [mac80211] ieee80211_process_addba_resp+0x27b/0x2a0 [mac80211] ieee80211_iface_work+0x4bd/0x4d0 [mac80211] ? _raw_spin_unlock_irq+0x1f/0x40 cfg80211_wiphy_work+0x117/0x1f0 [cfg80211] process_one_work+0x1ee/0x570 worker_thread+0x1c5/0x3b0 ? bh_worker+0x240/0x240 kthread+0x110/0x220 ? kthread_queue_delayed_work+0x90/0x90 ret_from_fork+0x28/0x40 ? kthread_queue_delayed_work+0x90/0x90 ret_from_fork_asm+0x11/0x20 </TASK> Modules linked in: ctr aes_generic ccm sch_fq_codel bnep xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables btusb btrtl btintel btbcm bluetooth ecdh_generic ecc libaes hid_generic usbhid hid binfmt_misc joydev mousedev snd_hda_codec_hdmi iwldvm snd_hda_codec_idt snd_hda_codec_generic mac80211 coretemp iTCO_wdt watchdog kvm_intel i2c_dev snd_hda_intel libarc4 kvm snd_intel_dspcfg sdhci_pci sdhci_uhs2 snd_hda_codec iwlwifi sdhci irqbypass cqhci snd_hwdep snd_hda_core cfg80211 firewire_ohci mmc_core psmouse snd_pcm i2c_i801 firewire_core pcspkr led_class uhci_hcd i2c_smbus tg3 crc_itu_t iosf_mbi snd_timer rfkill libphy ehci_pci snd ehci_hcd lpc_ich mfd_core usbcore video intel_agp usb_common soundcore intel_gtt evdev agpgart parport_pc wmi parport backlight CR2: ffffc900009f5282 ---[ end trace 0000000000000000 ]--- RIP: 0010:iwl_trans_pcie_tx+0x4dd/0xe60 [iwlwifi] Code: 00 00 66 81 fa ff 0f 0f 87 42 09 00 00 3d ff 00 00 00 0f 8f 37 09 00 00 41 c1 e0 0c 41 09 d0 48 8d 14 b6 48 c1 e2 07 48 01 ca <66> 44 89 04 57 48 8d 0c 12 83 f8 3f 0f 8e 84 01 00 00 41 8b 85 80 RSP: 0018:ffffc900001c3b50 EFLAGS: 00010206 RAX: 00000000000000c1 RBX: ffff88810b180028 RCX: 00000000000000c1 RDX: 0000000000002141 RSI: 000000000000000d RDI: ffffc900009f1000 RBP: 0000000000000002 R08: 0000000000000025 R09: ffffffffa050fa60 R10: 00000000fbdbf4bc R11: 0000000000000082 R12: ffff88810e5ade40 R13: ffff88810af81588 R14: 000000000000001a R15: ffff888100dfe0c8 FS: 0000000000000000(0000) GS:ffff8881998c3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900009f5282 CR3: 0000000001e39000 CR4: 00000000000426f0 Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: disabled ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- Cc: Miri Korenblit <miriam.rachel.korenblit@intel.com> Fixes: 6204d5130a64 ("wifi: iwlwifi: use bc entries instead of bc table also for pre-ax210") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20250711205744.28723-1-ville.syrjala@linux.intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-07-15wifi: cfg80211: fix double free for link_sinfo in nl80211_station_dump()Sarika Sharma
Currently, the link_sinfo structure is being freed twice in nl80211_dump_station(), once after the send_station() call and again in the error handling path. This results in a double free of both link_sinfo and link_sinfo->pertid, which might lead to undefined behavior or kernel crashes. Hence, fix by ensuring cfg80211_sinfo_release_content() is only invoked once during execution of nl80211_station_dump(). Fixes: 49e47223ecc4 ("wifi: cfg80211: allocate memory for link_station info structure") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/81f30515-a83d-4b05-a9d1-e349969df9e9@sabinyo.mountain/ Reported-by: syzbot+4ba6272678aa468132c8@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68655325.a70a0220.5d25f.0316.GAE@google.com Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Link: https://patch.msgid.link/20250714084405.178066-1-quic_sarishar@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: cfg80211: fix off channel operation allowed check for MLOAditya Kumar Singh
In cfg80211_off_channel_oper_allowed(), the current logic disallows off-channel operations if any link operates on a radar channel, assuming such channels cannot be vacated. This assumption holds for non-MLO interfaces but not for MLO. With MLO and multi-radio devices, different links may operate on separate radios. This allows one link to scan off-channel while another remains on a radar channel. For example, in a 5 GHz split-phy setup, the lower band can scan while the upper band stays on a radar channel. Off-channel operations can be allowed if the radio/link onto which the input channel falls is different from the radio/link which has an active radar channel. Therefore, fix cfg80211_off_channel_oper_allowed() by returning false only if the requested channel maps to the same radio as an active radar channel. Allow off-channel operations when the requested channel is on a different radio, as in MLO with multi-radio setups. Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Signed-off-by: Amith A <quic_amitajit@quicinc.com> Link: https://patch.msgid.link/20250714040742.538550-1-quic_amitajit@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: use RCU-safe iteration in ieee80211_csa_finishMaharaja Kennadyrajan
The ieee80211_csa_finish() function currently uses for_each_sdata_link() to iterate over links of sdata. However, this macro internally uses wiphy_dereference(), which expects the wiphy->mtx lock to be held. When ieee80211_csa_finish() is invoked under an RCU read-side critical section (e.g., under rcu_read_lock()), this leads to a warning from the RCU debugging framework. WARNING: suspicious RCU usage net/mac80211/cfg.c:3830 suspicious rcu_dereference_protected() usage! This warning is triggered because wiphy_dereference() is not safe to use without holding the wiphy mutex, and it is being used in an RCU context without the required locking. Fix this by introducing and using a new macro, for_each_sdata_link_rcu(), which performs RCU-safe iteration over sdata links using list_for_each_entry_rcu() and rcu_dereference(). This ensures that the link pointers are accessed safely under RCU and eliminates the warning. Fixes: f600832794c9 ("wifi: mac80211: restructure tx profile retrieval for MLO MBSSID") Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250711033846.40455-1-maharaja.kennadyrajan@oss.qualcomm.com [unindent like the non-RCU macro] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15ipv6: mcast: Avoid a duplicate pointer check in mld_del_delrec()Yue Haibing
Avoid duplicate non-null pointer check for pmc in mld_del_delrec(). No functional changes. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250714081949.3109947-1-yuehaibing@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15wifi: mac80211_hwsim: Update comments in headerAlex Gavin
- Reorders 'HWSIM_ATTR_PAD' to after 'HWSIM_ATTR_FREQ', matching order in 'enum hwsim_attrs' - Change references from old commands to new names - Fixes typos Signed-off-by: Alex Gavin <alex.gavin@candelatech.com> Link: https://patch.msgid.link/20250710211437.8516-1-alex.gavin@candelatech.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: parse unsolicited broadcast probe response dataYuvarani V
During commands like channel switch and color change, the updated unsolicited broadcast probe response template may be provided. However, this data is not parsed or acted upon in mac80211. Add support to parse it and set the BSS changed flag BSS_CHANGED_UNSOL_BCAST_PROBE_RESP so that drivers could take further action. Signed-off-by: Yuvarani V <quic_yuvarani@quicinc.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250710-update_unsol_bcast_probe_resp-v2-2-31aca39d3b30@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: cfg80211: parse attribute to update unsolicited probe response templateYuvarani V
At present, the updated unsolicited broadcast probe response template is not processed during userspace commands such as channel switch or color change. This leads to an issue where older incorrect unsolicited probe response is still used during these events. Add support to parse the netlink attribute and store it so that mac80211/drivers can use it to set the BSS_CHANGED_UNSOL_BCAST_PROBE_RESP flag in order to send the updated unsolicited broadcast probe response templates during these events. Signed-off-by: Yuvarani V <quic_yuvarani@quicinc.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250710-update_unsol_bcast_probe_resp-v2-1-31aca39d3b30@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: don't use TPE data from assoc responseJohannes Berg
Since there's no TPE element in the (re)assoc response, trying to use the data from it just leads to using the defaults, even though the real values had been set during authentication from the discovered BSS information. Fix this by simply not handling the TPE data in assoc response since it's not intended to be present, if it changes later the necessary changes will be made by tracking beacons later. As a side effect, by passing the real frame subtype, now print a correct value for ML reconfiguration responses. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.caa1ca853f5a.I588271f386731978163aa9d84ae75d6f79633e16@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: handle WLAN_HT_ACTION_NOTIFY_CHANWIDTH asyncMiri Korenblit
If this action frame, with the value of IEEE80211_HT_CHANWIDTH_ANY, arrives right after a beacon that changed the operational bandwidth from 20 MHz to 40 MHz, then updating the rate control bandwidth to 40 can race with updating the chanctx width (that happens in the beacon proccesing) back to 40 MHz: cpu0 cpu1 ieee80211_rx_mgmt_beacon ieee80211_config_bw ieee80211_link_change_chanreq (*)ieee80211_link_update_chanreq ieee80211_rx_h_action (**)ieee80211_sta_cur_vht_bw (***) ieee80211_recalc_chanctx_chantype in (**), the maximum between the capability width and the bss width is returned. But the bss width was just updated to 40 in (*), so the action frame handling code will increase the width of the rate control before the chanctx was increased (in ***), leading to a FW error (at least in iwlwifi driver. But this is wrong regardless). Fix this by simply handling the action frame async, so it won't race with the beacon proccessing. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218632 Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.bb9dc6f36c35.I39782d6077424e075974c3bee4277761494a1527@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: simplify __ieee80211_rx_h_amsdu() loopJohannes Berg
The loop handling individual subframes can be simplified to not use a somewhat confusing goto inside the loop. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.a217a1e8c667.I5283df9627912c06c8327b5786d6b715c6f3a4e1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: don't mark keys for inactive links as uploadedMiri Korenblit
During resume, the driver can call ieee80211_add_gtk_rekey for keys that are not programmed into the device, e.g. keys of inactive links. Don't mark such a key as uploaded to avoid removing it later from the driver/device. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.655094412b0b.Iacae31af3ba2a705da0a9baea976c2f799d65dc4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: only assign chanctx in reconfigMiri Korenblit
At the end of reconfig we are activating all the links that were active before the error. During the activation, _ieee80211_link_use_channel will unassign and re-assign the chanctx from/to the link. But we only need to do the assign, as we are re-building the state as it was before the reconfig. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.6245c3ae7031.Ia5f68992c7c112bea8a426c9339f50c88be3a9ca@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211_hwsim: Declare support for AP scanningIlan Peer
To support testing scenarios. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.6916e0a49955.I48e374ad7e3ea5877a5e93e5c5fe8301465771c8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: clean up cipher suite handlingJohannes Berg
Under the previous commit's assumption that FIPS isn't supported by hardware, we don't need to modify the cipher suite list, but just need to use the software one instead of the driver's in this case, so clean up the code. Also fix it to exclude TKIP in this case, since that's also dependent on RC4. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.cff427e8f8a5.I744d1ea6a37e3ea55ae8bc3e770acee734eff268@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit (git 2.34.1) at 2025-09-11 16:01:09 +0000