summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-06-10of: cpu: add check in __of_find_n_match_cpu_property()Sergey Shtylyov
In __of_find_n_match_cpu_property(), checking the variable ac for 0 won't prevent a possible overflow when multiplying it by sizeof(*cell). Besides, of_read_number() (called in the *for* loop) can't return correct result if that variable (which equals the #address-cells prop's value) exceeds 2, so additionally checking for that seems logical... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: f3cea45a77c8 ("of: Fix iteration bug over CPU reg properties") Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev> Link: https://patch.msgid.link/0c7bf7e9-887c-42d5-bcfb-0ba7fe1e70b6@auroraos.dev Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-06-10Input: remove changelogsElliot Tester
There is no need to keep changelogs in driver sources, they are tracked in git. Signed-off-by: Elliot Tester <elliotctester1@gmail.com> Link: https://patch.msgid.link/20260514193302.117488-1-elliotctester1@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-10cxl/port: update reference to removed CONFIG_PROVE_CXL_LOCKINGEthan Nelson-Moore
A comment in drivers/cxl/port.c refers to CONFIG_PROVE_CXL_LOCKING, which was removed in commit 38a34e10768c ("cxl: Drop cxl_device_lock()"). That commit switched CXL subsystem locking to custom lock classes, which can be validated via the standard CONFIG_PROVE_LOCKING option. Update the comment to reflect this. Discovered while searching for CONFIG_* symbols referenced in code but not defined in any Kconfig file. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Reviewed-by: Dan Williams <djbw@kernel.org> Reviewed-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260610042101.222349-1-enelsonmoore@gmail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-06-10RDMA/core: Fix broadcast address falsely detected as localMaher Sanalla
When rdma_resolve_addr() is invoked with a broadcast destination on an IPoIB interface, is_dst_local() inspects the resolved route and incorrectly concludes that the address is local. As a result, the resolution fails with -ENODEV. The issue stems from using '&' to compare rt_type with RTN_LOCAL. The RTN_* values form a sequential enum, not a bitmask (RTN_LOCAL=2, RTN_BROADCAST=3). Thus, "rt_type & RTN_LOCAL" yields a non-zero result for a broadcast route as well. Replace '&' with '==' when comparing rt_type against RTN_LOCAL. Link: https://patch.msgid.link/r/20260609-fix-rdma-resolve-addr-v1-1-449b8b4e6c09@nvidia.com Cc: stable@vger.kernel.org Fixes: c31e4038c97f ("RDMA/core: Use route entry flag to decide on loopback traffic") Signed-off-by: Maher Sanalla <msanalla@nvidia.com> Reviewed-by: Vlad Dumitrescu <vdumitrescu@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-10RDMA/bnxt_re: Check debugfs parameter allocation for failureRuoyu Wang
bnxt_re_debugfs_add_pdev() allocates per-file private data for the CC configuration debugfs entries. The loop that initializes those entries uses rdev->cc_config_params immediately, so allocation failure would lead to NULL pointer dereferences while setting up debugfs. Debugfs is best-effort. If the CC configuration private data cannot be allocated just stop. Link: https://patch.msgid.link/r/20260606040644.13-1-ruoyuw560@gmail.com Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-10Input: Drop unused assignments from pnp_device_id arraysUwe Kleine-König (The Capable Hub)
Explicitly assigning .driver_data in drivers that don't use this member is silly and a bit irritating. Drop these. Also simplify the list terminator entry to be just empty to match what most other device_id tables do. There is no changed semantic, not even a change in the compiled result. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/f987c14dea1d3236d3889e5cf96c01eef6a2445d.1781016727.git.u.kleine-koenig@baylibre.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-10PCI: rcar-host: Remove unused LIST_HEAD(res)Lad Prabhakar
Remove the unused LIST_HEAD(res) declaration from rcar_pcie_hw_enable(). The macro instantiation defines an unused 'struct list_head res' variable, which conflicts with a valid resource loop-local 'struct resource *res' declaration further down in the function, triggering a compiler variable shadowing warning: drivers/pci/controller/pcie-rcar-host.c:357:34: warning: declaration of 'res' shadows a previous local [-Wshadow] 357 | struct resource *res = win->res; Fixes: ce351636c67f75a9 ("PCI: rcar: Add suspend/resume") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://patch.msgid.link/20260521091256.15737-1-prabhakar.mahadev-lad.rj@bp.renesas.com
2026-06-10HID: hid-goodix-spi: validate report size to prevent stack buffer overflowTianchu Chen
goodix_hid_set_raw_report() builds a protocol frame in a 128-byte stack buffer (tmp_buf), writing an 11-12 byte header followed by the caller-supplied report data. The HID core caps report size at HID_MAX_BUFFER_SIZE (16384) by default, while the driver does not set hid_ll_driver.max_buffer_size and performs no bounds checking before copying the payload: memcpy(tmp_buf + tx_len, buf, len); A hidraw SET_REPORT ioctl with a report larger than ~116 bytes overflows the stack buffer. Add a size check after constructing the header, rejecting reports that would exceed the buffer capacity. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: 75e16c8ce283 ("HID: hid-goodix: Add Goodix HID-over-SPI driver") Cc: stable@vger.kernel.org Signed-off-by: Tianchu Chen <flynnnchen@tencent.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-06-10drm/xe: include all registered queues in TLB invalidationTangudu Tilak Tirumalesh
Context-based TLB invalidation currently selects only scheduling-active exec queues via q->ops->active(). During rebind flows, queues may be suspended (or transitioning through resume) while still owning valid translations, causing them to be skipped from invalidation and leading to missed TLB invalidations on LR rebinds. The underlying issue is a TOCTOU: q->guc->state bits are flipped lock-free from enable_scheduling(), disable_scheduling{,_deregister}(), the suspend/resume sched-msg handlers, handle_sched_done(), and guc_exec_queue_stop(); nothing in send_tlb_inval_ctx_ppgtt() serializes against them, so any state-based predicate can race. Include all the registered queues so that TLB invalidations are not missed. This is race-free because list membership on vm->exec_queues.list is stable under vm->exec_queues.lock held by the caller. The performance impact is expected to be minimal and harmless. If it does turn out to be a concern, we can come back with a race-safe solution to ignore certain queues. Fixes: 6cdaa5346d6f ("drm/xe: Add context-based invalidation to GuC TLB invalidation backend") Assisted-by: Claude:claude-opus-4.6 Suggested-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260608162745.338725-2-tilak.tirumalesh.tangudu@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> (cherry picked from commit aa625e1e9f0710e424fe4f0e3f032807df81b5b0) Signed-off-by: Matthew Brost <matthew.brost@intel.com>
2026-06-10drm/xe/hw_error: Use HW_ERR prefix in logRaag Jadav
Hardware errors should be logged with HW_ERR prefix. Make them consistent with existing logs. Fixes: 01aab7e1c9d4 ("drm/xe/xe_hw_error: Add support for PVC SoC errors") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20260602044919.702209-5-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit ad60a618c49fef07d1860bfb1091140d29f5eddb) Signed-off-by: Matthew Brost <matthew.brost@intel.com>
2026-06-10drm/xe/drm_ras: Add per node cleanup actionRaag Jadav
cleanup_node_param() is not registered for previous node in case of counter allocation failure, which results in stale memory of previous node that isn't cleaned up on unwind. Add per node cleanup action which guarantees cleanup on unwind and also simplifies the cleanup logic. Fixes: b40db12b542f ("drm/xe/xe_drm_ras: Add support for XE DRM RAS") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20260602044919.702209-4-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 67fc5543d8274b2fcbef87734fad0469358f4478) Signed-off-by: Matthew Brost <matthew.brost@intel.com>
2026-06-10drm/xe/drm_ras: Make counter allocation drm managedRaag Jadav
cleanup_node_param() is not registered for previous node in case of counter allocation failure, which results in stale memory of previous node that isn't cleaned up on unwind. Fix this using drm managed allocation, which is guaranteed to be cleaned up on unwind. Fixes: b40db12b542f ("drm/xe/xe_drm_ras: Add support for XE DRM RAS") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20260602044919.702209-3-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 58d77c77ea0c5cb2b755ebe23e973c8272acd896) Signed-off-by: Matthew Brost <matthew.brost@intel.com>
2026-06-10drm/xe/display: fix oops in suspend/shutdown without displayJani Nikula
The xe driver keeps track of whether to probe display, and whether display hardware is there, using xe->info.probe_display. It gets set to false if there's no display after intel_display_device_probe(). However, the display may also be disabled via fuses, detected at a later time in intel_display_device_info_runtime_init(). In this case, the xe driver does for_each_intel_crtc() on uninitialized mode config in xe_display_flush_cleanup_work(), leading to a NULL pointer dereference, and generally calls display code with display info cleared. Check for intel_display_device_present() after intel_display_device_info_runtime_init(), and reset xe->info.probe_display as necessary. Also do unset_display_features() for completeness, although display runtime init has already done that. This will need to be unified across all cases later. Move intel_display_device_info_runtime_init() call slightly earlier, similar to i915, to avoid a bunch of unnecessary setup for no display cases. Note #1: The xe driver has no business doing low level display plumbing like for_each_intel_crtc() to begin with. It all needs to happen in display code. Note #2: The actual bug is present already in commit 44e694958b95 ("drm/xe/display: Implement display support"), but the oops was likely introduced later at commit ddf6492e0e50 ("drm/xe/display: Make display suspend/resume work on discrete"). Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7904 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/6150 Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260515160920.1082842-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 7c3eb9f47533220888a67266448185fd0775d4da) Signed-off-by: Matthew Brost <matthew.brost@intel.com>
2026-06-10HID: nintendo: add support for HORI Wireless Switch PadHector Zelaya
Add support for the HORI Wireless Switch Pad (vendor 0x0f0d, product 0x00f6), a licensed third-party Nintendo Switch Pro Controller. The controller reports controller type 0x06 (vs 0x03 for first-party Pro Controllers) and has the following quirks: - SPI flash calibration data is incompatible; use default stick calibration values instead. - X and Y button bits are swapped compared to first-party controllers; add a dedicated button mapping table. - Rumble and IMU enable may timeout (no vibration motor in hardware); treat as non-fatal for licensed controllers. Tested over Bluetooth on NixOS with kernel 7.0.5 and 7.0.10: - All 14 buttons map correctly - Player LED sets on connect - Sticks report correctly with default calibration - IMU/gyro data streams at 60Hz - D-pad reports on ABS_HAT0X/HAT0Y Device information: Bluetooth name: Lic Pro Controller Bluetooth HID: 0005:0F0D:00F6 Assisted-by: Kiro:Auto [Amazon Kiro IDE] Signed-off-by: Hector Zelaya <hector@hectorzelaya.dev> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-06-10HID: multitouch: Honor ContactCount for Yoga Book 9 to suppress ghost contactsDave Carey
The INGENIC 17EF:6161 firmware on the Lenovo Yoga Book 9 14IAH10 does not clear stale contact slots when fingers are lifted. Each HID report contains up to 10 finger slots, but only the first ContactCount slots represent valid contacts; the remaining slots retain TipSwitch=1 with positions from previous touches. Raw HID capture confirms this: across a 60-second capture with repeated multi-finger gestures, 90% of frames had more TipSwitch=1 slots than the reported ContactCount. The ContactCount field itself is always accurate. Add MT_QUIRK_CONTACT_CNT_ACCURATE to the MT_CLS_YOGABOOK9I class so the driver stops processing slots once ContactCount valid contacts have been consumed, discarding the stale ghost entries per HID specification section 17. MT_QUIRK_NOT_SEEN_MEANS_UP (already in the class) ensures that any slot skipped by this guard is released via INPUT_MT_DROP_UNUSED at frame sync. Signed-off-by: Dave Carey <carvsdriver@gmail.com> Tested-by: Dave Carey <carvsdriver@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-06-10HID: pidff: Use correct effect type in effect updateOleg Makarenko
When updating an existing effect, the effect type from the last created effect was sent to the device instead of the updated one. This caused incorrect reports when a game creates multiple different effects and updates only one that is not the last created. Fixes FFB in multiple games that create multiple simultaneous effects (Forza Horizon 5/6). Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices") Cc: stable@vger.kernel.org Tested-by: Oliver Roundtree <oroundtree1@gmail.com> Co-developed-by: Ryno Kotzé <lemon.xah@gmail.com> Signed-off-by: Ryno Kotzé <lemon.xah@gmail.com> Signed-off-by: Oleg Makarenko <oleg@makarenk.ooo> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-06-10HID: wacom: stop hardware after post-start probe failuresMyeonghun Pak
wacom_parse_and_register() starts HID hardware before registering inputs and initializing pad LEDs/remotes. Those later steps can fail, but their error paths currently release Wacom resources without stopping the HID hardware. Route post-hid_hw_start() failures through hid_hw_stop() before releasing driver resources. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: c1d6708bf0d3 ("HID: wacom: Do not register input devices until after hid_hw_start") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-06-10HID: core: demote warning to debug levelMatteo Croce
The log level for short messages was changed from debug to warning, flooding syslog on systems with devices that regularly send short reports, in my case an UPS: $ dmesg |grep -c 'Event data for report .* was too short' 35 Demote it back to debug level. Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") Signed-off-by: Matteo Croce <teknoraver@meta.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-06-10spi: rzv2h-rspi: Fix SPDR read access width for 16-bit RXFelix Gu
The RZ/V2H hardware manual (section 7.5.2.2.1) specifies that read access size for the SPI Data Register (SPDR) are fixed at 32 bits. The RZV2H_RSPI_RX macro for the 16-bit data path used readw(), violating this requirement. Switch to readl() for the 16-bit RX path to conform to the hardware specification. Fixes: 8b61c8919dff ("spi: Add driver for the RZ/V2H(P) RSPI IP") Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Felix Gu <ustc.gu@gmail.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Link: https://patch.msgid.link/20260610-rzv2h-rspi-v2-1-40c80b4a2c90@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10HID: lenovo: Use KEY_PERFORMANCE capability for ThinkPad X12 Tab Gen 2Vishnu Sankar
The X12 Tab Gen 2 emits KEY_PERFORMANCE via Fn+F8 through the raw event handler but never declared the capability via input_set_capability(). This prevents userspace tools from discovering the key through evdev capability bits. Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-06-10HID: lenovo: Add support for ThinkPad X13 Folio keyboardVishnu Sankar
Add USB ID support for the ThinkPad X13 detachable keyboard. The Keyboard uses the same HID raw event protocol as the ThinkPad X12 Gen 2. The functionality stays the same with X12 Gen 2 Keyboards. Also declare KEY_PERFORMANCE capability in lenovo_input_configured() for X13 detachable, allowing userspace to discover the key via evdev capability bits. Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-06-10HID: cp2112: Configure I2C bus speed from firmwareDanny Kaehn
Now that the I2C adapter on the CP2112 can have an associated firmware node, set the bus speed based on firmware configuration Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-06-10HID: cp2112: Add fwnode supportDanny Kaehn
Support describing the CP2112's I2C and GPIO interfaces in firmware. Bindings between the firmware nodes and the functions of the device are distinct between ACPI and DeviceTree. For ACPI, the i2c_adapter will use the child with _ADR equal to Zero and the gpio_chip will use the child with _ADR equal to One. For DeviceTree, the i2c_adapter will use the child with name "i2c", but the gpio_chip will share a firmware node with the CP2112. Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Tested-by: Jacky Huang <jackyhuang@nvidia.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-06-10net: dsa: yt921x: Add ACL supportDavid Yang
Enable filtering of incoming traffics. Note that custom filters are yet to be utilized, and thus not all flow dissectors are implemented. Tested-by: hong son Nguyen <hongson.hn@gmail.com> Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260606130011.307812-3-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-10nvmet-tcp: handle TCP_CLOSING state in nvmet_tcp_state_changeMaurizio Lombardi
When an NVMe/TCP connection shuts down, the underlying TCP socket can enter the TCP_CLOSING state (state 11). Currently, the nvmet_tcp_state_change() callback does not explicitly handle this state, which results in harmless but noisy kernel warnings: nvmet_tcp: queue 2 unhandled state 11 Add TCP_CLOSING to the switch statement alongside TCP_FIN_WAIT2 and TCP_LAST_ACK to silently ignore the state transition. Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-10fbdev: modedb: fix a possible UAF in fb_find_mode()Tuo Li
If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup. Signed-off-by: Tuo Li <islituo@gmail.com> Cc: stable@vger.kernel.org # v6.5+ Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-10Merge tag 'wireless-next-2026-06-10' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Quite a few last updates, notably: - b43: new support for an 11n device - mt76: - mt792x broken usb transport detection - mt7921 regd improvements - mt7927 support - iwlwifi: - more kunit tests - FW version updates - ath12k: WDS support - rtw89: - RTL8922AU support - USB 3 mode switch for performance - better monitor radiotap support - RTL8922DE preparations - cfg80211/mac80211: - update UHR to D1.4, UHR DBE support - finally remove 5/10 MHz support - S1G rate reporting - multicast encapsulation offload * tag 'wireless-next-2026-06-10' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (285 commits) b43: add RF power offset for N-PHY r8 + radio 2057 r8 b43: add channel info table for N-PHY r8 + radio 2057 r8 b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8 b43: support radio 2057 rev 8 b43: route d11 corerev 22 to 24-bit indirect radio access b43: add d11 core revision 0x16 to id table b43: add firmware mappings for rev22 rfkill: Replace strcpy() with memcpy() wifi: brcmfmac: flowring: simplify flow allocation wifi: brcm80211: change current_bss to value wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits wifi: ath: Update copyright in testmode_i.h wifi: ath10k: Update Qualcomm copyrights wifi: ath11k: Update Qualcomm copyrights wifi: ath12k: Update Qualcomm copyrights wifi: mt76: Drop unneeded mt76_register_debugfs_fops() return checks wifi: mt76: mt7921: assert sniffer on chanctx change wifi: mt76: mt7996: fix potential tx_retries underflow wifi: mt76: mt7925: fix potential tx_retries underflow ... ==================== Link: https://patch.msgid.link/20260610103637.179340-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-10bonding: 3ad: fix mux port state on oper downLouis Scalbert
When the bonding interface has carrier down due to the absence of usable slaves and a slave transitions from down to up, the bonding interface briefly goes carrier up, then down again, and finally up once LACP negotiates collecting and distributing on the port. When lacp_strict mode is on, the interface should not transition to carrier up until LACP negotiation is complete. This happens because the actor and partner port states remain in Collecting_Distributing when the port goes down. When the port comes back up, it temporarily remains in this state until LACP renegotiation occurs. Previously this was mostly cosmetic, but since the bonding carrier state may depend on the LACP negotiation state, it causes the interface to flap. According to IEEE 802.3ad-2000 and IEEE 802.1ax-2014, Collecting and Distributing should be reset when a port goes down: - In the Receive state machine, port_enabled == FALSE causes a transition to the PORT_DISABLED state, which is expected to clear Partner_Oper_Port_State.Synchronization. - In the Mux state machine, Partner_Oper_Port_State.Synchronization == FALSE causes a transition to the ATTACHED state, which disables Collecting and Distributing. However, Partner_Oper_Port_State.Synchronization is not cleared in the PORT_DISABLED state. Clear Partner_Oper_Port_State.Synchronization in the Receive PORT_DISABLED state. Fixes: 655f8919d549 ("bonding: add min links parameter to 802.3ad") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> Acked-by: Jay Vosburgh <jv@jvosburgh.net> Link: https://patch.msgid.link/20260603150331.1919611-6-louis.scalbert@6wind.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-10bonding: 3ad: fix carrier when no usable slavesLouis Scalbert
Apply the "lacp_strict" configuration from the previous commit. "lacp_strict" mode "on" asserts that the bonding master carrier is up only when at least 'min_links' slaves are in the Collecting_Distributing state. Fixes: 655f8919d549 ("bonding: add min links parameter to 802.3ad") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> Acked-by: Jay Vosburgh <jv@jvosburgh.net> Link: https://patch.msgid.link/20260603150331.1919611-5-louis.scalbert@6wind.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-10bonding: 3ad: add lacp_strict configuration knobLouis Scalbert
When an 802.3ad (LACP) bonding interface has no slaves in the collecting/distributing state, the bonding master still reports carrier as up as long as at least 'min_links' slaves have carrier. In this situation, only one slave is effectively used for TX/RX, while traffic received on other slaves is dropped. Upper-layer daemons therefore consider the interface operational, even though traffic may be blackholed if the lack of LACP negotiation means the partner is not ready to deal with traffic. Introduce a configuration knob to control this behavior. It allows the bonding master to assert carrier only when at least 'min_links' slaves are in Collecting_Distributing state. The default mode preserves the existing behavior. This patch only introduces the knob; its behavior is implemented in the subsequent commit. Fixes: 655f8919d549 ("bonding: add min links parameter to 802.3ad") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> Acked-by: Jay Vosburgh <jv@jvosburgh.net> Link: https://patch.msgid.link/20260603150331.1919611-4-louis.scalbert@6wind.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-10nvmet-auth: reject short AUTH_RECEIVE buffersMichael Bommarito
nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target. Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5-5-xhigh Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Hannes Reinecke <hare@kernel.org> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-10nvme-fc: Do not cancel requests in io target before it is initializedMohamed Khalfella
A new nvme-fc controller in CONNECTING state sees admin request timeout schedules ctrl->ioerr_work to abort inflight requests. This ends up calling __nvme_fc_abort_outstanding_ios() which aborts requests in both admin and io tagsets. In case fc_ctrl->tag_set was not initialized we see the warning below. This is because ctrl.queue_count is initialized early in nvme_fc_alloc_ctrl(). nvme nvme0: NVME-FC{0}: starting error recovery Connectivity Loss INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe lpfc 0000:ab:00.0: queue 0 connect admin queue failed (-6). you didn't initialize this object before use? turning off the locking correctness validator. Workqueue: nvme-reset-wq nvme_fc_ctrl_ioerr_work [nvme_fc] Call Trace: <TASK> dump_stack_lvl+0x57/0x80 register_lock_class+0x567/0x580 __lock_acquire+0x330/0xb90 lock_acquire.part.0+0xad/0x210 blk_mq_tagset_busy_iter+0xf9/0xc00 __nvme_fc_abort_outstanding_ios+0x23f/0x320 [nvme_fc] nvme_fc_ctrl_ioerr_work+0x172/0x210 [nvme_fc] process_one_work+0x82c/0x1450 worker_thread+0x5ee/0xfd0 kthread+0x3a0/0x750 ret_from_fork+0x439/0x670 ret_from_fork_asm+0x1a/0x30 </TASK> Update the check in __nvme_fc_abort_outstanding_ios() confirm that io tagset was created before iterating over busy requests. Also make sure to cancel ctrl->ioerr_work before removing io tagset. Reviewed-by: Randy Jennings <randyj@purestorage.com> Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Daniel Wagner <dwagner@suse.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com> Signed-off-by: James Smart <jsmart833426@gmail.com> Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-10nvme: make nvme_add_ns{_head}_cdev return voidJohn Garry
The return code from nvme_add_ns_head_cdev() and nvme_add_ns_cdev() is never checked, so make those functions return void. A cdev add failure is tolerated during initialization, and flags NVME_NS_CDEV_LIVE and NVME_NSHEAD_CDEV_LIVE are for determining whether a cdev needs to be deleted during un-initialization. Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@kernel.org> Signed-off-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-10nvme: make some sysfs diagnostic structures staticJohn Garry
Building with C=1 generates the following warnings: drivers/nvme/host/sysfs.c:397:25: warning: symbol 'dev_attr_io_errors' was not declared. Should it be static? drivers/nvme/host/sysfs.c:444:30: warning: symbol 'nvme_ns_diag_attr_group' was not declared. Should it be static? drivers/nvme/host/sysfs.c:1150:25: warning: symbol 'dev_attr_adm_errors' was not declared. Should it be static? Make those structures static. Closes: https://lore.kernel.org/oe-kbuild-all/202606101329.T3zXNqdy-lkp@intel.com/ Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-10PCI: imx6: Integrate new pwrctrl APISherry Sun
Integrate the PCI pwrctrl framework into the pci-imx6 driver to provide standardized power management for PCI devices. Legacy regulator handling (vpcie-supply at controller level) is maintained for backward compatibility with existing device trees. New device trees should specify power supplies at the Root Port level to utilize the pwrctrl framework. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260520084904.2424253-2-sherry.sun@oss.nxp.com
2026-06-10platform/x86: ISST: Restore SST-PP control to all domainsSrinivas Pandruvada
The SST-PP control offset is only restored to power domain 0 after resume. During suspend, control values are read and stored for all power domains. Use pd_info->sst_base instead of power_domain_info->sst_base, which only points to power domain 0 base address. Fixes: dc7901b5a156 ("platform/x86: ISST: Store and restore all domains data") Reported-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260528204521.3531456-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-10hwmon: (gpd-fan): fix race condition between device removal and sysfs accessPei Xiao
Replace the manual gpd_fan_remove() callback with a devres-managed action using devm_add_action_or_reset(). The original remove hook resets the fan to AUTOMATIC mode, but the hwmon sysfs interface (registered with devm_hwmon_device_register_with_info()) remains active until after the remove callback completes. This creates a race window where a concurrent userspace sysfs access can interleave with the EC I/O sequence, potentially corrupting EC registers. Using devm_add_action_or_reset() registers the reset function as a devres action. Due to the LIFO release order of devres, the hwmon device is unregistered (sysfs removed) before the reset action executes, eliminating the race condition. Fixes: 0ab88e239439 ("hwmon: add GPD devices sensor driver") Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Link: https://lore.kernel.org/r/4400828422cf3a88adad4db224d9efccdb1049d2.1781055639.git.xiaopei01@kylinos.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-10hwmon: (gpd-fan): upgrade log level from warn to err for platform device ↵Pei Xiao
creation failure When platform_create_bundle() fails, the error is fatal and prevents the driver from loading. Use pr_err() instead of pr_warn() to clearly indicate a critical failure. Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Link: https://lore.kernel.org/r/aeb2eaa6df90178b18057a8022a0eccde7bbc82c.1781055639.git.xiaopei01@kylinos.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-10hwmon: (gpd-fan): Initialize EC before registering hwmon devicePei Xiao
Move the gpd_init_ec() call to before devm_hwmon_device_register_with_info in the probe function. With the previous ordering the hwmon device was registered and exposed to userspace before the EC initialization completes, creating a window where sysfs reads could return invalid values. Some buggy firmware won't initialize EC properly on boot. Before its initialization, reading RPM will always return 0, and writing PWM will have no effect. So move gpd_init_ec to before hwmon device register. Fixes: 0ab88e239439 ("hwmon: add GPD devices sensor driver") Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Link: https://lore.kernel.org/r/4be3734b135c8013157979ab5e80c7ee51243ddd.1781055639.git.xiaopei01@kylinos.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-10hwmon: (gpd-fan): drop global driver data and use per-device allocationPei Xiao
replace the global state gpd_driver_priv with per-device private data (struct gpd_fan_data) allocated in probe. This allows the driver to support multiple instances in the future and aligns with kernel best practices. No functional change intended. Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Link: https://lore.kernel.org/r/1cd3e13033fdd3d0f9b59322f7c86e350d113b92.1781055639.git.xiaopei01@kylinos.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-10hwmon: (pmbus/max34440): add support adpm12250Alexis Czezar Torreno
ADPM12250 is a quarter brick DC/DC Power Module. It is a high power non-isolated converter capable of delivering regulated 12V with continuous power level of 2500W. Uses PMBus. Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20260610-dev-adpm12250-v1-1-422760bb80da@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-10watchdog: sc1200: Drop unused assignment of pnp_device_id driver dataUwe Kleine-König (The Capable Hub)
The driver explicitly sets the .driver_data member of struct pnp_device_id to zero without relying on that value. Drop this unused assignments. While touching this array simplify the list terminator. This patch doesn't modify the compiled array, only its representation in source form benefits. The former was confirmed with builds on x86 and arm64. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/0793f81a854f9e5880ad38f54c8583b3d56e5d60.1781081216.git.u.kleine-koenig@baylibre.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-06-10floppy: Drop unused pnp driver dataUwe Kleine-König (The Capable Hub)
The pnp_device_id array is only used for module data to support auto-loading the floppy module. So the .driver_data member is unused and this assignment can be dropped. While touching that array, align the coding style to what is used most for these. This patch doesn't modify the compiled array, only its representation in source form benefits. The former was confirmed with x86 and arm64 builds. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Denis Efremov (Oracle) <efremov@linux.com> Link: https://patch.msgid.link/99dbf851ffb99229ea1dcfd8f58e9ee6a1f05349.1781075967.git.u.kleine-koenig@baylibre.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-06-10platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplugGuixiong Wei
When the last CPU of a legacy uncore die goes offline, uncore_freq_remove_die_entry() clears control_cpu. During CPU hotplug re-add, uncore_freq_add_entry() still populates sysfs attributes before assigning the new control CPU. As a result, the current frequency read returns -ENXIO and current_freq_khz is omitted from the recreated sysfs group. Assign control_cpu before the initial read paths and before create_attr_group() so sysfs recreation uses the new online CPU. If sysfs creation fails, restore control_cpu to -1 to keep the error path state consistent. Fixes: 4d73c6772ab7 ("platform/x86: intel-uncore-freq: Conditionally create attribute for read frequency") Cc: stable@vger.kernel.org Signed-off-by: Guixiong Wei <weiguixiong@bytedance.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20260602020752.3126-1-weiguixiong@bytedance.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-10platform/x86: intel-hid: Protect ACPI notify handler against recursionHyeongJun An
Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") ACPI notify handlers like the intel-hid notify_handler() may run on multiple CPU cores racing with themselves. On convertibles and detachables (matched by DMI chassis-type 31 and 32 in dmi_auto_add_switch[]) the SW_TABLET_MODE input device is registered lazily from notify_handler() on the first tablet-mode event, via intel_hid_switches_setup(). When two such events race on different CPUs both can pass the !priv->switches check and register the priv->switches input device twice, resulting in a duplicate sysfs entry and a subsequent NULL pointer dereference. This is the same class of bug fixed by commit e075c3b13a0a ("platform/x86: intel-vbtn: Protect ACPI notify handler against recursion") for the sibling intel-vbtn driver. Protect intel-hid notify_handler() from racing with itself with a mutex to fix this. Fixes: e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") Cc: stable@vger.kernel.org Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Link: https://patch.msgid.link/20260605174905.131095-1-sammiee5311@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-10platform/x86/intel/vsec: Restore BAR fallback for header walkDavid E. Box
The base_addr refactor changed intel_vsec_walk_header() to pass info->base_addr as the discovery-table base address. For the PCI VSEC driver this info comes from driver_data, but exported callers may provide their own static headers and leave base_addr unset. For xe, this made the discovery-table base address zero instead of the BAR selected by header->tbir, preventing PMT endpoints from being created. Restore the previous behavior for the header-walk path by falling back to pci_resource_start(pdev, header->tbir) when base_addr is not specified. Keep explicit base_addr override behavior unchanged. This preserves the refactor structure while fixing the functional regression in manual-header users. Fixes: 904b333fc51c ("platform/x86/intel/vsec: Refactor base_addr handling") Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: David E. Box <david.e.box@linux.intel.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Link: https://patch.msgid.link/20260529183150.129744-1-david.e.box@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-10platform/x86: dell-laptop: fix missing cleanups in init error pathHaoxiang Li
dell_init() initializes several resources after dell_setup_rfkill(), including the optional touchpad LED, keyboard backlight LED, battery hook, debugfs directory and dell-laptop notifier. If a later LED or backlight registration fails, the error path only tears down the battery hook and rfkill resources. This leaves the notifier, debugfs directory, keyboard backlight LED and optional touchpad LED registered after dell_init() returns an error. Add the missing cleanup calls before tearing down rfkill. Fixes: 9c656b07997f ("platform/x86: dell-*: Call new led hw_changed API on kbd brightness change") Fixes: 037accfa14b2 ("dell-laptop: Add debugfs support") Fixes: 2d8b90be4f1c ("dell-laptop: support Synaptics/Alps touchpad led") Fixes: 6cff8d60aa0a ("platform: x86: dell-laptop: Add support for keyboard backlight") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Link: https://patch.msgid.link/20260609081419.1995169-1-lihaoxiang@isrc.iscas.ac.cn Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-10platform/x86/amd/pmc: Add PMC driver support for AMD 1Ah M80H SoCShyam Sundar S K
The 1Ah M80H SoC uses a different set of SMU mailbox register offsets compared to the existing 1Ah variants: message at 0xA10, argument at 0xA18, and response at 0xA14. Add amd_1ah_m80_cpu_info with these offsets, wire it into the PCI ID table via PCI_DEVICE_DATA(), populate scratch_reg field with AMD_PMC_SCRATCH_REG_1AH and add the corresponding ACPI ID AMDI000C. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20260609143952.2999707-3-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-10platform/x86/amd/pmc: Use per-SoC cpu_info struct for SMU mailbox and IP infoShyam Sundar S K
Replace the scattered per-field assignments in amd_pmc_get_ip_info() with a single amd_pmc_cpu_info struct capturing all SoC-specific parameters such as SMU offsets, IP block table, and OS hint. Define static const instances per SoC variant and embed them as driver_data in the PCI ID table via PCI_DEVICE_DATA(). Consolidate pci_match_id() into amd_pmc_set_cpu_info(), which assigns driver_data directly to cpu_info, the switch falls through only for 1Ah M20H/M60H variants requiring boot_cpu_data.x86_model detection to distinguish the M70 sub-variant. Add scratch_reg to amd_pmc_cpu_info and populate it for each SoC variant, allowing amd_pmc_idlemask_read() to drop its cpu_id switch in favour of a single cpu_info->scratch_reg lookup. Move dev->cpu_id assignment into amd_pmc_set_cpu_info() so it is valid before the switch statement. Handle SP/SHP directly in the switch since their NULL driver_data bypasses the early return, and remove the duplicate check from probe. Remove amd_pmc_get_os_hint() and use cpu_info->os_hint directly at call sites and rename AMD_CPU_ID_* to PCI_DEVICE_ID_AMD_CPU_ID_* with backward compatibility aliases. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20260609143952.2999707-2-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-10platform/x86: intel-hid: Add HP ProBook x360 440 G1 to button_array_tableNikolay Metchev
The volume rocker buttons on the HP ProBook x360 440 G1 convertible emit events 0xc4-0xc7 via the intel-hid ACPI device (INT33D5). These codes are only present in intel_array_keymap, which is used when the "5 button array" input device exists. On this machine button_array_present() returns false because the firmware does not advertise the array through the HEBC method, so notify_handler() routes the events to a NULL priv->array and they are dropped as "unknown event 0xc4". As a result the side volume keys do nothing. Add the machine to button_array_table so the array device is created and the volume rocker emits KEY_VOLUMEUP / KEY_VOLUMEDOWN. This is equivalent to booting with the enable_5_button_array=1 module parameter, which was used to confirm the fix on the affected hardware. Signed-off-by: Nikolay Metchev <nikolaymetchev@gmail.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260609213309.445019-1-nikolaymetchev@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>