HID: hid-oxp: fix and extend X2-family controller support by Grippy98 · Pull Request #13 · OpenGamingCollective/linux-unstable

Grippy98 · 2026-08-30T18:40:06Z

This four-patch series fixes button mapping and extends RGB support for
ONEXPLAYER X2-family controllers, including the ONEXPLAYER 3 and X2 Mini Pro.

Correct the default M1/M2 mappings to F15/F16.
Support the three-page button-mapping format used by these controllers.
Add joystick-ring RGB control for zones 0x01, 0x02, and 0x07.
Add independent RGB devices for the Guide button and rear logo using
zones 0x05 and 0x06.
Restore controller and RGB state after suspend/resume.
Restrict configuration ownership to USB interface 2 so additional FE00
interfaces cannot overwrite the active driver state.
Improve transaction serialization, acknowledgement validation, retry
handling, and teardown safety.

Testing

Tested on an ONEXPLAYER 3 running Bazzite 44 with kernel
7.2.0-ogc6.1.fc44.x86_64.

Verified:

Front controls and both rear paddles.
Correct Steam and Quick Access menu behavior.
Independent solid, breathing, brightness, and off control for the Guide
button and rear logo.
Joystick-ring RGB control.
Simultaneous independent RGB states.
RGB restoration after suspend/resume.
Module build with W=1.
git diff --check and checkpatch.pl.

The X2 Mini Pro uses the same controller protocol and interface layout, but
this series has not yet been tested on physical X2 Mini Pro hardware.

AI assistance disclosure

An LLM assisted with protocol analysis, implementation, documentation, code
review, and test orchestration. I reviewed and signed off on the resulting
changes and performed the physical ONEXPLAYER 3 testing described above.

…unavailable test_no_kmem_bypass() needs to read /sys/kernel/debug/zswap/stored_pages via get_zswap_stored_pages() to verify that compressed pages are charged to the memcg. When running in an environment where debugfs is not mounted or CONFIG_DEBUG_FS is disabled, get_zswap_stored_pages() fails, causing the loop to terminate early and report a false negative (KSFT_FAIL). Selftests should not fail if debugfs is unavailable, and it should print a message when it is skipped. While I'm here, also add a warning message if the test is being skipped due to totalram size and make the check for totalram more readable. Link: https://lore.kernel.org/20260812050848.848882-1-wfelipe@google.com Link: https://lore.kernel.org/20260811051434.3805648-1-wfelipe@google.com Signed-off-by: Wilson Felipe Pereira <wfelipe@google.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Reviewed-by: SJ Park <sj@kernel.org> Cc: Chengming Zhou <chengming.zhou@linux.dev> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Koutný <mkoutny@suse.com> Cc: Nhat Pham <nphamcs@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

…available-fix clarify debugfs-unavailable error message Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Chengming Zhou <chengming.zhou@linux.dev> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Koutný <mkoutny@suse.com> Cc: Nhat Pham <nphamcs@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Wilson Felipe Pereira <wfelipe@google.com> Cc: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

lru_gen_look_around() feeds its local 'young' counter into suitable_to_scan(), which decides whether the current PMD is added to the bloom filter and checked again on the next aging round. The folio triggering the look-around is processed at function entry: test_and_clear_young_ptes_notify() clears the accessed bits of the nr PTEs it maps, and the function bails out if none of them is young. The loop that follows therefore never recounts this folio, since its accessed bits are already cleared. Every other young folio the loop finds is accounted as a batch (young += nr), where nr is the number of consecutive PTEs it maps. The triggering folio, however, still contributes a fixed young = 1 regardless of its size -- a leftover from before PTE batching. A large triggering folio is thus accounted inconsistently with the rest of the window. Initialize young to nr so the triggering folio is accounted the same way as any other young folio batch in the loop. Note this is a deliberate overestimate, not a measured value. The test-and-clear helper only reports whether any of the nr PTEs is young, not how many were accessed, so the true number of accessed PTEs in a large folio is unknown and can be smaller than nr. Counting the full batch is intentional: the mm core tracks accessed/dirty state per folio, not per page, so a per-page count is neither obtainable nor meaningful. The only consumer is suitable_to_scan(), and the bloom filter it feeds tolerates error. Overestimating is also the safe direction: at worst a PMD that saw little access is rescanned, whereas underestimating could skip rescanning a PMD whose folios are still hot and reclaim them incorrectly. (nr here is the PTE batch size, not necessarily folio_nr_pages().) Link: https://lore.kernel.org/20260813061019.49806-1-hui.zhu@linux.dev Link: https://lore.kernel.org/20260812065933.103627-1-hui.zhu@linux.dev Fixes: 56e5b60 ("mm: support batched checking of the young flag for MGLRU") Signed-off-by: Hui Zhu <zhuhui@kylinos.cn> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Reviewed-by: Barry Song <baohua@kernel.org> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: David Hildenbrand <david@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kairui Song <kasong@tencent.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Wei Xu <weixugc@google.com> Cc: Yuanchu Xie <yuanchu@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

This file is a 'special' driver that implements /dev/zero and /dev/mem among other things. As such it makes sense for mm to be cc'd on mails and to have some say in how things are changed there, so add it to the mm misc section. Uniquely, it provides the 'old way' of obtaining an anonymous mapping - MAP_PRIVATE of /dev/zero - so is directly tied to memory mapping, therefore also add it to the memory mapping section. scripts/get_maintainer.pl copes perfectly fine with files in multiple sections so everything should work correctly. Link: https://lore.kernel.org/20260812-add-drivers-mem-to-mm-maintainers-v1-1-6218b861f4c8@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: SJ Park <sj@kernel.org> Reviewed-by: Anshuman Khandual<anshuman.khandual@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jann Horn <jannh@google.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

…_init_scan() Patch series "mm/khugepaged: several cleanups", v4. The following changes stem from a number of reviews during my khugepaged mTHP support series [1]. Some of these are minor code cleanups, issues or reviews that we decided to deferred to a followup series, or in the case of the more major patch of the series, changes [2] Lance Yang attempted while my series was in-flight and we decided to wait till later to try. The first 3 patches introduce helper functions to increase code reuse and readability. This includes a per-scan state clearing function, extracting the young page check into a helper, and a count_collapse_event() function to reduce a repetative pattern used across mTHP collapse. The 4th patch was the byproduct of me throwing Claude at all the comments in khugepaged verifying and looking for any outdated info. The 5th patch is based on Lance Yang's commit series [2] trying to extract the PTE state checking into a helper function. This required a bit of rewriting due to differences after mTHP collapse was introduced. I also took into account the changes requested during his patches review cycle. The remaining 2 patches were review points during my mTHP series that we agreed can be deferred to a later series. Thank you to those whos reviews and work I leveraged to achieve these cleanups. This patch (of 6): Extract the repeated clearing of node_load, alloc_nmask, and mthp_present_ptes into a helper to reduce duplication in collapse_scan_pmd() and collapse_scan_file(). Althought file scans do not current use the bitmap, they will in the future, and clearing it now is harmless. Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-0-ddac39d61c4a@linux.dev Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-1-ddac39d61c4a@linux.dev Link: https://lore.kernel.org/all/20260605161422.213817-1-npache@redhat.com/ [1] Link: https://lore.kernel.org/all/20251008043748.45554-1-lance.yang@linux.dev/ [2] Signed-off-by: Nico Pache (Red Hat) <nico.pache@linux.dev> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Acked-by: Usama Arif <usama.arif@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Pedro Falcato <pfalcato@suse.de> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: Barry Song <baohua@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

…lper This change deduplicates the "is this PTE/folio referenced enough to be considered for a collapse" condition that was repeated in both __collapse_huge_page_isolate() and collapse_scan_pmd(), extracting it into a single inline helper function. Also move the comment and use it as the function header. While we are at it, updated the comment to clarify that a young pte is a recently accessed one. Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-2-ddac39d61c4a@linux.dev Signed-off-by: Nico Pache (Red Hat) <nico.pache@linux.dev> Acked-by: Usama Arif <usama.arif@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: Barry Song <baohua@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes (ARM) <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Pedro Falcato <pfalcato@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Provide a simple helper function to help reduce a often used, and duplicate pattern across the khugepaged code. When collapsing to a PMD we need to record a vm_event and the mTHP_stat event. When doing mTHP collapse we only update the mTHP stat. Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-3-ddac39d61c4a@linux.dev Signed-off-by: Nico Pache (Red Hat) <nico.pache@linux.dev> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Acked-by: Usama Arif <usama.arif@linux.dev> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Pedro Falcato <pfalcato@suse.de> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: Barry Song <baohua@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Fix comment in collapse_scan_pmd() that still described the old folio_mapcount() > folio_ref_count() check and a "512" false-positive scenario. The code now uses folio_expected_ref_count() != folio_ref_count() which doesn't suffer from the same limitation. Fix comment in collapse_huge_page() that referenced ptep_clear_flush, when the code actually uses pmdp_collapse_flush. Fix comment in __collapse_huge_page_swapin() that referenced the old function name khugepaged_scan_pmd, now collapse_scan_pmd. Also clean up some simple typos and stale terminology (mmap_sem -> mmap_lock, PG_lock -> folio lock, page -> folio, grammar). We also clarify a comment regarding where the max_ptes_none check is deferred to in mthp_collapse() from the original collapse_scan_pmd check. Update all comments that references a function to include parentheses. Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-4-ddac39d61c4a@linux.dev Signed-off-by: Nico Pache (Red Hat) <nico.pache@linux.dev> Acked-by: Usama Arif <usama.arif@linux.dev> Assisted-by: Cursor(claude-sonnet-4):4.6 Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Acked-by: Pedro Falcato <pfalcato@suse.de> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

We are currently dropping the anon_vma write lock before unmapping the PTE. Although this is safe, due to us still holding the mmap_write_lock, its safer and less confusing to switch the order of these two operations. Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-6-ddac39d61c4a@linux.dev Signed-off-by: Nico Pache (Red Hat) <nico.pache@linux.dev> Suggested-by: David Hildenbrand <david@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Acked-by: Pedro Falcato <pfalcato@suse.de> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: Barry Song <baohua@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Usama Arif <usama.arif@linux.dev> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

The note about khugepaged counters references /proc/vmstat for the PMD case, but never mentions where the mTHPs stats can be found (i.e.: /sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/stats/) Add a small addition to this section for clarity. Also fix a missing period while we are at it. Link: https://lore.kernel.org/20260811-khugepaged_pte_refactor-v4-7-ddac39d61c4a@linux.dev Signed-off-by: Nico Pache (Red Hat) <nico.pache@linux.dev> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Suggested-by: Lorenzo Stoakes <ljs@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Acked-by: Pedro Falcato <pfalcato@suse.de> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: Barry Song <baohua@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Usama Arif <usama.arif@linux.dev> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Steps 7 and 9 of the migration description still say "radix tree", unlike steps 5 and 11 which already use "i_pages lock". The page cache moved to the XArray at mapping->i_pages long ago. Use "page cache tree" for the two remaining references. Link: https://lore.kernel.org/20260812075739.325441-1-husong@kylinos.cn Signed-off-by: Song Hu <husong@kylinos.cn> Cc: David Hildenbrand <david@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

sort_folio() has a shortcut for moving folios that are no longer evictable but are still sitting on a generation list. However, this shortcut is buggy. It does not follow the PG_lru usage convention, and it has a more serious issue. Unevictable folios are not threaded on lists[LRU_UNEVICTABLE], so that folio->lru can be reused to hold folio->mlock_count (see the comment in lruvec_init()). Hence lruvec_add_folio() skips the list_add() for them, and every other place that turns a folio unevictable initialises mlock_count explicitly: lru_add() sets it to 0, __mlock_folio() and __mlock_new_folio() set it to !!folio_test_mlocked(folio). sort_folio() sets nothing, and the lru_gen_del_folio() right above it may have already poisoned folio->lru via list_del(), so mlock_count ends up aliasing LIST_POISON2, which reads as 0x122, i.e. 290. The result is user visible. On munlock, __munlock_folio() decrements that bogus count, finds it still non-zero and bails out before clearing PG_mlocked, so the folio remains unevictable and the Mlocked accounting stays inflated until the folio is freed. The shortcut also touches the LRU flags in the wrong order. It calls lru_gen_del_folio() while PG_lru is still set, so a concurrent folio_test_clear_lru() (e.g. compaction, folio_isolate_lru()) can succeed on a folio that has already been taken off the generation list, which may lead to unexpected behavior. So fix it by isolating them as common folios and letting the generic shrink path cull them. This matches the classical LRU behavior, and there should be no visible effect on the generic eviction or isolation behavior. There is no performance concern either, such a folio goes through this once, and then it is off the generation lists for good. Link: https://lore.kernel.org/20260812-mglru-mlock-fix-v2-1-a3fec5853c08@tencent.com Fixes: ac35a49 ("mm: multi-gen LRU: minimal implementation") Signed-off-by: Kairui Song <kasong@tencent.com> Reviewed-by: Barry Song <baohua@kernel.org> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Brian Geffon <bgeffon@google.com> Cc: David Hildenbrand <david@kernel.org> Cc: Jan Alexander Steffens (heftig) <heftig@archlinux.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Oleksandr Natalenko <oleksandr@natalenko.name> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Steven Barrett <steven@liquorix.net> Cc: Suleiman Souhlal <suleiman@google.com> Cc: Wei Xu <weixugc@google.com> Cc: Yuanchu Xie <yuanchu@google.com> Cc: Yu Zhao <yuzhao@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

alpha requires percpu variables in modules to be defined as weak so that the compiler generates GOT based external references for them. This puts two extra restrictions on percpu variable definitions. The symbol must be globally unique even when static and a static percpu variable can't be defined inside a function. DEBUG_FORCE_WEAK_PER_CPU exists to give generic code build coverage for these restrictions without building for alpha. MEM_ALLOC_PROFILING defines a static percpu counter at each allocation call site and thus can't be built with weak percpu definitions, so it depends on !DEBUG_FORCE_WEAK_PER_CPU. As allmodconfig enables DEBUG_FORCE_WEAK_PER_CPU, this knocks MEM_ALLOC_PROFILING out of allmodconfig build coverage. allmodconfig coverage for MEM_ALLOC_PROFILING is worth more than build coverage for restrictions which only matter to alpha module builds. Drop DEBUG_FORCE_WEAK_PER_CPU. Restriction violations will now show up only on alpha builds. Link: https://lore.kernel.org/178656406317.2437052.7257990869957704195@slm.duckdns.org Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Acked-by: Gabriele Monaco <gmonaco@redhat.com> [include/rv/da_monitor.h] Cc: Dennis Zhou <dennis@kernel.org> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Move pr_debug() inside the `if (dpage)` block to avoid printing garbage pfn for NULL dpage, and correct the direction label from "sys to dev" to "dev to sys". Link: https://lore.kernel.org/20260812092856.55296-1-liuqiangneo@163.com Signed-off-by: Qiang Liu <liuqiang@kylinos.cn> Assisted-by: Qoder:Qwen-3.8-MAX-Preview Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Leon Romanovsky <leon@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

For embedded devices, lacking support for NUMA, memory hotplug/hotremove, CMA and huge pages is a quite common scenario. In this scenario, the demand for contiguous physical memory allocation is very low. To reduce the kernel image size, some devices disable the compaction. However, their SoCs do support DDR ECC, meaning that memory-failure may be needed. Migration is very useful for soft_offline_page() in memory-failure, which may be triggered by correctable memory errors. Most anonymous and file-mapped faulty pages can be migrated to other healthy pages. Currently, MEMORY_FAILURE does not explicitly select MIGRATION. When COMPACTION, MEMORY_HOTREMOVE, NUMA_MIGRATION and CMA are all disabled, MEMORY_FAILURE can be enabled, but MIGRATION cannot be selected. Make MEMORY_FAILURE select MIGRATION to handle this situation. Link: https://lore.kernel.org/20260813134916.292733-1-xieyuanbin1@huawei.com Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com> Suggested-by: Mike Rapoport <rppt@kernel.org> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: Zi Yan <ziy@nvidia.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Acked-by: Miaohe Lin <linmiaohe@huawei.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: "Borislav Petkov (AMD)" <bp@alien8.de> Cc: Byungchul Park <byungchul@sk.com> Cc: David Hildenbrand <david@kernel.org> Cc: Gregory Price <gourry@gourry.net> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: liaohua <liaohua4@huawei.com> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Yuanbin Xie <xieyuanbin1@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

mm/hmm.c:673 hmm_do_fault() error: we previously assumed 'hmm_vma_walk->locked' could be null (see line 654) Stanislav says this can't happen. Waste a few cycles to make the warning go away. Fixes: 1211708 ("mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/202608101053.PhnVUM4u-lkp@intel.com Cc: Stanislav Kinsburskii <skinsburskii@gmail.com> Cc: David Hildenbrand <david@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

WARN_ON_ONCE() if the handler didn't set ->locked, per Stanislav Link: https://lore.kernel.org/anu1N-DOnQwxO1kF@skinsburskii Cc: David Hildenbrand <david@kernel.org> Cc: kernel test robot <lkp@intel.com> Cc: Stanislav Kinsburskii <skinsburskii@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Currently, in anon_vma_clone(), src vma's anon_vma is assigned to active_anon_vma and is used when unlocking anon_vma after linking new AVCs. However, the anon_vma is locked using src->anon_vma, instead of active_anon_vma, making the lock and unlock target inconsistent. Use active_anon_vma for both locking and unlocking. Link: https://lore.kernel.org/OS7PR01MB139142FE16EC63B892559D40496DA2@OS7PR01MB13914.jpnprd01.prod.outlook.com Signed-off-by: Eric Kim <seohyun.kim@outlook.kr> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: David Hildenbrand <david@kernel.org> Cc: Harry Yoo <harry@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

…ask_map() When building ARCH=riscv using clang with CONFIG_FORTIFY_SOURCE and CONFIG_UBSAN_BOUNDS enabled, CONFIG_NR_CPUS > 64, and the default value of 2 for CONFIG_NODES_SHIFT, there is a compiletime warning from the fortify routines. In file included from mm/arch_numa.c:11: In file included from include/linux/acpi.h:14: In file included from include/linux/resource_ext.h:11: In file included from include/linux/slab.h:17: In file included from include/linux/gfp.h:7: In file included from include/linux/mmzone.h:8: In file included from include/linux/spinlock.h:60: In file included from include/linux/interrupt_rc.h:17: In file included from include/linux/smp.h:13: In file included from include/linux/cpumask.h:11: In file included from include/linux/bitmap.h:13: In file included from include/linux/string.h:383: include/linux/fortify-string.h:430:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribue-warning] 430 | __write_overflow_field(p_size_field, size); | ^ include/linux/fortify-string.h:430:4: note: called by function 'fortify_memset_chk(unsigned long, unsigned long, unsigned long)' include/linux/bitmap.h:248:3: note: inlined by function 'setup_node_to_cpumask_map' 248 | memset(dst, 0, len); | ^ include/linux/fortify-string.h:462:25: note: expanded from macro 'memset' 462 | #define memset(p, c, s) __fortify_memset_chk(p, c, s, \ | ^ include/linux/fortify-string.h:453:2: note: expanded from macro '__fortify_memset_chk' 453 | fortify_memset_chk(__fortify_size, p_size, p_size_field), \ | ^ include/linux/fortify-string.h:430:4: note: use '-gline-directives-only' (implied by '-g1') or higher for more accurate inlining chain locations 430 | __write_overflow_field(p_size_field, size); | ^ 1 warning generated. In this configuration, MAX_NUMNODES is 4. clang unrolls the for loop in setup_node_to_cpumask_map() past this, which triggers the fortify check when accessing node_to_cpumask_map on the theoretical fifth loop iteration because it would be an out of bounds write. Make it clear to clang that nr_node_ids is bounded by MAX_NUMNODES due to the logic in setup_nr_node_ids() by early returning in setup_node_to_cpumask_map() should that condition be violated. Link: https://lore.kernel.org/20260813-arch_numa-avoid-fortify-warning-v2-1-093ad97a78df@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> Closes: ClangBuiltLinux#2174 Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Cc: Kees Cook <kees@kernel.org> Cc: Bill Wendling <morbo@google.com> Cc: Justin Stitt <justinstitt@google.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Moving v1 userspace eventfd handling into memcontrol-v1.c shrank struct vmpressure from 112 to 24 bytes when CONFIG_MEMCG_V1 is disabled. This moved memory_events_local[MEMCG_SWAP_FAIL] and the hot vmstats_percpu pointer onto the same cacheline. The stress-ng mremap stressor exercises MADV_PAGEOUT with swap disabled, generating about 20 million MEMCG_SWAP_FAIL updates per 60-second run on a 176-CPU test system. Those writes bounce the line while memcg statistics paths load vmstats_percpu. Move cgwb_list into the existing alignment gap and cacheline-align vmstats_percpu. This separates the pointer from the event counters without increasing the size of struct mem_cgroup in the tested configuration. The blamed commit reduced median mremap throughput by 4.38% on the test system with one socket. The patched kernel brings the performance to within 0.5% of the parent which is within the observed boot-to-boot spread (up to 1.2%). Link: https://lore.kernel.org/20260817103835.2937733-1-usama.arif@linux.dev Fixes: ea928e9 ("mm/vmpressure: move v1 userspace eventfd code into memcontrol-v1.c") Signed-off-by: Usama Arif <usama.arif@linux.dev> Reported-by: kernel test robot <yi1.lai@intel.com> Closes: https://lore.kernel.org/oe-lkp/202608131743.c6a7dda4-lkp@intel.com Tested-by: kernel test robot <yi1.lai@intel.com> Link: http://lore.kernel.org/aoAABX59IzUXz/Rv@ly-workstation Acked-by: Shakeel Butt <shakeel.butt@linux.dev> Acked-by: Michal Hocko <mhocko@suse.com> Cc: David Hildenbrand <david@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Yi Lai <yi1.lai@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Remove duplicate open() for local pagemap_fd in mprotect_tests() that shadows the global pagemap_fd already opened in main(). The local fd is never used in the function. Link: https://lore.kernel.org/20260817080616.52946-1-hongfu.li@linux.dev Signed-off-by: Hongfu Li <lihongfu@kylinos.cn> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Muhammad Usama Anjum <usama.anjum@arm.com> Reviewed-by: SJ Park <sj@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

migrate_vma_insert_huge_pmd_page() calls flush_cache_page() before replacing an existing huge zero PMD. However, the third argument to flush_cache_page() is a PFN, while addr + HPAGE_PMD_SIZE is an end virtual address. More importantly, the mapping being invalidated is PMD-sized rather than PAGE_SIZE-sized. Flush the whole PMD range with flush_cache_range(), matching other huge PMD invalidation paths. There is no userspace-visible effect today. The architectures that currently enable ARCH_ENABLE_THP_MIGRATION use no-op implementations of flush_cache_page()/flush_cache_range(). 32-bit ARM has non-trivial implementations, but does not enable ARCH_ENABLE_THP_MIGRATION. So this appears to be a latent API misuse rather than a currently observable bug, and I don't think a stable backport is necessary. Link: https://lore.kernel.org/20260817060845.377800-2-sh_def@163.com Fixes: a30b48b ("mm/migrate_device: implement THP migration of zone device pages") Signed-off-by: Hui Su <sh_def@163.com> Reviewed-by: Balbir Singh <balbirs@nvidia.com> Reviewed-by: Zi Yan <ziy@nvidia.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Byungchul Park <byungchul@sk.com> Cc: Gregory Price <gourry@gourry.net> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rakie Kim <rakie.kim@sk.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

swapops.h uses MAX_SWAPFILES_SHIFT, SWP_MIGRATION_READ and SWP_PTE_MARKER, all of which swap.h defines, but does not include swap.h. It compiles only where the translation unit pulled swap.h in first. leafops.h includes swapops.h on the line above swap.h, so a file whose include list reaches leafops.h before swap.h gets: In file included from include/linux/leafops.h:11: include/linux/swapops.h:88:21: error: use of undeclared identifier 'MAX_SWAPFILES_SHIFT' A header that uses a definition has to include the header that provides it. Link: https://lore.kernel.org/20260818115026.656406-1-kirill@shutemov.name Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202608181757.mza9RRj7-lkp@intel.com/ Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Barry Song <baohua@kernel.org> Cc: Baoquan He <baoquan.he@linux.dev> Cc: Chris Li <chrisl@kernel.org> Cc: Kairui Song <kasong@tencent.com> Cc: Kemeng Shi <shikemeng@huaweicloud.com> Cc: Nhat Pham <nphamcs@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

consume_stock() can drive a stock slot's nr_pages to zero while its cached[] pointer stays set, so the slot keeps pinning the css reference that refill_stock() took. The offlining drain only flushes slots with cached pages, so the reference is never released unless the slot happens to be displaced by an unrelated charge or by CPU hotplug, and the memcg lingers in the dying state - up to NR_MEMCG_STOCK (7) of them per CPU under container churn. Keeping the slot populated past the last page only saves a css_get()/css_put() pair on the next charge of the same memcg, and costs more than that: the offlining drain has to know about empty slots, and refill_stock() cannot reuse them either, so a charge under a different memcg evicts a live batch through the drain_idx rotation instead. Drop the reference in consume_stock() when the slot empties. Empty slots stop existing, so is_memcg_drain_needed() and the drain path stay as they are, and refill_stock() reuses emptied slots directly. The cost is one refcount pair per emptied slot, at most once per MEMCG_CHARGE_BATCH pages. Link: https://lore.kernel.org/20260818130135.154315-1-husong@kylinos.cn Fixes: d1a05b6 ("memcg: do not try to drain per-cpu caches without pages") Signed-off-by: Song Hu <husong@kylinos.cn> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Shakeel Butt <shakeel.butt@linux.dev> Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Audra Mitchell <audra@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Nico Pache <npache@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

test_mprotect() calls ftruncate() to resize the backing file before mmap()'ing it, but never checks the return value. If ftruncate() fails, the file may remain shorter than the requested mapping size. The subsequent mmap() with MAP_SHARED can still succeed in this case, but the very next line writes directly into the mapped memory (*map = 1), which can trigger SIGBUS if the mapping extends beyond the actual file size. Check the return value and fail cleanly with ksft_exit_fail_msg() if ftruncate() fails, matching the error-handling style already used for the mmap() call immediately below it. Link: https://lore.kernel.org/20260818133206.39503-1-anshumantewari123@gmail.com Signed-off-by: Anshuman <anshumantewari123@gmail.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Sarthak Sharma <sarthak.sharma@arm.com> Cc: David Hildenbrand <david@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

A corrupt page table hands the same bogus entry to get_swap_device() on every access to the mapping, and every rejection is logged. One machine logged 6185620 copies of the same line in a few hours. swap_dup_entry_direct() prints the same message from the fork path, once per call: the WARN_ON_ONCE() guarding it warns once, the pr_err() inside does not. Rate limit all three prints. Link: https://lore.kernel.org/20260818-swap_part_one-v1-1-a4fc58119fc0@debian.org Fixes: 23b230b ("mm/swap: print bad swap offset entry in get_swap_device") Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Barry Song <baohua@kernel.org> Reviewed-by: Nhat Pham <nphamcs@gmail.com> Acked-by: Kairui Song <kasong@tencent.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Baoquan He <baoquan.he@linux.dev> Cc: Chris Li <chrisl@kernel.org> Cc: Kemeng Shi <shikemeng@huaweicloud.com> Cc: Miaohe Lin <linmiaohe@huawei.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

get_finfo() calls stat() to get metadata about the target directory, but never checks the return value. On failure, stat() returns -1 and leaves path_stat unmodified, so path_stat.st_mode may contain uninitialized stack data. The code then checks S_ISDIR(path_stat.st_mode) against this potentially garbage value. This can produce a misleading "Not a directory" error when the real problem is a nonexistent or inaccessible path, or, in the worst case, the check could pass by chance on garbage data and let the function continue using an invalid path_stat for the rest of its logic. Check the return value and fail with a clear error message if stat() fails, matching the error-handling style already used for statfs() and read_file() later in the same function. Link: https://lore.kernel.org/20260819121426.49500-1-anshumantewari123@gmail.com Signed-off-by: Anshuman <anshumantewari123@gmail.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: SJ Park <sj@kernel.org> Reviewed-by: Sarthak Sharma <sarthak.sharma@arm.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Patch series "maple_tree: lock checking and clean ups", v2. The goals of this series are: 1. Lock issue detection A number of syzbot reports are incorrectly pointing to the mm exit as a source of the locking error. The first three patches attempt to help users detect errors in their locking - but they still have to use LOCKDEP. I guess it's still down to hope and prayers. 2. Documentation fixes The documentation was lacking clarity, there are updates to try and help the users, especially around the erase() cases. 3. Two benign issues The cyclic allocator may have a race, although no in-kernel user can hit it. The erase functions may cause allocation issues if used with the incorrect locking type, but none are present in-tree. Beyond these goals there are some test fixes, some general speed-up patches targeting extra work and cycles, and dropping dead code. This patch (of 19): When CONFIG_LOCKDEP and CONFIG_RCU_STRICT_GRACE_PERIOD is enabled, check for rcu locking issues by recording the grace period in the maple state and checking the rcu window is still valid whenever the maple state is reused with a state that is not MA_START or MA_PAUSED. Link: https://lore.kernel.org/20260630190843.3563858-1-liam@infradead.org Link: https://lore.kernel.org/20260630190843.3563858-2-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) <liam@infradead.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Chris Mason <clm@meta.com> Cc: Chuck Lever <cel@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Joe Perches <joe@perches.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Waiman Long <longman@redhat.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Add an 8 bit small sequence counter to the held_lock struct to detect if the lock as been dropped and reacquired. This is useful when a data structure depends on a constant locking context, but is not able to detect locking and unlocking of the lock through its own API. Since the __lock_unpin_lock() will no longer detect underflow by casting the unsigned int to a signed int, update the casting code to use a temp variable for calculations using a signed int. Link: https://lore.kernel.org/20260630190843.3563858-3-liam@infradead.org Link: https://lore.kernel.org/all/h3tpnj5kzcrxms5picmimtkpg4aypcpip5wbd6bt2rpdj5k7eb@nhtzs3lefrkq/ Signed-off-by: Liam R. Howlett (Oracle) <liam@infradead.org> Suggested-by: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Will Deacon <will@kernel.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Waiman Long <longman@redhat.com> Cc: Chris Mason <clm@meta.com> Cc: Chuck Lever <cel@kernel.org> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Joe Perches <joe@perches.com> Cc: Rik van Riel <riel@surriel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Use the lockdep sequence numbers to ensure the write lock is not dropped between write operations. The lockdep sequence is recorded on any walk that starts from the top of the tree and re-checked prior to any operation using an active node. Link: https://lore.kernel.org/20260630190843.3563858-4-liam@infradead.org Signed-off-by: Liam R. Howlett (Oracle) <liam@infradead.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Chris Mason <clm@meta.com> Cc: Chuck Lever <cel@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Joe Perches <joe@perches.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Waiman Long <longman@redhat.com> Cc: Will Deacon <will@kernel.org> Cc: Breno Leitao <leitao@debian.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

…t/lenb/linux.git

…el/git/sergeh/linux.git

Signed-off-by: Mark Brown <broonie@kernel.org>

-- 2.47.3 (cherry picked from commit 536526d) (cherry picked from commit 0ebc551) (cherry picked from commit 2e5980a)

(cherry picked from commit c99c140) (cherry picked from commit 4ca2fc8) (cherry picked from commit 2f421f0)

(cherry picked from commit e822804) (cherry picked from commit 29ff0b0)

(cherry picked from commit 8829a4d) (cherry picked from commit 29e5e4d)

(cherry picked from commit 47b6fa7) (cherry picked from commit 779ea1f)

(cherry picked from commit 3fbcd8a) (cherry picked from commit 6cca8a3)

(cherry picked from commit 575ef87) (cherry picked from commit 756bcba)

(cherry picked from commit 25bc8cc) (cherry picked from commit 041cef1)

(cherry picked from commit 34c2996)

[Why] Chrontel CH7218 found in Ugreen DP -> HDMI 2.1 adapter (model 85564) works perfectly with VRR after testing. VRR and FreeSync compatibility is explicitly advertised as a feature so it's addition is a formality. Support FreeSync info packet passthrough and "generic" HDMI VRR. [How] Add CH7218's ID to dm_helpers_is_vrr_pcon_allowed() Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4773 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> (cherry picked from commit 7b2436287ed953496ad1c9eb5820f00b75db597f)

… Block why: HDMI FRL sinks were not parsed for the AMD VSDB and no VTEM info packet was emitted for them, so 2.1 FreeSync over HDMI FRL did not work. It is backward-compatible with 2.0 FreeSync. how: - Accept SIGNAL_TYPE_HDMI_FRL alongside SIGNAL_TYPE_HDMI_TYPE_A when parsing the AMD VSDB in amdgpu_dm_update_freesync_caps(). - Build and send the VTEM info packet via mod_build_infopacket_vtem() when the stream signal is HDMI FRL during the freesync state update. - Set the VTEM Data_Set_Length to 0 when no VTEM feature is enabled. build_infopacket_header_vtem() hardcodes Data_Set_Length = 4, so a VTEM with Data_Set_Length = 4 would be transmitted even when no VTEM feature is enabled (VRR_EN = 0 and no FVA), e.g. when the sink advertises VRRMIN = 0 and vrr_capable is false. This fails HDMI GCTS HF1-58 step 6.2. The VTEM must keep being transmitted every MTW while VRR is enabled (HF1-58 steps 8.1 and 8.3), so it cannot simply be suppressed per frame. Instead, follow the MLDS option in HDMI 2.1 10.10.2.4: keep transmitting the VTEM but set Data_Set_Length = 0 when no feature is enabled. When VRR becomes active the full Data_Set_Length = 4 payload with VRR_EN = 1 is sent as before. Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> (cherry picked from commit 62ac74defba77c84daee2adc56b19b2c0b4e9afd)

…m HF-VSDB Parse the HDMI 2.1 gaming-related capabilities advertised in the HDMI Forum VSDB (HF-VSDB) and expose them through struct drm_hdmi_info so drivers can consume them. Add struct drm_hdmi_vrr_cap describing the sink's VRR capabilities: Fast VActive (Quick Frame Transport), Negative M VRR, Cinema VRR, MDelta, and the VRRmin/VRRmax range, together with a "supported" flag derived from that range. Add the fapa_start_location and allm (Auto Low Latency Mode) flags to struct drm_hdmi_info. drm_parse_hdmi_gaming_info() reads byte 8 of the HF-VSDB for the FAPA/ALLM/FVA/CNMVRR/CinemaVRR/MDelta flags and bytes 9-10 for VRRmin/VRRmax. Per HDMI 2.1, VRR is considered supported when VRRmin is within 1-48 and VRRmax is either 0 (maximum based on the video mode) or >= 100. It is invoked from drm_parse_hdmi_forum_scds(), and the parsed values are logged for debugging. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Tested-by: Bernhard Berger <bernhard.berger@gmail.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> (cherry picked from commit 26e1509c3ec24f6314e972edd64d9dc18d8be779)

why: HDMI 2.1 sinks advertise their VRR range in the HDMI Forum VSDB (HF-VSDB), but amdgpu derived FreeSync capability only from the AMD VSDB. Sinks that expose just the HDMI Forum VRR capability (e.g. HDMI compliance EDIDs) were therefore reported as not VRR capable. how: - In amdgpu_dm_update_freesync_caps(), when the AMD VSDB does not provide a valid FreeSync range, fall back to the HDMI 2.1 VRR range parsed by DRM core from the HF-VSDB (connector->display_info.hdmi.vrr_cap). VRRMAX = 0 means "up to the Base Refresh Rate"; when the EDID provides no monitor range maximum either, fall back to the Base Refresh Rate (the highest refresh-rate mode of the preferred timing) so a valid VRR range is still reported to userspace. - Add VRR debug logging along the FreeSync capability and config paths. Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> (cherry picked from commit c5010ee089293c52c6489d308f1e659ba74f6ed5)

why: HDMI 2.1 Auto Low-Latency Mode (ALLM) lets a Source request the Sink's low-latency mode through the HF-VSIF. HDMI 2.1 Section 7.6.6 requires that when Gaming-VRR is enabled (VRR_EN=1) and the Sink advertises ALLM in the SCDS, the Source shall transmit the HF-VSIF and set ALLM_Mode=1. amdgpu never set ALLM_Mode, so this requirement was not met. how: - In update_freesync_state_on_stream(), set ALLM_Mode=1 in the HF-VSIF when Gaming-VRR is active (vrr state ACTIVE_VARIABLE/ACTIVE_FIXED, i.e. VRR_EN=1) and the sink advertises ALLM, per HDMI 2.1 Section 7.6.6, and push the updated HF-VSIF (vsp_infopacket) as a stream update. ALLM is driven only by the mandatory Gaming-VRR case. Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> (cherry picked from commit 7cafa47e65ace3daf0758553da2d6131c4290b5f)

The AYANEO 3 handheld has a detachable controller with swappable modules ("Magic Modules"). The controller exposes three USB HID interfaces behind 1c4f:0002 (a generic SigmaMicro VID/PID, hence the DMI gate): a gamepad, a keyboard for the extra buttons, and a vendor interface accepting 65-byte commands. Add a driver for the vendor interface providing module identification (module_left/module_right sysfs attributes), software eject of the modules (eject sysfs attribute, blocking until the firmware confirms the release handshake), and RGB control of the joystick rings as a multicolor LED class device named ayaneo:rgb:joystick_rings, matching the name InputPlumber already expects for this device. This complements the ayaneo-ec platform driver, which exposes module attach state and controller power. A full physical eject is performed by writing to eject and then cutting power through ayaneo-ec's controller_power attribute; that orchestration is deliberately left to userspace. The protocol was reverse engineered in the Handheld Daemon project by Antheas Kapenekakis. Tested on an AYANEO 3 (7.2.0-ogc4.1): module identification, RGB, and a full eject/reinsert/repower cycle. Signed-off-by: Matías Martínez <hello@matias.me>

Lets the build workflow compile the new driver. The real OGC config change is OpenGamingCollective/kernel-packages#35, which lands once the driver merges. Signed-off-by: Matías Martínez <hello@matias.me>

A brightness write racing a driver unbind can queue the LED's set_brightness_work after the flush inside led_classdev_unregister() but before the sysfs node is removed. With the LED registered through devm, that work then runs after aya3_remove() has called hid_hw_stop() and after devres has freed the driver data, writing through freed memory. Reproducible memory corruption (system hang with display artifacts) by unbinding under a brightness-write loop; the window is also reachable in normal use, since the controller power-cycles on resume and on module eject while userspace may be writing the LED. Register the LED without devm, unregister it first in remove, and flush set_brightness_work once more after the unregister -- at that point the sysfs node is provably gone and nothing can requeue it, and the transport is still up for a final send. Same fix as in the v2 upstream submission (lore.kernel.org/linux-input/20260824223103.93947-1-hello@matias.me); validated there on hardware with repeated unbinds under a concurrent brightness-write load. Signed-off-by: Matías Martínez <hello@matias.me>

The default button map intends to assign F15 and F16 to M1 and M2, but the selected mapping table indexes resolve to F16 and F17. Use indexes 47 and 48 so the programmed usages match the existing comments. Assisted-by: LLM Fixes: e4c850a ("HID: hid-oxp: Add Button Mapping Interface") Signed-off-by: Andrei Aldea <andrei1998@gmail.com>

The ONEXPLAYER 3 and X2 Mini Pro use the X2 controller mapping format. Their MCU expects format byte 0x02 and a third mapping page that preserves the factory mappings for the additional buttons. Sending the existing two-page 0x20 transaction leaves either M1 or Home unavailable. Add exact DMI quirks for both systems and send the third page only on those devices, retaining the existing format and two-page transaction everywhere else. Assisted-by: LLM Fixes: e4c850a ("HID: hid-oxp: Add Button Mapping Interface") Signed-off-by: Andrei Aldea <andrei1998@gmail.com>

The ONEXPLAYER 3 and X2 Mini Pro use the same full-size controllers and expose their lighting through the X2 FE00 protocol. Their left ring, right ring, and combined ring zones must all be programmed. Solid-color reports are 59 bytes long, and writes return an acknowledgment that identifies the command and zone. Extend the shared X2-family quirk, fan out commands to all three ring zones, validate acknowledgments, and retain cached effect and color state because X2 status replies do not report them reliably. Serialize complete RGB transactions and retry failed fanout writes. Also restore button, mode, rumble, and RGB state after a system resume once the controller MCU has restarted. Guard queued work across suspend, removal, and failed probe paths, and add the report-size and brightness-calculation fixes needed by the new path. Assisted-by: LLM Signed-off-by: Andrei Aldea <andrei1998@gmail.com>

The ONEXPLAYER 3 and X2 Mini Pro expose the front Guide button and rear logo as RGB zones 0x05 and 0x06. Existing X2 support only controls joystick-ring zones 0x01, 0x02, and 0x07. Register an independent multicolor LED for each auxiliary zone and expose the supported monocolor and breathing effects. Cache each zone separately, serialize and retry complete transactions, and restore configured state after the controller MCU restarts on resume. Limit X2 configuration ownership to USB interface 2 so additional controller interfaces cannot overwrite the singleton driver state. Document the new effect attributes and make work teardown race-safe across suspend, removal, and failed probe paths. Tested on an ONEXPLAYER 3 with independent solid, breathing, brightness, and off control for both zones, simultaneous different states, and restoration after suspend/resume. Assisted-by: LLM Signed-off-by: Andrei Aldea <andrei1998@gmail.com>

pastaq

Minor nit for patch 2

With that addressed for v2,
Reviewed-by: Derek J. Clark derekjohn.clark@gmail.com

pastaq · 2026-08-31T13:50:05Z

 {
-	u8 page_1[59] = { 0x02, 0x38, 0x20, 0x01, 0x01 };
-	u8 page_2[59] = { 0x02, 0x38, 0x20, 0x02, 0x01 };
+	u8 page_1[59] = { 0x02, 0x38, OXP_BMAP_FORMAT_DEFAULT, 0x01, 0x01 };


Use drvdata.bmap_format here.

pastaq · 2026-08-31T13:50:29Z


 	oxp_page_fill_data(page_1, p1, ARRAY_SIZE(p1));
 	oxp_page_fill_data(page_2, p2, ARRAY_SIZE(p2));
+	page_1[2] = drvdata.bmap_format;


Do this at buffer creation.

pastaq · 2026-08-31T13:50:57Z

 	};

 	oxp_page_fill_data(page_1, p1, ARRAY_SIZE(p1));
 	oxp_page_fill_data(page_2, p2, ARRAY_SIZE(p2));


So we not need to add/fill page_3 here for some reason?

pastaq

For patch 1, please add a fixes tag when up-streaming/

Reviewed-by: Derek J. Clark derekjohn.clark@gmail.com

pastaq

There are a lot of comments for patch 3 but overall it isn't bad. The summary is

Make each individual fix for an issue a fixes patch. use a fixes tag with the sha of the patch that added the feature.
Instead of branching in gen 2, identify gen 3 early and make new paths, leaving as much existing code in place. This is to avoid regressions in hardware that is difficult to get tested.

pastaq · 2026-08-31T14:03:51Z

 	struct oxp_gen_1_rgb_report *rgb_rep;

+	if (size < sizeof(*rgb_rep) || !led_mc)
+		return 0;


Please put general fixes in thier own separate preceding patches so they can be backported to stable kernels. One patch per fix.

pastaq · 2026-08-31T14:04:35Z

-	led_mc->led_cdev.brightness = rgb_rep->brightness / 4 *
+	led_mc->led_cdev.brightness = rgb_rep->brightness *
 				      led_mc->led_cdev.max_brightness;
-	/* If monocolor had less than 100% brightness on the previous boot,


Please retain the comment.

pastaq · 2026-08-31T14:04:59Z

 	drvdata.rgb_en = rgb_rep->enabled == 0 ? OXP_FEAT_DISABLED :
 						 OXP_FEAT_ENABLED;
 	drvdata.rgb_brightness = rgb_rep->brightness;
-	led_mc->led_cdev.brightness = rgb_rep->brightness / 4 *


General fix patch

pastaq · 2026-08-31T14:07:05Z

 static int oxp_gen_2_property_out(enum oxp_function_index fid, u8 *data, u8 data_size);
 static int oxp_set_buttons(void);
 static int oxp_rumble_intensity_set(u8 intensity);
+static int oxp_rgb_status_store(u8 enabled, u8 speed, u8 brightness);


Please make the restore on resume a fix patch as well

pastaq · 2026-08-31T14:08:44Z

 	/* Remainder only applies for xinput mode */
-	if (drvdata.gamepad_mode == OXP_GP_MODE_DEBUG)
+	if (drvdata.gamepad_mode == OXP_GP_MODE_DEBUG) {
+		oxp_rgb_restore();


Is this possible to do once prior to this early return block? I don't remember if the xinput mode needs to be set first.

pastaq · 2026-08-31T14:37:31Z

+	guard(mutex)(&drvdata.rgb_mutex);
+	old_effect = drvdata.rgb_effect;
+
+	if (!drvdata.x2_rgb) {


I'd prefer to fix up oxp_rgb_status_store to branch instead of branching here. Is there a technical reason you did it here?

pastaq · 2026-08-31T14:38:42Z

 	{
 		.color_index = LED_COLOR_ID_RED,
 		.intensity = 0x24,
+		.max_intensity = 0xff,


fixes patch

pastaq · 2026-08-31T14:42:28Z

+	drvdata.gen2_work_initialized = false;
+err_cancel_rgb:
+	WRITE_ONCE(drvdata.removing, true);
+	spin_lock_irqsave(&oxp_rgb_reply_lock, flags);


scoped guard

pastaq · 2026-08-31T14:43:00Z

 	drvdata.led_mc = &oxp_cdev_rgb;

 	INIT_DELAYED_WORK(&drvdata.oxp_rgb_queue, oxp_rgb_queue_fn);
+	drvdata.rgb_work_initialized = true;


add a probe fail fixes patch

pastaq · 2026-08-31T14:44:32Z

+	bool removing;
 } drvdata;

+static DEFINE_SPINLOCK(oxp_rgb_reply_lock);


In the future I'll be making drvdata unique per init. Please make this a member of drvdata to ease that transition.

pastaq

For patch 4, I'd like to break it into 2 patches. The first will refactor the existing RGB to use a common LED array for all LEDS, so that they are all handled the same way. Use a void pointer for the state and a new type enum for the switch case for casting. The second patch can then expand on the new format to add the aux zones

pastaq · 2026-08-31T17:15:58Z

@@ -0,0 +1,39 @@
+What:		/sys/class/leds/oxp:rgb:guide_button/effect


We can combine these I think.
/sys/class/leds/oxp:rgb:[joystick_rings|guide_button|rear_logo]/effect

Description would need to be more descriptive of existing effects.

pastaq · 2026-08-31T17:19:13Z

 	struct oxp_button_idx btn_m2;
 } __packed;

+enum oxp_x2_aux_effect {


Please move these to live after the existing rgb structs/enums

pastaq · 2026-08-31T17:23:18Z

+	bool valid;
+};
+
+struct oxp_x2_aux_led {


Why are we using a different pattern for this? A separate __packed rgb report would make more sense to me to keep things consistent. If this struct is necessary we should refactor existing RGB to use it and provide state as a void pointer we can cast for member access.

pastaq · 2026-08-31T17:27:02Z


 static const u8 oxp_x2_rgb_zones[] = { 0x01, 0x02, 0x07 };

+#define OXP_GEN2_RGB_DATA_SIZE 59


Please keep all defines at the top of the file

pastaq · 2026-08-31T17:28:11Z

+	int ret;
+	int attempt;
+
+	for (attempt = 0; attempt < 2; attempt++) {


Why are we looping here? This isn't iterating on an index.

pastaq · 2026-08-31T17:29:57Z

+	if (ret || !brightness)
+		return ret;
+
+	red = ((unsigned int)state->red * brightness + max_brightness / 2) /


Add a comment explaining this

pastaq · 2026-08-31T17:31:53Z

+	return container_of(mc_cdev, struct oxp_x2_aux_led, mc_cdev);
+}
+
+static const char *const oxp_x2_aux_effect_text[] = {


Please keep this directly under the enum

pastaq · 2026-08-31T17:32:42Z

 	.subled_info = oxp_rgb_subled_info,
 };

+struct oxp_x2_aux_led_desc {


define structs at the top

pastaq · 2026-08-31T17:34:09Z


+struct oxp_x2_aux_led_desc {
+	const char *name;
+	u8 zone;


Add a type enum (RGB_FULL/RGB_AUX) u8 here so we can match on it and reuse the same structs and functions.

pastaq · 2026-08-31T17:35:38Z

If we're adding docs (something I missed) we should include the rest of the ABI that was left out as well

wfelipe and others added 30 commits August 20, 2026 18:24

broonie and others added 25 commits August 21, 2026 14:24

Merge branch 'next' of https://git.kernel.org/pub/scm/linux/kernel/gi…

87bcc9a

…t/lenb/linux.git

Merge branch 'caps-next' of https://git.kernel.org/pub/scm/linux/kern…

d17b8a5

…el/git/sergeh/linux.git

Merge branch 'for-next' of https://github.com/hisilicon/linux-hisi.git

33281b5

Add linux-next specific files for 20260821

903c1cf

Signed-off-by: Mark Brown <broonie@kernel.org>

ogc: linux-unstable: first commit

4f55e63

-- 2.47.3 (cherry picked from commit 536526d) (cherry picked from commit 0ebc551) (cherry picked from commit 2e5980a)

ogc: linux-unstable: re-apply patches on top of linux-next

e52a8ce

(cherry picked from commit c99c140) (cherry picked from commit 4ca2fc8) (cherry picked from commit 2f421f0)

ogc: linux-unstable: build the kernel on push

e783a56

(cherry picked from commit e822804) (cherry picked from commit 29ff0b0)

ogc: linux-unstable: improve build time

eb50c54

(cherry picked from commit 8829a4d) (cherry picked from commit 29e5e4d)

ogc: linux-unstable: build rpm for fedora distros

913a90a

(cherry picked from commit 47b6fa7) (cherry picked from commit 779ea1f)

ogc: linux-unstable: add debian packaging

d793050

(cherry picked from commit 3fbcd8a) (cherry picked from commit 6cca8a3)

ogc: linux-unstable: fix openssl errors in build

ca229dc

(cherry picked from commit 575ef87) (cherry picked from commit 756bcba)

ogc: linux-unstable: fix sync

de3e2bb

(cherry picked from commit 25bc8cc) (cherry picked from commit 041cef1)

ogc: linux-unstable: test PRs

37a3efa

(cherry picked from commit 34c2996)

[NOT-FOR-UPSTREAM] github: enable CONFIG_HID_AYANEO in the CI fragment

5c32c7e

Lets the build workflow compile the new driver. The real OGC config change is OpenGamingCollective/kernel-packages#35, which lands once the driver merges. Signed-off-by: Matías Martínez <hello@matias.me>

pastaq requested changes Aug 31, 2026

View reviewed changes

pastaq approved these changes Aug 31, 2026

View reviewed changes

pastaq requested changes Aug 31, 2026

View reviewed changes

NeroReflex force-pushed the master branch from d36eccf to 370d86f Compare September 1, 2026 19:43

		@@ -0,0 +1,39 @@
		What: /sys/class/leds/oxp:rgb:guide_button/effect


		static const u8 oxp_x2_rgb_zones[] = { 0x01, 0x02, 0x07 };

		#define OXP_GEN2_RGB_DATA_SIZE 59

Uh oh!

Conversation

Grippy98 commented Aug 30, 2026

Testing

AI assistance disclosure

Uh oh!

pastaq left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pastaq left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pastaq left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pastaq left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

pastaq left a comment •

edited

Loading