Commit graph

1,461,726 commits

Author SHA1 Message Date
Praveen Talari
8f4ce470ff soc: qcom: geni-se: Add resources activation/deactivation helpers
The GENI SE protocol drivers (I2C, SPI, UART) implement similar resource
activation/deactivation sequences independently, leading to code
duplication.

Introduce geni_se_resources_activate()/geni_se_resources_deactivate() to
power on/off resources.The activate function enables ICC, clocks, and TLMM
whereas the deactivate function disables resources in reverse order
including OPP rate reset, clocks, ICC and TLMM.

Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20260227061544.1785978-6-praveen.talari@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 21:56:38 -05:00
Praveen Talari
e5f54cda9d soc: qcom: geni-se: Handle core clk in geni_se_clks_off() and geni_se_clks_on()
Currently, core clk is handled individually in protocol drivers like
the I2C driver. Move this clock management to the common clock APIs
(geni_se_clks_on/off) that are already present in the common GENI SE
driver to maintain consistency across all protocol drivers.

Core clk is now properly managed alongside the other clocks (se->clk
and wrapper clocks) in the fundamental clock control functions,
eliminating the need for individual protocol drivers to handle this
clock separately.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20260227061544.1785978-5-praveen.talari@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 21:56:38 -05:00
Praveen Talari
5b8a39dcf9 soc: qcom: geni-se: Introduce helper API for resource initialization
The GENI Serial Engine drivers (I2C, SPI, and SERIAL) currently duplicate
code for initializing shared resources such as clocks and interconnect
paths.

Introduce a new helper API, geni_se_resources_init(), to centralize this
initialization logic, improving modularity and simplifying the probe
function.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20260227061544.1785978-4-praveen.talari@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 21:56:38 -05:00
Praveen Talari
f746fedb89 soc: qcom: geni-se: Add geni_icc_set_bw_ab() function
Add a new function geni_icc_set_bw_ab() that allows callers to set
average bandwidth values for all ICC (Interconnect) paths in a single
call. This function takes separate parameters for core, config, and DDR
average bandwidth values and applies them to the respective ICC paths.

This provides a more convenient API for drivers that need to configure
specific average bandwidth values.

Co-developed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20260227061544.1785978-3-praveen.talari@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 21:56:38 -05:00
Praveen Talari
e231930279 soc: qcom: geni-se: Refactor geni_icc_get() and make qup-memory ICC path optional
The "qup-memory" interconnect path is optional and may not be defined
in all device trees. Unroll the loop-based ICC path initialization to
allow specific error handling for each path type.

The "qup-core" and "qup-config" paths remain mandatory and will fail
probe if missing, while "qup-memory" is now handled as optional and
skipped when not present in the device tree.

Co-developed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
[...]
Tested-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20260227061544.1785978-2-praveen.talari@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 21:56:37 -05:00
Anup Kulkarni
89e77275b5 arm64: dts: qcom: lemans-evk: Enable CAN RX via I2C GPIO expander
The LeMans EVK board routes the RX lines of CAN controllers 2, 4, and 6
(part of the RTSS subsystem) through a signal multiplexer controlled by
GPIO 4 of the I2C GPIO expander at address 0x3b. The remaining CAN
controllers, out of 8 total on RTSS, are wired directly to their
transceivers.

The multiplexer select pin defaults low on reset, disconnecting CAN 2,
4, and 6 RX lines from their respective transceivers, which results in
no data being received on these interfaces.

Configure GPIO 4 as output-high to assert the mux select line at boot,
connecting the RX signals of CAN 2, 4, and 6 to their transceivers as
required by the EVK board wiring.

Signed-off-by: Anup Kulkarni <anup.kulkarni@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260519064954.2759960-1-anup.kulkarni@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 21:55:28 -05:00
Gopikrishna Garmidi
ecabfe832b arm64: dts: qcom: glymur: Fix wrong interrupt number for i2c19
The i2c19 node at 0x88c000 uses GIC SPI 584, but that interrupt
belongs to the neighboring i2c18/spi18 node at 0x888000. The correct
interrupt for i2c19 is GIC SPI 585, as used by its sibling nodes
spi19 and uart19 which share the same register base and clock.

Fixes: 41b6e8db40 ("arm64: dts: qcom: Introduce Glymur base dtsi")
Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260518-glymur-fix-i2c19-irq-v1-1-7d5968bd9b2b@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 21:55:16 -05:00
Bartosz Golaszewski
9bee0a0a33 clk: qcom: nord: negcc: add support for the USB2 PHY reset
Expose the USB2 PHY reset in order to enable adding the USB nodes in DTS
for Nord.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260518-nord-clk-usb2-phy-v2-2-17a86cb307c3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 21:54:09 -05:00
Bartosz Golaszewski
d62b0e3104 dt-bindings: clock: qcom: add the definition for the USB2 PHY reset
Provide the USB2 PHY reset definition in dt-bindings for the Nord negcc
module in order to enable adding the USB nodes in DTS.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260518-nord-clk-usb2-phy-v2-1-17a86cb307c3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 21:54:09 -05:00
Mukesh Ojha
85abff1549 arm64: dts: qcom: Drop unused remoteproc_adsp_glink label
The remoteproc_adsp_glink label on the ADSP glink-edge node has no
users in the upstream tree across all affected SoCs. The only user
of this label is qcs6490-audioreach.dtsi which references the label
defined in its own SoC dtsi and is left untouched.

Remove the label from kaanapali, lemans, monaco, sar2130p, sc8180x,
sc8280xp, sm8450, sm8550, sm8650 and sm8750.

Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260409181329.556899-1-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 21:53:34 -05:00
Dan Carpenter
db0ec1ad72 soc: qcom: llcc-qcom: Fix NULL vs IS_ERR() bug in qcom_llcc_get_fw_config()
The devm_memremap() function doesn't return NULL, it returns error
pointers.  Fix the error checking to match.

Fixes: ac23106a9b ("soc: qcom: llcc-qcom: get SCT descriptors from fw-populated memory")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/ag1N_rAHEQ1YJsa7@stanley.mountain
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 21:51:04 -05:00
Dmitry Baryshkov
8db813dc08 drm/ci: disable mr-label-maker-test
The MR labelling is not used for DRM CI, however the job got enabled as
a part of the CI pipeline and now prevents it from being executed.
Disable the mr-label-maker-test job implicitly.

Link: https://gitlab.freedesktop.org/drm/msm/-/pipelines/1672049
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-05-22 05:26:26 +03:00
Byungchul Park
54cf41c969 Revert "mm: introduce a new page type for page pool in page type"
This reverts commit db359fccf2 ("mm: introduce a new page type for page
pool in page type") and a part of 735a309b4b ("net: add net_iov_init()
and use it to initialize ->page_type").

Netpp page_type'ed pages might be used in mapping so as to use @_mapcount.
However, since @page_type and @_mapcount are union'ed in struct page,
these two can't be used at the same time.  Revert the commit introducing
page_type for Netpp for now.

The patch will be retried once @page_type and @_mapcount get allowed to be
used at the same time.

The revert also includes removal of @page_type initialization part
introduced by commit 735a309b4b ("net: add net_iov_init() and use it
to initialize ->page_type"), which will be restored on the retry.

Link: https://lore.kernel.org/20260515034701.17027-1-byungchul@sk.com
Fixes: db359fccf2 ("mm: introduce a new page type for page pool in page type")
Signed-off-by: Byungchul Park <byungchul@sk.com>
Reported-by: Dragos Tatulea <dtatulea@nvidia.com>
Closes: https://lore.kernel.org/all/982b9bc1-0a0a-4fc5-8e3a-3672db2b29a1@nvidia.com
Acked-by: Jakub Kicinski <kuba@kernel.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Acked-by: Harry Yoo (Oracle) <harry@kernel.org>
Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Brendan Jackman <jackmanb@google.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jesper Dangaard Brouer <hawk@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Mark Bloch <mbloch@nvidia.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Pavel Begunkov <asml.silence@gmail.com>
Cc: Saeed Mahameed <saeedm@nvidia.com>
Cc: Simon Horman <horms@kernel.org>
Cc: Stanislav Fomichev <sdf@fomichev.me>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Tariq Toukan <tariqt@nvidia.com>
Cc: Toke Hoiland-Jorgensen <toke@redhat.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:13 -07:00
Uladzislau Rezki (Sony)
04aa71da5f mm/vmalloc: do not trigger BUG() on BH disabled context
__get_vm_area_node() currently triggers a BUG() if in_interrupt() returns
true.  However, in_interrupt() also reports true when BH are disabled.

The bridge code can call rhashtable_lookup_insert_fast() with bottom
halves disabled:

__vlan_add()
 -> br_fdb_add_local()
  spin_lock_bh(&br->hash_lock); <-- Disable BH
   -> fdb_add_local()
    -> fdb_create()
     -> rhashtable_lookup_insert_fast()
      -> kvmalloc()
       -> vmalloc()
        -> __get_vm_area_node()
         -> BUG_ON(in_interrupt())
  spin_unlock_bh(&br->hash_lock)

this triggers the BUG() despite the caller not being in NMI or
hard IRQ context.

Replace the in_interrupt() check with in_nmi() || in_hardirq().

Link: https://lore.kernel.org/20260515153009.2296191-1-urezki@gmail.com
Fixes: c6307674ed ("mm: kvmalloc: add non-blocking support for vmalloc")
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Ido Schimmel <idosch@nvidia.com>
Reported-by: syzbot+8b12fc6e0fb139765b58@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/69ff8c7c.050a0220.1036b8.000b.GAE@google.com/
Reviewed-by: Baoquan He <baoquan.he@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:13 -07:00
Eugen Hristev
f0af98ff6b MAINTAINERS, mailmap: change email for Eugen Hristev
Replace old bouncing emails with ehristev@kernel.org

Link: https://lore.kernel.org/20260425-eh-mailmap-v1-1-58788d401eef@kernel.org
Signed-off-by: Eugen Hristev <ehristev@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:13 -07:00
Sunny Patel
2c6f81d587 mm/migrate_device: fix pgtable leak in migrate_vma_insert_huge_pmd_page
When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due
to a PMD check failure, the pgtable allocated earlier via
pte_alloc_one() is never freed, causing a memory leak.

Added free_abort label to release the pgtable in error path.

Link: https://lore.kernel.org/20260501115122.23288-1-nueralspacetech@gmail.com
Fixes: a30b48bf1b ("mm/migrate_device: implement THP migration of zone device pages")
Signed-off-by: Sunny Patel <nueralspacetech@gmail.com>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Huang Ying <ying.huang@linux.alibaba.com>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Balbir Singh <balbirs@nvidia.com>
Cc: Byungchul Park <byungchul@sk.com>
Cc: Gregory Price <gourry@gourry.net>
Cc: Joshua Hahn <joshua.hahnjy@gmail.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Rakie Kim <rakie.kim@sk.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:13 -07:00
Deepanshu Kartikey
09e7827e78 kernel/fork: validate exit_signal in kernel_clone()
When a child process exits, it sends exit_signal to its parent via
do_notify_parent().  The clone() syscall constructs exit_signal as:

(lower_32_bits(clone_flags) & CSIGNAL)

CSIGNAL is 0xff, so values in the range 65-255 are possible.  However,
valid_signal() only accepts signals up to _NSIG (64 on x86_64).  A
non-zero non-valid exit_signal acts the same as exit_signal == 0: the
parent process is not signaled when the child terminates.

The syzkaller reproducer triggers this by calling clone() with flags=0x80,
resulting in exit_signal = (0x80 & CSIGNAL) = 128, which exceeds _NSIG and
is not a valid signal.

The v1 of this patch added the check only in the clone() syscall handler,
which is incomplete.  kernel_clone() has other callers such as
sys_ia32_clone() which would remain unprotected.  Move the check to
kernel_clone() to cover all callers.

Since the valid_signal() check is now in kernel_clone() and covers all
callers including clone3(), the same check in copy_clone_args_from_user()
becomes redundant and is removed.  The higher 32bits check for clone3() is
kept as it is clone3() specific.

Note that this is a user-visible change: previously, passing an invalid
exit_signal to clone() was silently accepted.  The man page for clone()
does not document any defined behavior for invalid exit_signal values, so
rejecting them with -EINVAL is the correct behavior.  It is unlikely that
any sane application relies on passing an invalid exit_signal.

[oleg@redhat.com: the comment above kernel_clone() should be updated]
  Link: https://lore.kernel.org/abwvgU17W8wuW2-J@redhat.com
Link: https://lore.kernel.org/20260316151956.563558-1-kartikey406@gmail.com
Fixes: 3f2c788a13 ("fork: prevent accidental access to clone3 features")
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: syzbot+bbe6b99feefc3a0842de@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=bbe6b99feefc3a0842de
Tested-by: syzbot+bbe6b99feefc3a0842de@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/20260307064202.353405-1-kartikey406@gmail.com/T/ [v1]
Link: https://lore.kernel.org/all/20260316104536.558108-1-kartikey406@gmail.com/T/ [v2]
Acked-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Ben Segall <bsegall@google.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Liam Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:12 -07:00
Alexandre Ghiti
e16f17a9c5 mm: memcontrol: propagate NMI slab stats to memcg vmstats
flush_nmi_stats() drains per-node NMI slab atomics into the per-node
lruvec_stats, but does not propagate them to the memcg-level vmstats.

For non NMI case, account_slab_nmi_safe() calls mod_memcg_lruvec_state()
which updates both per-node lruvec_stats and memcg-level vmstats, so
flush_nmi_stats() needs to flush to per-node lruvec_stats as well as
memcg-level vmstats.

So fix this by flushing to the memcg-level vmstats for NMI too.

Link: https://lore.kernel.org/20260518082830.599102-1-alex@ghiti.fr
Fixes: 940b01fc8d ("memcg: nmi safe memcg stats for specific archs")
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:12 -07:00
SeongJae Park
441f92f7d3 mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()
DAMON sysfs maintains the DAMOS tried region directory objects via a
linked list.  When the user requests refresh of the directories, DAMON
sysfs removes all the region directories first, and then generate updated
regions directory on the empty space.  The removal function
(damon_sysfs_scheme_regions_rm_dirs()) only puts the kobj objects. 
Deletion of the container region object from the linked list is done
inside the kobj release callback function.

If somehow the callback invocation is delayed, the list will contain
regions list that gonna be freed.  If the updated region directories
creation is started in this situation, the list can be corrupted and
use-after-free can happen.

Because the kobj objects are managed by only DAMON sysfs, the issue cannot
happen in normal situation.  But, such delays can be made on kernels that
built with CONFIG_DEBUG_KOBJECT_RELEASE.  On the kernel, the issue can
indeed be reproduced like below.

    # damo start --damos_action stat
    # cd /sys/kernel/mm/damon/admin/kdamonds/0/
    # for i in {1..10}; do echo update_schemes_tried_regions > state; done
    # dmesg | grep underflow
    [   89.296152] refcount_t: underflow; use-after-free.

Fix the issue by removing the region object from the list when
decrementing the reference count.

Also update damos_sysfs_populate_region_dir() to add the region object to
the list only after the kobject_init_and_add() is success, so that fail of
kobject_init_and_add() is not leaving the deallocated object on the list.

The issue was discovered [1] by Sashiko.

Link: https://lore.kernel.org/20260518152559.93038-1-sj@kernel.org
Link: https://lore.kernel.org/20260513011920.119183-1-sj@kernel.org [1]
Fixes: 9277d0367b ("mm/damon/sysfs-schemes: implement scheme region directory")
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: <stable@vger.kernel.org> # 6.2.x
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:12 -07:00
Dev Jain
3f8968e9cb mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one
Initialize nr_pages to 1 at the start of each loop iteration, like
folio_referenced_one() does.

Without this, nr_pages computed by a previous folio_unmap_pte_batch() call
can be reused on a later iteration that does not run
folio_unmap_pte_batch() again.

mmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call
madvise(MADV_FREE), then make the last page device-exclusive via
HMM_DMIRROR_EXCLUSIVE.

Trigger node reclaim through sysfs.  Now, in try_to_unmap_one(), we will
first clear the first 15 out of 16 entries mapping the lazyfree folio. 
This will set nr_pages to 15.  In the next pvmw walk, this nr_pages gets
reused on a device-exclusive pte, thus potentially corrupting folio
refcount/mapcount.

At the moment, I have a userspace program which can make the kernel spit
out a trace, but the blow up is in folio_referenced_one(), because there
are existing bugs in the interaction between device-private and rmap
(which too I am investigating).  I did a one liner kernel change to avoid
going into folio_referenced_one(), and the kernel blows up at
folio_remove_rmap_ptes in try_to_unmap_one which is what I wanted.

Note that the bug is there not since file folio batching but lazyfree
folio batching, since device-exclusive only works for anonymous folios.

Userspace visible effect is simply kernel crashing somewhere due to
refcount/mapcount corruption.

Link: https://lore.kernel.org/20260518063656.3721056-1-dev.jain@arm.com
Fixes: 354dffd295 ("mm: support batched unmap for lazyfree large folios during reclamation")
Signed-off-by: Dev Jain <dev.jain@arm.com>
Acked-by: Barry Song <baohua@kernel.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Barry Song <baohua@kernel.org>
Cc: Dev Jain <dev.jain@arm.com>
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: Ryan Roberts <ryan.roberts@arm.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:12 -07:00
Richard Chang
bf62f69574 zram: fix use-after-free in zram_writeback_endio
A crash was observed in zram_writeback_endio due to a NULL pointer
dereference in wake_up.  The root cause is a race condition between the
bio completion handler (zram_writeback_endio) and the writeback task.

In zram_writeback_endio, wake_up() is called on &wb_ctl->done_wait after
releasing wb_ctl->done_lock.  This creates a race window where the
writeback task can see num_inflight become 0, return, and free wb_ctl
before zram_writeback_endio calls wake_up().

CPU 0 (zram_writeback_endio)     CPU 1 (writeback_store)
============================     ============================
                                 zram_writeback_slots
                                   zram_submit_wb_request
                                   zram_submit_wb_request
                                   wait_event(wb_ctl->done_wait)
spin_lock(&wb_ctl->done_lock);
list_add(&req->entry, &wb_ctl->done_reqs);
spin_unlock(&wb_ctl->done_lock);
wake_up(&wb_ctl->done_wait);
                                   zram_complete_done_reqs
spin_lock(&wb_ctl->done_lock);
list_add(&req->entry, &wb_ctl->done_reqs);
spin_unlock(&wb_ctl->done_lock);
                                   while (num_inflight) > 0)
                                     spin_lock(&wb_ctl->done_lock);
                                     list_del(&req->entry);
                                     spin_unlock(&wb_ctl->done_lock);
                                     // num_inflight becomes 0
                                     atomic_dec(num_inflight);

                                 // Leave zram_writeback_slots
                                 // Free wb_ctl
                                 release_wb_ctl(wb_ctl);
// UAF crash!
wake_up(&wb_ctl->done_wait);

This patch fixes this race by using RCU.  By protecting wb_ctl with
rcu_read_lock() in zram_writeback_endio and using kfree_rcu() to free it,
we ensure that wb_ctl remains valid during the execution of
zram_writeback_endio.

Link: https://lore.kernel.org/20260512074918.2606208-1-richardycc@google.com
Fixes: f405066a1f ("zram: introduce writeback bio batching")
Signed-off-by: Richard Chang <richardycc@google.com>
Suggested-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Suggested-by: Minchan Kim <minchan@kernel.org>
Acked-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Martin Liu <liumartin@google.com>
Cc: wang wei <a929244872@163.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:11 -07:00
Pratyush Yadav (Google)
3b041514cb memfd: deny writeable mappings when implying SEAL_WRITE
When SEAL_EXEC is added, SEAL_WRITE is implied to make W^X.  But the
implied seal is set after the check that makes sure the memfd can not have
any writable mappings.  This means one can use SEAL_EXEC to apply
SEAL_WRITE while having writeable mappings.

This breaks the contract that SEAL_WRITE provides and can be used by an
attacker to pass a memfd that appears to be write sealed but can still be
modified arbitrarily.

Fix this by adding the implied seals before the call for
mapping_deny_writable() is done.

Link: https://lore.kernel.org/20260505133922.797635-1-pratyush@kernel.org
Fixes: c4f75bc8bd ("mm/memfd: add write seals when apply SEAL_EXEC to executable memfd")
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> 
Acked-by: Jeff Xu <jeffxu@google.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Brendan Jackman <jackmanb@google.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Kees Cook <kees@kernel.org>
Cc: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:11 -07:00
Linpu Yu
fa0b9b2b7a ipc: limit next_id allocation to the valid ID range
The checkpoint/restore sysctl path can request the next SysV IPC id
through ids->next_id.  ipc_idr_alloc() currently forwards that request to
idr_alloc() with an open-ended upper bound.

If the valid tail of the SysV IPC id space is full, the allocation can
spill beyond ipc_mni.  The returned SysV IPC id still uses the normal
index encoding, so later lookup and removal can target the wrong slot. 
This leaves the real IDR entry behind and breaks the IDR state for the
object.

The bug is in ipc_idr_alloc() in the checkpoint/restore path.

1. ids->next_id is passed to:

       idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...)

2. The zero upper bound makes the allocation effectively open-ended.
   Once the valid SysV IPC tail is occupied, idr_alloc() can spill past
   ipc_mni and allocate an entry beyond the valid IPC id range.

3. The new object id is still encoded with the narrower SysV IPC index
   width:

       new->id = (new->seq << ipcmni_seq_shift()) + idx

4. Later removal goes through ipc_rmid(), which uses:

       ipcid_to_idx(ipcp->id)

   That truncates the real IDR index. An object actually stored at a
   high index can then be removed as if it lived at a low in-range
   index.

5. For shared memory, shm_destroy() frees the current object anyway, but
   the real high IDR slot is left behind as a dangling pointer.

6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry
   and dereferences freed memory.

Prevent this by bounding the requested allocation to ipc_mni so the
checkpoint/restore path fails once the valid range is exhausted.

Link: https://lore.kernel.org/cover.1778336914.git.linpu5433@gmail.com
Link: https://lore.kernel.org/2eebe949bfa7d1f6e13b5be6a92c64c850ce9d45.1778336914.git.linpu5433@gmail.com
Fixes: 03f5956680 ("ipc: add sysctl to specify desired next object id")
Signed-off-by: Linpu Yu <linpu5433@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Cc: Kees Cook <kees@kernel.org>
Cc: Stanislav Kinsbursky <skinsbursky@parallels.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:11 -07:00
Lorenzo Stoakes
83f9efcce9 Revert "mm/hugetlbfs: update hugetlbfs to use mmap_prepare"
This reverts commit ea52cb24cd ("mm/hugetlbfs: update hugetlbfs to use
mmap_prepare") with conflict resolution to account for changes in commit
ea52cb24cd ("mm/hugetlbfs: update hugetlbfs to use mmap_prepare").

The patch incorrectly handled hugetlb VMA lock allocation at the
mmap_prepare stage, where a failed allocation occurring after mmap_prepare
is called might result in the lock leaking.

There is no risk of a merge causing a similar issues, as
VMA_DONTEXPAND_BIT is set for hugetlb mappings.

As a first step in addressing this issue, simply revert the change so we
can rework how we do this having corrected the underlying issues.

We maintain the VMA flags changes as best we can, accounting for the fact
that we were working with a VMA descriptor previously and propagating
like-for-like changes for this.

Note that we invoke vma_set_flags() and do not call vma_start_write() as
vm_flags_set() does.  This is OK as it's being done in an .mmap hook where
the VMA is not yet linked into the tree so nobody else can be accessing
it.

Link: https://lore.kernel.org/20260512160643.266960-1-ljs@kernel.org
Fixes: ea52cb24cd ("mm/hugetlbfs: update hugetlbfs to use mmap_prepare")
Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reported-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Closes: https://lore.kernel.org/linux-mm/20260425070700.562229-1-25181214217@stu.xidian.edu.cn/
Acked-by: Muchun Song <muchun.song@linux.dev>
Acked-by: Oscar Salvador <osalvador@suse.de>
Cc: David Hildenbrand <david@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Pedro Falcato <pfalcato@suse.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:11 -07:00
Ian Ray
83ec6eeb74 MAINTAINERS: .mailmap: update after GEHC spin-off
Update my email address from @ge.com to @gehealthcare.com after GE
HealthCare was spun-off from GE.

Link: https://lore.kernel.org/20260506063335.3-1-ian.ray@gehealthcare.com
Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21 19:06:10 -07:00
Marco Elver
e90ef85ada nios2: Implement _THIS_IP_ using inline asm
Both GCC [1] and Clang [2] consider the generic version of _THIS_IP_ to
be broken:

        #define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here; })

In particular, the address of a label is only expected to be used with a
computed goto.

While the generic version more or less works today, it is known to be
brittle and may break with current and future optimizations. For
example, Clang -O2 always returns 1 when this function is inlined:

        static inline unsigned long get_ip(void)
        { return ({ __label__ __here; __here: (unsigned long)&&__here; }); }

Fix it by overriding _THIS_IP_ in <asm/linkage.h> (which is included by
<linux/instruction_pointer.h>) using an architecture-specific inline asm
version. Additionally, avoiding taking the address of a label prevents
compilers from emitting spurious indirect branch targets (e.g. ENDBR or
BTI) under control-flow integrity schemes.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120071 [1]
Link: https://github.com/llvm/llvm-project/issues/138272 [2]
Signed-off-by: Marco Elver <elver@google.com>
Reviewed-by: David Laight <david.laight.linux@gmail.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2026-05-21 18:50:46 -05:00
Simon Schuster
7734b168ca MAINTAINERS: arch/nios2: Add Simon Schuster as co-maintainer
Add Simon Schuster as a co-maintainer for the nios2 architecture and
mark it as supported.

Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2026-05-21 18:48:24 -05:00
Arnaldo Carvalho de Melo
6c1b9c1ed6 Merge remote-tracking branch 'torvalds/master' into perf-tools-next
Fixup clash of:

  552636b931 ("perf trace: Add beautifier script for fsmount flags")

That went via Namhyung upstream and the following ones in the
perf-tools-next tree:

  32969ef6e3 ("perf build: Pre-generate BPF skeleton tooling during umbrella prepare phase")
  537609924c ("perf trace beauty: Make beauty generated C code standalone .o files")

This complements f8d0db39bc ("perf build: Fix fsmount.o build")
sent by Ian Rogers.

Acked-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Ian Rogers <irogers@google.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Thorsten Leemhuis <linux@leemhuis.info>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-05-21 20:42:25 -03:00
ChenXiaoSong
4ec9c8e023 smb/server: promote S_DEL_ON_CLS to S_DEL_PENDING when close
Reproducer:

  1. server: systemctl start ksmbd
  2. client: mount -t cifs //${server_ip}/export /mnt
  3. client: C program: openat(AT_FDCWD, "/mnt", O_RDWR | O_TMPFILE, 0600)

Do not treat `FILE_DELETE_ON_CLOSE_LE` as delete pending while files
remain open.

This patch fixes xfstests generic/004.

Cc: stable@vger.kernel.org
Link: https://chenxiaosong.com/en/smb-xfstests-generic-004.html
Co-developed-by: Huiwen He <hehuiwen@kylinos.cn>
Signed-off-by: Huiwen He <hehuiwen@kylinos.cn>
Signed-off-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
Tested-by: Steve French <stfrench@microsoft.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
2026-05-21 18:20:24 -05:00
Junyi Liu
69f030cf95 ksmbd: validate SID in parent security descriptor during ACL inheritance
Introduce smb_validate_ntsd_sid() helper to safely validate Owner SID
and Group SID inside the NT Security Descriptor (smb_ntsd) retrieved
from the parent directory.

Cc: stable@vger.kernel.org
Signed-off-by: Junyi Liu <moss80199@gmail.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
2026-05-21 18:18:49 -05:00
Junyi Liu
3515503322 ksmbd: fix durable reconnect error path file lifetime
After a durable reconnect succeeds, ksmbd_reopen_durable_fd() republishes
the same ksmbd_file into the session volatile-id table. If smb2_open()
then takes a later error path, cleanup first calls ksmbd_fd_put(work, fp)
and then unconditionally calls ksmbd_put_durable_fd(dh_info.fp).

In this case fp and dh_info.fp are the same object. The first put drops the
reconnect lookup reference, but the final durable put can run
__ksmbd_close_fd(NULL, fp). Because the final close is not session-aware,
it can free the file object without removing the volatile-id entry that was
just published into the session table.

Use the session-aware put for the final reconnect drop when the reconnect
had already succeeded and the error path is cleaning up the republished
file. Earlier reconnect failures, before fp is assigned to dh_info.fp, keep
using the durable-only put path.

Fixes: 1baff47b81 ("ksmbd: fix use-after-free in smb2_open during durable reconnect")
Signed-off-by: Junyi Liu <moss80199@gmail.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
2026-05-21 18:18:49 -05:00
Manivannan Sadhasivam
462a85f9f8 soc: qcom: ice: Fix the error code when 'qcom,ice' property is not found
When both 'ice' reg entry and 'qcom,ice' property are not found in DT, then
it implies that ICE is not supported. So return -EOPNOTSUPP instead of
-ENODEV to client drivers to specify ICE functionality is not supported.

Fixes: b9ab7217dd ("soc: qcom: ice: Return proper error codes from devm_of_qcom_ice_get() instead of NULL")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Closes: https://lore.kernel.org/linux-arm-msm/8bac0358-9da0-4cbb-98ee-333b85ba4908@samsung.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260520155704.130803-1-manivannan.sadhasivam@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 18:18:44 -05:00
Chancel Liu
caa7a37118
ASoC: dt-bindings: imx-card: Complete the full list of supported DAI formats
Currently this binding only lists i2s and dsp_b formats that are used
by existing sound cards. However, DT bindings should describe the full
hardware capabilities rather than only the formats of current usage.

The SAI audio controller of i.MX audio sound card supports multiple DAI
formats, including:
  - i2s
  - left_j
  - right_j
  - dsp_a
  - dsp_b
  - pdm
  - msb
  - lsb

Complete the full list of formats supported by i.MX audio sound card to
ensure the binding correctly describes hardware.

Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260331012450.1298115-1-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:18:19 +01:00
Peter Ujfalusi
6320b64451
ASoC: SOF: ipc4-topology: Print for format type in dbg_audio_format
8 and 32 bit formats can have different types, print them in debug
information to have complete view of the supported formats.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260520150204.18303-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:17:59 +01:00
Mark Brown
4c433607b6
ASoC: cs35l56: Replace open-coded SoundWire regmap with generic regmap-sdw
Richard Fitzgerald <rf@opensource.cirrus.com> says:

This series replaces the entirely custom SoundWire regmap with the generic
regmap-sdw. The reasons for doing this are:

- Avoid code duplication
- Avoid effort of keeping custom implementation up-to-date
- Prepare for supporting BRA

Link: https://patch.msgid.link/20260521115420.978616-1-rf@opensource.cirrus.com
2026-05-22 00:17:14 +01:00
Richard Fitzgerald
4e2310f14a
ASoC: cs35l56: Use standard SoundWire regmap implementation
Use the regmap_sdw implementation for SoundWire instead of
re-implementing the low-level bus transactions in cs35l56-sdw.c

The cs35l56 registers are big-endian on I2C and SPI but little-endian
over SoundWire. The firmware files are all big-endian and contain opaque
blobs in big-endian order. So these must be endian-swapped to transfer
over SoundWire. A custom regmap bus implementation is used to do this
endian-swapping.

The original implementation of this custom regmap bus was a complete bus
backend, performing the endian swapping and low-level SoundWire bus
read/write.

This commit changes the custom regmap bus to only perform the endian-swap.
It uses an underlying simple uncached regmap_sdw bus to deal with
transferring the 32-bit registers over the SoundWire bus. Although this
adds a small amount of overhead, from passing through the regmap APIs
twice, it avoids having a local duplicate implementation of what regmap_sdw
already does.

The slow-read handling for OTP registers must access 8-bit SoundWire
registers so it still uses low-level SoundWire bus reads.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260521115420.978616-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:17:13 +01:00
Richard Fitzgerald
371d1e3a01
ASoC: cs35l56: Use reg_base to offset addresses on SoundWire
Set the reg_base member of regmap_config for SoundWire so that
the regmap core will apply the 0x8000 offset to addresses, instead
of doing it within our low-level regmap read/write callbacks.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260521115420.978616-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:17:12 +01:00
Richard Fitzgerald
cb9a52b3ab
ASoC: cs35l56-shared-test: Subtract reg_base offset in dummy regmap
Subtract the value of cs35l56 regmap_config->reg_base from addresses
passed into the mock regmap bus.

Chip register addresses transferred over SoundWire are offset by 0x8000
to move them after the address range reserved in the SoundWire spec.

This commit prepares for changing the cs35l56-sdw driver to use
regmap_config->reg_base to add this offset. When that is done the
addresses passed into the mock regmap_bus will include this offset.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260521115420.978616-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:17:11 +01:00
Mark Brown
7d28d5ce83
ASoC: SOF: Intel: Enable offload for UAOL for LNL+
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:

The USB Audio Offload (UAOL) can only be used from the DSP side and
on Lunar Lake (ACE2) and newer platforms the access to it's register
space must be granted by the host, just like for SSP or DMIC.

This series enable the offload for UAOL for LNL or newer devices.

Link: https://patch.msgid.link/20260520150639.25301-1-peter.ujfalusi@linux.intel.com
2026-05-22 00:16:33 +01:00
Peter Ujfalusi
fdfbd9ff86
ASoC: SOF: Intel: lnl: Enable offload for UAOL link
The handling of UAOL (USB Audio Offload Link) is similar to SSP and DMIC,
it is handled by the DSP firmware.
Set the offload enable for it similar to SSP and DMIC.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20260520150639.25301-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:16:32 +01:00
Peter Ujfalusi
978152b2ca
ASoC: SOF: Intel: hda-mlink/lnl: Convert offload enable functions to void
hdac_bus_eml_enable_offload() can only fail in case the IP is not enabled
in the platform, which is not really an error as the ACE IP can be
configured differently when integrated into a specific SoC.

While it is unlikely, but it is a valid configuration that for example the
DMIC is disabled.
In this case we will just skip setting the offload for a link that is not
present.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20260520150639.25301-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:16:31 +01:00
Mark Brown
75b992accc
ASoC: AMD: ACP7.x initial PCI driver bring-up
Vijendar Mukunda <Vijendar.Mukunda@amd.com> says:

This series adds initial AMD ACP 7.x support for ACP7.D / 7.E / 7.F
platforms.

Compared to earlier ACP generations, ACP7.x includes substantial design
changes, including an updated register set/layout. For that reason,
the ACP7.x implementation is placed under a separate sound/soc/amd/acp7x/
directory instead of extending older-generation code paths,
keeping ACP7.x-specific logic and register definitions cleanly separated
and easier to maintain.

This initial version is intentionally focused on the core PCI driver
bring-up: register definitions, probe/remove, basic helper wiring, and
system sleep + runtime PM integration. A follow-up series will add support
for additional Audio I/O blocks, including SoundWire and the ACP PDM
controller.

The primary goal of this series is to unblock power validation, since the
ACP IP currently does not have a driver available with PM ops support on
these platforms.

Link: https://patch.msgid.link/20260507181251.20594-1-Vijendar.Mukunda@amd.com
2026-05-22 00:15:05 +01:00
Vijendar Mukunda
07d56a83ba
ASoC: amd: acp7x: add system and runtime PM ops
Add ACP7.x PM callbacks and hook up system sleep and runtime PM ops for
the PCI driver.

Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260507181251.20594-6-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:15:04 +01:00
Vijendar Mukunda
533308171b
ASoC: amd: enable acp7.x drivers build
ACP7.x drivers can be built by selecting necessary
kernel config option.
The patch enables build support of the same.

Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260507181251.20594-5-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:15:03 +01:00
Vijendar Mukunda
b5a2fdc5e7
ASoC: amd: acp7x: add helper functions and hw ops
Add ACP7.x init/deinit helper routines and wire up PCI hw ops for
ACP7.D/7.E/7.F variants.

Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260507181251.20594-4-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:15:02 +01:00
Vijendar Mukunda
1da6f798ed
ASoC: amd: acp7x: add ACP PCI driver probe/remove sequence
Add ACP7.x PCI driver probe and remove sequence for ACP7.D/7.E/7.F
variants.

Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260507181251.20594-3-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:15:01 +01:00
Vijendar Mukunda
44d16948af
include: sound: add register header file for acp7.x series
Add acp register header file for ACP7.x(7.D/7.E/7.F) variants.

Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://patch.msgid.link/20260507181251.20594-2-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-22 00:15:00 +01:00
Jakub Kicinski
1a1f055318 Not much going on here right now:
- mac80211/hwsim:
    - some NAN related things
    - MCS/NSS rate issues with S1G
  - p54: port SPI version to device-tree
  - (a few other random things)
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmoPJbIACgkQ10qiO8sP
 aAAaPw/+N1dZbDbayDy2sA9oniqpiCJEWspfaK3fnkh1qdpit84tGxEbZtCUIeNB
 WYsvvce25qNifWH+xSoma0v+F70eLdlWf6cvjL+dtpf3ITX9HkL055vRtpR+t+vL
 /hTtLL8q4OXdu4I/UuCw47ftXzV2zPcHh3+VQK1uR0aM3kXpJhewCAYC3TY1tDVe
 +YiUynbidG/893sGnXPG0KMDT92TF/N6sIQLcVw7Yn3d+GjPPP1M0W89FfZzCO5+
 ngi529r4VQ8z/XDAWUFzK8SzCNbaVqZtAZt0/NuhfCWOCIXq76qYkJq3L4MxMQRg
 MPHDkgKQI5cZB6/zHq1DEdhEcu8f0zo7gTFnSrXbq4I3DkYVpFaOo9JVjcHLKE9f
 O6M4fr/a59Zi/jMFPvGDuSItOrR4fERD9H9y+U0DmV6fk4PxXYgE7qWcWDdHdKeD
 rtwp5FUHrNZxujKvxR2CPzW0JfCh4IZnb4IFLgloGI79SBJ6JL4WgriHavKGCihq
 7JDo3TEn1oh9hcbIytXIZ6ZD8PkGZk93f7HeRuCSDo27SfLOvAR0KKpC1opX0zQw
 dWEbTpz4jhmgskb0SM8BmuD+XxhNHPojzMmPdyjtrA7pDRfZfM255/F5++etmgQm
 ToS93CEPU4rCZsy7O2NoLQGVZSfXc2y5fCZwTJoBZdUDYRviG7A=
 =XLqG
 -----END PGP SIGNATURE-----

Merge tag 'wireless-next-2026-05-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next

Johannes Berg says:

====================
Not much going on here right now:
 - mac80211/hwsim:
   - some NAN related things
   - MCS/NSS rate issues with S1G
 - p54: port SPI version to device-tree
 - (a few other random things)

* tag 'wireless-next-2026-05-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next:
  ARM: dts: omap2: add stlc4560 spi-wireless node
  p54spi: convert to devicetree
  dt-bindings: net: add st,stlc4560/p54spi binding
  wifi: mac80211: allow cipher change on NAN_DATA interfaces
  wifi: mac80211_hwsim: Do not declare NAN support for Extended Key ID
  wifi: cfg80211: add a function to parse UHR DBE
  wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed
  wifi: mac80211: Allow per station GTK for NAN Data interfaces
  wifi: mac80211_hwsim: advertise NPCA capability
  wifi: mac80211_hwsim: reject NAN on multi-radio wiphys
  wifi: plfxlc: use module_usb_driver() macro
  wifi: mac80211: don't recalc min def for S1G chan ctx
  wifi: mac80211: skip NSS and BW init for S1G sta
  wifi: mac80211: check stations are removed before MLD change
  wifi: rt2x00: allocate anchor with rt2x00dev
====================

Link: https://patch.msgid.link/20260521153519.380276-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-21 16:00:06 -07:00
Dave Airlie
4378a41165 Mediatek DRM Fixes - 20260521
1. fix sparse warnings
 -----BEGIN PGP SIGNATURE-----
 
 iQJMBAABCgA2FiEEACwLKSDmq+9RDv5P4cpzo8lZTiQFAmoPDQ4YHGNodW5rdWFu
 Zy5odUBrZXJuZWwub3JnAAoJEOHKc6PJWU4kV/4P/jP1tA6eV70SWEJ1UqJYULua
 ZUV2N+GT28mjjY653cXTZtWEC7JPGZXtGfJ8PoY9iF0EOtI0VgJ9uJySlIGOWASV
 uqN4GB5UKX//GD1qdD0BU7VT5YP75qTSNNrmgdrpq4z4kiffzClvuUIasic6gwSu
 pz2m8ngH79x330x2X70Lyu4YCYjfZwVCkl4410c8ZEWUf0nRgcIQxOqXUqH+P+52
 oouKk5kxFBekFV8fIK7O4Xtb2l8jjLChn4dK8RCgT7PQzR5BE3ergeCxsMLoh3SK
 LF6JHFkqiXaZNo8ixrIYIilq5A7dBD0POJqW2nF7fbMXLsIMSNndHxsa6Ec5hjdL
 Wxlb4DFKkIwfRhSNNV7DjrvtyomJ/0sQVzT/VyCMTKsZfvQC+qP4UgZNWpBv//6A
 q+0/y8zIpwsL5b5B3+OxIihbnVLOhHFlrbzN3bbJt9VpOeuitt8j9RyYiLWWtQwa
 9rggJD4F4UW2U3mhD28R5hz5dtRfHTfbZh1Use+7mJbxWDcH4TDbH4gJxuhCxCJM
 0xHQTagk02FUCj/mARhoYz3thl7db/uEqT7IP5LgXIXjlUn4wuzdhtqVbs9pq2+3
 bk9QuXiNHramvREw6n90F7jzRnZHsenZJDibMZl2awuiHMCakfMuca/RTM1ZIN6T
 +Bgek2y0ZftKr4StOdJd
 =ODxK
 -----END PGP SIGNATURE-----

Merge tag 'mediatek-drm-fixes-20260521' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes

Mediatek DRM Fixes - 20260521

1. fix sparse warnings

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://patch.msgid.link/20260521135649.4681-1-chunkuang.hu@kernel.org
2026-05-22 08:31:08 +10:00
Ritesh Kumar
4bd073e00f arm64: dts: qcom: lemans: Add eDP ref clock for eDP PHYs
The eDP PHY nodes on lemans were missing the reference clock voting.
This initially went unnoticed because the clock was implicitly enabled
by the UFS PHY driver, and the eDP PHY happened to rely on that.

After commit 77d2fa54a9 ("scsi: ufs: qcom : Refactor phy_power_on/off
calls"), the UFS driver no longer keeps the reference clock enabled.
As a result, the eDP PHY fails to power on.

To fix this, add eDP reference clock for eDP PHYs on lemans chipset
ensuring reference clock is enabled.

Fixes: e1e3e5673f ("arm64: dts: qcom: sa8775p: add DisplayPort device nodes")
Signed-off-by: Ritesh Kumar <quic_riteshk@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260128114853.2543416-3-quic_riteshk@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-21 17:22:45 -05:00