summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-04-04net: fec: make FIXED_PHY dependency unconditionalArnd Bergmann1-1/+1
When CONFIG_FIXED_PHY is in a loadable module, the fec driver cannot be built-in any more: x86_64-linux-ld: vmlinux.o: in function `fec_enet_mii_probe': fec_main.c:(.text+0xc4f367): undefined reference to `fixed_phy_unregister' x86_64-linux-ld: vmlinux.o: in function `fec_enet_close': fec_main.c:(.text+0xc59591): undefined reference to `fixed_phy_unregister' x86_64-linux-ld: vmlinux.o: in function `fec_enet_mii_probe.cold': Select the fixed phy support on all targets to make this build correctly, not just on coldfire. Notat that Essentially the stub helpers in include/linux/phy_fixed.h cannot be used correctly because of this build time dependency, and we could just remove them to hit the build failure more often when a driver uses them without the 'select FIXED_PHY'. Fixes: dc86b621e1b4 ("net: fec: register a fixed phy using fixed_phy_register_100fd if needed") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260402141048.2713445-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-04PCI: Update PCIe spec references for AtomicOpsGerd Bayer1-2/+2
Point to the relevant sections in the most recent release 7.0 of the PCIe spec. Text has mostly just moved around without any semantic change. Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260330-fix_pciatops-v7-3-f601818417e8@linux.ibm.com
2026-04-04PCI: Enable AtomicOps only if Root Port supports themGerd Bayer1-21/+20
When inspecting the config space of a Connect-X physical function in an s390 system after it was initialized by the mlx5_core device driver, we found the function to be enabled to request AtomicOps despite the Root Port lacking support for completing them: 00:00.1 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx] Subsystem: Mellanox Technologies Device 0002 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- AtomicOpsCtl: ReqEn+ On s390 and many virtualized guests, the Endpoint is visible but the Root Port is not. In this case, pci_enable_atomic_ops_to_root() previously enabled AtomicOps in the Endpoint even though it can't tell whether the Root Port supports them as a completer. Change pci_enable_atomic_ops_to_root() to fail if there's no Root Port or the Root Port doesn't support AtomicOps. Fixes: 430a23689dea ("PCI: Add pci_enable_atomic_ops_to_root()") Reported-by: Alexander Schmidt <alexs@linux.ibm.com> Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com> [bhelgaas: commit log, check RP first to simplify flow] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260330-fix_pciatops-v7-2-f601818417e8@linux.ibm.com
2026-04-04PCI: Do not enable AtomicOps by RCiEPsGerd Bayer1-3/+2
Since Root Complex Integrated Endpoints (RCiEPs) attach to a bus that has no bridge device describing the Root Port, the capability to complete AtomicOps requests cannot be determined with PCIe methods. Change default of pci_enable_atomic_ops_to_root() to not enable AtomicOps requests on RCiEPs. As far as we know, there are no RCiEPs that need AtomicOps (see Link below). Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260330-fix_pciatops-v7-1-f601818417e8@linux.ibm.com
2026-04-04net: stmmac: qcom-ethqos: set clk_csrRussell King (Oracle)1-0/+6
The clocks for qcom-ethqos return a rate of zero as firmware manages their rate. According to hardware documentation, the clock which is fed to the slave AHB interface can range between 50 to 100MHz for non-RGMII and 30 to 75MHz for boards with a RGMII interfaces. Currently, stmmac uses an undefined divisor value. Instead, use STMMAC_CSR_60_100M which will mean we meet IEEE 802.3 specification since this will generate: 714kHz @ 30MHz 1.19MHz @ 50MHz 1.79MHz @ 75MHz 2.42MHz @ 100MHz This gives MDC rates within the IEEE 802.3 specification, although the 30MHz case is particularly slow. Selecting the next lowest divisor, STMMAC_CSR_35_60M, which is /26 will give: 1.15MHz @ 30MHz 1.92MHz @ 50MHz 2.88MHz @ 75MHz (exceeding 802.3 spec) 3.85MHz @ 100MHz (exceeding 802.3 spec) Unfortunately, this divisor makes the upper bound of both ranges exeed the IEEE 802.3 specification, and thus we can not use it without knowing for certain what the current CSR clock rate actually is. So, STMMAC_CSR_60_100M is the best fit for all boards based on the information provided thus far. Link: https://lore.kernel.org/r/acGhQ0oui+dVRdLY@oss.qualcomm.com Link: https://lore.kernel.org/r/acw1habUsiSqlrky@oss.qualcomm.com Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1w8JKr-0000000EdLC-41Bt@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-04stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in KconfigJulian Braha1-6/+3
There are already 'if STMMAC_ETH' and 'STMMAC_PLATFORM' conditions wrapping these config options, making the 'depends on' statements duplicate dependencies (dead code). I propose leaving the outer 'if STMMAC_PLATFORM...endif' and 'if STMMAC_ETH...endif' conditions, and removing the individual 'depends on' statements. This dead code was found by kconfirm, a static analysis tool for Kconfig. Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20260402145858.240231-1-julianbraha@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-04net: always inline some skb helpersEric Dumazet1-20/+26
Some performance critical helpers from include/linux/skbuff.h are not inlined by clang. Use __always_inline hint for: - __skb_fill_netmem_desc() - __skb_fill_page_desc() - skb_fill_netmem_desc() - skb_fill_page_desc() - __skb_pull() - pskb_may_pull_reason() - pskb_may_pull() - pskb_pull() - pskb_trim() - skb_orphan() - skb_postpull_rcsum() - skb_header_pointer() - skb_clear_delivery_time() - skb_tstamp_cond() - skb_warn_if_lro() This increases performance and saves ~1200 bytes of text. $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 4/24 grow/shrink: 66/12 up/down: 4104/-5306 (-1202) Function old new delta ip_multipath_l3_keys - 303 +303 tcp_sendmsg_locked 4560 4848 +288 xfrm_input 6240 6455 +215 esp_output_head 1516 1711 +195 skb_try_coalesce 696 866 +170 bpf_prog_test_run_skb 1951 2091 +140 tls_strp_read_copy 528 667 +139 gue_udp_recv 738 871 +133 __ip6_append_data 4159 4279 +120 __bond_xmit_hash 1019 1122 +103 ip6_multipath_l3_keys 394 495 +101 bpf_lwt_seg6_action 1096 1197 +101 input_action_end_dx2 344 442 +98 vxlan_remcsum 487 581 +94 udpv6_queue_rcv_skb 393 480 +87 udp_queue_rcv_skb 385 471 +86 gue_remcsum 453 539 +86 udp_lib_checksum_complete 84 168 +84 vxlan_xmit 2777 2857 +80 nf_reset_ct 456 532 +76 igmp_rcv 1902 1978 +76 mpls_forward 1097 1169 +72 tcp_add_backlog 1226 1292 +66 nfulnl_log_packet 3091 3156 +65 tcp_rcv_established 1966 2026 +60 __strp_recv 1547 1603 +56 eth_type_trans 357 411 +54 bond_flow_ip 392 444 +52 __icmp_send 1584 1630 +46 ip_defrag 1636 1681 +45 tpacket_rcv 2793 2837 +44 refcount_add 132 176 +44 nf_ct_frag6_gather 1959 2003 +44 napi_skb_free_stolen_head 199 240 +41 __pskb_trim - 41 +41 napi_reuse_skb 319 358 +39 icmpv6_rcv 1877 1916 +39 br_handle_frame_finish 1672 1711 +39 ip_rcv_core 841 879 +38 ip_check_defrag 377 415 +38 br_stp_rcv 909 947 +38 qdisc_pkt_len_segs_init 366 399 +33 mld_query_work 2945 2975 +30 bpf_sk_assign_tcp_reqsk 607 637 +30 udp_gro_receive 1657 1686 +29 ip6_rcv_core 1170 1193 +23 ah_input 1176 1197 +21 tun_get_user 5174 5194 +20 llc_rcv 815 834 +19 __pfx_udp_lib_checksum_complete 16 32 +16 __pfx_refcount_add 48 64 +16 __pfx_nf_reset_ct 96 112 +16 __pfx_ip_multipath_l3_keys - 16 +16 __pfx___pskb_trim - 16 +16 packet_sendmsg 5771 5781 +10 esp_output_tail 1460 1470 +10 alloc_skb_with_frags 433 443 +10 xsk_generic_xmit 3477 3486 +9 mptcp_sendmsg_frag 2250 2259 +9 __ip_append_data 4166 4175 +9 __ip6_tnl_rcv 1159 1168 +9 skb_zerocopy 1215 1220 +5 gre_parse_header 1358 1362 +4 __iptunnel_pull_header 405 407 +2 skb_vlan_untag 692 693 +1 psp_dev_rcv 701 702 +1 netkit_xmit 1263 1264 +1 gre_rcv 2776 2777 +1 gre_gso_segment 1521 1522 +1 bpf_skb_net_hdr_pop 535 536 +1 udp6_ufo_fragment 888 884 -4 br_multicast_rcv 9154 9148 -6 snap_rcv 312 305 -7 skb_copy_ubufs 1841 1834 -7 __pfx_skb_tstamp_cond 16 - -16 __pfx_skb_clear_delivery_time 16 - -16 __pfx_pskb_trim 16 - -16 __pfx_pskb_pull 16 - -16 ipv6_gso_segment 1400 1383 -17 ipv6_frag_rcv 2511 2492 -19 erspan_xmit 1221 1190 -31 __pfx_skb_warn_if_lro 32 - -32 __pfx___skb_fill_page_desc 32 - -32 skb_tstamp_cond 42 - -42 pskb_trim 46 - -46 __pfx_skb_postpull_rcsum 48 - -48 tcp_gso_segment 1524 1475 -49 skb_clear_delivery_time 54 - -54 __pfx_skb_fill_page_desc 64 - -64 __pfx_skb_header_pointer 80 - -80 pskb_pull 91 - -91 skb_warn_if_lro 110 - -110 tcp_v6_rcv 3288 3170 -118 __pfx___skb_pull 128 - -128 __pfx_skb_orphan 144 - -144 __pfx_pskb_may_pull 160 - -160 tcp_v4_rcv 3334 3153 -181 __skb_fill_page_desc 231 - -231 udp_rcv 1809 1553 -256 skb_postpull_rcsum 318 - -318 skb_header_pointer 367 - -367 fib_multipath_hash 3399 3018 -381 skb_orphan 513 - -513 skb_fill_page_desc 534 - -534 __skb_pull 568 - -568 pskb_may_pull 604 - -604 Total: Before=29652698, After=29651496, chg -0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260402152654.1720627-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-04net: sched: act_csum: validate nested VLAN headersRuide Cao1-1/+5
tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path. Fixes: 2ecba2d1e45b ("net: sched: act_csum: Fix csum calc for tagged packets") Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Co-developed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Yuan Tan <yuantan098@gmail.com> Suggested-by: Xin Liu <bird@lzu.edu.cn> Tested-by: Ren Wei <enjou1224z@gmail.com> Signed-off-by: Ruide Cao <caoruide123@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/22df2fcb49f410203eafa5d97963dd36089f4ecf.1774892775.git.caoruide123@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-04rust: macros: simplify `format!` argumentsMiguel Ojeda1-7/+2
Clippy in Rust 1.88.0 (only) reported [1] up to the previous commit: warning: variables can be used directly in the `format!` string --> rust/macros/module.rs:112:23 | 112 | let content = format!("{param}:{content}", param = param, content = content); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]` help: change this to | 112 - let content = format!("{param}:{content}", param = param, content = content); 112 + let content = format!("{param}:{content}"); The reason it only triggers in that version is that the lint was moved from `pedantic` to `style` in Rust 1.88.0 and then back to `pedantic` in Rust 1.89.0 [2][3]. In this case, the suggestion is fair and a pure simplification, thus just apply it. In addition, do the same for another place in the file that Clippy does not report because it is multi-line. Link: https://lore.kernel.org/rust-for-linux/CANiq72=drAtf3y_DZ-2o4jb6Az9J3Yj4QYwWnbRui4sm4AJD3Q@mail.gmail.com/ [1] Link: https://github.com/rust-lang/rust-clippy/pull/15287 [2] Link: https://github.com/rust-lang/rust-clippy/issues/15151 [3] Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Sami Tolvanen <samitolvanen@google.com> Link: https://patch.msgid.link/20260331205849.498295-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-03selinux: fix overlayfs mmap() and mprotect() access checksPaul Moore2-64/+189
The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the "user" file) and the mounter's credentials are sufficient to access the lower level file (the "backing" file). Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems. This patch makes use of the newly created security_mmap_backing_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls. Cc: stable@vger.kernel.org Acked-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-04-03lsm: add backing_file LSM hooksPaul Moore16-17/+206
Stacked filesystems such as overlayfs do not currently provide the necessary mechanisms for LSMs to properly enforce access controls on the mmap() and mprotect() operations. In order to resolve this gap, a LSM security blob is being added to the backing_file struct and the following new LSM hooks are being created: security_backing_file_alloc() security_backing_file_free() security_mmap_backing_file() The first two hooks are to manage the lifecycle of the LSM security blob in the backing_file struct, while the third provides a new mmap() access control point for the underlying backing file. It is also expected that LSMs will likely want to update their security_file_mprotect() callback to address issues with their mprotect() controls, but that does not require a change to the security_file_mprotect() LSM hook. There are a three other small changes to support these new LSM hooks: * Pass the user file associated with a backing file down to alloc_empty_backing_file() so it can be included in the security_backing_file_alloc() hook. * Add getter and setter functions for the backing_file struct LSM blob as the backing_file struct remains private to fs/file_table.c. * Constify the file struct field in the LSM common_audit_data struct to better support LSMs that need to pass a const file struct pointer into the common LSM audit code. Thanks to Arnd Bergmann for identifying the missing EXPORT_SYMBOL_GPL() and supplying a fixup. Cc: stable@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-unionfs@vger.kernel.org Cc: linux-erofs@lists.ozlabs.org Reviewed-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-04-03fs: prepare for adding LSM blob to backing_fileAmir Goldstein1-2/+20
In preparation to adding LSM blob to backing_file struct, factor out helpers init_backing_file() and backing_file_free(). Cc: stable@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-unionfs@vger.kernel.org Cc: linux-erofs@lists.ozlabs.org Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Serge Hallyn <serge@hallyn.com> [PM: use the term "LSM blob", fix comment style to match file] Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-04-03drm/amdgpu: dump job ibs in the devcoredumpPierre-Eric Pelloux-Prayer1-1/+92
Now that we have a worker thread, we can try to access the IBs of the job. The process is: * get the VM from the PASID * get the BO from its VA and the VM * map the BO for CPU access * copy everything, then add it to the dump Each step can fail so we have to be cautious. These operations can be slow so when amdgpu_devcoredump_format is called only to determine the size of the buffer we skip all of them and assume they will succeed. --- v3: use kvfree --- Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu: store ib info for devcoredumpPierre-Eric Pelloux-Prayer2-1/+20
Store the basic state of IBs so we can read it back in the amdgpu_devcoredump_format function. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03Merge branch 'for-7.1/cxl-region-refactor' into cxl-for-nextDave Jiang7-285/+302
Refactor CXL core/region code to make region code more manageable by splitting out DAX and PMEM code from RAM handling code. cxl/core: use cleanup.h for devm_cxl_add_dax_region cxl/core/region: move dax region device logic into region_dax.c cxl/core/region: move pmem region driver logic into region_pmem.c
2026-04-03Merge branch 'for-7.1/dax-hmem' into cxl-for-nextDave Jiang16-35/+462
The series addresses conflicts between HMEM and CXL when handling Soft Reserved memory ranges. CXL will try best effort in claiming the Soft Reserved memory region that are CXL regions. If fails, it will punt back to HMEM. tools/testing/cxl: Test dax_hmem takeover of CXL regions tools/testing/cxl: Simulate auto-assembly failure dax/hmem: Parent dax_hmem devices dax/hmem: Fix singleton confusion between dax_hmem_work and hmem devices dax/hmem: Reduce visibility of dax_cxl coordination symbols cxl/region: Constify cxl_region_resource_contains() cxl/region: Limit visibility of cxl_region_contains_resource() dax/cxl: Fix HMEM dependencies cxl/region: Fix use-after-free from auto assembly failure dax/hmem, cxl: Defer and resolve Soft Reserved ownership cxl/region: Add helper to check Soft Reserved containment by CXL regions dax: Track all dax_region allocations under a global resource tree dax/cxl, hmem: Initialize hmem early and defer dax_cxl binding dax/hmem: Gate Soft Reserved deferral on DEV_DAX_CXL dax/hmem: Request cxl_acpi and cxl_pci before walking Soft Reserved ranges dax/hmem: Factor HMEM registration into __hmem_register_device() dax/bus: Use dax_region_put() in alloc_dax_region() error path
2026-04-03Merge branch 'for-7.1/cxl-type2-support' into cxl-for-nextDave Jiang12-300/+394
Prep patches for CXL type2 accelerator basic support cxl/region: Factor out interleave granularity setup cxl/region: Factor out interleave ways setup cxl: Make region type based on endpoint type cxl/pci: Remove redundant cxl_pci_find_port() call cxl: Move pci generic code from cxl_pci to core/cxl_pci cxl: export internal structs for external Type2 drivers cxl: support Type2 when initializing cxl_dev_state
2026-04-03Merge branch 'for-7.1/cxl-consolidate-endpoint' into cxl-for-nextDave Jiang5-6/+13
Add code to ensure the endpoint has completed initialization before usage. cxl/pci: Check memdev driver binding status in cxl_reset_done() cxl/pci: Hold memdev lock in cxl_event_trace_record()
2026-04-03Merge tag 'sched_ext-for-7.0-rc6-fixes-2' of ↵Linus Torvalds2-26/+54
git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fixes from Tejun Heo: "These are late but both fix subtle yet critical problems and the blast radius is limited strictly to sched_ext. - Fix stale direct dispatch state in ddsp_dsq_id which can cause spurious warnings in mark_direct_dispatch() on task wakeup - Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU configs which can lead to incorrectly dispatching migration- disabled tasks to remote CPUs" * tag 'sched_ext-for-7.0-rc6-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Fix stale direct dispatch state in ddsp_dsq_id sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU
2026-04-03Merge tag 'io_uring-7.0-20260403' of ↵Linus Torvalds7-29/+87
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull io_uring fixes from Jens Axboe: - A previous fix in this release covered the case of the rings being RCU protected during resize, but it missed a few spots. This covers the rest - Fix the cBPF filters when COW'ed, introduced in this merge window - Fix for an attempt to import a zero sized buffer - Fix for a missing clamp in importing bundle buffers * tag 'io_uring-7.0-20260403' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: io_uring/bpf_filters: retain COW'ed settings on parse failures io_uring: protect remaining lockless ctx->rings accesses with RCU io_uring/rsrc: reject zero-length fixed buffer import io_uring/net: fix slab-out-of-bounds read in io_bundle_nbufs()
2026-04-03drm/amdgpu: extract amdgpu_vm_lock_by_pasid from amdgpu_vm_handle_faultPierre-Eric Pelloux-Prayer2-29/+54
This is tricky to implement right and we're going to need it from the devcoredump. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03tools/testing/cxl: Enable replay of user regions as auto regionsAlison Schofield1-10/+373
The cxl_test module currently hard-codes auto regions in the mock topology, limiting coverage of the driver's region auto-assembly logic. Teach cxl_test to replay previously committed decoder programming across a cxl_acpi unbind/bind cycle. Decoder programming is recorded in a registry keyed by a stable port identity and decoder id. The registry is updated on decoder commit and reset events and consulted during enumeration to restore previously enabled decoders. This allows regions created through the user interface to be replayed during enumeration and treated as auto-discovered regions, enabling testing of region auto-assembly using configurations created in the cxl_test topology. Example workflow: # cxl create-region ... # echo 1 > /sys/bus/platform/devices/cxl_acpi.0/decoder_reset_preserve_registry # echo cxl_acpi.0 > /sys/bus/platform/drivers/cxl_acpi/unbind # echo cxl_acpi.0 > /sys/bus/platform/drivers/cxl_acpi/bind # echo 0 > /sys/bus/platform/devices/cxl_acpi.0/decoder_reset_preserve_registry The NDCTL CXL unit test, cxl-region-replay.sh, demonstrates the usage. Co-developed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Co-developed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260314061952.2221030-1-alison.schofield@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-04-03PM / devfreq: tegra30-devfreq: add support for Tegra114Svyatoslav Ryhel1-5/+12
Lets add Tegra114 support to activity monitor device as a preparation to upcoming EMC controller support. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Acked-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: MyungJoo Ham <myungjoo.ham@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/lkml/20260126185423.77786-1-clamor95@gmail.com/
2026-04-03PM / devfreq: use _visible attribute to replace create/remove_sysfs_files()Pengjie Zhang1-43/+60
Previously, non-generic attributes (polling_interval, timer) used separate create/delete logic, leading to race conditions during concurrent access in creation/deletion. Multi-threaded operations also caused inconsistencies between governor capabilities and attribute states. 1.Use is_visible + sysfs_update_group() to unify management of these attributes, eliminating creation/deletion races. 2.Add locks and validation to these attributes, ensuring consistency between current governor capabilities and attribute operations in multi-threaded environments. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://www.spinics.net/lists/kernel/msg5967745.html
2026-04-03PM / devfreq: Remove unneeded casting for HZ_PER_KHZAndy Shevchenko1-3/+2
HZ_PER_KHZ is defined as UL (unsigned long), no need to repeat that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/lkml/20260114093115.276818-1-andriy.shevchenko@linux.intel.com/
2026-04-03hwmon: (sparx5) Make it selectable for ARCH_LAN969XRobert Marko1-1/+1
LAN969x uses the same sensor and driver, so make it selectable for ARCH_LAN969X. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Link: https://lore.kernel.org/r/20260402123436.47856-1-robert.marko@sartura.hr Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-03hwmon: (tmp102) add support for update intervalFlaviu Nistor2-24/+123
Since the sensor supports different sampling intervals via bits CR0 and CR1 from the CONFIG register, add support in order for the conversion rate to be changed from user space. Default is 4 conv/sec. Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com> Link: https://lore.kernel.org/r/20260403140654.10368-1-flaviu.nistor@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-03hwmon: (yogafan) fix markup warningRandy Dunlap1-0/+1
Add a blank line between the License and heading lines to prevent a documentation build warning: Documentation/hwmon/yogafan.rst:2: WARNING: Explicit markup ends without a blank line; unexpected unindent. [docutils] Fixes: c67c248ca406 ("hwmon: (yogafan) Add support for Lenovo Yoga/Legion fan monitoring") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20260330214624.3781789-1-rdunlap@infradead.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-03hwmon: (yogafan) Add support for Lenovo Yoga/Legion fan monitoringSergio Melas6-0/+427
This driver provides fan speed monitoring for Lenovo Yoga, Legion, and IdeaPad laptops by interfacing with the Embedded Controller (EC) via ACPI. To address low-resolution sampling in Lenovo EC firmware, a Rate-Limited Lag (RLLag) filter is implemented. The filter ensures a consistent physical curve regardless of userspace polling frequency. Hardware identification is performed via DMI-based quirk tables, which map specific ACPI object paths and register widths (8-bit vs 16-bit) deterministically. Signed-off-by: Sergio Melas <sergiomelas@gmail.com> Link: https://lore.kernel.org/r/20260327221602.18832-1-sergiomelas@gmail.com [groeck: Dropped double empty line in Kconfig] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-03drm/amdgpu: Use amdgpu by default for CIK APUs tooTimur Kristóf2-7/+3
CIK APUs are: Kaveri, Kabini and Mullins from 2013~2015, which all have a second generation GCN based integrated GPU. The amdgpu driver has been working well on CIK APUs for years. Features which were previously missing have been added recently, specifically DC support for analog connectors and DP bridge encoders. Now amdgpu is at feature parity with the old radeon driver on CIK APUs. Enabling the amdgpu driver by default for CIK APUs has the following benefits: - More stable OpenGL support through RadeonSI - Vulkan support through RADV - Improved performance - Better display features through DC Users who want to keep using the old driver can do so using: amdgpu.cik_support=0 radeon.cik_support=1 Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amd/display: Remove unused NUM_ELEMENTS macrosLinus Probert4-12/+0
Removes unused NUM_ELEMENTS macros. Discovered while removing cases where ARRAY_SIZE from the header <linus/array_size.h> can be used. This also aligns with the array_size.cocci coccinelle check. Suggested-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Linus Probert <linus.probert@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amd/display: Replace inline NUM_ELEMENTS macro with ARRAY_SIZELinus Probert2-5/+6
Replaces the use of local NUM_ELEMENTS macro with the ARRAY_SIZE macro defined in <linux/array_size.h>. This aligns with existing coccinelle script array_size.cocci which has been applied to other sources in order to remove inline sizeof(a)/sizeof(a[0]) patterns from other source files. Suggested-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Linus Probert <linus.probert@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu: save ring content before resetting the devicePierre-Eric Pelloux-Prayer2-18/+80
Otherwise the content might not be relevant. When a coredump is generated the rings with outstanding fences are saved and then printed to the final devcoredump from the worker thread. Since this requires memory allocation, the ring capture might be missing from the generated devcoredump. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu: make userq fence_drv drop explicit in queue destroyPrike Liang3-7/+12
amdgpu_userq_fence_driver_free() is now responsible only for releasing per-queue ancillary state (last_fence, fence_drv_xa) and no longer touches the ownership reference, making each function's contract clear. v2: Get the userq fence driver from amdgpu_userq_fence_driver_alloc() directly and dropping the userq fence driver reference after removing userq_doorbell_xa entry.(Christian) Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu: rework userq fence driver alloc/destroyPrike Liang8-52/+28
The correct fix is to tie the global xa entry lifetime to the queue lifetime: insert in amdgpu_userq_create() and erase in amdgpu_userq_cleanup(), both at the well-defined doorbell_index key, making the operation O(1) and resolve the fence driver UAF problem by binding the userq driver fence to per queue. v2: clean up the local variables initialization. (Christian) Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu/userq: use dma_fence_wait_timeout without test for signalledSunil Khatri1-13/+4
In function amdgpu_userq_wait_for_last_fence use dma_fence_wait to wait infinitely. Also there is no need to print error as we wont be timing out anymore. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu/userq: call dma_resv_wait_timeout without test for signalledSunil Khatri3-23/+11
In function amdgpu_userq_gem_va_unmap_validate call dma_resv_wait_timeout directly. Also since we are waiting forever we should not be having any return value and hence no handling needed. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu/userq: add the return code too in error conditionSunil Khatri1-5/+4
In function amdgpu_userq_restore a. amdgpu_userq_vm_validate: add return code in error condition b. amdgpu_userq_restore_all: It already prints the error log, just update the erorr log in the function and remove it from caller. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu/userq: fence wait for max time in amdgpu_userq_wait_for_signalSunil Khatri1-12/+3
wait for infinite time for fences in function amdgpu_userq_wait_for_signal and for that use dma_fence_wait(f, false); Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amd/display: Change dither policy for 10 bpc output back to ditheringMario Kleiner1-1/+1
Commit d5df648ec830 ("drm/amd/display: Change dither policy for 10bpc to round") degraded display of 12 bpc color precision output to 10 bpc sinks by switching 10 bpc output from dithering to "truncate to 10 bpc". I don't find the argumentation in that commit convincing, but the consequences highly unfortunate, especially for applications that require effective > 10 bpc precision output of > 10 bpc framebuffers. The argument wasn't something strong like "there are hardware design defects or limitations which require us to work around broken dithering to 10 bpc", or "there are some special use cases which do require truncation to 10 bpc", but essentially "at some point in the past we used truncation in Polaris/Vega times and it looks like it got inadvertently changed for Navi, so let's do that again". I couldn't find evidence for that in the git commit logs for this. The commit message also acknowledges that using dithering "...makes some sense for FP16... ...but not for ARGB2101010 surfaces..." The problem with this is that it makes fp16 surfaces, and especially rgba16 fixed point surfaces, less useful. These are now well supported by Mesa 25.3 and later via OpenGL + EGL, Vulkan/WSI, and by OSS AMDVLK Vulkan/WSI/display, and also by GNOME 50 mutter under Wayland, and they used to provide more than 10 bpc effective precision at the output. Even for 8 or 10 bpc surfaces, the color pipeline behind the framebuffer, e.g., gamma tables, CTM, can be used for color correction and will benefit from an effective > 10 bpc output precision via dithering, retaining some precision that would get lost on the way through the pipeline, e.g., due to non-linear gamma functions. Scientific apps rely on this for > 10 bpc display precision. Truncating to 10 bpc, instead of dithering the pipeline internal 12 bpc precision down to 10 bpc, causes a serious loss of precision. This also creates the undesirable and slightly absurd situation that using a cheap monitor with only 8 bpc input and display panel will yield roughly 12 bpc precision via dithering from 12 -> 8 bpc, whereas investment into a more expensive monitor with 10 bpc input and native 10 bpc display will only yield 10 bpc, even if a fp16 or rgb16 framebuffer and/or a properly set up color pipeline (gamma tables, CTM's etc. with more than 10 bpc out precision) would allow effective 12 bpc precision output. Therefore this patch proposes reverting that commit and going back to dithering down to 10 bpc, consistent with the behaviour for 6 bpc or 8 bpc output. Successfully tested on AMD Polaris DCE 11.2 and Raven Ridge DCN 1.0 with a native 10 bpc capable monitor, outputting a RGBA16 unorm framebuffer and measuring resulting color precision with a photometer. No apparent visual artifacts or problems were observed, and effective precision was measured to be 12 bpc again, as expected. Fixes: d5df648ec830 ("drm/amd/display: Change dither policy for 10bpc to round") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org Cc: Aric Cyr <aric.cyr@amd.com> Cc: Anthony Koo <anthony.koo@amd.com> Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Cc: Krunoslav Kovac <krunoslav.kovac@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reported-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu: replace PASID IDR with XArrayMikhail Gavrilov1-20/+19
Replace the PASID IDR + spinlock with XArray as noted in the TODO left by commit ea56aa262570 ("drm/amdgpu: fix the idr allocation flags"). The IDR conversion still has an IRQ safety issue: amdgpu_pasid_free() can be called from hardirq context via the fence signal path, but amdgpu_pasid_idr_lock is taken with plain spin_lock() in process context, creating a potential deadlock: CPU0 ---- spin_lock(&amdgpu_pasid_idr_lock) // process context, IRQs on <Interrupt> spin_lock(&amdgpu_pasid_idr_lock) // deadlock The hardirq call chain is: sdma_v6_0_process_trap_irq -> amdgpu_fence_process -> dma_fence_signal -> drm_sched_job_done -> dma_fence_signal -> amdgpu_pasid_free_cb -> amdgpu_pasid_free Use XArray with XA_FLAGS_LOCK_IRQ (all xa operations use IRQ-safe locking internally) and XA_FLAGS_ALLOC1 (zero is not a valid PASID). Both xa_alloc_cyclic() and xa_erase() then handle locking consistently, fixing the IRQ safety issue and removing the need for an explicit spinlock. v8: squash in irq safe fix Reviewed-by: Christian König <christian.koenig@amd.com> Suggested-by: Lijo Lazar <lijo.lazar@amd.com> Fixes: ea56aa262570 ("drm/amdgpu: fix the idr allocation flags") Fixes: 8f1de51f49be ("drm/amdgpu: prevent immediate PASID reuse case") Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu/userq: dont need check for return values in amdgpu_userq_evictSunil Khatri1-12/+4
Function of amdgpu_userq_evict function do not need to check for return values as we dont use them and no need to log errors as we are already logging in called functions. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amd/pm: fix memleak issue in smu_v15_0_8_get_gpu_metrics()Yang Wang1-2/+0
remove unsued code to avoid memleak issue. (NOTE: This bug occurs during internal branch switching) Fixes: 0a66ca3b351f ("drm/amd/pm: add get_gpu_metrics support for 15.0.8") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amd/pm: optimize logic and remove unnecessary checks in smu v15.0.8Yang Wang1-29/+23
the following two sets of logic are clearly mutually exclusive in smu_v15_0_8_set_soft_freq_limited_range. remove unnecessary code logic to keep the code logic clear. e.g: if (smu_dpm->dpm_level != AMD_DPM_FORCED_LEVEL_MANUAL) return -EINVAL; if (smu_dpm->dpm_level == AMD_DPM_FORCED_LEVEL_MANUAL) { ... } Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amd/pm: fix null pointer dereference issue in smu_v15_0_8_get_power_limit()Yang Wang1-1/+1
Fix null pointer issues caused by coding errors Fixes: e20e47bcb3f1 ("drm/amd/pm: add set{get}_power_limit support for smu 15.0.8") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amd/pm: correct mem_busy_percent display due to calculation errorsYang Wang4-15/+32
PMFW may return invalid values due to internal calculation errors. so, the kmd driver must validate and sanitize the returned values to prevent issues caused by firmware calculation errors. For example, values 0xfffe (-2) and 0xffff (-1) are treated as invalid and clamped to 0. this applies to devices with CAB (Cache As Buffer) functionality. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/4905 Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/radeon: add WQ_PERCPU to alloc_workqueue usersMarco Crivellari1-1/+2
This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The refactoring is going to alter the default behavior of alloc_workqueue() to be unbound by default. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. For more details see the Link tag below. In order to keep alloc_workqueue() behavior identical, explicitly request WQ_PERCPU. Suggested-by: Tejun Heo <tj@kernel.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03amd/amdkfd: add WQ_UNBOUND to alloc_workqueue usersMarco Crivellari1-1/+2
This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The refactoring is going to alter the default behavior of alloc_workqueue() to be unbound by default. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. For more details see the Link tag below. This specific workload has no benefit being per-cpu, so its behavior has been changed using explicitly WQ_UNBOUND. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu: replace use of system_wq with system_dfl_wqMarco Crivellari1-2/+2
This patch continues the effort to refactor workqueue APIs, which has begun with the changes introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The point of the refactoring is to eventually alter the default behavior of workqueues to become unbound by default so that their workload placement is optimized by the scheduler. Before that to happen after a careful review and conversion of each individual case, workqueue users must be converted to the better named new workqueues with no intended behaviour changes: system_wq -> system_percpu_wq system_unbound_wq -> system_dfl_wq This way the old obsolete workqueues (system_wq, system_unbound_wq) can be removed in the future. Suggested-by: Tejun Heo <tj@kernel.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-04-03drm/amdgpu: replace use of system_unbound_wq with system_dfl_wqMarco Crivellari3-3/+3
This patch continues the effort to refactor workqueue APIs, which has begun with the changes introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The point of the refactoring is to eventually alter the default behavior of workqueues to become unbound by default so that their workload placement is optimized by the scheduler. Before that to happen after a careful review and conversion of each individual case, workqueue users must be converted to the better named new workqueues with no intended behaviour changes: system_wq -> system_percpu_wq system_unbound_wq -> system_dfl_wq This way the old obsolete workqueues (system_wq, system_unbound_wq) can be removed in the future. Suggested-by: Tejun Heo <tj@kernel.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-09 05:06:39 +0300