summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-08-20net: ntb_netdev: Fix TX busy and drop handlingKoichiro Den1-8/+19
Currently, ntb_netdev returns NETDEV_TX_BUSY for every enqueue error. It also increments the drop and error counters while leaving the skb owned by the qdisc, and may return BUSY with the subqueue still awake. Retrying a permanent error cannot succeed either. The unconditional BUSY return and premature accounting date back to the initial driver. The error-path queue stop was later removed without changing that return value. The current flow-control code includes a resource check, but ntb_netdev does not honor its result before enqueue. Honor the resource check before enqueue. For -EAGAIN and -EBUSY, stop the subqueue, arm the existing reaper timer, and return BUSY without touching the skb. For other errors, free the skb, increment tx_dropped, and return NETDEV_TX_OK. Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Fixes: d723485cb4ca ("ntb_netdev: remove tx timeout") Fixes: e74bfeedad08 ("NTB: Add flow control to the ntb_netdev") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260817053519.4135287-3-den@valinux.co.jp Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20NTB: ntb_transport: Recycle TX entries before client callbacksKoichiro Den1-9/+14
ntb_tx_copy_callback() invokes the client callback before returning the entry to tx_free_q. The callback may wake a stopped client queue, only for the next enqueue to find no local entry and return -EBUSY. The window is narrow, but the retry is unnecessary. Save the callback data and length, then return the entry to tx_free_q before invoking the client. A completion callback then means both the client buffer and transport entry are ready for reuse. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260817053519.4135287-2-den@valinux.co.jp Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20Merge branch 'ionic_rcq_shared' of https://github.com/abhijitG-xlnx/linuxJakub Kicinski1-1/+5
Abhijit Gangurde says: ==================== Extend the net/ionic firmware identity structure to expose the rcq_sign_bit field from the RDMA LIF identity. * 'ionic_rcq_shared' of https://github.com/abhijitG-xlnx/linux: net: ionic: Fetch RCQ sign bit from firmware ==================== Link: https://patch.msgid.link/ Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20Merge tag 'fs_for_v7.3-rc1' of ↵Linus Torvalds1-27/+0
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs Pull ext2, udf, isofs, and quota updates from Jan Kara: - Remove deprecated quota code printing warnings about exceeded quota directly to console - Various udf & isofs hardening for handling of corrupted filesystems - Fix a possible data loss in udf when converting files from inline to out-of-line format - Simplify EIO error handling in ext2 xattr code * tag 'fs_for_v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: udf: Fix data loss when converting inline inodes to out of line udf: Move udf_map_block() up ext2: Simplify error handling of IO error when adding xattr isofs: Drop support of directory entries straddling blocks isofs: validate directory records consistently quota: remove CONFIG_PRINT_QUOTA_WARNING code udf: Fix i_lenExtents truncation on 32-bit kernels isofs: release zisofs block pointer buffer head udf: Fix bh leak for unallocated space entries udf: bound lengthAllocDescs from unallocated space entry UDF symlink pathComponent header OOB read isofs: fix out-of-bounds page array access on empty zisofs block udf: reject VAT indexes equal to the entry count udf: Mark LVID buffer as uptodate before marking it dirty udf: avoid recursive s_alloc_mutex deadlock when freeing AED blocks udf: validate extent partition references in udf_current_aext()
2026-08-20net: qlcnic: validate unified ROM sections before loadingPengpeng Hou1-196/+247
The unified ROM parser reads directory, product, and data-descriptor fields from the firmware file. Existing validation forms table and data ends with unchecked additions and multiplications. Malformed values can wrap before they are compared with the firmware size. The parser also dereferences typed pointers at firmware-controlled offsets. Valid descriptor extents alone are insufficient for the consumers. The loader reads a fixed-size bootloader regardless of its declared size, the version parser assumes a 17-byte tail, and a partial final firmware word is read as a full u64. A truncated image can therefore make the driver read beyond the firmware allocation during validation or loading. Replace the pointer-returning parser with bounded range helpers. Validate table entry sizes, descriptor indices, section ranges, the fixed bootloader load length, and the version tail before exposing any section. Read all file fields with unaligned little-endian accessors and assemble a partial final word from only the bytes that remain. Apply the same range checks to the legacy image before reading its fixed fields. Fixes: af19b49152bd ("qlcnic: Qlogic ethernet driver for CNA devices") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260816052109.4607-1-pengpeng@iscas.ac.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20bnx2x: fix double free in bnx2x_init_firmware() error pathJiangshan Yi1-0/+3
bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op. Fixes: 94a78b79cb5f ("bnx2x: Separated FW from the source.") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260815122149.951215-1-yijiangshan@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20netdevsim: update queue NAPI association on queue resetEric Dumazet1-0/+2
In netdevsim, receive queues (struct nsim_rq) embed their own struct napi_struct. When queue reset is performed (e.g. via queue_reset debugfs), nsim_queue_start() swaps in a newly allocated struct nsim_rq, and nsim_queue_mem_free() later deletes and frees the old one. However, nsim_queue_start() failed to update the queue-to-NAPI mapping via netif_queue_set_napi(). As a result, dev->_rx[idx].napi continued to point to the old NAPI struct. After the old queue was freed, a subsequent queue dump via Netlink (NETDEV_CMD_QUEUE_GET) triggered a KASAN slab-use-after-free read in nla_put_napi_id() when accessing rxq->napi->napi_id. Fix this by calling netif_queue_set_napi() in nsim_queue_start() to associate the new NAPI with the RX queue, and clear the association with netif_queue_set_napi(..., NULL) in nsim_del_napi() during teardown. Fixes: 5bc8e8dbef27 ("netdevsim: add queue management API support") Reported-by: syzbot+483a6efbc4882c1201ee@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a82c3d4.f7a79266.2f965f.0024.GAE@google.com/T/#u Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260817082511.2300402-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20ACPI: pfr_update: fix stack buffer overflow in query_capability()Anirudh Prasad1-21/+24
query_capability() copies four ACPI buffer objects returned by the firmware _DSM into fixed-size u8[16] fields in struct pfru_update_cap_info using memcpy with the firmware-supplied length: memcpy(&cap_hdr->code_type, elements[CAP_CODE_TYPE_IDX].buffer.pointer, elements[CAP_CODE_TYPE_IDX].buffer.length); The same pattern repeats for drv_type, platform_id, and oem_id. If the firmware returns buffer.length > 16 for any of these fields, memcpy writes past the destination array. struct pfru_update_cap_info is stack-allocated in pfru_ioctl(). Confirmed with KASAN on 7.2-rc6: three stack-out-of-bounds reports are generated when a DSM returns 64-byte buffers, with writes reaching 44 bytes past the end of cap_hdr's [64, 156) frame window into adjacent stack redzones. Introduce a helper pointer to out_obj->package.elements and use it to validate each buffer length against its destination field size before copying, returning -EINVAL if the firmware supplies an oversized buffer. Fixes: 0db89fa243e5 ("ACPI: Introduce Platform Firmware Runtime Update device driver") Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Anirudh Prasad <icarus@a0rg.com> Link: https://patch.msgid.link/1a001e1fee9.637da6dc3533246.238498880682901704@a0rg.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-08-20net: ipa: balance runtime PM reference on remove errorRuoyu Wang1-3/+3
ipa_remove() takes a runtime PM reference before accessing IPA hardware during teardown. If a concurrent modem start or stop keeps ipa_modem_stop() busy across both attempts, the callback intentionally returns without releasing the remaining resources because proceeding with teardown could crash. That return also skips the matching pm_runtime_put_noidle(), leaving the callback's usage-count reference held. Drop only this runtime PM reference before returning. pm_runtime_put_noidle() does not request an idle transition, so the hardware and resources retained on this exceptional path remain untouched while the usage count stays balanced. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 923a6b698447 ("net: ipa: get clock in ipa_probe()") Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Reviewed-by: Alex Elder <elder@riscstar.com> Link: https://patch.msgid.link/20260815151737.3758320-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20forcedeth: stop the tx_timeout register dump past the requested windowMarek Czernohous1-1/+1
nv_tx_timeout() dumps the register window in rows of eight dwords: for (i = 0; i <= np->register_size; i += 32) { netdev_info(dev, "%3x: %08x ... %08x\n", i, readl(base + i + 0), ..., readl(base + i + 28)); The loop bound only checks the row's starting offset, so the final row reads a full 32 bytes from a position that is below the end of the window but too close to it. base is mapped with exactly that length: np->base = ioremap(addr, np->register_size); so the tail of that row is read from beyond the length the driver asked for. Per variant, the last iteration reads past register_size by: NV_PCI_REGSZ_VER1 (0x270): row 0x260 reads to 0x27f, 16 bytes over NV_PCI_REGSZ_VER2 (0x2d4): row 0x2c0 reads to 0x2df, 12 bytes over NV_PCI_REGSZ_VER3 (0x604): row 0x600 reads to 0x61f, 28 bytes over This happens on every supported device, not just one of them. Note that it is not a consequence of the sizes being odd: with i <= register_size the offending row is reached whatever the size, and a size that were a multiple of 32 would overrun by a full row rather than by a remainder. To be precise about the severity: the reads stay inside the BAR. Memory BAR sizes are powers of two, the driver only accepts a region with pci_resource_len() >= register_size (forcedeth.c:5757-5762), and the next power of two at or above each register_size already covers the offending row: 0x400 for 0x270 and 0x2d4, 0x800 for 0x604. ioremap() also rounds the mapped length up to page granularity, so the reads land inside the mapping the CPU has as well. What they leave is the window the driver asked for, not the BAR and not the mapping. That is still a driver reading registers it did not ask for, and it is trivial to avoid, but nobody should expect a fault from it. Changing <= to < is not enough: register_size is a length and every size above is larger than its last row start, so i still reaches the offending row. Check that the whole row fits instead. The trade-off is that a partial trailing row is no longer dumped: 16 bytes for VER1, 20 for VER2, 4 for VER3. That seemed preferable to reading outside the requested window, and to open-coding a second, narrower dump for the remainder in what is a debug-only path. Extending the dump to cover the tail can be done on top if anyone misses those registers. Only reachable with the debug_tx_timeout module parameter, which defaults to false. It has not been observed at runtime: forcing a genuine TX timeout on the reference machine is not something I can do safely, so this rests on the arithmetic above and on a build test, not on a reproduction. UBSAN does not catch it either, since these are MMIO reads rather than an array access. It was found by reading the function while fixing the saved_config_space off-by-one in nv_suspend() and nv_resume(). The dump was introduced with a fixed 0x400 bound while ioremap() mapped only NV_PCI_REGSZ (0x270), so it read about 0x190 bytes too far from the start. Commit 86a0f04387bf ("[PATCH] forcedeth: fix initialization") later replaced 0x400 with np->register_size, which shrank the overrun to the remainder but did not remove it. Fixes: c2dba06dae7d ("[PATCH] forcedeth: rewritten tx irq handling") Signed-off-by: Marek Czernohous <marek@czernohous.de> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Link: https://patch.msgid.link/178682367886.3748309.6978554332066826294@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20forcedeth: fix off-by-one when saving/restoring non-PCI config spaceMarek Czernohous1-2/+2
nv_suspend() and nv_resume() walk the non-PCI configuration space with for (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as u32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: np->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the "?" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f ("forcedeth: fix buffer overflow") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes. Fixes: 1a1ca86158ee ("[netdrvr] forcedeth: save/restore device configuration space") Cc: stable@vger.kernel.org Signed-off-by: Marek Czernohous <marek@czernohous.de> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Link: https://patch.msgid.link/178682367885.3748309.10595890901761762683@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20net/mlx5: E-Switch, preserve max tx speed on vport state modificationOr Har-Toov2-0/+44
When modifying vport state, the firmware interprets a zero in the max tx speed field as an intentional reset, which can overwrite previously set values. This patch attempts to fix this by querying the current max tx speed from firmware before modifying the vport state and passing it back in the modification command. If the query fails, fall back to the cached agg_max_tx_speed value to avoid inadvertently resetting the speed. Fixes: 50f1d188c580 ("net/mlx5: Propagate LAG effective max_tx_speed to vports") Signed-off-by: Or Har-Toov <ohartoov@nvidia.com> Reviewed-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/20260816065015.3280733-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20net/mlx5: Move vport DOWN state check out of mlx5_query_vport_max_tx_speed()Or Har-Toov2-10/+7
mlx5_query_vport_max_tx_speed() was introduced to serve the query_port_speed path, which uses max_tx_speed == 0 when port is down. This is incorrect for callers that need the actual configured speed regardless of vport state, such as modify-vport-state helpers that must preserve the speed across state transitions. Move this logic to the caller function in the verb flow and let mlx5_query_vport_max_tx_speed() return the raw firmware value unconditionally. Fixes: aaecff5e13cd ("RDMA/mlx5: Implement query_port_speed callback") Signed-off-by: Or Har-Toov <ohartoov@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/20260816065015.3280733-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20net/mlx5: E-Switch, use state lock for vport state changesMark Bloch5-5/+31
Protect vport admin state modifications and vport iteration with the eswitch state_lock mutex to ensure proper serialization of concurrent vport state changes. Currently, calls to mlx5_modify_vport_admin_state() and loops iterating over eswitch vports can race with each other, potentially leading to inconsistent vport state. Fix this by acquiring esw->state_lock Fixes: 7d0314b11cdd ("net/mlx5e: Modify uplink state on interface up/down") Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Shay Drori <shayd@nvidia.com> Reviewed-by: Or Har-Toov <ohartoov@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260816065015.3280733-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20net: thunderbolt: Count delivered packets in rx_packets and rx_bytesFan Ye1-3/+3
tbnet_poll() increments rx_packets once per received frame because that is the NAPI work unit, and then adds the same number to stats.rx_packets. An skb is handed to the stack only when the last frame of a packet arrives, so once the MTU exceeds TBNET_MAX_PAYLOAD_SIZE the statistic reports frames. tx_packets is bumped once per skb, so the two ends of a link disagree: at MTU 65330 the receiver reports 16 times the packets its sender sent. rx_bytes has the matching problem: frames of a packet that is later dropped mid-assembly are already accounted, so it does not correspond to rx_packets as documented. Account for both where the packet is completed, and leave the NAPI work counter alone. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Signed-off-by: Fan Ye <fy15309206903@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Acked-by: Mika Westerberg <westeri@kernel.org> Link: https://patch.msgid.link/20260815-tbnet-rx-stats-v1-1-8da375c2cd09@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20Merge tag 'libnvdimm-for-7.3' of ↵Linus Torvalds6-55/+176
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull NVDIMM and DAX updates from Alison Schofield: "Most are DAX preparatory patches for FAMFS support, along with a few NVDIMM fixes and documentation cleanups. - Documentation cleanup, removing kernel-doc warnings - preparing DAX for FAMFS - misc NVDIMM fixups with cleanups for issues reported by Coccinelle" * tag 'libnvdimm-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: nvdimm-btt: clean up kernel-doc warnings libnvdimm: nd.h: clean up kernel-doc warnings dax: fsdev.c minor formatting cleanup dax: fix holder_ops race in fs_put_dax() dax: read holder_ops once in dax_holder_notify_failure() dax/fsdev: fail probe on invalid pgmap offset dax/fsdev: use __va(phys) for kaddr in direct_access dax/fsdev: clear pgmap ops and owner on unbind dax/fsdev: don't leave a dangling dev_dax->pgmap on probe failure dax/fsdev: clear vmemmap_shift when binding static pgmap dax/fsdev: fix multi-range offset in memory_failure handler dax: fix misleading comment about share/index union in dax_folio_reset_order() nvdimm/btt: reject an arena whose nfree is below the lane count libnvdimm/labels: Bound the on-media label size before the shift libnvdimm/labels: Prevent integer overflow in __nd_label_validate() nvdimm: ndtest: remove redundant NULL check before vfree() nvdimm: nfit: remove redundant NULL check before vfree()
2026-08-20net: macb: drop CONFIG_OF #if blockThéo Lebrun1-3/+1
Fix -Wimplicit-function-declaration error on CONFIG_OF=n builds: drivers/net/ethernet/cadence/macb_main.c: In function ‘macb_probe’: drivers/net/ethernet/cadence/macb_main.c:5951:15: error: implicit declaration of function ‘macb_alloc_tieoff’ [...] 5951 | err = macb_alloc_tieoff(bp); | ^~~~~~~~~~~~~~~~~ drivers/net/ethernet/cadence/macb_main.c:5973:9: error: implicit declaration of function ‘macb_free_tieoff’ [...] 5973 | macb_free_tieoff(bp); | ^~~~~~~~~~~~~~~~ Error got introduced because functions are mistakenly declared in a `#if defined(CONFIG_OF)` block. Instead of moving functions around, avoid any future mistake and drop the block entirely. Change the module content slightly on CONFIG_OF=n. Previously match tables were ignored. Now they appear in the resulting build. This is considered trivial in size by most and is the common case: ⟩ 18 out of 254 OF net drivers reference CONFIG_OF ⟩ rg -lF 'MODULE_DEVICE_TABLE(of,' drivers/net/ | tee /tmp/a | wc -l 254 ⟩ xargs -a /tmp/a rg -l CONFIG_OF | wc -l 18 Tangent: no, of_match_ptr() does not imply that the compiler can optimize out match tables, because MODULE_DEVICE_TABLE(of, ...) unconditionally puts the match tables in the binary. It is only meant to avoid undefined declaration issues when match tables are hidden behind a #ifdef, as was done before. We therefore drop the macro call. Fixes: 5262eab9462a ("net: macb: allocate tieoff descriptor once across device lifetime") Reported-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260820-macb-fix-x86-v1-1-b2e7c902104e@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20ACPI: scan: Defer device power initializationPeixin Xie2-4/+1
acpi_bus_get_power_flags() initializes the device power state while the ACPI device object is being created, before checking whether the device is ready for enumeration. If enumeration is deferred, acpi_bus_attach() clears the initialized and power_manageable flags. When the dependency is later satisfied, acpi_bus_init_power() is called again and takes additional references to the power resources used by the device. These references prevent the resources from being turned off when the device enters D3. This issue was reproduced on a SpacemiT K3 RISC-V Pico-ITX. The affected device uses a power resource through _PR0 and has an automatically derived dependency on its interrupt controller. The initial power initialization acquires a power resource reference. The device is then deferred, but that reference is not dropped. When the dependency becomes available, power initialization acquires another reference. Consequently, entering D3 only drops the reference count from 2 to 1 and _OFF is not evaluated: [ 0.314611] ACPI Debug: "I2P2 _STA" [ 0.318260] ACPI: \_SB_.I2P2: ACPI: PM: Power resource is on [ 0.323998] ACPI: \_SB_.I2P2: New power resource [ 0.382108] ACPI Debug: "I2P2 _STA" [ 0.478964] ACPI Debug: "I2P2 _ON" [ 0.482498] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned on [ 0.488597] ACPI Debug: "I2C2, PS0" [ 0.863170] ACPI: \_SB_.I2P2: ACPI: PM: Power resource already on [ 0.873686] ACPI Debug: "I2C2, PS0" [ 2.416055] ACPI Debug: "I2C2, PS3" [ 2.423397] ACPI: \_SB_.I2P2: ACPI: PM: Power resource still in use To address this, remove the early acpi_bus_init_power() call and leave regular ACPI device objects uninitialized until acpi_bus_attach() runs after the device is ready for enumeration. Power resource objects are initialized through acpi_add_power_resource() and do not require the generic initialization in acpi_bus_attach(), so mark them as initialized there. After the change, device power state initialization is deferred until its dependency is met. Since no reference is acquired before then, the power resource left on by firmware is turned off as unused after the namespace scan. Once the dependency is met, the resource is turned on once for the device and is turned off normally when the device later enters D3: [ 0.314628] ACPI Debug: "I2P2 _STA" [ 0.318277] ACPI: \_SB_.I2P2: ACPI: PM: Power resource is on [ 0.324016] ACPI: \_SB_.I2P2: New power resource [ 0.382118] ACPI Debug: "I2P2 _STA" [ 0.496116] ACPI: \_SB_.I2P2: ACPI: PM: Turning OFF [ 0.501081] ACPI Debug: "I2P2 _OFF" [ 0.504705] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned off [ 1.415899] ACPI Debug: "I2P2 _ON" [ 1.418866] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned on [ 1.424947] ACPI Debug: "I2C2, PS0" [ 2.647655] ACPI Debug: "I2C2, PS3" [ 2.654856] ACPI Debug: "I2P2 _OFF" [ 2.654866] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned off This also avoids powering up devices before their dependencies are available. Signed-off-by: Peixin Xie <peixin.xie@linux.spacemit.com> [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260820-acpi-power-resource-ref-fix-v2-1-29818173ea13@linux.spacemit.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-08-20Merge tag 'bitmap-for-7.3' of https://github.com/norov/linuxLinus Torvalds40-55/+46
Pull bitmap updates from Yury Norov: "The usual set of fixes, cleanups and performance improvements together with a couple of new tests: - bitmap_find_next_zero_area_off() optimization (Sunyi) - bitmap_find_next_zero_area_off(): return size when no zero area is found (Yury) - bitmap vs IDA vs Maple Tree performance test (Yury) - get rid of cpumap_print_to_pagebuf() (Yury) - use nr_node_ids in __nodemask_pr_numnodes() (Li RongQing) - bitops: make the *_bit_le functions use unsigned long (Benjamin) - bitmap scatter & gather test fix (Christophe) - use __ASSEMBLER__ in bitmap header files (Thomas)" * tag 'bitmap-for-7.3' of https://github.com/norov/linux: (25 commits) lib: test bitmap vs IDA vs Maple Tree performance for region allocations bitmap: Return size when no zero area is found media: s5p-mfc: Treat bitmap size as allocation failure crypto: ccp: Treat bitmap size as allocation failure powerpc/msi: Treat bitmap size as allocation failure ARM: dma-mapping: Treat bitmap size as allocation failure bitmap: drop bitmap_next_set_region() nodemask: reduce bitmap width to nr_node_ids in __nodemask_pr_numnodes() bitmap: Properly initialise destination bitmap for scatter & gather test lib/bitmap-str: get rid of cpumap_print_to_pagebuf() perf: Use sysfs_emit() for cpumask show callbacks PCI/sysfs: Use sysfs_emit() for cpumask show callbacks RDMA/hfi1: Use sysfs_emit() for cpumask show helper hwtracing: hisi_ptt: Use sysfs_emit() for cpumask show fpga: dfl-fme-perf: Use sysfs_emit() for cpumask show devfreq: Use sysfs_emit() for cpumask show callbacks cpu: Use sysfs_emit() for cpumask show callback x86/events: Use sysfs_emit() for cpumask show callbacks powerpc: Use sysfs_emit() for cpumask show callbacks arm: Use sysfs_emit() for cpumask show callbacks ...
2026-08-20net: ipa: fix stalled modem TX queue after runtime resumeJorijn van der Graaf1-1/+17
ipa_start_xmit() unconditionally stops the TX queue before calling pm_runtime_get(), relying on the wake scheduled by runtime resume (ipa_modem_wake_queue_work()) to restart it once power is ACTIVE. But that work is queued from within the runtime resume callback, before the device's power state reaches RPM_ACTIVE, so it can run while the device is still RPM_RESUMING. The wake is then consumed too early: the transmit it restarts stops the queue again, pm_runtime_get() returns -EINPROGRESS without arranging any future wake (deferred_resume exists only for RPM_SUSPENDING), and after the resume completes nothing is left to wake the queue. Transmit stalls permanently: packets pile up in the qdisc behind the stopped queue, the device runtime-suspends, and since the netdev registers no ndo_tx_timeout the watchdog never fires. Observed on SM7635 (Fairphone 6) as the cellular data path going permanently deaf within hours, RX included, since nothing resumes the suspended endpoints. Close the window by making the wake work wait for the resume to complete (pm_runtime_get_sync()) before waking the queue. Every queue stop is then guaranteed a later wake that happens while power is ACTIVE; a transmit racing a new suspend/resume cycle re-schedules the work. If the device could not be resumed, wake the queue anyway so pending packets are dropped by the transmit path rather than stranded. The STARTED power flag used to narrow this window: a wake running before the transmit path's stop suppressed that stop, but only once, as the flag was cleared by the first stop it absorbed. Removing the flag made a single transmit during an in-flight resume sufficient to strand the queue, which is the form observed. With an accelerated reproducer (autosuspend delay shortened to 5 ms, ~20 packets/s of TX), an unpatched kernel stalled three times in 230 s / 4380 packets; with this patch the same test ran 3601 s / 70298 packets without a stall. Fixes: 688de12f080f ("net: ipa: kill the STARTED IPA power flag") Cc: stable@vger.kernel.org Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260815040302.653650-1-jorijnvdgraaf@catcrafts.net Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-20irqchip/irq-realtek-rtl: Use readl_be()/writel_be() instead of readl()/writel()Rustam Adilov1-7/+13
When CONFIG_SWAP_IO_SPACE is enabled, readl() performs a swap from little endian device to big endian CPU and vice versa for writel(). This is incorrect for Realtek Interrupt controller as that is a big endian device and so the LE to BE conversions are unwanted. Fix this by converting the MMIO accesses to readl_be() and writel_be(). Fixes: 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller") Signed-off-by: Rustam Adilov <adilov@disroot.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Carlo Szelinsky <github@szelinsky.de> Link: https://patch.msgid.link/20260820162017.28507-1-adilov@disroot.org
2026-08-20Merge tag 'net-next-7.3' of ↵Linus Torvalds892-25746/+93987
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next Pull networking updates from Jakub Kicinski: "One of the 'small improvements all over the place' releases for us. It's hard to draw any direct comparisons because summer vacations disrupted our patch processing (and presumably - generation) quite a bit. Quick and dirty count suggests we (Paolo and I) merged a very similar number of net (632) and net-next (648) patches. This is not telling the full story either because 1/3 to 1/2 of the net-next patches also *seem* like AI-driven low priority fixes, cleanups and clarifications. We are completely overwhelmed, of course. The glimmer of hope is that we secured sufficient LLM budget and access (thank you Meta!) to run reviews with multiple frontier models on each patch. This eliminates some hallucinations. That said, in terms of review, the LLMs can only do so much. The sad truth is that our APIs (especially for rare events like PCIe errors, timeouts etc) have always been racy, and now LLMs don't let us ignore that. I expect our direction for the next release will be to tweak the reviews a little bit more, but start shifting focus to letting the LLMs take care of the busy work - managing patchwork, automating common process complaints, editing commit messages, and maybe applying patches which already got "reviewed-by" tags from people we trust... Core & protocols: - A few steps lowering rtnl_lock dependence: - per-netns netdev unregistration for select SW drivers (e.g. veth, ipvlan, tunnels) - rtnl_lock-less FIB rule changes (RTM_NEWRULE and RTM_DELRULE) - prepare software drivers and TC qdiscs for rtnl_lock-less GET - Support BIG TCP (>64kB TSO) in UDP tunnels (vxlan, geneve) - Support buffers larger than PAGE_SIZE in devmem zero-copy API - Improve MPTCP handling of extreme memory pressure handling, when out-of-order queue had to be pruned - Report the per-group user count via RTM_GETMULTICAST - Expose the route deletion reason in RTM_DELROUTE - Add a SO_RIGHTS_NOTRUNC option to UNIX sockets to enable more useful handling of LSM denials when receiving SCM_RIGHTS messages: instead of truncating the message at the first blocked fd, keep every fd slot and store the LSM errno in the blocked slot - IPv6 Segment Routing - support looking up the post-encap SID (address) in a different/specified routing table - Support PRP RedBox (interlink) creation - Support per-nexthop UDP dst port in VXLAN - Continue converting getsockopt callbacks in a number of protocols to iov_iter Ethernet: - Merge initial CXL support for AMD/Solarflare NICs (shared branch with the CXL tree) - New drivers: - ADIN1140 10BASE-T1S MACPHY - Initial skeleton of Intel iXD and ZTE Dinghai drivers - High-speed NICs: - AMD/Pensando: - support firmware flashing - Cisco (enic): - SR-IOV V2 admin channel and MBOX protocol - Huawei (hns3): - support for ethtool pfc_prevention_tout - nVidia/Mellanox: - support sharing bandwidth control across interfaces of the same device - Marvell (octeontx2-pf): - link RQ page pools to netdev for Netlink stats - Google vNIC: - XDP metadata support for DQ RDA - Microsoft vNIC: - support forcing full-page RX buffers - Other NICs: - Synopsys IP: - eic7700: support for eth1 - Microchip (lan743x): - support for RMII interface - Wangxun: - support for ethtool -G and -C for VFs - add Tx timeout and PCIe error handling - Intel (igb/igc): - RSS key get/set support - support for forcing link speed without auto-negotiation - Switches: - NXP (dpaa2): - support bonding/LAG offload - Mediatek: - mt7530: EN7528 support - initial support for MT7628 - Micrel (ksz8/9): - refactoring work to move towards library model - PTP support for KSZ8463 - nVidia/Mellanox: - support rtnl-lock-less ethtool callbacks - Realtek: - rtl8366rb: use generic RTL83xx code - support SGMII and HSGMII for RTL8367S - PHYs: - Airoha: - EcoNet EN7528 PHY support - DAPU Telecom - DAPU Telecom DAP8211R(I) Gigabit PHY support - Realtek: - support RTL8261C_CG - support RTL8261D Wireless: - nl80211: per-link statistics support for multi-link operation - mac80211: AQL/airtime-fairness support for multicast - Merge Peripheral Authentication Service (PAS) / TEE support for ath12k (shared branch with the firmware/qcom tree) - New drivers: - mm81x for Morse Micro Long-Range S1G devices - nxpwifi for NXP devices (mostly forked off from mwifiex) - Driver changes: - Broadcom (brcmfmac): - DPP support, some Cypress part update - MediaTek (mt76): - mt7928 support - mt7925 NAN support - mt7996 AP powersave improvements - Qualcomm (ath12k): - much kernel infrastructure integration work - AHB platform MultiPD support - Realtek (rt89): - LED support - RTL8922DE support - dual-BT coex for RTL8922D - Intel: - new FW version support Bluetooth: - HCI: add support for Shorter Connection Interval (SCI) feature - af_bluetooth: add minimal context analysis annotations - Driver changes: - Intel: - add Bluetooth SAR revision 2 support - add vendor_reset PCI sysfs for PLDR - Mediatek: - add USB IDs for MT7902 and MT7922 devices - Realtek: - add USB IDs for 8761CU and 8852BE devices - NXP: - add M.2 Bluetooth device support using pwrseq Misc: - DPLL support for manual/numerical oscillator control (NCO) (implement in zl3073x) - MCTP support for MCTP over USB v1.1 (DMTF DSP0283) - Power-over-Ethernet: support Realtek PSE controllers - Remove the IBM EHEA driver - Remove tulip/xircom_cb driver" * tag 'net-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1433 commits) net/mlx5e: do not HW-GRO coalesce small frames net: openvswitch: fix nf_connlabels leak in ovs_ct_init net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs() net: openvswitch: fix flow mask use-after-free on flow deletion sctp: stop processing a packet once its association is deleted dpll: zl3073x: add PTP clock support dpll: zl3073x: add channel ToD, phase step and TIE operations dpll: zl3073x: scale poll interval proportionally to timeout ptp: vmclock: prevent read-only mappings from becoming writable ipv4: reject undersized MTUs in ip_do_fragment() bonding: initialize err for empty target lists net: dsa: initial support for MT7628 embedded switch net: dsa: initial MT7628 tagging driver net: phy: mediatek: add phy driver for MT7628 built-in Fast Ethernet PHYs dt-bindings: net: dsa: add MT7628 ESW net: pse-pd: realtek-pse-mcu: add UART transport net: pse-pd: realtek-pse-mcu: add I2C transport net: pse-pd: add Realtek PSE MCU core dt-bindings: net: pse-pd: add bindings for Realtek PSE MCU vsock: use sock_error() to consume sk_err after a failed connect ...
2026-08-20Merge tag 'bpf-next-7.3' of ↵Linus Torvalds1-5/+5
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Pull bpf updates from Daniel Borkmann: "Major changes: - Redesign the verifier error reporting: failures now carry source and instruction annotations along with the causal event history that led to them, making program rejections far easier to debug and repair (Kumar Kartikeya Dwivedi) - Add arena argument support to kfuncs and struct_ops through the new __arena and __arena__nullable suffixes (Tejun Heo, Puranjay Mohan, Kumar Kartikeya Dwivedi, Ihor Solodrai) - Signed BPF program loader rework to accommodate both BPF and security community needs where the kernel runs the signature verification at BPF_PROG_LOAD time before the LSM admission hook (Daniel Borkmann) - Add a set of ksock kfuncs which let BPF LSM and syscall programs create, connect and send on UDP sockets in order to emit telemetry data (Mahe Tardy) - Unify helper and kfunc call argument verification and classify kfunc arguments purely from BTF into a generated bpf_func_proto which is computed once at add-call time (Amery Hung) Other features and fixes: - Enable EXECMEM_ROX_CACHE for BPF allocations on x86 (Mike Rapoport) - Add bidirectional VLAN support to bpf_fib_lookup() through the new BPF_FIB_LOOKUP_VLAN and BPF_FIB_LOOKUP_VLAN_INPUT flags (Avinash Duduskar) - Infer zext_dst from static register liveness analysis to fix 32-bit zero-extension semantics, and remove the artificial limitations on pointer types eligible for spilling (Eduard Zingerman) - Inline the numeric open-coded iterator kfuncs so that bpf_for() loops no longer pay a kfunc call on every iteration (Puranjay Mohan) - Add an arena-based bitmap data structure to libarena along with serial and parallel selftests (Emil Tsalapatis) - Teach resolve_btfids to discover kfuncs from the kernel's BTF ID sets and to emit kfunc BTF decl tags, reducing the kernel build's dependency on pahole features (Ihor Solodrai) - Add BPF_F_ADJ_ROOM_DECAP_* flags to bpf_skb_adjust_room() so that tunnel decapsulation can update the GSO and encapsulation state of the skb (Nick Hudson) - Fix the ring buffer pending_pos walk and the available-data accounting on 32-bit position wrap (Israel Téllez García) - Add memory usage accounting for arena maps and fix an mmap_lock deadlock on arena lock failure (Jiayuan Chen) - Add tracing_multi link info support to the kernel UAPI and bpftool, and refactor the stack map code to run with preemption disabled (Jiri Olsa) - Support BPF_F_EGRESS in bpf_redirect_peer() to emit the skb in the egress direction of the target's peer device (Jordan Rife) - Add a KF_SPINLOCK_SAFE kfunc flag so that providers, in particular modules, can declare kfuncs safe to call under bpf_spin_lock instead of relying on the verifier's hard-coded allowlist (Kaitao Cheng) - Introduce global percpu data for BPF programs with libbpf probing and bpftool skeleton support, and stop exposing uninitialized kernel heap memory when copying per-CPU map values (Leon Hwang) - Add s390 JIT support for load-acquire and store-release instructions (Maxim Khmelevskii) - Fix a CFI mismatch in the task work callback and an arm64 KASAN false positive after bpf_throw() (Mykyta Yatsenko) - Reject writes through untrusted BTF pointers and bound the rdonly/rdwr_buf_size kfunc arguments (Nicholas Dudar) - Invalidate RCU pointers only after the final spin unlock and account for preempt and IRQ disabled regions as overlapping RCU protection (Ning Ding) - Support mixing bpf2bpf calls and tail calls on RV64, add signed operations and 32-bit atomics to the RV32 JIT, and add timed may_goto support (Pu Lehui, Kuan-Wei Chiu, Feng Jiang) - Fix a use-after-free on mm_struct in bpf_find_vma() for foreign tasks and an mmap_lock leak in the irq_work path (Sanghyun Park) - Populate mmap-able BPF array map memory lazily which makes mmap() O(1) instead of proportional to the map size (Song Liu) - Introduce a jit_required flag and reject programs with inlined helpers when no JIT is available, where the interpreter would otherwise jump into an invalid address (Tiezhu Yang) - Fix the x86 JIT per-CPU address resolution into an extended register where the REX prefix dropped the high destination register bit (Vineet Gupta) - Reject MEM_ALLOC BTF accesses past object bounds, arena frees below the arena base, and mixed arena and ordinary atomic paths (Yiyang Chen) - Fix the trampoline handling of 128-bit arguments and of return values larger than 8 bytes (Yonghong Song) - Ensure that any fault prone load is rewritten with exception table handling, and fix the arena load-acquire and atomic fetch handling in the x86, arm64, riscv and s390 JITs (Daniel Borkmann) - Many more fixes and cleanups across the verifier, arena, trampolines, sockmap, cgroup, ring buffer, x86/arm64/riscv/s390 JITs, libbpf, bpftool, resolve_btfids and selftests" * tag 'bpf-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (373 commits) selftests/bpf: Add tests for a store on a fault prone qdisc pointer selftests/bpf: Add tests for fault prone loads out of RCU pointers selftests/bpf: Add tests for pointer type merge at a shared load selftests/bpf: Remove duplicate copies of the arena spinlock qnodes selftests/bpf: Retry stat generation in cgroup_iter_memcg selftests/bpf: Test pseudo-function policy diagnostics bpf: Distinguish function references in policy diagnostics bpf: Preserve source attribution without source text selftests/bpf: Test kfunc argument diagnostics bpf: Correct kfunc argument diagnostics bpf: Use canonical stack argument names in diagnostics bpf: Preserve R0 lineage across helper calls selftests/bpf: Exercise negative optlen in cgroup getsockopt hook bpf: Reject negative optlen in cgroup getsockopt hook selftests/bpf: tc_tunnel - validate decap GSO and encapsulation state bpf: Clear decap state on skb_adjust_room shrink path bpf: Allow new DECAP flags and add guard rails bpf: Add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation bpf: Refactor masks for ADJ_ROOM flags and encap validation bpf: Name the enum for BPF_FUNC_skb_adjust_room flags ...
2026-08-20drm/xe: don't WARN on kernel job timeout when device already wedgedNitin Gote1-0/+6
igt@xe_wedged@wedged-at-any-timeout wedges the device in mode 2 (UPON_ANY_HANG_NO_RESET) and then rebinds the driver. During unbind, a GSC proxy kernel submission can still time out; with the device wedged and the GuC CT stopped it can never complete, so its kernel job times out. Tile0: GT1: Kernel-submitted job timed out WARNING: drivers/gpu/drm/xe/xe_guc_submit.c:... at guc_exec_queue_timedout_job() Workqueue: gt-ordered-wq drm_sched_job_timedout Killed queues skip guc_submit_hint_wedged(), leaving 'wedged' false even though the device is already wedged. The timeout handler then treats the kernel queue timeout as unexpected and taints the kernel. Honour an already-wedged device even for killed queues so the expected teardown timeout no longer trips the WARN. Fixes: 5a2f117a80c2 ("drm/xe: Do not wedge device on killed exec queues") Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patch.msgid.link/20260814074106.92670-2-nitin.r.gote@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit a1c1dbd0f047bb05de6aaf6abe9103031179bf19) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-20spi: loongson: pm: add .freeze .poweroff .thaw .restoreLi Jun1-4/+2
after execute s4, the spi error, [ 1104.754246][ 4] [ T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110 [ 1104.761503][ 4] [ T1] spi_master spi1: failed to transfer one message from queue [ 1104.769201][ 4] [ T1] spi_master spi1: noqueue transfer failed [ 1104.776344][ 4] [ T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110 [ 1104.783609][ 4] [ T1] spi_master spi1: failed to transfer one message from queue [ 1104.791308][ 4] [ T1] spi_master spi1: noqueue transfer failed [ 1104.797446][ 4] [ T1] gttadd tpm_chip_start1 ret = -110 and in s4 the loongson_spi_resume&suspend are not called at all. use DEFINE_SIMPLE_DEV_PM_OPS() add .freeze .poweroff .thaw .restore, after s4 the spi communication is normal. Signed-off-by: Li Jun <lijun01@kylinos.cn> Link: https://patch.msgid.link/20260820092351.101605-1-lijun01@kylinos.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-20spi: amlogic-spisg: Make sure clk_init_data is fully initializedGeert Uytterhoeven1-1/+1
The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. aml_spisg_clk_init() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: cef9991e04aed330 ("spi: Add Amlogic SPISG driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://patch.msgid.link/9fb35ae0aedb7a6db0db6c78a8193c7602dd9d44.1787165329.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-20efi: apple-properties: validate setup data header lengthPengpeng Hou1-1/+4
map_properties() remaps the Apple properties setup_data payload and then reads the properties header fields. Reject a truncated payload before checking the header version and length fields. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-08-20RDMA/ucma: Allow path records to exactly fit the output bufferSerhat Kumral1-1/+1
ucma_query_path() emits a path record only when the remaining output buffer is strictly larger than struct ib_path_rec_data. A buffer sized exactly for the response header and N complete records therefore gets only N - 1 records, while resp->num_paths still advertises N. A caller sizing its buffer for a single record gets a header claiming one path and no path data at all. ucma_query_ib_service() in the same file computes the record count with a plain division and so accepts an exact fit; make ucma_query_path() behave the same way. Current librdmacm is unaffected because it always sizes the response for six records while the kernel currently reports at most two paths. Other users of the UAPI that provide an exactly sized buffer can observe the truncated response. Fixes: ac53b264b2f3 ("RDMA/ucma: Support querying when IB paths are not reversible") Signed-off-by: Serhat Kumral <serhatkumral1@gmail.com> Link: https://patch.msgid.link/20260806201358.147478-1-serhatkumral1@gmail.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-08-20efi/runtime-wrappers: retire the worker if a wedged call ever returnsBreno Leitao1-0/+3
When __efi_queue_work() times out it disables runtime services and returns, but the kworker is still blocked inside firmware. If the firmware eventually unblocks, efi_call_rts() would run its tail on an efi_rts_work that the timed-out caller has long abandoned: signalling a stale completion and clearing efi_runtime_lock_owner that may by then belong to another caller. If runtime services have been disabled by the time the call returns, park the worker with efi_rts_park_worker() instead, so it never touches efi_rts_work again or returns to the workqueue. Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-08-20efi/runtime-wrappers: honour EFI_RUNTIME_SERVICES in the non-blocking pathsBreno Leitao1-0/+16
Three wrappers call firmware directly instead of going through __efi_queue_work(), and none of them check whether runtime services are still enabled: virt_efi_set_variable_nb(), virt_efi_query_variable_info_nb() and virt_efi_reset_system(). Once a hang has cleared EFI_RUNTIME_SERVICES - or efi_recover_from_page_fault() has cleared it on a firmware page fault - these paths still enter the (possibly wedged) firmware, e.g. an EFI pstore write through the non-blocking SetVariable() variant, in violation of UEFI's non-reentrancy rules. reset_system() is reachable too: efi_reboot() only gates it on the static efi_rt_services_supported() mask, which does not track the runtime disable. Check efi_enabled(EFI_RUNTIME_SERVICES) in each before calling into firmware. Test it after taking efi_runtime_lock rather than before: the bit is only ever cleared at runtime while that lock is held, so checking it under the lock avoids racing with a concurrent timeout that clears the bit and drops the lock. Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-08-20efi/runtime-wrappers: bound the wait for EFI runtime service callsBreno Leitao1-1/+18
When an EFI runtime service hangs in firmware, the efi_rts_wq worker is stuck inside the call and cannot be cancelled. __efi_queue_work() then waits on the completion forever while holding efi_runtime_lock, so every later EFI caller is wedged until reboot; the only symptom is a "workqueue lockup" and tasks piling up on the semaphore. Replace wait_for_completion() with wait_for_completion_timeout() bounded by EFI_RTS_TIMEOUT (120 seconds). On timeout, clear EFI_RUNTIME_SERVICES and return EFI_ABORTED so later callers fail fast at the entry check instead of each paying another 120 seconds. The wedged worker is intentionally leaked and keeps ownership of efi_rts_work. A worker that only starts running after the timeout would otherwise dereference efi_rts_work.args, now pointing into the caller's freed stack frame, and hand stale pointers to firmware. Park it with efi_rts_park_worker() at the entry of efi_call_rts() when runtime services are already disabled, before it touches args or enters firmware. Known limitation: a worker already inside firmware when the timeout fires still holds efi_rts_args pointing into the caller's stack frame; if firmware unblocks afterwards and writes the output buffers, they land in reused memory. Firmware hung this long rarely recovers; a follow-up could bounce the buffers through kmalloc. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-08-20efi/runtime-wrappers: check EFI_RUNTIME_SERVICES before using efi_rts_workBreno Leitao1-6/+5
Move the EFI_RUNTIME_SERVICES check to the top of __efi_queue_work() and return directly, so a caller that finds runtime services disabled returns without touching the shared efi_rts_work. No functional change. This prepares for bounding the wait, where a timeout will clear EFI_RUNTIME_SERVICES while the leaked worker still owns efi_rts_work; a later caller must then bail out before reinitialising it. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-08-20efi/runtime-wrappers: handle queue_work() failure with goto exitBreno Leitao1-3/+5
Convert the queue_work() failure path in __efi_queue_work() to a goto exit instead of falling through to the wait and the WARN_ON_ONCE(status == EFI_ABORTED) below it. A failed queue_work() leaves the status at its initial EFI_ABORTED, so that warning would fire even though no call ran; it is meant for a completed call that returned EFI_ABORTED. No change for the common (successful enqueue) path. This also prepares __efi_queue_work() for the timeout handling added later. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-08-20efi/runtime-wrappers: factor out efi_rts_park_worker()Breno Leitao1-1/+14
x86's efi_crash_gracefully_on_page_fault() ends in an infinite schedule() loop so the kworker that faulted in firmware never runs efi_rts_wq again. A later change needs the same "park this worker forever" primitive on the runtime service timeout path, so factor the loop into a shared efi_rts_park_worker() and call it from the x86 page-fault handler. No functional change. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-08-20irqchip/gic-v5: Defer default SPI and LPI IAFFID programmingLorenzo Pieralisi1-14/+4
SPI and LPI interrupts do not have an architected default value for their IAFFID (interrupt affinity ID) - the property that determines an IRQ affinity. Current code awkwardly tries to set a default IAFFID value corresponding to the logical cpu executing the gicv5_hwirq_init() function at SPI/LPI allocation time. There are two issues with this approach: - gicv5_hwirq_init() is called in preemptible context and current code uses smp_processor_id() to check the logical cpu executing the function. Whilst that's harmless, it can spit a splat on DEBUG_PREEMPT kernels - Setting the default SPI/LPI IAFFID to the one belonging to the cpu executing the IRQ allocation is a completely arbitrary choice It is saner to remove the SPI/LPI IAFFID set-up in the SPI/LPI domain IRQ allocation code and flag SPI/LPI irqchips as IRQCHIP_AFFINITY_PRE_STARTUP so that the SPI/LPI affinity is initialized by IRQ core to a sane value before an IRQ is started up using the respective irq_chip irq_set_affinity() callback. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-7-3743e82c69a4@kernel.org
2026-08-20irqchip/gic-v5: Use logical cpu 0 irs_data for dynamic IST allocationLorenzo Pieralisi1-1/+1
In set-ups with a 2-level IST, L1 table entries are created dynamically when LPIs are allocated. The L1 allocation and mapping, implemented in gicv5_irs_iste_alloc() is carried out in preemtible context and can be carried out on any IRS in the system. Current code indexes the per_cpu_irs_data per cpu array using smp_processor_id() to retrieve the IRS that is local to the core executing gicv5_irs_iste_alloc(). Since that's preemptible context, the core executing that function can change on preemption. Given that every IRS in the system is equivalent to each core, this is not really an issue in that even if the thread is preempted and resumed on a different cpu, the table allocation and mapping to an IRS would work seamlessly regardless. On the other hand, smp_processor_id() spits a legitimate splat on DEBUG_PREEMPT kernels when used in preemtible context and this should be fixed. Given that all IRSes are equivalent from a core perspective in terms of IST initialization, always choose as a policy the IRS local to logical cpu 0, preventing the smp_processor_id() splat. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-6-3743e82c69a4@kernel.org
2026-08-20irqchip/gic-v5: Release IRS iomem region on driver init failureLorenzo Pieralisi1-0/+10
In gicv5_irs_of_init(), an IRS is set-up using of_io_request_and_map() to request its memory region (corresponding to the configuration frame) and map the IRS configuration frame. On gicv5_irs_of_init() failure, the driver unmaps the IRS iomem region but does not release the requested memory region leaving it allocated in the iomem resource tree. Fix it by releasing the iomem region on gicv5_irs_of_init() probe failure. Likewise, on both OF and ACPI driver init failure, IRS iomem regions are requested but never released in gicv5_irs_remove(). Stash a copy of the IRS iomem region in a struct resource in struct gicv5_irs_chip_data and use it to release the requested region in gicv5_irs_remove() if the driver probe fails. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-5-3743e82c69a4@kernel.org
2026-08-20irqchip/gic-v5: Fix gicv5_init_common() error pathsLorenzo Pieralisi1-3/+4
Current code fails to disable interrupts on gicv5_starting_cpu() failure and to set the handle_arch_irq pointer to NULL if gicv5_irs_enable() fails. Update the respective error paths to fix them. Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-4-3743e82c69a4@kernel.org
2026-08-20irqchip/gic-v5: Disable IRSes on probe failuresLorenzo Pieralisi1-0/+9
GICv5 driver probe failures cause IRSes initialized by the kernel to be unmapped and their data structures to be destroyed but the current driver leaves the probed IRSes enabled, whereas they should be disabled. Disable IRSes on driver probe failures so that the IRSes are brought back to their quiescent HW state. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-3-3743e82c69a4@kernel.org
2026-08-20irqchip/gic-v5: Check for NULL LPI domain on domain teardownLorenzo Pieralisi1-0/+3
In gicv5_free_lpi_domain() the LPI domain being freed can be NULL. Check it and return before trying to free it if it is. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-2-3743e82c69a4@kernel.org
2026-08-20irqchip/gic-v5: Check get_logical_index() return value in MADT IAFFID parsingLorenzo Pieralisi1-0/+2
In gic_acpi_parse_iaffid() a given MADT GICC entry might not correspond to a logical cpu recognized by the kernel, resulting in the cpu variable initialization to an error value. Currently, the get_logical_index() return value is not checked for failure, which might result in out-of-bounds memory corruption while trying to index a per_cpu variable array. Add a check to evaluate get_logical_index() return value. Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://sashiko.dev/#/message/20260810104747.E5CE71F000E9%40smtp.kernel.org Link: https://patch.msgid.link/20260812-gicv5-7-2-fixes-v1-1-3743e82c69a4@kernel.org
2026-08-20irqchip/gic-v5: Synchronize CPU interface disableSascha Bischoff1-0/+1
The write disabling the GICv5 CPU interface is only guaranteed to take effect after a context synchronization event. Without one, execution can return from gicv5_cpu_disable_interrupts() while an interrupt is still able to be taken. Add an ISB after the ICC_CR0_EL1 write to ensure interrupts are disabled before the function returns. No corresponding ISB is added when enabling the interface, as interrupt delivery is asynchronous and there is no obvious benefit to waiting for it. Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Link: https://sashiko.dev/#/patchset/20260724104819.1296803-1-sascha.bischoff@arm.com?part=6 Link: https://patch.msgid.link/20260811152630.942023-3-sascha.bischoff@arm.com
2026-08-20irqchip/gic-v5: Clear per-CPU IRS data on teardownSascha Bischoff1-0/+15
IRS affinity setup publishes an IRS pointer and IAFFID state in the per-CPU data before the remaining IRS initialization can fail. The error path then frees the IRS data without clearing that published state, leaving CPUs associated with freed memory. On initialization failure and normal IRS teardown, clear the per-CPU IRS association by removing the stale pointer to irs_data. Also invalidate the per-CPU IAFFID state for any CPUs that were tied to the IRS before it was freed. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Fixes: 35866efa52fe ("irqchip/gic-v5: Add ACPI IRS probing") Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Link: https://sashiko.dev/#/patchset/20260724104819.1296803-1-sascha.bischoff@arm.com?part=2 Link: https://patch.msgid.link/20260811152630.942023-2-sascha.bischoff@arm.com
2026-08-20irqchip/ast2700-intc: Disable all interrupt merge banks on probeMichael Pesa1-1/+1
The INTC0 interrupt-merge (INTM) space has 50 sources at 10 per bank, i.e. INTC0_INTM_NUM / INTM_IRQS_PER_BANK = 5 banks. This is reflected everywhere the banks are indexed: the aspeed_intc0_intm_routes[] table has 5 valid entries, and the mask/unmask/eoi paths compute the bank as (hwirq - INTM_BASE) / INTM_IRQS_PER_BANK, spanning banks 0-4. However, INTC0_INTM_BANK_NUM is hardcoded to 3, so aspeed_intc0_disable_intm() only clears IER for banks 0-2 at probe. Banks 3 and 4 are left in whatever state the firmware configured them , which can leave interrupts enabled before a handler is installed. Derive the bank count from the source count so the probe-time disable covers every bank. Fixes: 07825e41519a ("irqchip/ast2700-intc: Add AST2700-A2 support") Signed-off-by: Michael Pesa <michael.pesa@icloud.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260722050243.298355-1-michael.pesa@icloud.com
2026-08-19clk: microchip: mpfs: fix regmap_update_bits() mask/val orderPedro Kopper1-1/+1
mpfs_cfg_clk_set_rate() passes the mask and value arguments to regmap_update_bits() in the wrong order. The resulting write becomes reg = orig_reg | val, causing bits to not be cleared if the clock divider changes. Pass the arguments in the correct order so the divider field is updated as intended. Fixes: c6f2dddfa7f9 ("clk: microchip: mpfs: use regmap for clocks") Signed-off-by: Pedro Kopper <pedro.kopper@microchip.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Cc: stable@vger.kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2026-08-19clk: visconti: Make sure clk_init_data is fully initializedGeert Uytterhoeven1-1/+1
The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. visconti_clk_register_gate() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: b4cbe606dc3674b2 ("clk: visconti: Add support common clock driver and reset driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2026-08-19clk: ti: Make sure clk_init_data is fully initializedGeert Uytterhoeven3-4/+4
The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. _register_mux() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter is uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: 667f420c09f1417c ("clk: ti: mux: resolve parent clocks by DT index, not by name") Closes: https://lore.kernel.org/CAMuHMdU3yVqoyHC4eNF2NuYo8wy+6ODLoYat4R71X99Mxc_=kw@mail.gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2026-08-20BackMerge tag 'v7.2' into drm-nextDave Airlie912-4910/+12015
Linux 7.2 There was a lot of conflicts this round between fixes and next, and I'd like to get the merge resolutions that we have in drm-tip. Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-08-19Merge tag 'v7.3-p1' of ↵Linus Torvalds102-1918/+1008
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto update from Herbert Xu: "API: - Add af_alg_restrict sysctl and white list - Fix potential suspend/resume races in hwrng Algorithms: - Optimize vli additive operations using compiler builtins in ecc Drivers: - Remove unsafe/deprecated algorithms from qce - Mark qce as BROKEN - Add runtime PM and interconnect bandwidth scaling support to qce - Remove crypto_rng from qcom, sun8i and caam - Fix SG list issues in iaa - Fix SEV init path bugs in ccp" * tag 'v7.3-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (122 commits) crypto: lskcipher - propagate errors from unaligned crypt crypto: keembay - use crypto_memneq() to compare CCM AEAD tags crypto: keembay - use crypto_memneq() to compare GCM AEAD tags crypto: sa2ul - use crypto_memneq() to compare AEAD tag hwrng: drivers - use named initializers for acpi_device_id crypto: qce - fix CCM AAD buffer underallocation crypto: iaa - unmap dst before software fallback on decompress crypto: iaa - use bounce buffer for multi-sg decompress input crypto: iaa - avoid counting fallback decompression bytes crypto: iaa - fall back to software for multi-entry scatterlists hwrng: core - Stop/start hwrng_fillfn() kthread before/after suspend-resume crypto: hisilicon/sec2 - fix CCM algorithm long packet failure crypto: eip93 - use struct_size() and flexible array for ring allocation crypto: krb5 - use kfree_sensitive() for derived key buffers crypto: af_alg - Stop after finding name in allowlist crypto: af_alg - Replace 'bool privileged' with flags crypto: af_alg - Make cbc(paes) privileged-only hwrng: imx-rngc - Disable clock on registration failure crypto: qat - remove dead ADF_HEX code crypto: qce - simplify qce_handle_request ...
2026-08-20rtc: gamecube: check return value of devm_rtc_register_device()Linkai Gong1-3/+1
gamecube_rtc_probe() ignored the return value of devm_rtc_register_device() and always returned success. Propagate the error so probe fails when RTC registration fails. Fixes: 86559400b3ef ("rtc: gamecube: Add a RTC driver for the GameCube, Wii and Wii U") Signed-off-by: Linkai Gong <gonglinkai@kylinos.cn> Link: https://patch.msgid.link/20260731080458.417532-1-gonglinkai@kylinos.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>