summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-09-03mptcp: pm: reduce entries iterations on connectMatthieu Baerts (NGI0)
__mptcp_subflow_connect() is currently called from the path-managers, which have all the required information to create subflows. No need to call the PM again to re-iterate over the list of entries with RCU lock to get more info. Instead, it is possible to pass a mptcp_pm_addr_entry structure, instead of a mptcp_addr_info one. The former contains the ifindex and the flags that are required when creating the new subflow. This is a partial revert of commit ee285257a9c1 ("mptcp: drop flags and ifindex arguments"). While at it, the local ID can also be set if it is known and 0, to avoid having to set it in the 'rebuild_header' hook, which will cause a new iteration of the endpoint entries. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20240902-net-next-mptcp-mib-mpjtx-misc-v1-2-d3e0f3773b90@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03mptcp: pm: rename helpers linked to 'flush'Matthieu Baerts (NGI0)
Rename all the helpers specific to the flushing operations to make it clear that the intention is to flush all created subflows, and remove all announced addresses, not just a specific selection. That way, it is easier to understand why the id_avail_bitmap and local_addr_used are reset at the end. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20240902-net-next-mptcp-mib-mpjtx-misc-v1-1-d3e0f3773b90@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03Merge branch 'rx-software-timestamp-for-all'Jakub Kicinski
Gal Pressman says: ==================== RX software timestamp for all All devices support SOF_TIMESTAMPING_RX_SOFTWARE by virtue of net_timestamp_check() being called in the device independent code. Following Willem's suggestion [1], make it so drivers do not have to handle SOF_TIMESTAMPING_RX_SOFTWARE and SOF_TIMESTAMPING_SOFTWARE, nor setting of the PHC index to -1. All drivers will now report RX software timestamp as supported. The series is limited to 15 patches, I will submit other drivers in subsequent submissions. [1] https://lore.kernel.org/netdev/661550e348224_23a2b2294f7@willemb.c.googlers.com.notmuch/ v1: https://lore.kernel.org/20240829144253.122215-1-gal@nvidia.com ==================== Link: https://patch.msgid.link/20240901112803.212753-1-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03net: mvpp2: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Marcin Wojtas <marcin.s.wojtas@gmail.com> Link: https://patch.msgid.link/20240901112803.212753-16-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03octeontx2-pf: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com> Link: https://patch.msgid.link/20240901112803.212753-15-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03gianfar: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Link: https://patch.msgid.link/20240901112803.212753-14-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03net: enetc: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20240901112803.212753-13-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03net: fec: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20240901112803.212753-12-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03net: hns3: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20240901112803.212753-11-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03net: ethernet: rtsn: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20240901112803.212753-10-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03net: renesas: rswitch: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20240901112803.212753-9-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03ravb: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://patch.msgid.link/20240901112803.212753-8-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03ionic: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20240901112803.212753-7-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03tsnep: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Gerhard Engleder <gerhard@engleder-embedded.com> Link: https://patch.msgid.link/20240901112803.212753-6-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03can: peak_usb: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://patch.msgid.link/20240901112803.212753-5-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03can: peak_canfd: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://patch.msgid.link/20240901112803.212753-4-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03can: dev: Remove setting of RX software timestampGal Pressman
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://patch.msgid.link/20240901112803.212753-3-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03ethtool: RX software timestamp for allGal Pressman
All devices support SOF_TIMESTAMPING_RX_SOFTWARE by virtue of net_timestamp_check() being called in the device independent code. Move the responsibility of reporting SOF_TIMESTAMPING_RX_SOFTWARE and SOF_TIMESTAMPING_SOFTWARE, and setting PHC index to -1 to the core. Device drivers no longer need to use them. Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Link: https://lore.kernel.org/netdev/661550e348224_23a2b2294f7@willemb.c.googlers.com.notmuch/ Co-developed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Marc Kleine-Budde <mkl@pengutronix.de> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20240901112803.212753-2-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03PCI/pwrctl: Rescan bus on a separate threadBartosz Golaszewski
If we trigger the bus rescan from sysfs, we'll try to lock the PCI rescan mutex recursively and deadlock - the platform device will be populated and probed on the same thread that handles the sysfs write. Add a workqueue to the pwrctl code on which we schedule the rescan for controlled PCI devices. While at it: add a new interface for initializing the pwrctl context where we'd now assign the parent device address and initialize the workqueue. Link: https://lore.kernel.org/r/20240823093323.33450-3-brgl@bgdev.pl Fixes: 4565d2652a37 ("PCI/pwrctl: Add PCI power control core code") Reported-by: Konrad Dybcio <konradybcio@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-09-03PCI: Don't rely on of_platform_depopulate() for reused OF-nodesBartosz Golaszewski
of_platform_depopulate() doesn't play nicely with reused OF nodes - it ignores the ones that are not marked explicitly as populated and it may happen that the PCI device goes away before the platform device in which case the PCI core clears the OF_POPULATED bit. Unconditionally unregister the platform devices for child nodes when stopping the PCI device. Link: https://lore.kernel.org/r/20240823093323.33450-2-brgl@bgdev.pl Fixes: 8fb18619d910 ("PCI/pwrctl: Create platform devices for child OF nodes of the port node") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-09-03EDAC/sb_edac: Fix the compile warning of large frame sizeQiuxu Zhuo
Compiling sb_edac driver with GCC 11.4.0 and the W=1 option reported the following warning: drivers/edac/sb_edac.c: In function ‘sbridge_mce_output_error’: drivers/edac/sb_edac.c:3249:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=] As there is no concurrent invocation of sbridge_mce_output_error(), fix this warning by moving the large-size variables 'msg' and 'msg_full' from the stack to the pre-allocated data segment. [Tony: Fix checkpatch warnings for code alignment & use of strcpy()] Reported-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/all/20240829120903.84152-1-qiuxu.zhuo@intel.com
2024-09-04dt-bindings: arm: rockchip: Add rk3576 compatible string to pmu.yamlDetlev Casanova
Add the compatible for the pmu mfd on rk3576. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240903152308.13565-3-detlev.casanova@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-09-03MAINTAINERS: update Andreas Hindborg's email addressAndreas Hindborg
Move away from corporate infrastructure for upstream work. Also update mailmap. Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20240903200956.68231-1-a.hindborg@kernel.org [ Reworded title slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-09-03spi: mxs: Switch to RUNTIME/SYSTEM_SLEEP_PM_OPS()Fabio Estevam
Replace SET_RUNTIME_PM_OPS()/SET SYSTEM_SLEEP_PM_OPS() with their modern RUNTIME_PM_OPS() and SYSTEM_SLEEP_PM_OPS() alternatives. The combined usage of pm_ptr() and RUNTIME_PM_OPS/SYSTEM_SLEEP_PM_OPS() allows the compiler to evaluate if the runtime suspend/resume() functions are used at build time or are simply dead code. This allows removing the __maybe_unused annotations from the suspend/resume() functions. Signed-off-by: Fabio Estevam <festevam@denx.de> Link: https://patch.msgid.link/20240902184655.932699-1-festevam@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-03audit: Make use of str_enabled_disabled() helperHongbo Li
Use str_enabled_disabled() helper instead of open coding the same. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-09-03ASoC: loongson: fix error releasetangbin
In function loongson_card_parse_of(), when get device_node 'codec' failed, the function of_node_put(codec) should not be invoked, thus fix error release. Fixes: d24028606e76 ("ASoC: loongson: Add Loongson ASoC Sound Card Support") Signed-off-by: tangbin <tangbin@cmss.chinamobile.com> Link: https://patch.msgid.link/20240903090620.6276-1-tangbin@cmss.chinamobile.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-03ASoC: tlv320aic32x4: Add multi endpoint supportMarek Vasut
Support multiple endpoints on TLV320AIC32x4 codec port when used in of_graph context. This patch allows to share the codec port between two CPU DAIs. Example: Custom STM32MP157C board uses TLV320AIC32x4 audio codec. This codec is connected to two serial audio interfaces, which are configured either as rx or tx. >From AsoC point of view the topolgy is the following: // 2 CPU DAIs (SAI2A/B), 1 Codec (TLV320AIC32x4) Playback: CPU-A-DAI(slave) -> (master)CODEC-DAI/port0 Record: CPU-B-DAI(slave) <- (master)CODEC-DAI/port0 In the DT two endpoints have to be associated to the codec port: tlv320aic32x4_port: port { tlv320aic32x4_tx_endpoint: endpoint@0 { remote-endpoint = <&sai2a_endpoint>; }; tlv320aic32x4_rx_endpoint: endpoint@1 { remote-endpoint = <&sai2b_endpoint>; }; }; However, when the audio graph card parses the codec nodes, it expects to find DAI interface indexes matching the endpoints indexes. The current patch forces the use of DAI id 0 for both endpoints, which allows to share the codec DAI between the two CPU DAIs for playback and capture streams respectively. Signed-off-by: Marek Vasut <marex@denx.de> Link: https://patch.msgid.link/20240830231007.205707-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-03ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the errorMa Ke
Return devm_of_clk_add_hw_provider() in order to transfer the error, if it fails due to resource allocation failure or device tree clock provider registration failure. Cc: stable@vger.kernel.org Fixes: ebbfabc16d23 ("ASoC: rt5682: Add CCF usage for providing I2S clks") Signed-off-by: Ma Ke <make24@iscas.ac.cn> Link: https://patch.msgid.link/20240830143154.3448004-1-make24@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-03clk: qcom: gcc-sc8280xp: don't use parking clk_ops for QUPsJohan Hovold
A recent change started parking the RCG at an always on parent during registration, something which specifically breaks handover from an early serial console. Quoting Stephen Boyd who fixed this issue for SM8550 [1]: The QUPs aren't shared in a way that requires parking the RCG at an always on parent in case some other entity turns on the clk. The hardware is capable of setting a new frequency itself with the DFS mode, so parking is unnecessary. Furthermore, there aren't any GDSCs for these devices, so there isn't a possibility of the GDSC turning on the clks for housekeeping purposes. This wasn't a problem to mark these clks shared until we started parking shared RCGs at clk registration time in commit 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration"). Parking at init is actually harmful to the UART when earlycon is used. If the device is pumping out data while the frequency changes you'll see garbage on the serial console until the driver can probe and actually set a proper frequency. Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") Fixes: d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver") Link: https://lore.kernel.org/all/20240819233628.2074654-2-swboyd@chromium.org/ [1] Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240902070830.8535-1-johan+linaro@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2024-09-03Merge branch '1GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2024-08-30 (igc, e1000e, i40e) This series contains updates to igc, e1000e, and i40 drivers. Kurt Kanzenbach adds support for MQPRIO offloads and stops unintended, excess interrupts on igc. Sasha adds reporting of EEE (Energy Efficient Ethernet) ability and moves a register define to a better suited file for igc. Vitaly stops reporting errors on shutdown and suspend as they are not fatal for e1000e. Alex adds reporting of EEE to i40e. * '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: i40e: Add Energy Efficient Ethernet ability for X710 Base-T/KR/KX cards e1000e: avoid failing the system during pm_suspend igc: Move the MULTI GBT AN Control Register to _regs file igc: Add Energy Efficient Ethernet ability igc: Get rid of spurious interrupts igc: Add MQPRIO offload support ==================== Link: https://patch.msgid.link/20240830210451.2375215-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03EDAC/{skx_common,i10nm}: Remove the AMAP register for determing DDR5Qiuxu Zhuo
The configuration flag 'res_config->support_ddr5 = true' sufficiently indicates DDR5 memory support for Sapphire Rapids and Granite Rapids. Additionally, the i10nm_edac driver doesn't need to use the AMAP register for setting the 'fine_grain_bank' of each DIMM. Therefore, remove the AMAP register for determining DDR5. Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/all/20240829061309.57738-1-qiuxu.zhuo@intel.com
2024-09-03EDAC/{skx_common,skx,i10nm}: Move the common debug code to skx_commonQiuxu Zhuo
Commit afdb82fd763c ("EDAC, i10nm: make skx_common.o a separate module") made skx_common.o a separate module. With skx_common.o now a separate module, move the common debug code setup_{skx,i10nm}_debug() and teardown_{skx,i10nm}_debug() in {skx,i10nm}_base.c to skx_common.c to reduce code duplication. Additionally, prefix these function names with 'skx' to maintain consistency with other names in the file. Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/all/20240829055101.56245-1-qiuxu.zhuo@intel.com
2024-09-03Merge tag 'fuse-fixes-6.11-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse Pull fuse fixes from Miklos Szeredi: - Fix EIO if splice and page stealing are enabled on the fuse device - Disable problematic combination of passthrough and writeback-cache - Other bug fixes found by code review * tag 'fuse-fixes-6.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse: fuse: disable the combination of passthrough and writeback cache fuse: update stats for pages in dropped aux writeback list fuse: clear PG_uptodate when using a stolen page fuse: fix memory leak in fuse_create_open fuse: check aborted connection before adding requests to pending list for resending fuse: use unsigned type for getxattr/listxattr size truncation
2024-09-03EDAC/igen6: Fix conversion of system address to physical memory addressQiuxu Zhuo
The conversion of system address to physical memory address (as viewed by the memory controller) by igen6_edac is incorrect when the system address is above the TOM (Total amount Of populated physical Memory) for Elkhart Lake and Ice Lake (Neural Network Processor). Fix this conversion. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/stable/20240814061011.43545-1-qiuxu.zhuo%40intel.com
2024-09-03bpf, net: Fix a potential race in do_sock_getsockopt()Tze-nan Wu
There's a potential race when `cgroup_bpf_enabled(CGROUP_GETSOCKOPT)` is false during the execution of `BPF_CGROUP_GETSOCKOPT_MAX_OPTLEN`, but becomes true when `BPF_CGROUP_RUN_PROG_GETSOCKOPT` is called. This inconsistency can lead to `BPF_CGROUP_RUN_PROG_GETSOCKOPT` receiving an "-EFAULT" from `__cgroup_bpf_run_filter_getsockopt(max_optlen=0)`. Scenario shown as below: `process A` `process B` ----------- ------------ BPF_CGROUP_GETSOCKOPT_MAX_OPTLEN enable CGROUP_GETSOCKOPT BPF_CGROUP_RUN_PROG_GETSOCKOPT (-EFAULT) To resolve this, remove the `BPF_CGROUP_GETSOCKOPT_MAX_OPTLEN` macro and directly uses `copy_from_sockptr` to ensure that `max_optlen` is always set before `BPF_CGROUP_RUN_PROG_GETSOCKOPT` is invoked. Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks") Co-developed-by: Yanghui Li <yanghui.li@mediatek.com> Signed-off-by: Yanghui Li <yanghui.li@mediatek.com> Co-developed-by: Cheng-Jui Wang <cheng-jui.wang@mediatek.com> Signed-off-by: Cheng-Jui Wang <cheng-jui.wang@mediatek.com> Signed-off-by: Tze-nan Wu <Tze-nan.Wu@mediatek.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Acked-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20240830082518.23243-1-Tze-nan.Wu@mediatek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03net: dqs: Do not use extern for unused dql_groupBreno Leitao
When CONFIG_DQL is not enabled, dql_group should be treated as a dead declaration. However, its current extern declaration assumes the linker will ignore it, which is generally true across most compiler and architecture combinations. But in certain cases, the linker still attempts to resolve the extern struct, even when the associated code is dead, resulting in a linking error. For instance the following error in loongarch64: >> loongarch64-linux-ld: net-sysfs.c:(.text+0x589c): undefined reference to `dql_group' Modify the declaration of the dead object to be an empty declaration instead of an extern. This change will prevent the linker from attempting to resolve an undefined reference. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202409012047.eCaOdfQJ-lkp@intel.com/ Fixes: 74293ea1c4db ("net: sysfs: Do not create sysfs for non BQL device") Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Simon Horman <horms@kernel.org> # build-tested Link: https://patch.msgid.link/20240902101734.3260455-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03Merge tag 'ieee802154-for-net-2024-09-01' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan Stefan Schmidt says: ==================== pull-request: ieee802154 for net 2024-09-01 Simon Horman catched two typos in our headers. No functional change. * tag 'ieee802154-for-net-2024-09-01' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan: ieee802154: Correct spelling in nl802154.h mac802154: Correct spelling in mac802154.h ==================== Link: https://patch.msgid.link/20240901184213.2303047-1-stefan@datenfreihafen.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03sch/netem: fix use after free in netem_dequeueStephen Hemminger
If netem_dequeue() enqueues packet to inner qdisc and that qdisc returns __NET_XMIT_STOLEN. The packet is dropped but qdisc_tree_reduce_backlog() is not called to update the parent's q.qlen, leading to the similar use-after-free as Commit e04991a48dbaf382 ("netem: fix return value if duplicate enqueue fails") Commands to trigger KASAN UaF: ip link add type dummy ip link set lo up ip link set dummy0 up tc qdisc add dev lo parent root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2: handle 3: drr tc filter add dev lo parent 3: basic classid 3:1 action mirred egress redirect dev dummy0 tc class add dev lo classid 3:1 drr ping -c1 -W0.01 localhost # Trigger bug tc class del dev lo classid 1:1 tc class add dev lo classid 1:1 drr ping -c1 -W0.01 localhost # UaF Fixes: 50612537e9ab ("netem: fix classful handling") Reported-by: Budimir Markovic <markovicbudimir@gmail.com> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Link: https://patch.msgid.link/20240901182438.4992-1-stephen@networkplumber.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03ioam6: improve checks on user dataJustin Iurman
This patch improves two checks on user data. The first one prevents bit 23 from being set, as specified by RFC 9197 (Sec 4.4.1): Bit 23 Reserved; MUST be set to zero upon transmission and be ignored upon receipt. This bit is reserved to allow for future extensions of the IOAM Trace-Type bit field. The second one checks that the tunnel destination address != IPV6_ADDR_ANY, just like we already do for the tunnel source address. Signed-off-by: Justin Iurman <justin.iurman@uliege.be> Link: https://patch.msgid.link/20240830191919.51439-1-justin.iurman@uliege.be Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03usbnet: modern method to get random MACOliver Neukum
The driver generates a random MAC once on load and uses it over and over, including on two devices needing a random MAC at the same time. Jakub suggested revamping the driver to the modern API for setting a random MAC rather than fixing the old stuff. The bug is as old as the driver. Signed-off-by: Oliver Neukum <oneukum@suse.com> Reviewed-by: Simon Horman <horms@kernel.org> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://patch.msgid.link/20240829175201.670718-1-oneukum@suse.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-03MAINTAINERS: wifi: cw1200: add net-cw1200.hSimon Horman
This is part of an effort [1] to assign a section in MAINTAINERS to header files that relate to Networking. In this case the files with "net" in their name. [1] https://lore.kernel.org/netdev/20240821-net-mnt-v2-0-59a5af38e69d@kernel.org/ It seems that net-cw1200.h is part of the CW1200 WLAN driver and this it is appropriate to add it to the section for that driver. Signed-off-by: Simon Horman <horms@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240902-wifi-mnt-v2-1-f5ad1f36e993@kernel.org
2024-09-03wifi: mwifiex: Convert to use jiffies macroChen Yufan
Use time_after macro instead of using jiffies directly to handle wraparound. Change the type to to unsigned long to avoid unnecessary casts. Signed-off-by: Chen Yufan <chenyufan@vivo.com> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240823070320.430753-1-chenyufan@vivo.com
2024-09-03wifi: wilc1000: Re-enable RTC clock on resumeMarek Vasut
The wilc_sdio_suspend() does clk_disable_unprepare() on rtc_clk clock, make sure wilc_sdio_resume() does matching clk_prepare_enable(), else any suspend/resume cycle leads to clock disable/enable imbalance. Fix the imbalance. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240821183717.163235-1-marex@denx.de
2024-09-03wifi: wilc1000: Do not operate uninitialized hardware during suspend/resumeMarek Vasut
In case the hardware is not initialized, do not operate it during suspend/resume cycle, the hardware is already off so there is no reason to access it. In fact, wilc_sdio_enable_interrupt() in the resume callback does interfere with the same call when initializing the hardware after resume and makes such initialization after resume fail. Fix this by not operating uninitialized hardware during suspend/resume. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240821183639.163187-1-marex@denx.de
2024-09-03btrfs: fix race between direct IO write and fsync when using same fdFilipe Manana
If we have 2 threads that are using the same file descriptor and one of them is doing direct IO writes while the other is doing fsync, we have a race where we can end up either: 1) Attempt a fsync without holding the inode's lock, triggering an assertion failures when assertions are enabled; 2) Do an invalid memory access from the fsync task because the file private points to memory allocated on stack by the direct IO task and it may be used by the fsync task after the stack was destroyed. The race happens like this: 1) A user space program opens a file descriptor with O_DIRECT; 2) The program spawns 2 threads using libpthread for example; 3) One of the threads uses the file descriptor to do direct IO writes, while the other calls fsync using the same file descriptor. 4) Call task A the thread doing direct IO writes and task B the thread doing fsyncs; 5) Task A does a direct IO write, and at btrfs_direct_write() sets the file's private to an on stack allocated private with the member 'fsync_skip_inode_lock' set to true; 6) Task B enters btrfs_sync_file() and sees that there's a private structure associated to the file which has 'fsync_skip_inode_lock' set to true, so it skips locking the inode's VFS lock; 7) Task A completes the direct IO write, and resets the file's private to NULL since it had no prior private and our private was stack allocated. Then it unlocks the inode's VFS lock; 8) Task B enters btrfs_get_ordered_extents_for_logging(), then the assertion that checks the inode's VFS lock is held fails, since task B never locked it and task A has already unlocked it. The stack trace produced is the following: assertion failed: inode_is_locked(&inode->vfs_inode), in fs/btrfs/ordered-data.c:983 ------------[ cut here ]------------ kernel BUG at fs/btrfs/ordered-data.c:983! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 9 PID: 5072 Comm: worker Tainted: G U OE 6.10.5-1-default #1 openSUSE Tumbleweed 69f48d427608e1c09e60ea24c6c55e2ca1b049e8 Hardware name: Acer Predator PH315-52/Covini_CFS, BIOS V1.12 07/28/2020 RIP: 0010:btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs] Code: 50 d6 86 c0 e8 (...) RSP: 0018:ffff9e4a03dcfc78 EFLAGS: 00010246 RAX: 0000000000000054 RBX: ffff9078a9868e98 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff907dce4a7800 RDI: ffff907dce4a7800 RBP: ffff907805518800 R08: 0000000000000000 R09: ffff9e4a03dcfb38 R10: ffff9e4a03dcfb30 R11: 0000000000000003 R12: ffff907684ae7800 R13: 0000000000000001 R14: ffff90774646b600 R15: 0000000000000000 FS: 00007f04b96006c0(0000) GS:ffff907dce480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f32acbfc000 CR3: 00000001fd4fa005 CR4: 00000000003726f0 Call Trace: <TASK> ? __die_body.cold+0x14/0x24 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90 ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? exc_invalid_op+0x50/0x70 ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? asm_exc_invalid_op+0x1a/0x20 ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] btrfs_sync_file+0x21a/0x4d0 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? __seccomp_filter+0x31d/0x4f0 __x64_sys_fdatasync+0x4f/0x90 do_syscall_64+0x82/0x160 ? do_futex+0xcb/0x190 ? __x64_sys_futex+0x10e/0x1d0 ? switch_fpu_return+0x4f/0xd0 ? syscall_exit_to_user_mode+0x72/0x220 ? do_syscall_64+0x8e/0x160 ? syscall_exit_to_user_mode+0x72/0x220 ? do_syscall_64+0x8e/0x160 ? syscall_exit_to_user_mode+0x72/0x220 ? do_syscall_64+0x8e/0x160 ? syscall_exit_to_user_mode+0x72/0x220 ? do_syscall_64+0x8e/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Another problem here is if task B grabs the private pointer and then uses it after task A has finished, since the private was allocated in the stack of task A, it results in some invalid memory access with a hard to predict result. This issue, triggering the assertion, was observed with QEMU workloads by two users in the Link tags below. Fix this by not relying on a file's private to pass information to fsync that it should skip locking the inode and instead pass this information through a special value stored in current->journal_info. This is safe because in the relevant section of the direct IO write path we are not holding a transaction handle, so current->journal_info is NULL. The following C program triggers the issue: $ cat repro.c /* Get the O_DIRECT definition. */ #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <stdint.h> #include <fcntl.h> #include <errno.h> #include <string.h> #include <pthread.h> static int fd; static ssize_t do_write(int fd, const void *buf, size_t count, off_t offset) { while (count > 0) { ssize_t ret; ret = pwrite(fd, buf, count, offset); if (ret < 0) { if (errno == EINTR) continue; return ret; } count -= ret; buf += ret; } return 0; } static void *fsync_loop(void *arg) { while (1) { int ret; ret = fsync(fd); if (ret != 0) { perror("Fsync failed"); exit(6); } } } int main(int argc, char *argv[]) { long pagesize; void *write_buf; pthread_t fsyncer; int ret; if (argc != 2) { fprintf(stderr, "Use: %s <file path>\n", argv[0]); return 1; } fd = open(argv[1], O_WRONLY | O_CREAT | O_TRUNC | O_DIRECT, 0666); if (fd == -1) { perror("Failed to open/create file"); return 1; } pagesize = sysconf(_SC_PAGE_SIZE); if (pagesize == -1) { perror("Failed to get page size"); return 2; } ret = posix_memalign(&write_buf, pagesize, pagesize); if (ret) { perror("Failed to allocate buffer"); return 3; } ret = pthread_create(&fsyncer, NULL, fsync_loop, NULL); if (ret != 0) { fprintf(stderr, "Failed to create writer thread: %d\n", ret); return 4; } while (1) { ret = do_write(fd, write_buf, pagesize, 0); if (ret != 0) { perror("Write failed"); exit(5); } } return 0; } $ mkfs.btrfs -f /dev/sdi $ mount /dev/sdi /mnt/sdi $ timeout 10 ./repro /mnt/sdi/foo Usually the race is triggered within less than 1 second. A test case for fstests will follow soon. Reported-by: Paulo Dias <paulo.miguel.dias@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219187 Reported-by: Andreas Jahn <jahn-andi@web.de> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219199 Reported-by: syzbot+4704b3cc972bd76024f1@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/00000000000044ff540620d7dee2@google.com/ Fixes: 939b656bc8ab ("btrfs: fix corruption after buffer fault in during direct IO append write") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2024-09-03wifi: brcmsmac: Use kvmemdup to simplify the codeJinjie Ruan
Use kvmemdup instead of kvmalloc() + memcpy() to simplify the code. No functional change. Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240821070257.2298559-1-ruanjinjie@huawei.com
2024-09-03dt-bindings: net: wireless: convert marvel-8xxx.txt to yaml formatFrank Li
Convert binding doc marvel-8xxx.txt to yaml format. Additional change: - Remove marvell,caldata_00_txpwrlimit_2g_cfg_set in example. - Remove mmc related property in example. - Add wakeup-source property. - Remove vmmc-supply and mmc-pwrseq. Fix below warning: arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dtb: /soc@0/bus@30800000/mmc@30b40000/wifi@1: failed to match any schema with compatible: ['marvell,sd8997'] Acked-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240820142143.443151-1-Frank.Li@nxp.com
2024-09-03selftests: filesystems: fix warn_unused_result build warningsAbhinav Jain
Add return value checks for read & write calls in test_listmount_ns function. This patch resolves below compilation warnings: ``` statmount_test_ns.c: In function ‘test_listmount_ns’: statmount_test_ns.c:322:17: warning: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Wunused-result] statmount_test_ns.c:323:17: warning: ignoring return value of ‘read’ declared with attribute ‘warn_unused_result’ [-Wunused-result] ``` Signed-off-by: Abhinav Jain <jain.abhinav177@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-09-03usb: typec: ucsi: Fix cable registrationHeikki Krogerus
The Cable PD Revision field in GET_CABLE_PROPERTY was introduced in UCSI v2.1, so adding check for that. The cable properties are also not used anywhere after the cable is registered, so removing the cable_prop member from struct ucsi_connector while at it. Fixes: 38ca416597b0 ("usb: typec: ucsi: Register cables based on GET_CABLE_PROPERTY") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240903130945.3395291-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-09-03MAINTAINERS: move the BFQ io scheduler to orphan stateJens Axboe
Nobody is maintaining this code, and it just falls under the umbrella of block layer code. But at least mark it as such, in case anyone wants to care more deeply about it and assume the responsibility of doing so. Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>