summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-05-11drm/i915: Move the i915_dpt_offset()==0 assertVille Syrjälä
Move the i915_dpt_offset() check into the lower level intel_fb_pin_to_dpt() function. Clears out some of the unnecessary junk from the higher level code, making it easier to introduce the new fb_pin parent interface. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-4-ville.syrjala@linux.intel.com
2026-05-11drm/i915: Move intel_fb_pin_params to the parent interfaceVille Syrjälä
strut intel_fb_pin_params will be an important part of the fb_pin interface, so move the definition to the parent interface file. Or maybe we should have a separate header for this kind of stuff since the users of the parent interface will need the struct definition but not the parent interface vfunc struct definitions? Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-3-ville.syrjala@linux.intel.com
2026-05-11drm/i915: Introduce intel_parent_fb_pin_get_map()Ville Syrjälä
Introduce the "fb_pin" parent interface, as the first trivial step move the *_get_map() stuff there. The whole "fb_pin" as an interface might not really make sense, and perhaps this (and other stuff) should just be collected into some kind of "bo" interface. But let's go with "fb_pin" for now to match where things are implemented, and possibly restructure it later. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260508143426.26504-2-ville.syrjala@linux.intel.com
2026-05-11s390/ap: Implement SE bind and associate ueventsHarald Freudenberger
Notify userspace about two important events on AP queues when run within Secure Execution (SE) environment: - Send AP CHANGE uevent with "SE_BIND=1" on successful bind operation on this AP queue device. - Send AP CHANGE uevent with "SE_ASSOC=<association_index>" on successful association operation with the secret of the reported index on this AP queue device. Note there is no SE unbind/unassociate event. Unbind/unassociate can have different triggers and technically there is no signaling done which the AP code could catch. A user space application can, if this information is crucial, query the sysfs attribute se_bind on the AP queue which runs a synchronous TAPQ. If the attribute returns with "unbound" a reset took place and SE bind and associate states are unbound and unassociated. Suggested-by: Marc Hartmayer mhartmay@linux.ibm.com Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-05-11s390/cio: Restore GFP_DMA for CHSC allocationPeter Oberparleiter
Re-add GFP_DMA when allocating memory for CHSC control blocks. On some supported machines, CHSC cannot access memory outside the DMA zone, causing CHSC command failures. Cc: stable@vger.kernel.org Fixes: a3a64a4def8d ("s390/cio: remove unneeded DMA zone allocation") Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-05-11mmc: dw_mmc: exynos: increase DMA threshold value for exynos7870Kaustabh Chakraborty
Exynos 7870 compatible controllers, such as SDIO ones are not able to perform DMA transfers for small sizes of data (~16 to ~512 bytes), resulting in cache issues in subsequent transfers. Increase the DMA transfer threshold to 512 to allow the shorter transfers to take place, bypassing DMA. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-05-11mmc: dw_mmc: implement option for configuring DMA thresholdKaustabh Chakraborty
Some controllers, such as certain Exynos SDIO ones, are unable to perform DMA transfers of small amount of bytes properly. Following the device tree schema, implement the property to define the DMA transfer threshold (from a hard coded value of 16 bytes) so that lesser number of bytes can be transferred safely skipping DMA in such controllers. The value of 16 bytes stays as the default for controllers which do not define it. This value can be overridden by implementation-specific init sequences. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-05-11platform/x86: pmc_atom: Use named initializer for pci_device_id arrayUwe Kleine-König (The Capable Hub)
While being more verbose using a named initializer yields easier to understand code and doesn't rely on the two hidden zeros in the PCI_VDEVICE macro. This doesn't introduce any changes to the compiled result of the array, which was confirmed with an ARCH=x86 build. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20260507155025.3186956-2-u.kleine-koenig@baylibre.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-11irqchip/gic-v3-its: Use FIELD_MODIFY()Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260430162954.44156-1-18255117159@163.com
2026-05-11platform/x86: asus-nb-wmi: add DMI quirk for ASUS Zenbook Duo UX8407AAPaolo Pisati
Use the existing zenbook duo keyboard quirk for the UX8407AA model too. Signed-off-by: Paolo Pisati <p.pisati@gmail.com> Reviewed-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/20260508070956.62201-1-p.pisati@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-11soc: qcom: ice: Allow explicit votes on 'iface' clock for ICEHarshal Dev
Since Qualcomm inline-crypto engine (ICE) is now a dedicated driver de-coupled from the QCOM UFS driver, it explicitly votes for its required clocks during probe. For scenarios where the 'clk_ignore_unused' flag is not passed on the kernel command line, to avoid potential unclocked ICE hardware register access during probe the ICE driver should additionally vote on the 'iface' clock. Also update the suspend and resume callbacks to handle un-voting and voting on the 'iface' clock. Fixes: 2afbf43a4aec6 ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver") Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-2-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11drm/i915/dp: Fix VSC dynamic range signaling for RGB formatsChaitanya Kumar Borah
For RGB, set dynamic_range to CTA or VESA based on crtc_state->limited_color_range so sinks apply correct quantization. YCbCr remains limited (CTA) range. (DP v1.4, Table 5-1) v2: - Added Reported-by and Tested-by tags v3: - Add back YCbCr comment(Suraj) Cc: stable@vger.kernel.org #v5.8+ Reported-by: DeepChirp <DeepChirp@outlook.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15874 Tested-by: DeepChirp <DeepChirp@outlook.com> Fixes: 9799c4c3b76e ("drm/i915/dp: Add compute routine for DP VSC SDP") Assisted-by: GitHub-Copilot:GPT-5.4 Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260505090920.2479112-1-chaitanya.kumar.borah@intel.com
2026-05-11watchdog: apple: Add "apple,t8103-wdt" compatibleJanne Grunau
After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,wdt" anymore [1]. Use "apple,t8103-wdt" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/ Fixes: 4ed224aeaf66 ("watchdog: Add Apple SoC watchdog driver") Cc: stable@vger.kernel.org Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Janne Grunau <j@jannau.net> Link: https://lore.kernel.org/r/20251231-watchdog-apple-t8103-base-compat-v1-1-1702a02e0c45@jannau.net Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-05-11platform: arm64: Add driver for EC found on Qualcomm reference devicesSibi Sankar
Add Embedded controller driver support for Hamoa/Purwa/Glymur qualcomm reference boards. It handles fan control, temperature sensors, access to EC state changes and supports reporting suspend entry/exit to the EC. Co-developed-by: Maya Matuszczyk <maccraft123mc@gmail.com> Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com> Link: https://patch.msgid.link/20260511-add-driver-for-ec-v9-2-e5437c39b7f8@oss.qualcomm.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-11ublk: reject max_sectors smaller than PAGE_SECTORS in parameter validationMing Lei
blk_validate_limits() requires max_hw_sectors >= PAGE_SECTORS and fires a WARN_ON_ONCE if this invariant is violated. ublk_validate_params() only checked the upper bound of max_sectors against max_io_buf_bytes, allowing userspace to pass small values (including zero) that trigger the warning when blk_mq_alloc_disk() is called from ublk_ctrl_start_dev(). Before 494ea040bcb5, ublk used blk_queue_max_hw_sectors() which silently clamped small values up to PAGE_SECTORS. The conversion to passing queue_limits directly to blk_mq_alloc_disk() lost that clamping and now hits blk_validate_limits()'s WARN_ON_ONCE instead. Validate that max_sectors is at least PAGE_SECTORS in ublk_validate_params() so invalid values are rejected early with -EINVAL instead of reaching the block layer. Fixes: 494ea040bcb5 ("ublk: pass queue_limits to blk_mq_alloc_disk") Signed-off-by: Ming Lei <tom.leiming@gmail.com> Link: https://patch.msgid.link/20260510144843.769031-1-tom.leiming@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-05-11irqchip/econet-en751221: Support MIPS 34Kc VEIC modeCaleb James DeLisle
The Vectored External Interrupt Controller mode present in the MIPS 34Kc and 1004Kc variants causes the CPU to stop dispatching interrupts by the normal code path and instead it sends those interrupts to the external interrupt controller to be prioritized, renumbered, and sent back. When they come back, they are handled through a different path using a dispatch table, so plat_irq_dispatch() never sees action. This of course subverts the traditional intc hierarchy, and on the 1004Kc the interrupt controller is standardized (IRQ_GIC) so it can be reasonably considered part of the CPU itself - and tighter coupling between IRQ_GIC and arch/mips/* is tolerable. However on the 34Kc the intc is defined by each SoC vendor, so it's required to have a modular driver - but for a device which in fact ends up taking over the entire interrupt system. Let the DT describe which IRQs which come from the CPU and should be routed back and handled by the CPU intc. These particularly include the two IPI interrupts which would otherwise necessitate duplication of all the IPI supporting infrastructure from the CPU intc. Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260430164157.6026-3-cjd@cjdns.fr
2026-05-11mmc: dw_mmc: Move misplaced commentShawn Lin
It was originally part of the @cmd_status field description but became separated and now appears between @ring_size and @dms without proper context. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-05-11mmc: core: Add validation for host-provided max_segsShawn Lin
The max_segs field is of type unsigned short, and if a host driver sets an excessively large value, it may be truncated to zero. This can cause mmc_alloc_sg() to call kmalloc_objs() with a zero size allocation request, which leads to undefined behavior. Under the SLUB allocator, kmalloc(0) returns a special pointer (ZERO_SIZE_PTR). The subsequent 'if (sg)' check will evaluate to true, and sg_init_table() will then attempt to access invalid memory, resulting in a crash: dwmmc_rockchip 2a310000.mmc: Successfully tuned phase to 133 mmc1: new UHS-I speed SDR104 SDHC card at address aaaa Unable to handle kernel paging request at virtual address 0000001ffffffff0 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000102c88000 [0000001ffffffff0] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 2 UID: 0 PID: 102 Comm: kworker/2:1 Not tainted 7.0.0-rc6-next-20260331-00013-g4d93c25963c5-dirty #80 PREEMPT Hardware name: Rockchip RK3576 EVB V10 Board (DT) Workqueue: events_freezable mmc_rescan pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sg_init_table+0x2c/0x50 lr : sg_init_table+0x24/0x50 sp : ffff8000837db710 x29: ffff8000837db710 x28: 000000000000c000 x27: 0000000000000300 x26: 0000000000000000 x25: 0000000000000040 x24: ffff0000c46a0000 x23: 0000000000000000 x22: ffff0000c0c73c00 x21: 0000000000000010 x20: 0000000000000010 x19: 0000000000000000 x18: 000000000000002c x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 x14: 0000000000000400 x13: ffff8000837dc000 x12: 0000000000000000 x11: ffff0000c0c73ca0 x10: 0000000000000040 x9 : 459ec1f0abbdbb00 x8 : 0000001fffffffe0 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000035579 x4 : 0000000000000901 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000010 Call trace: sg_init_table+0x2c/0x50 (P) mmc_mq_init_request+0x64/0x90 blk_mq_alloc_map_and_rqs+0x3ac/0x480 blk_mq_alloc_set_map_and_rqs+0x98/0x1e0 blk_mq_alloc_tag_set+0x1c0/0x290 mmc_init_queue+0x120/0x370 mmc_blk_alloc_req+0x150/0x420 To prevent this, add a validation check in mmc_mq_init_request() to detect when sg_len (derived from max_segs) is zero. If sg_len is zero, we return an error and print an error message, allowing host driver developers to identify and fix incorrect max_segs configuration. This is a defensive measure that ensures the MMC core fails gracefully when host drivers provide invalid max_segs values, rather than crashing with a page fault. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-05-11rust: driver core: remove drvdata() and driver_typeDanilo Krummrich
When drvdata() was introduced in commit 6f61a2637abe ("rust: device: introduce Device::drvdata()"), its commit message already noted that a direct accessor to the driver's bus device private data is not commonly required -- bus callbacks provide access through &self, and other entry points (IRQs, workqueues, IOCTLs, etc.) carry their own private data. The sole motivation for drvdata() was inter-driver interaction -- an auxiliary driver deriving the parent's bus device private data from the parent device. However, drvdata() exposes the driver's bus device private data beyond the driver's own scope. This creates ordering constraints; for instance drvdata may not be set yet when the first caller of drvdata() can appear. It also forces the driver's bus device private data to outlive all registrations that access it, which causes unnecessary complications. Private data should be private to the entity that issues it, i.e. bus device private data belongs to bus callbacks, class device private data to class callbacks, IRQ private data to the IRQ handler, etc. With registration-private data now available through the auxiliary bus, there is no remaining user of drvdata(), thus remove it. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260505152400.3905096-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-11rust: auxiliary: add registration data to auxiliary devicesDanilo Krummrich
Add a registration_data pointer to struct auxiliary_device, allowing the registering (parent) driver to attach private data to the device at registration time and retrieve it later when called back by the auxiliary (child) driver. By tying the data to the device's registration, Rust drivers can bind the lifetime of device resources to it, since the auxiliary bus guarantees that the parent driver remains bound while the auxiliary device is bound. On the Rust side, Registration<T> takes ownership of the data via ForeignOwnable. A TypeId is stored alongside the data for runtime type checking, making Device::registration_data<T>() a safe method. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260505152400.3905096-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-11gpio: spear-spics: Add COMPILE_TEST supportRosen Penev
The SPEAr SPI chip-select GPIO driver only depends on generic platform, OF, and MMIO interfaces, so it can be built outside SPEAr platform configurations. Enable compile-test coverage to catch build regressions on other architectures. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260510195531.10561-1-rosenp@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-11irqchip/riscv-imsic: Clear interrupt move state during CPU offliningYong-Xuan Wang
Affinity changes of IMSIC interrupts have to be careful to not lose an interrupt in the process. Each vector keeps track of an affinity change in progress with two pointers in struct imsic_vector. imsic_vector::move_prev points to the previous CPU target data and imsic_vector::move_next to the designated new CPU target data. imsic_vector::move_prev on the new CPU can only be cleared after the previous CPU has cleared imsic_vector::move_next, which ususally happens in __imsic_remote_sync(). In case of CPU hot-unplug __imsic_remote_sync() is not invoked because the CPU is already marked offline. That means imsic_vector::move_prev becomes stale until the CPU is onlined again. The stale pointer prevents further affinity changes for the affected interrupts. Solve this by clearing the imsic_vector::move_prev pointers in the CPU hotplug offline path. [ tglx: Replace word salad in change log ] Fixes: 0f67911e821c ("irqchip/riscv-imsic: Separate next and previous pointers in IMSIC vector") Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260508-imsic-v2-1-e9f08dd46cf5@sifive.com
2026-05-11irqchip/meson-gpio: Use the correct register in meson_s4_gpio_irq_set_type()Xianwei Zhao
meson_s4_gpio_irq_set_type() uses the both-edge trigger register for configuring level type and single edge mode interrupts, which is not correct. Use REG_EDGE_POL instead. Fixes: bbd6fcc76b39 ("irqchip: Add support for Amlogic A4 and A5 SoCs") Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260508-a9-gpio-irqchip-v1-1-9dc5f3e022e0@amlogic.com
2026-05-11irqchip/meson-gpio: Add support for Amlogic A9 SoCsXianwei Zhao
The Amlogic A9 SoCs supports the following GPIO interrupt lines: A9 IRQ Number: - 95:86 10 pins on bank Y - 85:84 2 pins on bank CC - 83:64 20 pins on bank A - 63:48 16 pins on bank Z - 47:30 18 pins on bank X - 29:22 8 pins on bank H - 21:14 8 pins on bank M - 13:0 14 pins on bank B A9 AO IRQ Number: - 38 1 pins on bank TESTN - 37:31 7 pins on bank C - 30:13 18 pins on bank D - 12:0 13 pins on bank AO Update the driver to handle these variants. Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260508-a9-gpio-irqchip-v1-3-9dc5f3e022e0@amlogic.com
2026-05-11Merge branch 'irq/urgent' into irq/driversThomas Gleixner
to synchronize upstream fixes on which other changes depend on.
2026-05-11irqchip/meson-gpio: Use the correct register in meson_s4_gpio_irq_set_type()Xianwei Zhao
meson_s4_gpio_irq_set_type() uses the both-edge trigger register for configuring level type and single edge mode interrupts, which is not correct. Use REG_EDGE_POL instead. Fixes: bbd6fcc76b39 ("irqchip: Add support for Amlogic A4 and A5 SoCs") Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260508-a9-gpio-irqchip-v1-1-9dc5f3e022e0@amlogic.com
2026-05-11irqchip/ath79-cpu: Remove unused functionRosen Penev
ath79_cpu_irq_init() was part of the legacy pre-OF code that got removed a while back. Remove it to get rid of a missing prototype warning, reported by the kernel test robot. [ tglx: Fix the subject prefix. Sigh ... ] Fixes: 51fa4f8912c0 ("MIPS: ath79: drop legacy IRQ code") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260506085522.1210143-1-rosenp@gmail.com Closes: https://lore.kernel.org/oe-kbuild-all/202412011509.kGQkDr1y-lkp@intel.com/
2026-05-11irqchip/gic-v5: Allocate ITS parent LPIs as a rangeSascha Bischoff
The ITS MSI domain no longer manages LPI allocation directly. LPIs are allocated and freed by the parent LPI domain, which can now handle a full range of interrupts and unwind partial allocations internally. Make the ITS domain request and release the parent IRQs as a single range instead of iterating over each interrupt. The ITS allocation path then only needs to reserve EventIDs, allocate the parent range, and fill in the ITS irq_data for each MSI. Since no operation in the per-MSI loop can fail, the partial parent-free unwind becomes unnecessary. On teardown, reset the ITS irq_data for the range and then release the parent range in one call, leaving LPI teardown to the LPI domain. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260506093634.382062-4-sascha.bischoff@arm.com
2026-05-11irqchip/gic-v5: Support range allocation for LPIsSascha Bischoff
The per-IPI parent allocation loop returns immediately on failure and leaks any parent interrupts allocated by earlier iterations. The GICv5 LPI domain now owns LPI allocation and teardown internally, but its irq_domain callbacks still reject requests where nr_irqs is greater than one. This forces child domains to allocate and free LPIs one at a time even when the interrupt core requests a contiguous range. Handle multi-interrupt allocation and teardown in the LPI domain by iterating over the requested range and unwinding any partially allocated state on failure. Allocate the parent LPIs for the IPI domain with a single range request as well, which cures the leakage problem. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260506093634.382062-3-sascha.bischoff@arm.com
2026-05-11irqchip/gic-v5: Move LPI allocation into the LPI domainSascha Bischoff
The IPI and ITS MSI domains currently allocate and release LPIs directly, then pass the selected LPI ID to the parent LPI domain. This leaks the LPI domain's allocation policy into its child domains and forces each child to duplicate part of the parent domain's teardown. Make the LPI domain allocate LPIs in its .alloc() callback and release them in a matching .free() callback. Child domains can then request a parent interrupt without passing an implementation-specific LPI ID, and the LPI lifetime is tied to the domain that owns the LPI namespace. Remove the gicv5_alloc_lpi() and gicv5_free_lpi() wrappers now that no external caller needs to manage LPIs directly. This is a preparatory change for an actual leakage problem in the allocation code and therefore tagged with the same Fixes tag. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260506093634.382062-2-sascha.bischoff@arm.com
2026-05-11staging: rtl8723bs: fix buffer over-read in rtw_update_protectionSalman Alghamdi
rtw_update_protection() is called with a pointer offset into the ies buffer but the full ie_length is passed, causing a potential buffer over-read. Fixes: e945c43df60b ("Staging: rtl8723bs: Delete dead code from update_current_network()") Fixes: d3fcee1b78a5 ("staging: rtl8723bs: fix camel case in struct wlan_bssid_ex") Reported-by: Luka Gejak <luka.gejak@linux.dev> Closes: https://lore.kernel.org/linux-staging/DI2H39EAAFBZ.3KI5NWN02AQ2S@linux.dev Cc: stable@vger.kernel.org Signed-off-by: Salman Alghamdi <me@cipherat.com> Reviewed-by: Luka Gejak <luka.gejak@linux.dev> Link: https://patch.msgid.link/20260508222649.23989-1-me@cipherat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11Merge tag 'ib-gpio-add-gpiod-is-single-ended-for-v7.2' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into gpio/for-next Immutable branch betweeb the GPIO and I2C trees for v7.2-rc1 - add the gpiod_is_single_ended() helper function
2026-05-11gpiolib: add gpiod_is_single_ended() helperJie Li
The direction of a single-ended (open-drain or open-source) GPIO line cannot always be reliably determined by reading hardware registers. In true open-drain implementations, the "high" state is achieved by entering a high-impedance mode, which many hardware controllers report as "input" even if the software intends to use it as an output. This creates issues for consumer drivers (like I2C) that rely on gpiod_get_direction() to decide if a line can be driven. Introduce gpiod_is_single_ended() to allow consumers to check the software configuration (GPIO_FLAG_OPEN_DRAIN/GPIO_FLAG_OPEN_SOURCE) of a descriptor. This provides a robust way to identify lines that are capable of being driven, regardless of their instantaneous hardware state. Signed-off-by: Jie Li <jie.i.li@nokia.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260511113726.49041-2-jie.i.li@nokia.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-11spi: Use FIELD_MODIFY() for bitfield operationsMark Brown
Hans Zhang <18255117159@163.com> says: Replace open-coded bitfield modifications with the standard FIELD_MODIFY() macro across multiple SPI controller drivers. This improves readability and adds compile-time checking without functional changes. Each patch modifies a single driver, allowing independent review and application. Link: https://patch.msgid.link/20260430155456.36998-1-18255117159@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-11spi: uniphier: Use FIELD_MODIFY()Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260430155456.36998-11-18255117159@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-11spi: sunplus-sp7021: Use FIELD_MODIFY()Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260430155456.36998-10-18255117159@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-11spi: stm32-qspi: Use FIELD_MODIFY()Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Link: https://patch.msgid.link/20260430155456.36998-9-18255117159@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-11spi: stm32-ospi: Use FIELD_MODIFY()Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Link: https://patch.msgid.link/20260430155456.36998-8-18255117159@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-11spi: sn-f-ospi: Use FIELD_MODIFY()Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260430155456.36998-7-18255117159@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-11spi: nxp-xspi: Use FIELD_MODIFY()Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260430155456.36998-6-18255117159@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-11spi: meson-spicc: Use FIELD_MODIFY()Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260430155456.36998-5-18255117159@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-11spi: cadence-xspi: Use FIELD_MODIFY()Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260430155456.36998-4-18255117159@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-11spi: amlogic-spisg: Use FIELD_MODIFY()Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260430155456.36998-3-18255117159@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-11spi: amlogic-spifc-a1: Use FIELD_MODIFY()Hans Zhang
Use FIELD_MODIFY() to remove open-coded bit manipulation. No functional change intended. Signed-off-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260430155456.36998-2-18255117159@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-11platform/x86: lenovo-wmi-other: Limit adding attributes to supported devicesDerek J. Clark
Adds lwmi_is_attr_01_supported, and only creates the attribute subfolder if the attribute is supported by the hardware. Due to some poorly implemented BIOS this is a multi-step sequence of events. This is because: - Some BIOS support getting the capability data from custom mode (0xff), while others only support it in no-mode (0x00). - Some BIOS support get/set for the current value from custom mode (0xff), while others only support it in no-mode (0x00). - Some BIOS report capability data for a method that is not fully implemented. - Some BIOS have methods fully implemented, but no complimentary capability data. To ensure we only expose fully implemented methods with corresponding capability data, we check each outcome before reporting that an attribute can be supported. Checking for lwmi_is_attr_01_supported during remove is not done to ensure that we don't attempt to call cd01 or send WMI events if one of the interfaces being removed was the cause of the driver unloading. Fixes: edc4b183b794 ("platform/x86: Add Lenovo Other Mode WMI Driver") Reported-by: Kurt Borja <kuurtb@gmail.com> Closes: https://lore.kernel.org/platform-driver-x86/DG60P3SHXR8H.3NSEHMZ6J7XRC@gmail.com/ Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang <i@rong.moe> Tested-by: Rong Zhang <i@rong.moe> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-10-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-11platform/x86: lenovo-wmi-other: Add Attribute ID helper functionsDerek J. Clark
Adds lwmi_attr_id() function. In the same vein as LWMI_ATTR_ID_FAN_RPM(), but as a generic, to de-duplicate attribute_id assignment boilerplate. Adds tunable_attr_01_id() function that breaks out the members of a tunable_attr_01 struct and passes them to lwmi_attr_id(). No functional change intended. Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang <i@rong.moe> Tested-by: Rong Zhang <i@rong.moe> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-9-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-11platform/x86: lenovo-wmi-helpers: Move gamezone enums to wmi-helpersDerek J. Clark
In a later patch in the series the thermal mode enum will be accessed across three separate drivers (wmi-capdata, wmi-gamezonem and wmi-other). An additional patch in the series will also add a function prototype that needs to reference this enum in wmi-helpers.h. To avoid having all these drivers begin to import each others headers, and to avoid declaring an opaque enum to hande the second case, move the thermal mode enum to helpers where it can be safely accessed by everything that needs it from a single import. While at it, since the gamezone_events_type enum is the only remaining item in the header, move that as well and remove the gamezone header entirely. Cc: stable@vger.kernel.org Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Rong Zhang <i@rong.moe> Tested-by: Rong Zhang <i@rong.moe> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-8-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-11platform/x86: lenovo: Decouple lenovo-wmi-gamezone and lenovo-wmi-otherRong Zhang
Currently, lenovo-wmi-gamezone depends on lenovo-wmi-other as the former imports symbols from the latter. The imported symbols are just used to register a notifier block. However, there is no runtime dependency between both drivers, and either of them can run without the other, which is the major purpose of using the notifier framework. Such a link-time dependency is non-optimal. A previous attempt to "fix" it made LENOVO_WMI_GAMEZONE select LENOVO_WMI_TUNING, which was fundamentally broken and resulted in undefined Kconfig behavior, as `select' cannot be used on a symbol with potentially unmet dependencies. Decouple both drivers by moving the thermal mode notifier chain to lenovo-wmi-helpers. Methods for notifier block (un)registration are exported for lenovo-wmi-gamezone, while a method for querying the current thermal mode are exported for lenovo-wmi-other. This turns the dependency graph from +------------ lenovo-wmi-gamezone | | v | lenovo-wmi-helpers | ^ | | V +------------ lenovo-wmi-other into +------------ lenovo-wmi-gamezone | v lenovo-wmi-helpers ^ | +------------ lenovo-wmi-other To make it clear, the name of the notifier chain is also renamed from `om_chain_head' to `tm_chain_head', indicating that it's used to query the current thermal mode. No functional change intended. Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Fixes: 6e38b9fcbfa3 ("platform/x86: lenovo: gamezone needs "other mode"") Cc: stable@vger.kernel.org Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202603252259.gHvJDyh3-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202603260302.X0NjQOda-lkp@intel.com/ Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-7-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-11platform/x86: lenovo-wmi-other: Fix tunable_attr_01 struct membersDerek J. Clark
In struct tunable_attr_01 the capdata pointer is unused and the size of the id members is u32 when it should be u8. Fix these prior to adding additional members. No functional change intended. Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang <i@rong.moe> Tested-by: Rong Zhang <i@rong.moe> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-6-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-11platform/x86: lenovo-wmi-other: Zero initialize WMI argumentsDerek J. Clark
Adds explicit initialization of wmi_method_args_32 declarations with zero values to prevent uninitialized data from being sent to the device BIOS when passed. No functional change intended. Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Fixes: 22024ac5366f ("platform/x86: Add Lenovo Gamezone WMI Driver") Fixes: edc4b183b794 ("platform/x86: Add Lenovo Other Mode WMI Driver") Reported-by: Rong Zhang <i@rong.moe> Closes: https://lore.kernel.org/platform-driver-x86/95c7e7b539dd0af41189c754fcd35cec5b6fe182.camel@rong.moe/ Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang <i@rong.moe> Tested-by: Rong Zhang <i@rong.moe> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Link: https://patch.msgid.link/20260510042546.436874-5-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-06 08:08:58 +0000