user/sven/linux.git, branch v6.12.57

Linux 6.12.57

2025-11-02T13:15:23Z

Link: https://lore.kernel.org/r/20251031140043.939381518@linuxfoundation.org Tested-by: Peter Schneider Tested-by: Brett Mastbergen Tested-by: Jon Hunter Tested-by: Salvatore Bonaccorso Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Dileep Malepu Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Brett A C Sheffield Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

btrfs: tree-checker: fix bounds check in check_inode_extref()

2025-11-02T13:15:23Z

commit e92c2941204de7b62e9c2deecfeb9eaefe54a22a upstream. The parentheses for the unlikely() annotation were put in the wrong place so it means that the condition is basically never true and the bounds checking is skipped. Fixes: aab9458b9f00 ("btrfs: tree-checker: add inode extref checks") Signed-off-by: Dan Carpenter Reviewed-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman

sfc: fix NULL dereferences in ef100_process_design_param()

2025-11-02T13:15:23Z

[ Upstream commit 8241ecec1cdc6699ae197d52d58e76bddd995fa5 ] Since cited commit, ef100_probe_main() and hence also ef100_check_design_params() run before efx->net_dev is created; consequently, we cannot netif_set_tso_max_size() or _segs() at this point. Move those netif calls to ef100_probe_netdev(), and also replace netif_err within the design params code with pci_err. Reported-by: Kyungwook Boo Fixes: 98ff4c7c8ac7 ("sfc: Separate netdev probe/remove from PCI probe/remove") Signed-off-by: Edward Cree Reviewed-by: Michal Swiatkowski Link: https://patch.msgid.link/20250401225439.2401047-1-edward.cree@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Amelia Crate Signed-off-by: Greg Kroah-Hartman

udmabuf: fix a buf size overflow issue during udmabuf creation

2025-11-02T13:15:23Z

[ Upstream commit 021ba7f1babd029e714d13a6bf2571b08af96d0f ] by casting size_limit_mb to u64 when calculate pglimit. Signed-off-by: Xiaogang Chen Link: https://patchwork.freedesktop.org/patch/msgid/20250321164126.329638-1-xiaogang.chen@amd.com Signed-off-by: Christian König Signed-off-by: Amelia Crate Signed-off-by: Greg Kroah-Hartman

wifi: ath12k: fix read pointer after free in ath12k_mac_assign_vif_to_vdev()

2025-11-02T13:15:23Z

[ Upstream commit 5a10971c7645a95f5d5dc23c26fbac4bf61801d0 ] In ath12k_mac_assign_vif_to_vdev(), if arvif is created on a different radio, it gets deleted from that radio through a call to ath12k_mac_unassign_link_vif(). This action frees the arvif pointer. Subsequently, there is a check involving arvif, which will result in a read-after-free scenario. Fix this by moving this check after arvif is again assigned via call to ath12k_mac_assign_link_vif(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Closes: https://scan5.scan.coverity.com/#/project-view/63541/10063?selectedIssue=1636423 Fixes: b5068bc9180d ("wifi: ath12k: Cache vdev configs before vdev create") Signed-off-by: Aditya Kumar Singh Acked-by: Jeff Johnson Acked-by: Kalle Valo Link: https://patch.msgid.link/20241210-read_after_free-v1-1-969f69c7d66c@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Amelia Crate Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE

2025-11-02T13:15:23Z

[ Upstream commit 60f030f7418d3f1d94f2fb207fe3080e1844630b ] There is a WARN_ON_ONCE to catch an unlikely situation when domain_remove_dev_pasid can't find the `pasid`. In case it nevertheless happens we must avoid using a NULL pointer. Signed-off-by: Kees Bakker Link: https://lore.kernel.org/r/20241218201048.E544818E57E@bout3.ijzerbout.nl Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Amelia Crate Signed-off-by: Greg Kroah-Hartman

gpio: idio-16: Define fixed direction of the GPIO lines

2025-11-02T13:15:22Z

[ Upstream commit 2ba5772e530f73eb847fb96ce6c4017894869552 ] The direction of the IDIO-16 GPIO lines is fixed with the first 16 lines as output and the remaining 16 lines as input. Set the gpio_config fixed_direction_output member to represent the fixed direction of the GPIO lines. Fixes: db02247827ef ("gpio: idio-16: Migrate to the regmap API") Reported-by: Mark Cave-Ayland Closes: https://lore.kernel.org/r/9b0375fd-235f-4ee1-a7fa-daca296ef6bf@nutanix.com Suggested-by: Michael Walle Cc: stable@vger.kernel.org # ae495810cffe: gpio: regmap: add the .fixed_direction_output configuration parameter Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: William Breathitt Gray Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20251020-fix-gpio-idio-16-regmap-v2-3-ebeb50e93c33@kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

gpio: regmap: add the .fixed_direction_output configuration parameter

2025-11-02T13:15:22Z

[ Upstream commit 00aaae60faf554c27c95e93d47f200a93ff266ef ] There are GPIO controllers such as the one present in the LX2160ARDB QIXIS FPGA which have fixed-direction input and output GPIO lines mixed together in a single register. This cannot be modeled using the gpio-regmap as-is since there is no way to present the true direction of a GPIO line. In order to make this use case possible, add a new configuration parameter - fixed_direction_output - into the gpio_regmap_config structure. This will enable user drivers to provide a bitmap that represents the fixed direction of the GPIO lines. Signed-off-by: Ioana Ciornei Acked-by: Bartosz Golaszewski Reviewed-by: Michael Walle Signed-off-by: Bartosz Golaszewski Stable-dep-of: 2ba5772e530f ("gpio: idio-16: Define fixed direction of the GPIO lines") Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

gpio: regmap: Allow to allocate regmap-irq device

2025-11-02T13:15:22Z

[ Upstream commit 553b75d4bfe9264f631d459fe9996744e0672b0e ] GPIO controller often have support for IRQ: allow to easily allocate both gpio-regmap and regmap-irq in one operation. Reviewed-by: Andy Shevchenko Acked-by: Bartosz Golaszewski Signed-off-by: Mathieu Dubois-Briand Link: https://lore.kernel.org/r/20250824-mdb-max7360-support-v14-5-435cfda2b1ea@bootlin.com Signed-off-by: Lee Jones Stable-dep-of: 2ba5772e530f ("gpio: idio-16: Define fixed direction of the GPIO lines") Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

bits: introduce fixed-type GENMASK_U*()

2025-11-02T13:15:22Z

[ Upstream commit 19408200c094858d952a90bf4977733dc89a4df5 ] Add GENMASK_TYPE() which generalizes __GENMASK() to support different types, and implement fixed-types versions of GENMASK() based on it. The fixed-type version allows more strict checks to the min/max values accepted, which is useful for defining registers like implemented by i915 and xe drivers with their REG_GENMASK*() macros. The strict checks rely on shift-count-overflow compiler check to fail the build if a number outside of the range allowed is passed. Example: #define FOO_MASK GENMASK_U32(33, 4) will generate a warning like: include/linux/bits.h:51:27: error: right shift count >= width of type [-Werror=shift-count-overflow] 51 | type_max(t) >> (BITS_PER_TYPE(t) - 1 - (h))))) | ^~ The result is casted to the corresponding fixed width type. For example, GENMASK_U8() returns an u8. Note that because of the C promotion rules, GENMASK_U8() and GENMASK_U16() will immediately be promoted to int if used in an expression. Regardless, the main goal is not to get the correct type, but rather to enforce more checks at compile time. While GENMASK_TYPE() is crafted to cover all variants, including the already existing GENMASK(), GENMASK_ULL() and GENMASK_U128(), for the moment, only use it for the newly introduced GENMASK_U*(). The consolidation will be done in a separate change. Co-developed-by: Yury Norov Signed-off-by: Lucas De Marchi Acked-by: Jani Nikula Signed-off-by: Vincent Mailhol Reviewed-by: Andy Shevchenko Signed-off-by: Yury Norov Stable-dep-of: 2ba5772e530f ("gpio: idio-16: Define fixed direction of the GPIO lines") Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman