summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-01-28HID: asus: fortify keyboard handshakeAntheas Kapenekakis
Handshaking with an Asus device involves sending it a feature report with the string "ASUS Tech.Inc." and then reading it back to verify the handshake was successful, under the feature ID the interaction will take place. Currently, the driver only does the first part. Add the readback to verify the handshake was successful. As this could cause breakages, allow the verification to fail with a dmesg error until we verify all devices work with it (they seem to). Since the response is more than 16 bytes, increase the buffer size to 64 as well to avoid overflow errors. In addition, add the report ID to prints, to help identify failed handshakes. Reviewed-by: Benjamin Tissoires <bentiss@kernel.org> Reviewed-by: Denis Benato <benato.denis96@gmail.com> Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260122075044.5070-5-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-28HID: asus: use same report_id in responseAntheas Kapenekakis
Currently, asus_kbd_get_functions prods the device using feature report report_id, but then is hardcoded to check the response through FEATURE_KBD_REPORT_ID. This only works if report_id is that value (currently true). So, use report_id in the response as well to maintain functionality if that value changes in the future. Reviewed-by: Denis Benato <benato.denis96@gmail.com> Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260122075044.5070-4-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-28HID: asus: initialize additional endpoints only for certain devicesAntheas Kapenekakis
Currently, ID1/ID2 initializations are performed for all NKEY devices. However, ID1 initializations are only required for RGB control and are only supported for RGB capable devices. ID2 initializations are only required for initializing the Anime display endpoint which is only supported on devices with an Anime display. Both of these initializations are for functionality that is not present on this driver and are performed for devices which might not support them. At the same time, there are older NKEY devices that have only been tested with these initializations in the kernel and it is not possible to recheck them. There is a possibility that especially with the ID1 initialization, certain laptop models might have their shortcuts stop working (currently unproven). To avoid sending unnecessary commands, change to only initialize ID1/ID2 for those NKEY devices suspected to be problematic without them by introducing a quirk for them and replacing the NKEY quirk in the block that performs the inits with that. Therefore, new devices that do not need (and some do not support) these initializations will not have them performed. In addition, as these initializations might not be supported by the affected devices, change the function to not bail if they fail. Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Reviewed-by: Denis Benato <benato.denis96@gmail.com> Link: https://patch.msgid.link/20260122075044.5070-3-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-28HID: asus: simplify RGB init sequenceAntheas Kapenekakis
Currently, RGB initialization forks depending on whether a device is NKEY. However, in reality both initialization forks are the same, other than the NKEY initialization initializing the LED_REPORT_ID1, LED_REPORT_ID2 endpoints, and the non-NKEY initialization having a functionality check which is skipped for the NKEY path. Therefore, merge the if blocks, gate the ID1/ID2 initializations behind the NKEY quirk instead, and introduce the functionality check for NKEY devices (it is supported by them). There should be no functional change with this patch. Acked-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260122075044.5070-2-lkml@antheas.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-28spi: dw: Remove duplicate error messageAndy Shevchenko
devm_platform_ioremap_resource() prints an error message depending on the actual error. The caller doesn't need to repeat that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260128095748.4156926-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-28spi: aspeed: Improve handling of shared SPIMark Brown
Merge series from Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>: This patch series improves handling of SPI controllers that are shared by spi-mem devices and other SPI peripherals. The primary goal of this series is to support non-spi-mem devices in the ASPEED FMC/SPI controller driver. It also addresses an issue in the spi-mem framework observed when different types of SPI devices operate concurrently on the same controller, ensuring that spi-mem operations are properly serialized.
2026-01-28RDMA/core: add rdma_rw_max_sge() helper for SQ sizingChuck Lever
svc_rdma_accept() computes sc_sq_depth as the sum of rq_depth and the number of rdma_rw contexts (ctxts). This value is used to allocate the Send CQ and to initialize the sc_sq_avail credit pool. However, when the device uses memory registration for RDMA operations, rdma_rw_init_qp() inflates the QP's max_send_wr by a factor of three per context to account for REG and INV work requests. The Send CQ and credit pool remain sized for only one work request per context, causing Send Queue exhaustion under heavy NFS WRITE workloads. Introduce rdma_rw_max_sge() to compute the actual number of Send Queue entries required for a given number of rdma_rw contexts. Upper layer protocols call this helper before creating a Queue Pair so that their Send CQs and credit accounting match the QP's true capacity. Update svc_rdma_accept() to use rdma_rw_max_sge() when computing sc_sq_depth, ensuring the credit pool reflects the work requests that rdma_rw_init_qp() will reserve. Reviewed-by: Christoph Hellwig <hch@lst.de> Fixes: 00bd1439f464 ("RDMA/rw: Support threshold for registration vs scattering to local pages") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Link: https://patch.msgid.link/20260128005400.25147-5-cel@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-28RDMA/core: add MR support for bvec-based RDMA operationsChuck Lever
The bvec-based RDMA API currently returns -EOPNOTSUPP when Memory Region registration is required. This prevents iWARP devices from using the bvec path, since iWARP requires MR registration for RDMA READ operations. The force_mr debug parameter is also unusable with bvec input. Add rdma_rw_init_mr_wrs_bvec() to handle MR registration for bvec arrays. The approach creates a synthetic scatterlist populated with DMA addresses from the bvecs, then reuses the existing ib_map_mr_sg() infrastructure. This avoids driver changes while keeping the implementation small. The synthetic scatterlist is stored in the rdma_rw_ctx for cleanup. On destroy, the MRs are returned to the pool and the bvec DMA mappings are released using the stored addresses. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Link: https://patch.msgid.link/20260128005400.25147-4-cel@kernel.org Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-28RDMA/core: use IOVA-based DMA mapping for bvec RDMA operationsChuck Lever
The bvec RDMA API maps each bvec individually via dma_map_phys(), requiring an IOTLB sync for each mapping. For large I/O operations with many bvecs, this overhead becomes significant. The two-step IOVA API (dma_iova_try_alloc / dma_iova_link / dma_iova_sync) allocates a contiguous IOVA range upfront, links all physical pages without IOTLB syncs, then performs a single sync at the end. This reduces IOTLB flushes from O(n) to O(1). It also requires only a single output dma_addr_t compared to extra per-input element storage in struct scatterlist. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Link: https://patch.msgid.link/20260128005400.25147-3-cel@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-28RDMA/core: add bio_vec based RDMA read/write APIChuck Lever
The existing rdma_rw_ctx_init() API requires callers to construct a scatterlist, which is then DMA-mapped page by page. Callers that already have data in bio_vec form (such as the NVMe-oF target) must first convert to scatterlist, adding overhead and complexity. Introduce rdma_rw_ctx_init_bvec() and rdma_rw_ctx_destroy_bvec() to accept bio_vec arrays directly. The new helpers use dma_map_phys() for hardware RDMA devices and virtual addressing for software RDMA devices (rxe, siw), avoiding intermediate scatterlist construction. Memory registration (MR) path support is deferred to a follow-up series; callers requiring MR-based transfers (iWARP devices or force_mr=1) receive -EOPNOTSUPP and should use the scatterlist API. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Link: https://patch.msgid.link/20260128005400.25147-2-cel@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-28RDMA/irdma: Use kvzalloc for paged memory DMA address arrayCarlos Bilbao
Allocate array chunk->dmainfo.dmaaddrs using kvzalloc() to allow the allocation to fall back to vmalloc when contiguous memory is unavailable (instead of failing and logging page allocation warnings). Acked-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Carlos Bilbao (Lambda) <carlos.bilbao@kernel.org> Link: https://patch.msgid.link/20260128014446.405247-1-carlos.bilbao@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-28RDMA/rxe: Fix race condition in QP timer handlersLi Zhijian
I encontered the following warning: WARNING: drivers/infiniband/sw/rxe/rxe_task.c:249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... libsha1 [last unloaded: ip6_udp_tunnel] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.19.0-rc5-64k-v8+ #37 PREEMPT Tainted: [C]=CRAP Hardware name: Raspberry Pi 4 Model B Rev 1.2 Call trace: rxe_sched_task+0x1c8/0x238 [rdma_rxe] (P) retransmit_timer+0x130/0x188 [rdma_rxe] call_timer_fn+0x68/0x4d0 __run_timers+0x630/0x888 ... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:111 at do_work+0x488/0x5c8 [rdma_rxe], CPU#3: kworker/u17:4/93400 ... refcount_t: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400 The issue is caused by a race condition between retransmit_timer() and rxe_destroy_qp, leading to the Queue Pair's (QP) reference count dropping to zero during timer handler execution. It seems this warning is harmless because rxe_qp_do_cleanup() will flush all pending timers and requests. Example of flow causing the issue: CPU0 CPU1 retransmit_timer() { spin_lock_irqsave rxe_destroy_qp() __rxe_cleanup() __rxe_put() // qp->ref_count decrease to 0 rxe_qp_do_cleanup() { if (qp->valid) { rxe_sched_task() { WARN_ON(rxe_read(task->qp) <= 0); } } spin_unlock_irqrestore } spin_lock_irqsave qp->valid = 0 spin_unlock_irqrestore } Ensure the QP's reference count is maintained and its validity is checked within the timer callbacks by adding calls to rxe_get(qp) and corresponding rxe_put(qp) after use. Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> Fixes: d94671632572 ("RDMA/rxe: Rewrite rxe_task.c") Link: https://patch.msgid.link/20260120074437.623018-1-lizhijian@fujitsu.com Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-28drm/imx/tve: fix probe device leakJohan Hovold
Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: fcbc51e54d2a ("staging: drm/imx: Add support for Television Encoder (TVEv2)") Cc: stable@vger.kernel.org # 3.10 Cc: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20251030163456.15807-1-johan@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-01-28gpio: spacemit-k1: Use PDR for pin direction, not SDR/CDRVivian Wang
On the SpacemiT GPIO controller, the direction control register PDR is readable and writable [1]. Therefore, implement direction control by using PDR as dirout, and don't mark it as unreadable. The original implementation, using SDR as dirout and CDR as dirin, is not actually a supported configuration by gpio-mmio. The hardware supports changing the direction of some pins atomically by writing a value with the corresponding bits set to SDR (set as output) or to CDR (set as input). However, gpio-mmio does not actually handle this. Using only PDR as dirout to match the expectations of gpio-mmio. This also allows us to avoid clobbering potentially important GPIO direction configurations set by pre-Linux boot stages. Found while trying to add PCIe support to OrangePi RV2, where the regulator (controlled by GPIO 116) turns off on boot while some other GPIO pin in the same bank is touched, which is not desirable. Link: https://developer.spacemit.com/documentation?token=Rn9Kw3iFHirAMgkIpTAcV2Arnkf#18.4-gpio # [1] Fixes: d00553240ef8 ("gpio: spacemit: add support for K1 SoC") Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://patch.msgid.link/20260127-gpio-spacemit-k1-pdr-v1-1-bb868a517dbc@iscas.ac.cn Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-28gpio: brcmstb: correct hwirq to bank mapDoug Berger
The brcmstb_gpio_hwirq_to_bank() function was designed to accommodate the downward numbering of dynamic GPIOs by traversing the bank list in the reverse order. However, the dynamic numbering has changed to increment upward which can produce an incorrect mapping. The function is modified to no longer assume an ordering of the list to accommodate either option. Fixes: 7b61212f2a07 ("gpiolib: Get rid of ARCH_NR_GPIOS") Signed-off-by: Doug Berger <opendmb@gmail.com> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260127214656.447333-2-florian.fainelli@broadcom.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-28gpio: max77620: Implement .get_direction() callbackDiogo Ivo
Add support for reporting the current GPIO line direction by implementing the .get_direction() callback for the MAX77620 GPIO controller. Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260127-smaug-spi_flash-v1-1-5fd334415118@tecnico.ulisboa.pt Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-28gpio: omap: do not register driver in probe()Danilo Krummrich
Commit 11a78b794496 ("ARM: OMAP: MPUIO wake updates") registers the omap_mpuio_driver from omap_mpuio_init(), which is called from omap_gpio_probe(). However, it neither makes sense to register drivers from probe() callbacks of other drivers, nor does the driver core allow registering drivers with a device lock already being held. The latter was revealed by commit dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()") leading to a potential deadlock condition described in [1]. Additionally, the omap_mpuio_driver is never unregistered from the driver core, even if the module is unloaded. Hence, register the omap_mpuio_driver from the module initcall and unregister it in module_exit(). Link: https://lore.kernel.org/lkml/DFU7CEPUSG9A.1KKGVW4HIPMSH@kernel.org/ [1] Fixes: dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()") Fixes: 11a78b794496 ("ARM: OMAP: MPUIO wake updates") Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260127201725.35883-1-dakr@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-28pinctrl: equilibrium: Fix device node reference leak in pinbank_init()Felix Gu
When calling of_parse_phandle_with_fixed_args(), the caller is responsible to call of_node_put() to release the reference of device node. In pinbank_init(), the reference of the node obtained from the "gpio-ranges" property is never released, resulting in a reference count leak. Add the missing of_node_put() call to fix the leak. Fixes: 1948d5c51dba ("pinctrl: Add pinmux & GPIO controller driver for a new SoC") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-01-28Merge tag 'drm-msm-fixes-2026-01-23' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-fixes Late fix for v6.19: GPU: - Fix bogus hwcg register update for a690 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <rob.clark@oss.qualcomm.com> Link: https://patch.msgid.link/CACSVV03A-GE5mNG1OLF3s9UCenQk4x3jO71Hmvr9j+vCF2hc7g@mail.gmail.com
2026-01-27rnbd-clt: fix refcount underflow in device unmap pathChaitanya Kulkarni
During device unmapping (triggered by module unload or explicit unmap), a refcount underflow occurs causing a use-after-free warning: [14747.574913] ------------[ cut here ]------------ [14747.574916] refcount_t: underflow; use-after-free. [14747.574917] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x55/0x90, CPU#9: kworker/9:1/378 [14747.574924] Modules linked in: rnbd_client(-) rtrs_client rnbd_server rtrs_server rtrs_core ... [14747.574998] CPU: 9 UID: 0 PID: 378 Comm: kworker/9:1 Tainted: G O N 6.19.0-rc3lblk-fnext+ #42 PREEMPT(voluntary) [14747.575005] Workqueue: rnbd_clt_wq unmap_device_work [rnbd_client] [14747.575010] RIP: 0010:refcount_warn_saturate+0x55/0x90 [14747.575037] Call Trace: [14747.575038] <TASK> [14747.575038] rnbd_clt_unmap_device+0x170/0x1d0 [rnbd_client] [14747.575044] process_one_work+0x211/0x600 [14747.575052] worker_thread+0x184/0x330 [14747.575055] ? __pfx_worker_thread+0x10/0x10 [14747.575058] kthread+0x10d/0x250 [14747.575062] ? __pfx_kthread+0x10/0x10 [14747.575066] ret_from_fork+0x319/0x390 [14747.575069] ? __pfx_kthread+0x10/0x10 [14747.575072] ret_from_fork_asm+0x1a/0x30 [14747.575083] </TASK> [14747.575096] ---[ end trace 0000000000000000 ]--- Befor this patch :- The bug is a double kobject_put() on dev->kobj during device cleanup. Kobject Lifecycle: kobject_init_and_add() sets kobj.kref = 1 (initialization) kobject_put() sets kobj.kref = 0 (should be called once) * Before this patch: rnbd_clt_unmap_device() rnbd_destroy_sysfs() kobject_del(&dev->kobj) [remove from sysfs] kobject_put(&dev->kobj) PUT #1 (WRONG!) kref: 1 to 0 rnbd_dev_release() kfree(dev) [DEVICE FREED!] rnbd_destroy_gen_disk() [use-after-free!] rnbd_clt_put_dev() refcount_dec_and_test(&dev->refcount) kobject_put(&dev->kobj) PUT #2 (UNDERFLOW!) kref: 0 to -1 [WARNING!] The first kobject_put() in rnbd_destroy_sysfs() prematurely frees the device via rnbd_dev_release(), then the second kobject_put() in rnbd_clt_put_dev() causes refcount underflow. * After this patch :- Remove kobject_put() from rnbd_destroy_sysfs(). This function should only remove sysfs visibility (kobject_del), not manage object lifetime. Call Graph (FIXED): rnbd_clt_unmap_device() rnbd_destroy_sysfs() kobject_del(&dev->kobj) [remove from sysfs only] [kref unchanged: 1] rnbd_destroy_gen_disk() [device still valid] rnbd_clt_put_dev() refcount_dec_and_test(&dev->refcount) kobject_put(&dev->kobj) ONLY PUT (CORRECT!) kref: 1 to 0 [BALANCED] rnbd_dev_release() kfree(dev) [CLEAN DESTRUCTION] This follows the kernel pattern where sysfs removal (kobject_del) is separate from object destruction (kobject_put). Fixes: 581cf833cac4 ("block: rnbd: add .release to rnbd_dev_ktype") Signed-off-by: Chaitanya Kulkarni <ckulkarnilinux@gmail.com> Acked-by: Jack Wang <jinpu.wang@ionos.com> Reviewed-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-27Revert "rnbd-clt: fix refcount underflow in device unmap path"Jens Axboe
This reverts commit ec19ed2b3e2af8ec5380400cdee9cb6560144506. This commit relies on changes queued for 7.0, and isn't safe in its current form for the 6.19 release. Revert it for now for 6.19. Link: https://lore.kernel.org/linux-block/aXhLQmRudk7cSAnT@shinmob/ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-28regmap: reg_default_cb for flat cache defaultsMark Brown
Merge series from "Sheetal ." <sheetal@nvidia.com>: This series adds a reg_default_cb callback for REGCACHE_FLAT to provide defaults for registers not listed in reg_defaults. Defaults are loaded eagerly during regcache init and the callback can use writeable_reg to filter valid addresses and avoid holes.
2026-01-28Merge tag 'drm-rust-next-2026-01-26' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next DRM Rust changes for v7.0-rc1 DRM: - Fix documentation for Registration constructors. - Use pin_init::zeroed() for fops initialization. - Annotate DRM helpers with __rust_helper. - Improve safety documentation for gem::Object::new(). - Update AlwaysRefCounted imports. MM: - Prevent integer overflow in page_align(). Nova (Core): - Prepare for Turing support. This includes parsing and handling Turing-specific firmware headers and sections as well as a Turing Falcon HAL implementation. - Get rid of the Result<impl PinInit<T, E>> anti-pattern. - Relocate initializer-specific code into the appropriate initializer. - Use CStr::from_bytes_until_nul() to remove custom helpers. - Improve handling of unexpected firmware values. - Clean up redundant debug prints. - Replace c_str!() with native Rust C-string literals. - Update nova-core task list. Nova (DRM): - Align GEM object size to system page size. Tyr: - Use generated uAPI bindings for GpuInfo. - Replace manual sleeps with read_poll_timeout(). - Replace c_str!() with native Rust C-string literals. - Suppress warnings for unread fields. - Fix incorrect register name in print statement. Signed-off-by: Dave Airlie <airlied@redhat.com> From: "Danilo Krummrich" <dakr@kernel.org> Link: https://patch.msgid.link/DFYW1WV6DUCG.3K8V2DAVD1Q4A@kernel.org
2026-01-28wifi: rtw89: regd: update regulatory map to R73-R54Zong-Zhe Yang
Sync Realtek Channel Plan R73 and Realtek Regulatory R54. Configure 6 GHz field of Realtek regd for the following countries. PY NA BD ID VN TN GL GP YT EH Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-12-pkshih@realtek.com
2026-01-28wifi: rtw89: pci: validate release report content before using for RTL8922DEPing-Ke Shih
The commit 957eda596c76 ("wifi: rtw89: pci: validate sequence number of TX release report") does validation on existing chips, which somehow a release report of SKB becomes malformed. As no clear cause found, add rules ahead for RTL8922DE to avoid crash if it happens. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-11-pkshih@realtek.com
2026-01-28wifi: rtw89: get designated link to replace link instance 0Zong-Zhe Yang
Clean up some places where still to get link instance 0 directly. Since now MLSR switch is supported, it's not guaranteed to always run on link instance 0. So, prefer to get designated link in most cases. For now, the only exception is MCC (multi-channel concurrency) case. How to fill content of its H2C command depends on how to choose link instance, so cannot simply change it as above. Will handle MCC case separately afterwards. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-10-pkshih@realtek.com
2026-01-28wifi: rtw89: 8922a: configure FW version for SIM_SER_L0L1_BY_HALT_H2CZong-Zhe Yang
After FW version 0.35.97.0, 8922A supports SIM_SER_L0L1_BY_HALT_H2C FW feature. It allows to simulate FW L0/L1 crash under PS mode. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-9-pkshih@realtek.com
2026-01-28wifi: rtw89: phy: add PHY C2H event dummy handler for func 1-7 and 2-10Ping-Ke Shih
The two functions aren't implemented and hard necessary by driver. Implement dummy handler to avoid messages: rtw89_8922de 0000:03:00.0: PHY c2h class 1 func 7 not support rtw89_8922de 0000:03:00.0: PHY c2h class 2 func 10 not support Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-8-pkshih@realtek.com
2026-01-28wifi: rtw89: fw: correct content of DACK H2C commandPing-Ke Shih
The fields of command should be u8 instead of __le32. However, current firmware doesn't really use the data for now, so this mistake doesn't impact performance. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-7-pkshih@realtek.com
2026-01-28wifi: rtw89: rfk: update RFK report format of IQK, DACK and TXGAPKPing-Ke Shih
The report formats of IQK, DACK and TXGAPK are changed. Update them accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-6-pkshih@realtek.com
2026-01-28wifi: rtw89: rfk: add to print debug log of CIM3KPing-Ke Shih
Add calibration report of CIM3K, which does calibration in firmware and send a C2H event as debug purpose. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-5-pkshih@realtek.com
2026-01-28wifi: rtw89: rfk: add firmware command to do CIM3KPing-Ke Shih
CIM is short for counter intermodulation products 3rd-order. Due to non-linearity in transmit path, need a calibration to yield performance for RF system. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-4-pkshih@realtek.com
2026-01-28wifi: rtw89: rfk: add to print debug log of TX IQKPing-Ke Shih
Add report format for TX IQK, which do calibration in firmware and send a C2H event as debug purpose. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-3-pkshih@realtek.com
2026-01-28Merge tag 'drm-msm-next-2026-01-23' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-next Changes for v6.20 GPU: - Document a612/RGMU dt bindings - UBWC 6.0 support (for A840 / Kaanapali) - a225 support - Fixes DPU: - Switched to use virtual planes by default - Fixed DSI CMD panels on DPU 3.x - Rewrote format handling to remove intermediate representation - Fixed watchdog on DPU 8.x+ - Fixed TE / Vsync source setting on DPU 8.x+ - Added 3D_Mux on SC7280 - Kaanapali platform support - Fixed UBWC register programming - Made RM reserve DSPP-enabled mixers for CRTCs with LMs. - Gamma correction support DP: - Enabled support for eDP 1.4+ link rate tables - Fixed MDSS1 DP indices on SA8775P, making them to work - Fixed msm_dp_ctrl_config_msa() to work with LLVM 20 DSI: - Documented QCS8300 as compatible with SA8775P - Kaanapali platform support DSI PHY: - switched to divider_determine_rate() MDP5: - Dropped support for MSM8998, SDM660 and SDM630 (switched over to DPU) MDSS: - Kaanapali platform support - Fixed UBWC register programming Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <rob.clark@oss.qualcomm.com> Link: https://patch.msgid.link/CACSVV03Sbeca93A+gGh-TKpzFYVabbkWVgPCCicG0_NQG+5Y2A@mail.gmail.com
2026-01-28wifi: rtw89: rfk: add firmware command to do TX IQKPing-Ke Shih
TX IQK is a RF calibration, which driver call this H2C command to trigger the calibration. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-2-pkshih@realtek.com
2026-01-28BackMerge tag 'v6.19-rc7' into drm-nextDave Airlie
Linux 6.19-rc7 This is needed for msm and rust trees. Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-01-27gve: fix probe failure if clock read failsJordan Rhee
If timestamping is supported, GVE reads the clock during probe, which can fail for various reasons. Previously, this failure would abort the driver probe, rendering the device unusable. This behavior has been observed on production GCP VMs, causing driver initialization to fail completely. This patch allows the driver to degrade gracefully. If gve_init_clock() fails, it logs a warning and continues loading the driver without PTP support. Cc: stable@vger.kernel.org Fixes: a479a27f4da4 ("gve: Move gve_init_clock to after AQ CONFIGURE_DEVICE_RESOURCES call") Signed-off-by: Jordan Rhee <jordanrhee@google.com> Reviewed-by: Shachar Raindel <shacharr@google.com> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260127010210.969823-1-hramamurthy@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-27net/mlx5e: Account for netdev stats in ndo_get_stats64Gal Pressman
The driver's ndo_get_stats64 callback is only reporting mlx5 counters, without accounting for the netdev stats, causing errors from the network stack to be invisible in statistics. Add netdev_stats_to_stats64() call to first populate the counters, then add mlx5 counters on top, ensuring both are accounted for (where appropriate). Fixes: f62b8bb8f2d3 ("net/mlx5: Extend mlx5_core to support ConnectX-4 Ethernet functionality") Signed-off-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1769411695-18820-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-27net/mlx5e: TC, delete flows only for existing peersMark Bloch
When deleting TC steering flows, iterate only over actual devcom peers instead of assuming all possible ports exist. This avoids touching non-existent peers and ensures cleanup is limited to devices the driver is currently connected to. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 133c8a067 P4D 0 Oops: Oops: 0002 [#1] SMP CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core] Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49 RSP: 0018:ff11000143867528 EFLAGS: 00010246 RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000 RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0 RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002 R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78 R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0 FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0 Call Trace: <TASK> mlx5e_tc_del_flow+0x46/0x270 [mlx5_core] mlx5e_flow_put+0x25/0x50 [mlx5_core] mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core] tc_setup_cb_reoffload+0x20/0x80 fl_reoffload+0x26f/0x2f0 [cls_flower] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] tcf_block_playback_offloads+0x9e/0x1c0 tcf_block_unbind+0x7b/0xd0 tcf_block_setup+0x186/0x1d0 tcf_block_offload_cmd.isra.0+0xef/0x130 tcf_block_offload_unbind+0x43/0x70 __tcf_block_put+0x85/0x160 ingress_destroy+0x32/0x110 [sch_ingress] __qdisc_destroy+0x44/0x100 qdisc_graft+0x22b/0x610 tc_get_qdisc+0x183/0x4d0 rtnetlink_rcv_msg+0x2d7/0x3d0 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x249/0x320 ? __alloc_skb+0x102/0x1f0 netlink_sendmsg+0x1e3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1ef/0x230 ? copy_msghdr_from_user+0x6c/0xa0 ___sys_sendmsg+0x7f/0xc0 ? ___sys_recvmsg+0x8a/0xc0 ? __sys_sendto+0x119/0x180 __sys_sendmsg+0x61/0xb0 do_syscall_64+0x55/0x640 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f35238bb764 Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55 RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764 RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003 RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20 R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790 R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780 Fixes: 9be6c21fdcf8 ("net/mlx5e: Handle offloads flows per peer") Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Shay Drori <shayd@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1769411695-18820-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-27net/mlx5: Fix Unbinding uplink-netdev in switchdev modeShay Drory
It is possible to unbind the uplink ETH driver while the E-Switch is in switchdev mode. This leads to netdevice reference counting issues[1], as the driver removal path was not designed to clean up from this state. During uplink ETH driver removal (_mlx5e_remove), the code now waits for any concurrent E-Switch mode transition to finish. It then removes the REPs auxiliary device, if exists. This ensures a graceful cleanup. [1] unregister_netdevice: waiting for eth2 to become free. Usage count = 2 ref_tracker: netdev@00000000c912e04b has 1/1 users at ib_device_set_netdev+0x130/0x270 [ib_core] mlx5_ib_vport_rep_load+0xf4/0x3e0 [mlx5_ib] mlx5_esw_offloads_rep_load+0xc7/0xe0 [mlx5_core] esw_offloads_enable+0x583/0x900 [mlx5_core] mlx5_eswitch_enable_locked+0x1b2/0x290 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x107/0x3e0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 __x64_sys_sendto+0x20/0x30 Fixes: 7a9fb35e8c3a ("net/mlx5e: Do not reload ethernet ports when changing eswitch mode") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1769411695-18820-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-27net: usb: int51x1: use usbnet_cdc_update_filterEthan Nelson-Moore
The int51x1 driver uses the same requests as USB CDC to handle packet filtering, but provides its own definitions and function to handle it. The chip datasheet says the requests are CDC compliant. Replace this unnecessary code with a reference to usbnet_cdc_update_filter. Also fix the broken datasheet link and remove an empty comment. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260126044049.40359-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-27Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2026-01-26 (ice, idpf) For ice: Jake converts ring stats to utilize u64_stats APIs and performs some cleanups along the way. Alexander reorganizes layout of Tx and Rx rings for cacheline locality and utilizes __cacheline_group* macros on the new layouts. For idpf: YiFei Zhu adds support for BPF kfunc reporting of hardware Rx timestamps. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: idpf: export RX hardware timestamping information to XDP ice: reshuffle and group Rx and Tx queue fields by cachelines ice: convert all ring stats to u64_stats_t ice: shorten ring stat names and add accessors ice: use u64_stats API to access pkts/bytes in dim sample ice: remove ice_q_stats struct and use struct_group ice: pass pointer to ice_fetch_u64_stats_per_ring ==================== Link: https://patch.msgid.link/20260126224313.3847849-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-27net: aquantia: Remove redundant UDP length adjustment with GSO_PARTIALGal Pressman
GSO_PARTIAL now takes care of updating the UDP header length, remove the redundant assignment in aq_nic_map_skb(). Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Link: https://patch.msgid.link/20260125121649.778086-4-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-27net/mlx5e: Remove redundant UDP length adjustment with GSO_PARTIALGal Pressman
GSO_PARTIAL now takes care of updating the UDP header length, mlx5e_udp_gso_handle_tx_skb() is redundant, remove it. Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260125121649.778086-3-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-27net: stmmac: don't pass ioaddr to fix_soc_reset() methodRussell King (Oracle)
As the stmmac_priv struct is passed to the fix_soc_reset() method which has the ioaddr, there is no need to pass ioaddr separately. Pass just the stmmac_priv struct. Fix up the glues that use it. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1vkLmM-00000005vE1-0nop@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-28ASoC: codec: Remove ak4641/pxa2xx-ac97 and convert toMark Brown
Merge series from "Peng Fan (OSS)" <peng.fan@oss.nxp.com>: The main goal is to convert drivers to use GPIO descriptors. While reading the code, I think it is time to remove ak4641 and pxa2xx-ac97 driver, more info could be found in commit log of each patch. Then only need to convert sound/arm/pxa2xx-ac97-lib.c to use GPIO descriptors. Not have hardware to test the pxa2xx ac97.
2026-01-27net: usb: sr9700: replace magic numbers with register bit macrosEthan Nelson-Moore
The first byte of the Rx frame is a copy of the Rx status register, so 0x40 corresponds to RSR_MF (meaning the frame is multicast). Replace 0x40 with RSR_MF for clarity. (All other bits of the RSR indicate errors. The fact that the driver ignores these errors will be fixed by a later patch.) The first byte of the status URB is a copy of the NSR, so 0x40 corresponds to NSR_LINKST. Replace 0x40 with NSR_LINKST for clarity. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Reviewed-by: Peter Korsgaard <peter@korsgaard.com> Link: https://patch.msgid.link/20260124032248.26807-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-27drm/amd/pm: fix race in power state check before mutex lockYang Wang
The power state check in amdgpu_dpm_set_powergating_by_smu() is done before acquiring the pm mutex, leading to a race condition where: 1. Thread A checks state and thinks no change is needed 2. Thread B acquires mutex and modifies the state 3. Thread A returns without updating state, causing inconsistency Fix this by moving the mutex lock before the power state check, ensuring atomicity of the state check and modification. Fixes: 6ee27ee27ba8 ("drm/amd/pm: avoid duplicate powergate/ungate setting") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 7a3fbdfd19ec5992c0fc2d0bd83888644f5f2f38)
2026-01-27drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_removeJon Doron
On APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and ih2 interrupt ring buffers are not initialized. This is by design, as these secondary IH rings are only available on discrete GPUs. See vega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when AMD_IS_APU is set. However, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to get the timestamp of the last interrupt entry. When retry faults are enabled on APUs (noretry=0), this function is called from the SVM page fault recovery path, resulting in a NULL pointer dereference when amdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[]. The crash manifests as: BUG: kernel NULL pointer dereference, address: 0000000000000004 RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu] Call Trace: amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu] svm_range_restore_pages+0xae5/0x11c0 [amdgpu] amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu] gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu] amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu] amdgpu_ih_process+0x84/0x100 [amdgpu] This issue was exposed by commit 1446226d32a4 ("drm/amdgpu: Remove GC HW IP 9.3.0 from noretry=1") which changed the default for Renoir APU from noretry=1 to noretry=0, enabling retry fault handling and thus exercising the buggy code path. Fix this by adding a check for ih1.ring_size before attempting to use it. Also restore the soft_ih support from commit dd299441654f ("drm/amdgpu: Rework retry fault removal"). This is needed if the hardware doesn't support secondary HW IH rings. v2: additional updates (Alex) Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3814 Fixes: dd299441654f ("drm/amdgpu: Rework retry fault removal") Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Philip Yang <Philip.Yang@amd.com> Signed-off-by: Jon Doron <jond@wiz.io> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526) Cc: stable@vger.kernel.org
2026-01-27drm/amd/pm: fix smu v14 soft clock frequency setting issueYang Wang
v1: resolve the issue where some freq frequencies cannot be set correctly due to insufficient floating-point precision. v2: patch this convert on 'max' value only. Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 53868dd8774344051999c880115740da92f97feb) Cc: stable@vger.kernel.org
generated by cgit v1.2.3 (git 2.25.1) at 2026-08-14 11:52:45 +0000