summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-05-25drm/exec, drm/xe, drm/amdgpu: Add an accessor for struct drm_exec::ticketThomas Hellström
Drivers were accessing this drm_exec member directly. While that may seem harmless, it will require action if the drm_exec utility is made a subclass of a dma-resv transaction utility as outlined in the cover-letter. Provide an accessor, drm_exec_ticket() to avoid that. v2: - Fix amdgpu compile error (Intel CI) - Update the commit message. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260520101616.41284-5-thomas.hellstrom@linux.intel.com
2026-05-25drm/exec, drm/xe: Avoid abusing the drm_exec retry pointerThomas Hellström
The xe driver was using the drm_exec retry pointer directly to restart the locking loop after out-of-memory errors. This is relying on undocumented behaviour. Instead add a drm_exec_retry() macro that can be used in this situation, and that also warns if the struct drm_exec is not newly (re-)initialized. Use that macro in xe. v2: - Only allow if the drm_exec context is newly initialized. (Christian) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260520101616.41284-4-thomas.hellstrom@linux.intel.com
2026-05-25drm/exec: Remove the index parameter from drm_exec_for_each_locked_obj[_reverse]Thomas Hellström
Nobody makes any use of it. Possible internal future users can instead use the _index variable. External users shouldn't use it since the array it's pointing into is internal drm_exec state. v2: - Use a unique id for the loop variable (Christian) Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260520101616.41284-2-thomas.hellstrom@linux.intel.com
2026-05-25pinctrl: s32cc: use dev_err_probe() and improve error messagesKhristine Andreea Barbulescu
Change dev_err&return statements into dev_err_probe throughout the driver on the probing path. Signed-off-by: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com> Reviewed-by: Enric Balletbo i Serra <eballetb@redhat.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-25pinctrl: avoid duplicate function definitionsArnd Bergmann
The pinctrl_generic_to_map() and pinctrl_generic_pins_function_dt_node_to_map() functions are built whenever CONFIG_GENERIC_PINCTRL is enabled, including configurations without CONFIG_OF. When CONFIG_OF is disabled, the dummy definitions are also present in the header, which causes the build to fail: drivers/pinctrl/pinctrl-generic.c:20:5: error: conflicting types for 'pinctrl_generic_to_map'; have 'int(struct pinctrl_dev *, struct device_node *, struct device_node *, struct pinctrl_map **, unsigned int *, unsigned int *, const char **, unsigned int, const char **, unsigned int *, unsigned int)' 20 | int pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent, | ^~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/pinctrl/pinctrl-generic.c:16: drivers/pinctrl/pinconf.h:193:1: note: previous definition of 'pinctrl_generic_to_map' with type 'int(struct pinctrl_dev *, struct device_node *, struct device_node *, struct pinctrl_map **, unsigned int *, unsigned int *, const char **, unsigned int, const char **, unsigned int *, void *)' 193 | pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent, | ^~~~~~~~~~~~~~~~~~~~~~ drivers/pinctrl/pinctrl-generic.c:130:5: error: redefinition of 'pinctrl_generic_pins_function_dt_node_to_map' 130 | int pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/pinctrl/pinconf.h:184:1: note: previous definition of 'pinctrl_generic_pins_function_dt_node_to_map' with type 'int(struct pinctrl_dev *, struct device_node *, struct pinctrl_map **, unsigned int *)' 184 | pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Removing either set of definitions is sufficient to avoid the problem. Remove the copy from the header for simplicity. Fixes: aaaf31be0426 ("pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()") Fixes: 43722575e5cd ("pinctrl: add generic functions + pins mapper") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-25pinctrl: starfive: jh7110: Avoid ifdefferyLinus Walleij
Use IS_ENABLED() inline assigning a variable instead of ifdeffery. Cc: Rosen Penev <rosenp@gmail.com> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/linux-gpio/CAMuHMdX7t7VHTzybjYo3s8SU3XLEH9GKsxmLBbh7p4D1CT3H_Q@mail.gmail.com/ Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-25pinctrl: starfive: jh7110: Use __counted_by() flexarrayLinus Walleij
Flexible arrays should use __counted_by() to be able to do runtime checks that the array does not go out of range. Cc: Rosen Penev <rosenp@gmail.com> Fixes: 87182ef0bf93 ("pinctrl: starfive: jh7110: use struct_size") Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-25pinctrl: aspeed: Add AST2700 SoC1 supportBilly Tsai
Implement pin multiplexing (and pin configuration where applicable) for the AST2700 SoC1 SCU pinctrl block using static SoC data tables. Unlike legacy ASPEED pin controllers, the SoC1 pin function control fields are highly regular, which makes it practical to describe the packed-field register layout directly in driver data rather than reuse the existing Aspeed pinctrl macro infrastructure. The driver uses the generic pinctrl, pinmux and pinconf frameworks. The controller registers are accessed via regmap from the parent syscon, allowing shared ownership of the SCU register block. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-25accel/ivpu: Document why full JSM message size is always usedKarol Wachowski
Firmware expects IPC messages to always carry the full fixed sizeof(struct vpu_jsm_msg) size. Sending the full struct also ensures unused fields are zeroed, which maintains compatibility when existing commands are extended with new fields in the future. Replace the misleading TODO comment with an explanation of the actual intent. Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20260522093209.1169716-1-karol.wachowski@linux.intel.com
2026-05-25ACPI: button: Add missing device class clearing on probe failuresRafael J. Wysocki
Commit e18947038bf4 ("ACPI: driver: Do not set acpi_device_class() unnecessarily") modified acpi_button_remove() to clear the device class field in struct acpi_device on driver removal, but it should also have updated the rollback path in acpi_button_probe(), which it didn't do, so do it now. Fixes: e18947038bf4 ("ACPI: driver: Do not set acpi_device_class() unnecessarily") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/6167713.MhkbZ0Pkbq@rafael.j.wysocki
2026-05-25ACPI: button: Enable wakeup GPEs for ACPI buttons at probe timeRafael J. Wysocki
Prior to commit 57c31e6d620f ("ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons"), ACPI button wakeup GPEs having handler methods remained enabled after acpi_wakeup_gpe_init(), but currently they are not enabled because acpi_setup_gpe_for_wake() disables them. That causes function keys to stop working on some systems [1] and there may be other related issues elsewhere. To address that, make the ACPI button driver enable wakeup GPEs for ACPI buttons so long as they have handler methods. While this does not restore the old behavior exactly (the ACPI button driver needs to be bound to the button devices for the GPEs to be enabled), it should be sufficient to restore the missing functionality. For this purpose, introduce acpi_enable_gpe_cond() that enables a GPE if its dispatch type matches the supplied one and modify acpi_button_probe() to use that function for enabling the GPEs in question. Fixes: 57c31e6d620f ("ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons") Reported-by: Nick <nick@kousu.ca> Closes: https://lore.kernel.org/linux-acpi/E2OXET.4X5GTP37VTNC3@kousu.ca/ [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Nick <nick@kousu.ca> Cc: 7.0+ <stable@vger.kernel.org> # 7.0+ Link: https://patch.msgid.link/9629117.CDJkKcVGEf@rafael.j.wysocki
2026-05-25ACPI: button: Fix ACPI GPE handler leak during removalRafael J. Wysocki
Commit a7e23ec17fee ("ACPI: button: Install notifier for system events as well") changed the ACPI notify handler type for ACPI buttons to ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect that change. This leads to leaking the notify handler past driver removal, which may cause a kernel crash to occur if ACPI notify on the given device is triggered after removing the driver, and causes a subsequent probe of the given device with the same driver to fail. Address this by updating the acpi_remove_notify_handler() call in acpi_button_remove() as appropriate. Fixes: a7e23ec17fee ("ACPI: button: Install notifier for system events as well") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Cc: 6.15+ <stable@vger.kernel.org> # 6.15+ Link: https://patch.msgid.link/7954431.EvYhyI6sBW@rafael.j.wysocki
2026-05-25pinctrl: core: Make pin group callbacks optional for pin-only driversOleksij Rempel
Currently, the pinctrl core strictly requires all drivers to implement .get_groups_count and .get_group_name callbacks in their pinctrl_ops. However, for simple pinctrl drivers that act purely as GPIO controllers and pin-specific configuration proxies, without any concept of muxing or pin groups, this strict requirement forces the implementation of dummy callbacks just to satisfy pinctrl_check_ops(). Relax this requirement for pin-only drivers by making the group callbacks optional when no muxing or group pin configuration support is provided. Update the core and debugfs helpers to check for the existence of these callbacks before invoking them. Drivers that provide muxing or group pin configuration operations still must implement group enumeration and naming callbacks, and are rejected at registration time if they do not. Suggested-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-25pinctrl: mcp23s08: Read spi-present-mask as u8 not u32Judith Mendez
The binding (microchip,mcp23s08) specifies microchip,spi-present-mask as uint8, but driver would read u32, causing type mismatch. Use device_property_read_u8 to match binding spec, hardware (8 chips max), & prevent probe failure. Cc: stable@vger.kernel.org Fixes: 3ad8d3ec6d87 ("dt-bindings: pinctrl: convert pinctrl-mcp23s08.txt to yaml format") Signed-off-by: Judith Mendez <jm@ti.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-25pinctrl: mcp23s08: Initialize mcp->dev and mcp->addr before regmap initJudith Mendez
Regmap initialization triggers regcache_maple_populate() which attempts SPI read to populate cache. SPI read requires mcp->dev and mcp->addr to be set, without them, NULL pointer dereference occurs during probe. Move initialization before mcp23s08_spi_regmap_init() call. Cc: stable@vger.kernel.org Fixes: f9f4fda15e72 ("pinctrl: mcp23s08: init reg_defaults from HW at probe and switch cache type") Signed-off-by: Judith Mendez <jm@ti.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-25Merge branch 'for-linus' into for-nextTakashi Iwai
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-05-25drm/i915: Remove useless comment about MTRR.Maarten Lankhorst
Commit 792d2b9a1259 ("drm: drop mtrr from i915"), added this comment, drop it since it since MTRR no longer exists since 2013 and is removed by commit 281856477cda ("drm: rip out drm_core_has_MTRR checks"). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260522104548.980226-1-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-05-25wifi: rtw88: usb: fix memory leaks on USB write failuresLuka Gejak
When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions. Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Cc: stable@vger.kernel.org Acked-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260518142311.10328-2-luka.gejak@linux.dev
2026-05-25wifi: rtw88: increase TX report timeout to fix race conditionLuka Gejak
The driver expects the firmware to report TX status within 500ms. However, a timeout can be triggered when the hardware performs background scans while under TX load. During these scans, the firmware stays off-channel for periods exceeding 500ms, delaying the delivery of TX reports back to the driver. When this occurs, the purge timer fires prematurely and drops the tracking skbs from the queue. This results in the host stack interpreting the missing status as packet loss, leading to TCP window collapse. In testing with iperf3, this causes throughput to drop from ~90 Mbps to near-zero for approximately 2 seconds until the connection recovers. Increase RTW_TX_PROBE_TIMEOUT to 2500ms for RTL8723DU. This duration is sufficient to accommodate off-channel dwell time during full background scans, ensuring the purge timer only trips during genuine firmware lockups and preventing unnecessary TCP retransmission cycles. Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Cc: stable@vger.kernel.org Acked-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260518142311.10328-1-luka.gejak@linux.dev
2026-05-25wifi: rtw89: Add missing TX queue mappings for RTL8922AUBitterblue Smith
A user with MLO-capable router reports: [ 753.080409] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26 [ 753.080417] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26 [ 813.649426] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26 [ 813.649445] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26 [ 813.855983] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26 Map RTW89_TX_QSEL_B1_MGMT and RTW89_TX_QSEL_B1_HI to RTW89_TXCH_CH10. This is probably the right channel for these queues. This function is also used for RTL8852AU and RTL8852CU, but those currently aren't used in DBCC mode with rtw89 so it makes no difference for them. Link: https://github.com/morrownr/rtw89/issues/83#issuecomment-4314735734 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/0c8e0cf1-13e9-4c67-a67f-5f6f79fd0658@gmail.com
2026-05-25wifi: rtw89: 8922d: add quota for RTL8922DE variantPing-Ke Shih
The existing quota set is for RTL8922DE-VS, so rename the existing tables. Add new quota set for RTL8922DE, containing more memory to yield better performance, so rearrange quota accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-14-pkshih@realtek.com
2026-05-25wifi: rtw89: mac: consolidate quota into a struct for variant chipsPing-Ke Shih
RTL8922D has many variants, using different quota tables. Consolidate the quota data into a struct, and then select corresponding table for the chip variant. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-13-pkshih@realtek.com
2026-05-25wifi: rtw89: mac: add field of release report size to DLE quotaPing-Ke Shih
The release report size is defined to indicate quota for TX completion. Define the field as vendor driver does. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-12-pkshih@realtek.com
2026-05-25wifi: rtw89: 8922d: change naming number and update values for WDE/PLE quotaPing-Ke Shih
The WDE/PLE quota are to configure memory size for TX/RX. Some quota are renamed, and some values are changed. Update them accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-11-pkshih@realtek.com
2026-05-25wifi: rtw89: correct drop logic for malformed AMPDU framesPo-Hao Huang
The previous commit aims to fix issue caused by malformed AMPDU frames. But the drop logic fails to deal with the first AMPDU packet paired with certain range of sequence number, and leads to unexpected packet drop. It is more likely to encounter this failure when there are busy traffic during rekey process and could lead to disconnection from the AP. Fix this by adding a initial state judgement and only reset status during pairwise rekey. Fixes: bda294ed0ed0 ("wifi: rtw89: Drop malformed AMPDU frames with abnormal PN") Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-10-pkshih@realtek.com
2026-05-25wifi: rtw89: wow: send ARP reply packets instead of Null packets to keep aliveChin-Yen Lee
In WoWLAN mode, the firmware periodically sends Null packets to the AP to keep the connection alive and prevent the AP from disconnecting the client due to inactivity. However, it was observed that certain APs, such as TP-Link Archer BE800, do not recognize Null packets as valid activity and still drop the connection. Replacing Null packets with ARP reply packets effectively resolves this compatibility issue and maintains the connection. Specifically, while the firmware typically handles standard ARP offloads by dynamically modifying target IP/MAC fields, these keep-alive ARP reply packets are pre-filled by the driver with the DUT's own MAC and IP addresses for both sender and target fields. In this case, the firmware transmits the packets as-is without further modification. This approach ensures compatibility with APs that require valid Layer 3 traffic for activity monitoring while simplifying the firmware's processing logic during WoWLAN mode. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-9-pkshih@realtek.com
2026-05-25wifi: rtw89: clear auto K delay value before downloading firmwarePing-Ke Shih
Once downloading firmware, do calibration on delay function to ensure firmware can do proper delay for hardware IO. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-8-pkshih@realtek.com
2026-05-25wifi: rtw89: pci: disable PCI PHY error flag 8Ping-Ke Shih
As the PHY error flag 8 works improperly, disable it to prevent false alarm causing SER. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-7-pkshih@realtek.com
2026-05-25wifi: rtw89: pci: not disable PCI completion timeout control for a variant ↵Ping-Ke Shih
of RTL8922DE The variant of RTL8922DE change the design, and no need to disable PCI completion timeout. Apply the setting accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-6-pkshih@realtek.com
2026-05-25wifi: rtw89: pci: enable LTR based on pcie control registerDian-Syuan Yang
Originally, driver always transmits LTR (Latency Tolerance Reporting) to pcie host, but it may cause pcie link down on some platforms because LTR is not supported. As a result, driver will check the control register of LTR setting to decide whether to enable LTR feature. This applies to Wi-Fi 6 chips only. For Wi-Fi 7 chips, although the driver still issues LTR, the hardware has its own internal logic to determine whether to actually transmit it to pcie host. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-5-pkshih@realtek.com
2026-05-25wifi: rtw89: fw: dump status of H2C command and C2H event for SERZong-Zhe Yang
When SER (system error recovery) happens, there may be some handshake between FW and SW, e.g. SER Level 1. These handshake are based on H2C commands and C2H events. Dump the status of them to enhance SER debug. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-4-pkshih@realtek.com
2026-05-25wifi: rtw89: debug: Wi-Fi 7 update simulation of SER L0/L1 by halt H2C commandZong-Zhe Yang
Wi-Fi 7 FW fixes support of triggering SER L0/L1 simulation via halt H2C command on v0.35.108.0. After that, the halt H2C command trigger for Wi-Fi 6 and Wi-Fi 7 can be the same. Update FW feature table and share the halt H2C command trigger function between Wi-Fi 6 and Wi-Fi 7. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-3-pkshih@realtek.com
2026-05-25wifi: rtw89: debug: Wi-Fi 7 show count of SER L0 simulationZong-Zhe Yang
Wi-Fi 7 has dedicated HW register to count SER L0 simulation, i.e. manually triggered by users. Show count of it in dbgfs ser_counters. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260515014433.16168-2-pkshih@realtek.com
2026-05-25Merge tag 'v7.1-rc5' into driver-core-nextDanilo Krummrich
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25bus: sunxi-rsb: Always check register address validitySamuel Holland
The register address was already validated for read operations in regmap_sunxi_rsb_reg_read before being truncated to a u8. Write operations have the same set of possible addresses, and the address is being truncated from u32 to u8 here as well, so the same check is needed. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus") Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20260301144939.1832806-1-andrej.skvortzov@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-05-24regulator: add support for SGM3804 Dual Output driverMark Brown
Neil Armstrong <neil.armstrong@linaro.org> says: Add support for the SG Micro SGM3804 Single Inductor Dual Output Buck/Boost Converter used to power LCD panels a provide positive and negative power rails with configurable voltage and active discharge function for each output. The SGM3804 is powered by the enable GPIO pins inputs and only supports I2C write messages. In order to add flexibility and simplify the driver, the regmap cache is enabled and populated with default values since we can't write registers when the 2 GPIOs are down. This regulator is used to provide vsn and vsn power to the Ayaneo Pocket S2 dual-DSI LCD panel. Link: https://patch.msgid.link/20260522-topic-sm8650-ayaneo-pocket-s2-sgm3804-v5-0-bd6b1c300ecc@linaro.org
2026-05-24regulator: add SGM3804 Dual Output driverKancyJoe
Add support for the SG Micro SGM3804 Single Inductor Dual Output Buck/Boost Converter used to power LCD panels a provide positive and negative power rails with configurable voltage and active discharge function for each output. The SGM3804 is powered by the enable GPIO pins inputs and only supports I2C write messages. In order to add flexibility and simplify the driver, the regmap cache is enabled and populated with default values since we can't write registers when the 2 GPIOs are down. Signed-off-by: KancyJoe <kancy2333@outlook.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260522-topic-sm8650-ayaneo-pocket-s2-sgm3804-v5-2-bd6b1c300ecc@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-24hwmon: (lm75) Add explicit default cases in lm75_is_visible()Flaviu Nistor
Add explicit default labels to switch statements in lm75_is_visible(). This makes the control flow explicit and improves readability, but also keeps consistency to other usage of the switch statement in the driver. Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com> Link: https://lore.kernel.org/r/20260417055700.5739-1-flaviu.nistor@gmail.com [groeck: Reformatted description for line length] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-05-24hwmon: add MP2985 driverWensheng Wang
Add support for MPS mp2985 controller. This driver exposes telemetry and limit value readings and writtings. Signed-off-by: Wensheng Wang <wenswang@yeah.net> Link: https://lore.kernel.org/r/20260414092921.1067735-2-wenswang@yeah.net Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-05-24RDMA/mana_ib: Use ib_get_eth_speed for reporting port speedShiraz Saleem
Replace hardcoded IB_WIDTH_4X/IB_SPEED_EDR with ib_get_eth_speed() to report the actual link speed in mana_ib_query_port(). Fixes: 4bda1d5332ec ("RDMA/mana_ib: Implement port parameters") Link: https://patch.msgid.link/r/20260512094056.264827-1-kotaranov@linux.microsoft.com Signed-off-by: Shiraz Saleem <shirazsaleem@microsoft.com> Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-05-24RDMA/rtrs: Use flexible array for client path statsRosen Penev
Store the client path statistics in the RTRS client path allocation instead of allocating them separately. This ties the stats lifetime directly to the path and removes a separate allocation failure path. Keep freeing the per-CPU stats data separately, but do not free the embedded stats object from error paths or the stats kobject release handler. Link: https://patch.msgid.link/r/20260511041812.378030-1-rosenp@gmail.com Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-05-24memory: renesas-rpc-if: Fix duplicate device name on multi-instance platformsLad Prabhakar
On platforms with multiple xSPI instances, the driver fails to probe additional instances due to duplicate sysfs entries: [ 86.878242] sysfs: cannot create duplicate filename '/bus/platform/devices/rpc-if-spi' This occurs because platform_device_alloc() uses pdev->id for the device ID, which may be PLATFORM_DEVID_NONE (-1) for multiple instances, causing all instances to attempt registration with the same name. Fix this by using PLATFORM_DEVID_AUTO instead, which automatically assigns unique IDs to each device instance, allowing multiple xSPI controllers to coexist without naming conflicts. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20260515115202.1515577-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-24memory: omap-gpmc: Silence W=1 kerneldoc warningsKrzysztof Kozlowski
Recent W=1 builds print kerneldoc warnings, even though a correct kerneldoc is there: Warning: drivers/memory/omap-gpmc.c:441 Excess function parameter 'cs' description in 'get_gpmc_timing_reg' Drop additional inline comments for arguments to fix that. They are anyway not that useful. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260520111630.89365-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-24Merge tag 'x86-urgent-2026-05-24' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: - On SEV guests, handle set_memory_{encrypted,decrypted}() failures more conservatively by assuming that all affected pages are unencrypted (Carlos López) - Disable broadcast TLB flush when PCID is disabled (Tom Lendacky) - Fix VMX vs. hrtimer_rearm_deferred() regression (Peter Zijlstra) - Move IRQ/NMI dispatch code from KVM into x86 core, to prepare for a KVM x2apic fix (Peter Zijlstra) - Fix incorrect munmap() size on map_vdso() failure (Guilherme Giacomo Simoes) * tag 'x86-urgent-2026-05-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: virt: sev-guest: Explicitly leak pages in unknown state x86/mm: Disable broadcast TLB flush when PCID is disabled x86/kvm/vmx: Fix VMX vs hrtimer_rearm_deferred() x86/kvm/vmx: Move IRQ/NMI dispatch from KVM into x86 core x86/vdso: Fix incorrect size in munmap() on map_vdso() failure
2026-05-24Merge tag 'irq-urgent-2026-05-24' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irqchip driver fixes from Ingo Molnar: - Fix the hardware probing error path of the renesas-rzt2h irqchip driver - Fix the exynos-combiner irqchip driver on -rt kernels by turning the IRQ controller spinlock into a raw spinlock * tag 'irq-urgent-2026-05-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/renesas-rzt2h: Use pm_runtime_put_sync() in probe error path irqchip/exynos-combiner: Switch to raw_spinlock
2026-05-24Merge tag 'hwmon-for-v7.1-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - adm1266: Various fixes from Abdurrahman Hussain The fixed issues were reported by Sashiko as part of a code review of a functional change in the driver. - lenovo-ec-sensors: Convert to devm_request_region() to fix release_region cleanup, and fix EC "MCHP" signature validation logic, from Kean Ren * tag 'hwmon-for-v7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with pmbus_lock hwmon: (pmbus/adm1266) serialize NVMEM blackbox read with pmbus_lock hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock hwmon: (pmbus/adm1266) register the nvmem device after pmbus_do_probe() hwmon: (pmbus/adm1266) register the gpio_chip after pmbus_do_probe() hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO accessors hwmon: (pmbus/adm1266) don't clobber GPIO bits before PDIO read in get_multiple hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized buffer hwmon: (pmbus/adm1266) include adapter number in GPIO line label hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer hwmon: (pmbus/adm1266) reject implausible blackbox record_count hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX hwmon: (pmbus/adm1266) seed timestamp from the real-time clock hwmon: (lenovo-ec-sensors): Fix EC "MCHP" signature validation logic hwmon: (lenovo-ec-sensors): Convert to devm_request_region()
2026-05-24drm/msm: Restore second parameter name in purge() and evict()Nathan Chancellor
After commit 3392291fc509 ("drm/msm: Fix shrinker deadlock"), all supported versions of clang warn (or error with CONFIG_WERROR=y): drivers/gpu/drm/msm/msm_gem_shrinker.c:105:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions] 105 | purge(struct drm_gem_object *obj, struct ww_acquire_ctx *) | ^ drivers/gpu/drm/msm/msm_gem_shrinker.c:117:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions] 117 | evict(struct drm_gem_object *obj, struct ww_acquire_ctx *) | ^ 2 errors generated. With older but supported versions of GCC, this is an unconditional hard error: drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'purge': drivers/gpu/drm/msm/msm_gem_shrinker.c:105:35: error: parameter name omitted purge(struct drm_gem_object *obj, struct ww_acquire_ctx *) ^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'evict': drivers/gpu/drm/msm/msm_gem_shrinker.c:117:35: error: parameter name omitted evict(struct drm_gem_object *obj, struct ww_acquire_ctx *) ^~~~~~~~~~~~~~~~~~~~~~~ Restore the parameter name to clear up the warnings, renaming it "unused" to make it clear it is only needed to satisfy the prototype of drm_gem_lru_scan(). Cc: stable@vger.kernel.org Fixes: 3392291fc509 ("drm/msm: Fix shrinker deadlock") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-05-24RDMA/bnxt_re: Enable app allocated QPsSriharsha Basavapatna
The driver supports a new comp_mask: REQ_MASK_FIXED_QUE_ATTR. The application sets this comp_mask bit in the CREATE_QP ureq to indicate direct control of the QP. The driver goes through the required processing for app allocated QPs (previous patches). Only variable WQE mode is supported for these QPs. This patch removes an unused comp_mask: BNXT_RE_QP_REQ_MASK_VAR_WQE_SQ_SLOTS Link: https://patch.msgid.link/r/20260519150041.7251-10-sriharsha.basavapatna@broadcom.com Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-05-24RDMA/bnxt_re: Support doorbells for app allocated QPsSriharsha Basavapatna
App allocated QPs can use a separate doorbell for each QP. This doorbell region can be passed through a new driver specific DBR_HANDLE attribute, during QP creation. When this attribute is set, associate the QP with the given doorbell region. While the QP holds a reference to the dbr, the dbr itself cannot be destroyed and is rejected with EBUSY error. Link: https://patch.msgid.link/r/20260519150041.7251-9-sriharsha.basavapatna@broadcom.com Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-05-24RDMA/bnxt_re: Enhance dpi lifecycle logic in doorbell uapisSriharsha Basavapatna
If the DPI is freed when the dbr object is freed, but if the process has not unmapped the page yet, then the DPI slot could get reallocated to another process while the original process still has it mapped. To prevent this, save the DPI info in the mmap entry during dbr allocation and free the DPI slot from bnxt_re_mmap_free(), which enures that there are no references to it. This change is needed to support doorbell allocation to QPs in the next patch. Link: https://patch.msgid.link/r/20260519150041.7251-8-sriharsha.basavapatna@broadcom.com Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-06 05:35:59 +0000