summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-03-07wifi: rework MAINTAINERS entries a bitJohannes Berg
Since I really don't want to be CC'ed on every patch add X: entries for all the drivers that are otherwise covered. In some cases, add a bit more to drivers that have other entries, mostly for the vendor directories, but for libertas also add libertas_tf. While at it, also add all nl80211-related (vendor) UAPI header files to the nl80211 entry. Link: https://patch.msgid.link/20250306092831.f7fdfe7df7b2.I7c86da443038af32e9bcbaa5f53b1e4128a0d1f9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-07ALSA: seq: Avoid client data changes during proc readsTakashi Iwai
The proc read of each client should protect against the concurrent data changes to keep the data consistent; although they are supposed to be safe and won't crash things, it doesn't guarantee the consistency between the read values. Take client->ioctl_mutex for protecting against the concurrent changes. Link: https://patch.msgid.link/20250307084246.29271-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-03-07ALSA: seq: Improve data consistency at pollingTakashi Iwai
snd_seq_poll() calls snd_seq_write_pool_allocated() that reads out a field in client->pool object, while it can be updated concurrently via ioctls, as reported by syzbot. The data race itself is harmless, as it's merely a poll() call, and the state is volatile. OTOH, the read out of poll object info from the caller side is fragile, and we can leave it better in snd_seq_pool_poll_wait() alone. A similar pattern is seen in snd_seq_kernel_client_write_poll(), too, which is called from the OSS sequencer. This patch drops the pool checks from the caller side and add the pool->lock in snd_seq_pool_poll_wait() for better data consistency. Reported-by: syzbot+2d373c9936c00d7e120c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/67c88903.050a0220.15b4b9.0028.GAE@google.com Link: https://patch.msgid.link/20250307084246.29271-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-03-07irqchip/imx-irqsteer: Support up to 960 input interruptsShengjiu Wang
The irqsteer IP routes groups of input interrupts to a dedicated system interrupt per group. Each group handles 64 input interrupts. The current driver is limited to 8 groups, i.e. 512 input interrupts, which is sufficient for the existing i.MX SoCs. The upcoming i.MX94 family extends the irqsteer IP to 15 groups, i.e. 960 interrupts. Extending the group limit to 15 enables this, but the new SoCs are not guaranteed to utilize all 15 groups. Unused groups have no mapping for the underlying output interrupt, which makes the probe function fail as it expects a valid mapping for each group output. Remove this limitation and stop the mapping loop, when no valid mapping is detected. [ tglx: Massage change log ] Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Signed-off-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/all/20250305095522.2177843-1-ping.bai@nxp.com
2025-03-07wifi: wfx: allow to enable WoWLAN using NL80211Jérôme Pouiller
It is possible to use nl80211 to request to the driver to do allow the required bus configuration to wake-up the host. This patch implements the required API for nl80211. Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://patch.msgid.link/20250304153224.39083-6-jerome.pouiller@silabs.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-07wifi: wfx: allow SDIO device to wake up the hostJérôme Pouiller
If the device is connected with SDIO bus, it can wake up the host using either the SDIO controller (that requires MMC_PM_WAKE_SDIO_IRQ capability) or the out-of-bound IRQ. This patch allows both. Obviously, the SDIO controller must be able to keep the SDIO device powered on. Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://patch.msgid.link/20250304153224.39083-5-jerome.pouiller@silabs.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-07wifi: wfx: allow SPI device to wake up the hostJérôme Pouiller
When the host is asleep, the device has wake up the host using the usual SPI IRQ. Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://patch.msgid.link/20250304153224.39083-4-jerome.pouiller@silabs.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-07wifi: wfx: declare support for WoWLANJérôme Pouiller
WF200 is able to keep the connection with the AP alive while the host is asleep. So, let's expose this capability to the user. For now, we don't provide any way to control the device filtering features. The user has to allow wake-up on any received packets and on disconnections. Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://patch.msgid.link/20250304153224.39083-3-jerome.pouiller@silabs.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-07wifi: wfx: align declarations between bus_spi.c and bus_sdio.cJérôme Pouiller
Just declare fields in the same order in bus_spi.c and bus_sdio.c Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://patch.msgid.link/20250304153224.39083-2-jerome.pouiller@silabs.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-07wifi: iwlegacy: avoid size increaseArnd Bergmann
My previous patch caused a slight code size increase when DEBUG_FS is disabled, as Stanislaw Gruszka pointed out. Fix this with an added IS_ENABLED() check. Fixes: cf6b9ba172dd ("wifi: iwlegacy: don't warn for unused variables with DEBUG_FS=n") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20250304144210.997531-1-arnd@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-07Merge tag 'ath-next-20250305' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ==================== ath.git patches for v6.15 This development cycle again featured multiple patchsets to ath12k to support the new 802.11be MLO feature. In addition, there was the usual set of bug fixes and cleanups. ==================== Link: https://lore.kernel.org/linux-wireless/d01b1976-ebe8-48cd-8f49-32bfa00bed7e@oss.qualcomm.com/ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-07media: platform: synopsys: hdmirx: Fix 64-bit division for 32-bit targetsNathan Chancellor
The build fails for 32-bit targets with: arm-linux-gnueabi-ld: drivers/media/platform/synopsys/hdmirx/snps_hdmirx.o: in function `hdmirx_get_timings': snps_hdmirx.c:(.text.hdmirx_get_timings+0x46c): undefined reference to `__aeabi_uldivmod' bt->pixelclock is __u64, which causes the compiler to emit a libcall for 64-bit division. Use the optimized kernel helper, div_u64(), to resolve this. Fixes: 7b59b132ad43 ("media: platform: synopsys: Add support for HDMI input driver") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-03-07irqchip/sunxi-nmi: Support Allwinner A523 NMI controllerAndre Przywara
The NMI controller in the Allwinner A523 is almost compatible to the previous versions of this IP, but requires the extra bit 31 to be set in the enable register to actually report the NMI. Add a mask to allow such an enable bit to be specified, and add this to the per-SoC data structure. As this struct was just for different register offsets so far, it was consequently named "reg_offs", which is now no longer applicable, so rename this to the more generic "data" on the way, and move the existing offsets into a struct of its own. Also add the respective Allwinner A523 compatible string, and set bit 31 in its enable mask, to add support for this SoC. [ tglx: Mop up some coding style along with it ] Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20250307005712.16828-7-andre.przywara@arm.com
2025-03-07dt-bindings: irq: sun7i-nmi: Document the Allwinner A523 NMI controllerAndre Przywara
The Allwinner A523 SoC contains an NMI controller very close to the one used in the recent Allwinner SoCs, but it adds another bit that needs to be toggled to actually deliver the IRQs. Sigh. Add the A523 specific name to the list of allowed compatible strings. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/all/20250307005712.16828-6-andre.przywara@arm.com
2025-03-07mtd: spi-nor: explicitly include <linux/math64.h>Tudor Ambarus
swp and otp drivers use div_u64 and div64_u64 and rely on implicit inclusion of <linux/math64.h>. It is good practice to directly include all headers used, it avoids implicit dependencies and spurious breakage if someone rearranges headers and causes the implicit include to vanish. Include the missing header. Reviewed-by: Pratyush Yadav <pratyush@kernel.org> Link: https://lore.kernel.org/r/20250223-snor-math64-v2-1-6f0313eea331@linaro.org Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2025-03-07selftests/nolibc: stop testing constructor orderThomas Weißschuh
The execution order of constructors in undefined and depends on the toolchain. While recent toolchains seems to have a stable order, it doesn't work for older ones and may also change at any time. Stop validating the order and instead only validate that all constructors are executed. Reported-by: Willy Tarreau <w@1wt.eu> Closes: https://lore.kernel.org/lkml/20250301110735.GA18621@1wt.eu/ Link: https://lore.kernel.org/r/20250306-nolibc-constructor-order-v1-1-68fd161cc5ec@weissschuh.net Acked-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2025-03-07mtd: spi-nor: macronix: add support for mx66{l2, u1}g45gCheng Ming Lin
Due to incorrect values in the 4-BAIT table for these two flash IDs, it is necessary to add these two flash IDs with fixups. Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw> Link: https://lore.kernel.org/r/20250211063028.382169-3-linchengming884@gmail.com [ta: update commit subject] Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2025-03-07mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page ProgramCheng Ming Lin
Although certain Macronix NOR flash support the Quad Input Page Program feature, the corresponding information in the 4-byte Address Instruction Table of these flash is not properly filled. As a result, this feature cannot be enabled as expected. To address this issue, a post_sfdp fixups implementation is required to correct the missing information. Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw> Link: https://lore.kernel.org/r/20250211063028.382169-2-linchengming884@gmail.com [ta: fix alignment to match open parenthesis] Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2025-03-06fs/pipe: add simpler helpers for common casesLinus Torvalds
The fix to atomically read the pipe head and tail state when not holding the pipe mutex has caused a number of headaches due to the size change of the involved types. It turns out that we don't have _that_ many places that access these fields directly and were affected, but we have more than we strictly should have, because our low-level helper functions have been designed to have intimate knowledge of how the pipes work. And as a result, that random noise of direct 'pipe->head' and 'pipe->tail' accesses makes it harder to pinpoint any actual potential problem spots remaining. For example, we didn't have a "is the pipe full" helper function, but instead had a "given these pipe buffer indexes and this pipe size, is the pipe full". That's because some low-level pipe code does actually want that much more complicated interface. But most other places literally just want a "is the pipe full" helper, and not having it meant that those places ended up being unnecessarily much too aware of this all. It would have been much better if only the very core pipe code that cared had been the one aware of this all. So let's fix it - better late than never. This just introduces the trivial wrappers for "is this pipe full or empty" and to get how many pipe buffers are used, so that instead of writing if (pipe_full(pipe->head, pipe->tail, pipe->max_usage)) the places that literally just want to know if a pipe is full can just say if (pipe_is_full(pipe)) instead. The existing trivial cases were converted with a 'sed' script. This cuts down on the places that access pipe->head and pipe->tail directly outside of the pipe code (and core splice code) quite a lot. The splice code in particular still revels in doing the direct low-level accesses, and the fuse fuse_dev_splice_write() code also seems a bit unnecessarily eager to go very low-level, but it's at least a bit better than it used to be. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-03-06Merge tag 'drm-fixes-2025-03-07' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Fixes across the board, mostly xe and imagination with some amd and misc others. The xe fixes are mostly hmm related, though there are some others in there as well, nothing really stands out otherwise. The nouveau Kconfig to select FW_CACHE is in this, which we discussed a while back. nouveau: - rely on fw caching Kconfig fix imagination: - avoid deadlock on fence release - fix fence initialisation - fix timestamps firmware traces scheduler: - fix include guard bochs: - dpms fix i915: - bump max stream count to match pipes xe: - Remove double page flip on initial plane - Properly setup userptr pfn_flags_mask - Fix GT "for each engine" workarounds - Fix userptr races and missed validations - Userptr invalid page access fixes - Cleanup some style nits amdgpu: - Fix NULL check in DC code - SMU 14 fix amdkfd: - Fix NULL check in queue validation radeon: - RS400 HyperZ fix" * tag 'drm-fixes-2025-03-07' of https://gitlab.freedesktop.org/drm/kernel: (22 commits) drm/bochs: Fix DPMS regression drm/xe/userptr: Unmap userptrs in the mmu notifier drm/xe/hmm: Don't dereference struct page pointers without notifier lock drm/xe/hmm: Style- and include fixes drm/xe: Add staging tree for VM binds drm/xe: Fix fault mode invalidation with unbind drm/xe/vm: Fix a misplaced #endif drm/xe/vm: Validate userptr during gpu vma prefetching drm/amd/pm: always allow ih interrupt from fw drm/radeon: Fix rs400_gpu_init for ATI mobility radeon Xpress 200M drm/amdkfd: Fix NULL Pointer Dereference in KFD queue drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_params drm/xe: Fix GT "for each engine" workarounds drm/xe/userptr: properly setup pfn_flags_mask drm/i915/mst: update max stream count to match number of pipes drm/xe: Remove double pageflip drm/sched: Fix preprocessor guard drm/imagination: Fix timestamps in firmware traces drm/imagination: only init job done fences once drm/imagination: Hold drm_gem_gpuva lock for unmap ...
2025-03-06Merge tag 'nf-25-03-06' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) Fix racy non-atomic read-then-increment operation with PREEMPT_RT in nft_ct, from Sebastian Andrzej Siewior. 2) GC is not skipped when jiffies wrap around in nf_conncount, from Nicklas Bo Jensen. 3) flush_work() on nf_tables_destroy_work waits for the last queued instance, this could be an instance that is different from the one that we must wait for, then make destruction work queue. * tag 'nf-25-03-06' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_tables: make destruction work queue pernet netfilter: nf_conncount: garbage collection is not skipped when jiffies wrap around netfilter: nft_ct: Use __refcount_inc() for per-CPU nft_ct_pcpu_template. ==================== Link: https://patch.msgid.link/20250306153446.46712-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06Merge branch 'mlx5-misc-enhancements-2025-03-04'Jakub Kicinski
Tariq Toukan says: ==================== mlx5 misc enhancements 2025-03-04 This series introduces enhancements to the mlx5 core and Eth drivers. Patches 1-3 by Shahar introduce support for configuring lanes alongside speed when autonegotiation is disabled. The combination of speed and the number of lanes corresponds to a specific link mode (in the extended mask typically used in newer hardware), allowing the user to select a precise link mode when autonegotiation is off, instead of just choosing the speed. Patch 4 by Amir extends the multi-port LAG support. Patches 5-6 by Leon enhance IPsec matching logic. v1: https://lore.kernel.org/20250226114752.104838-1-tariqt@nvidia.com ==================== Link: https://patch.msgid.link/20250304160620.417580-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net/mlx5e: Properly match IPsec subnet addressesLeon Romanovsky
Existing match criteria didn't allow to match whole subnet and only by specific addresses only. This caused to tunnel mode do not forward such traffic through relevant SA. In tunnel mode, policies look like this: src 192.169.0.0/16 dst 192.169.0.0/16 dir out priority 383615 ptype main tmpl src 192.169.101.2 dst 192.169.101.1 proto esp spi 0xc5141c18 reqid 1 mode tunnel crypto offload parameters: dev eth2 mode packet In this case, the XFRM core code handled all subnet calculations and forwarded network address to the drivers e.g. 192.169.0.0. For mlx5 devices, there is a need to set relevant prefix e.g. 0xFFFF00 to perform flow steering match operation. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250304160620.417580-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net/mlx5e: Separate address related variables to be in structLeon Romanovsky
Prepare the code to addition of prefix handling logic which is needed to support matching logic based on source and/or destination network prefixes. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250304160620.417580-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net/mlx5: Lag, Enable Multiport E-Switch offloads on 8 ports LAGAmir Tzin
Patch [1] added mlx5 driver support for 8 ports HCAs which are available since ConnectX-8. Now that Multiport E-Switch is tested, we can enable it by removing flag MLX5_LAG_MPESW_OFFLOADS_SUPPORTED_PORTS. [1] commit e0e6adfe8c20 ("net/mlx5: Enable 8 ports LAG") Signed-off-by: Amir Tzin <amirtz@nvidia.com> Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250304160620.417580-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net/mlx5e: Enable lanes configuration when auto-negotiation is offShahar Shitrit
Currently, when auto-negotiation is disabled, the driver retrieves the speed and converts it into all link modes that correspond to that speed. With this patch, we add the ability to set the number of lanes, so that the combination of speed and lanes corresponds to exactly one specific link mode for the extended bit map. For the legacy bit map the driver sets all link modes correspond to speed and lanes. This change provides users with the option to set a specific link mode, rather than enabling all link modes associated with a given speed when auto-negotiation is off. Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250304160620.417580-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net/mlx5: Refactor link speed handling with mlx5_link_info structShahar Shitrit
Introduce struct mlx5_link_info with a speed field and change the types of mlx5e_link_speed and mlx5e_ext_link_speed from arrays of u32 to arrays of struct mlx5_link_info. These arrays are renamed to mlx5e_link_info and mlx5e_ext_link_info, respectively. This change prepares for a future patch that will introduce a lanes field in struct mlx5_link_info and add lanes mapping alongside the speed for each link mode in the two arrays. Additionally, rename function mlx5_port_speed2linkmodes() to mlx5_port_info2linkmodes() and function mlx5_port_ptys2speed() to mlx5_port_ptys2info() and update the speed parameter/return type to struct mlx5_link_info, in preparation for the upcoming patch where these functions will also utilize the lanes field. Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250304160620.417580-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net/mlx5: Relocate function declarations from port.h to mlx5_core.hShahar Shitrit
The port header is a general file under include, yet it contains declarations for functions that are either not exported or exported but not used outside the mlx5_core driver. To enhance code organization, we move these declarations to mlx5_core.h, where they are more appropriately scoped. This refactor removes unnecessary exported symbols and prevents unexported functions from being inadvertently referenced outside of the mlx5_core driver. Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250304160620.417580-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06Merge branch 'add-perout-configuration-support-in-iep-driver'Jakub Kicinski
Meghana Malladi says: ==================== Add perout configuration support in IEP driver IEP driver supported both perout and pps signal generation but perout feature is faulty with half-cooked support due to some missing configuration. Hence perout feature is removed as a bug fix. This patch series adds back this feature which configures perout signal based on the arguments passed by the perout request. This patch series is continuation to the bug fix: https://lore.kernel.org/20250227092441.1848419-1-m-malladi@ti.com as suggested by Jakub Kicinski and Jacob Keller: https://lore.kernel.org/20250220172410.025b96d6@kernel.org v3: https://lore.kernel.org/20250303135124.632845-1-m-malladi@ti.com ==================== Link: https://patch.msgid.link/20250304105753.1552159-1-m-malladi@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net: ti: icss-iep: Add phase offset configuration for perout signalMeghana Malladi
icss_iep_perout_enable_hw() is a common function for generating both pps and perout signals. When enabling pps, the application needs to only pass enable/disable argument, whereas for perout it supports different flags to configure the signal. In case the app passes a valid phase offset value, the signal should start toggling after that phase offset, else start immediately or as soon as possible. ICSS_IEP_SYNC_START_REG register take number of clock cycles to wait before starting the signal after activation time. Set appropriate value to this register to support phase offset. Signed-off-by: Meghana Malladi <m-malladi@ti.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20250304105753.1552159-3-m-malladi@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net: ti: icss-iep: Add pwidth configuration for perout signalMeghana Malladi
icss_iep_perout_enable_hw() is a common function for generating both pps and perout signals. When enabling pps, the application needs to only pass enable/disable argument, whereas for perout it supports different flags to configure the signal. But icss_iep_perout_enable_hw() function is missing to hook the configuration params passed by the app, causing perout to behave same a pps (except being able to configure the period). As duty cycle is also one feature which can configured for perout, incorporate this in the function to get the expected signal. Signed-off-by: Meghana Malladi <m-malladi@ti.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20250304105753.1552159-2-m-malladi@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06block: Name the RQF flags enumBreno Leitao
Commit 5f89154e8e9e3445f9b59 ("block: Use enum to define RQF_x bit indexes") converted the RQF flags to an anonymous enum, which was a beneficial change. This patch goes one step further by naming the enum as "rqf_flags". This naming enables exporting these flags to BPF clients, eliminating the need to duplicate these flags in BPF code. Instead, BPF clients can now access the same kernel-side values through CO:RE (Compile Once, Run Everywhere), as shown in this example: rqf_stats = bpf_core_enum_value(enum rqf_flags, __RQF_STATS) Suggested-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20250306-rqf_flags-v1-1-bbd64918b406@debian.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-03-06selftests: openvswitch: don't hardcode the drop reason subsysJakub Kicinski
WiFi removed one of their subsys entries from drop reasons, in commit 286e69677065 ("wifi: mac80211: Drop cooked monitor support") SKB_DROP_REASON_SUBSYS_OPENVSWITCH is now 2 not 3. The drop reasons are not uAPI, read the correct value from debug info. We need to enable vmlinux BTF, otherwise pahole needs a few GB of memory to decode the enum name. Acked-by: Stanislav Fomichev <sdf@fomichev.me> Acked-by: Aaron Conole <aconole@redhat.com> Link: https://patch.msgid.link/20250304180615.945945-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net: airoha: Enable TSO/Scatter Gather for LAN portLorenzo Bianconi
Set net_device vlan_features in order to enable TSO and Scatter Gather for DSA user ports. Reviewed-by: Mateusz Polchlopek <mateusz.polchlopek@intel.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250304-lan-enable-tso-v1-1-b398eb9976ba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net: airoha: Fix lan4 support in airoha_qdma_get_gdm_port()Lorenzo Bianconi
EN7581 SoC supports lan{1,4} ports on MT7530 DSA switch. Fix lan4 reported value in airoha_qdma_get_gdm_port routine. Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250304-airoha-eth-fix-lan4-v1-1-832417da4bb5@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06Merge branch 'increase-maximum-mtu-to-9k-for-airoha-en7581-soc'Jakub Kicinski
Lorenzo Bianconi says: ==================== Increase maximum MTU to 9k for Airoha EN7581 SoC EN7581 SoC supports 9k maximum MTU. Enable the reception of Scatter-Gather (SG) frames for Airoha EN7581. Introduce airoha_dev_change_mtu callback. ==================== Link: https://patch.msgid.link/20250304-airoha-eth-rx-sg-v1-0-283ebc61120e@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net: airoha: Increase max mtu to 9kLorenzo Bianconi
EN7581 SoC supports 9k maximum MTU. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250304-airoha-eth-rx-sg-v1-4-283ebc61120e@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net: airoha: Introduce airoha_dev_change_mtu callbackLorenzo Bianconi
Add airoha_dev_change_mtu callback to update the MTU of a running device. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250304-airoha-eth-rx-sg-v1-3-283ebc61120e@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net: airoha: Enable Rx Scatter-GatherLorenzo Bianconi
EN7581 SoC can receive 9k frames. Enable the reception of Scatter-Gather (SG) frames. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250304-airoha-eth-rx-sg-v1-2-283ebc61120e@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net: airoha: Move min/max packet len configuration in airoha_dev_open()Lorenzo Bianconi
In order to align max allowed packet size to the configured mtu, move REG_GDM_LEN_CFG configuration in airoha_dev_open routine. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250304-airoha-eth-rx-sg-v1-1-283ebc61120e@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06smccc: kvm_guest: Fix kernel builds for 32 bit armShameer Kolothum
The paravirtual implementation ID stuffs is 64-bit only and broke 32bit arm builds. Slap an ifdef bandaid on the situation to get things rolling again. Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-06net: stmmac: simplify phylink_suspend() and phylink_resume() callsRussell King (Oracle)
Currently, the calls to phylink's suspend and resume functions are inside overly complex tests, and boil down to: if (device_may_wakeup(priv->device) && priv->plat->pmt) { call phylink } else { call phylink and if (device_may_wakeup(priv->device)) do something else } This results in phylink always being called, possibly with differing arguments for phylink_suspend(). Simplify this code, noting that each site is slightly different due to the order in which phylink is called and the "something else". Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/E1tpQL1-005St4-Hn@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06sched: address a potential NULL pointer dereference in the GRED scheduler.Jun Yang
If kzalloc in gred_init returns a NULL pointer, the code follows the error handling path, invoking gred_destroy. This, in turn, calls gred_offload, where memset could receive a NULL pointer as input, potentially leading to a kernel crash. When table->opt is NULL in gred_init(), gred_change_table_def() is not called yet, so it is not necessary to call ->ndo_setup_tc() in gred_offload(). Signed-off-by: Jun Yang <juny24602@gmail.com> Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com> Fixes: f25c0515c521 ("net: sched: gred: dynamically allocate tc_gred_qopt_offload") Link: https://patch.msgid.link/20250305154410.3505642-1-juny24602@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06net: stmmac: avoid shadowing global buf_szRussell King (Oracle)
stmmac_rx() declares a local variable named "buf_sz" but there is also a global variable for a module parameter which is called the same. To avoid confusion, rename the local variable. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Furong Xu <0x1207@gmail.com> Link: https://patch.msgid.link/E1tpswi-005U6C-Py@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2025-03-05 (ice) This series contains updates to ice driver. Larysa removes modification of destination override that caused LLDP packets to be blocked. Grzegorz fixes a memory leak in aRFS. Marcin resolves an issue with operation of switchdev and LAG. Przemek adjusts order of calls for registering devlink in relation to health reporters. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: register devlink prior to creating health reporters ice: Fix switchdev slow-path in LAG ice: fix memory leak in aRFS after reset ice: do not configure destination override for switchdev ==================== Link: https://patch.msgid.link/20250305213549.1514274-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-07Merge tag 'amd-drm-fixes-6.14-2025-03-06' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.14-2025-03-06: amdgpu: - Fix NULL check in DC code - SMU 14 fix amdkfd: - Fix NULL check in queue validation radeon: - RS400 HyperZ fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306193424.27413-1-alexander.deucher@amd.com
2025-03-06Merge tag 'bcachefs-2025-03-06' of git://evilpiepirate.org/bcachefsLinus Torvalds
Pull bcachefs fixes from Kent Overstreet: - Fix a compatibility issue: we shouldn't be setting incompat feature bits unless explicitly requested - Fix another bug where the journal alloc/resize path could spuriously fail with -BCH_ERR_open_buckets_empty - Copygc shouldn't run on read-only devices: fragmentation isn't an issue if we're not currently writing to a given device, and it may not have anywhere to move the data to * tag 'bcachefs-2025-03-06' of git://evilpiepirate.org/bcachefs: bcachefs: copygc now skips non-rw devices bcachefs: Fix bch2_dev_journal_alloc() spuriously failing bcachefs: Don't set BCH_FEATURE_incompat_version_field unless requested
2025-03-06selftests: net: bpf_offload: add 'libbpf_global' to ignored mapsJakub Kicinski
After installing pahole on the CI image we have a new map created by libbpf. Ignore it otherwise we see: Exception: Time out waiting for map counts to stabilize want 2, have 3 Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250304233204.1139251-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06selftests: net: fix error message in bpf_offloadJakub Kicinski
We hit a following exception on timeout, nmaps is never set: Test bpftool bound info reporting (own ns)... Traceback (most recent call last): File "/home/virtme/testing-1/tools/testing/selftests/net/./bpf_offload.py", line 1128, in <module> check_dev_info(False, "") File "/home/virtme/testing-1/tools/testing/selftests/net/./bpf_offload.py", line 583, in check_dev_info maps = bpftool_map_list_wait(expected=2, ns=ns) File "/home/virtme/testing-1/tools/testing/selftests/net/./bpf_offload.py", line 215, in bpftool_map_list_wait raise Exception("Time out waiting for map counts to stabilize want %d, have %d" % (expected, nmaps)) NameError: name 'nmaps' is not defined Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250304233204.1139251-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-06tcp: clamp window like before the cleanupMatthieu Baerts (NGI0)
A recent cleanup changed the behaviour of tcp_set_window_clamp(). This looks unintentional, and affects MPTCP selftests, e.g. some tests re-establishing a connection after a disconnect are now unstable. Before the cleanup, this operation was done: new_rcv_ssthresh = min(tp->rcv_wnd, new_window_clamp); tp->rcv_ssthresh = max(new_rcv_ssthresh, tp->rcv_ssthresh); The cleanup used the 'clamp' macro which takes 3 arguments -- value, lowest, and highest -- and returns a value between the lowest and the highest allowable values. This then assumes ... lowest (rcv_ssthresh) <= highest (rcv_wnd) ... which doesn't seem to be always the case here according to the MPTCP selftests, even when running them without MPTCP, but only TCP. For example, when we have ... rcv_wnd < rcv_ssthresh < new_rcv_ssthresh ... before the cleanup, the rcv_ssthresh was not changed, while after the cleanup, it is lowered down to rcv_wnd (highest). During a simple test with TCP, here are the values I observed: new_window_clamp (val) rcv_ssthresh (lo) rcv_wnd (hi) 117760 (out) 65495 < 65536 128512 (out) 109595 > 80256 => lo > hi 1184975 (out) 328987 < 329088 113664 (out) 65483 < 65536 117760 (out) 110968 < 110976 129024 (out) 116527 > 109696 => lo > hi Here, we can see that it is not that rare to have rcv_ssthresh (lo) higher than rcv_wnd (hi), so having a different behaviour when the clamp() macro is used, even without MPTCP. Note: new_window_clamp is always out of range (rcv_ssthresh < rcv_wnd) here, which seems to be generally the case in my tests with small connections. I then suggests reverting this part, not to change the behaviour. Fixes: 863a952eb79a ("tcp: tcp_set_window_clamp() cleanup") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/551 Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Tested-by: Jason Xing <kerneljasonxing@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250305-net-next-fix-tcp-win-clamp-v1-1-12afb705d34e@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-28 00:49:29 +0000