Marc Zyngier [Wed, 20 May 2026 09:19:34 +0000 (10:19 +0100)]
KVM: arm64: vgic-v5: Remove use of __assign_bit() with a constant
Using __assign_bit() is very useful when the value of the bit is
not known at compile time. In all other cases, __set_bit() and
__clear_bit() are the correct tool for the job.
This also fixes an odd case of using VGIC_V5_NR_PRIVATE_IRQS as
the bit value...
usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize
The USB488 subclass specification requires interrupt wMaxPacketSize to
be 0x02, unless the device sends vendor-specific notifications.
Endpoints that advertise less than 2 bytes for wMaxPacketSize are
unlikely to work with the current driver, as URBs will not have enough
space for interrupt headers. Considering that any notification URBs will
be ignored by the driver, reject these endpoints early during probe.
usb: usbtmc: check URB actual_length for interrupt-IN notifications
USBTMC devices can use an optional interrupt endpoint for notification
messages. These typically contain two-byte headers indicating the
payload format, but the driver does not check if these headers are
present before accessing the data buffers. In cases where the URB
actual_length is not enough to fit these headers, the driver will either
cause an out-of-bounds read, or consume stale leftover data from a
previous notification.
Fix by checking if actual_data contains enough bytes for the headers,
otherwise resubmit URB to the interrupt endpoint.
Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.") Reported-by: syzbot+abbfd103085885cf16a2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=abbfd103085885cf16a2 Cc: stable <stable@kernel.org> Suggested-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Heitor Alves de Siqueira <halves@igalia.com> Link: https://patch.msgid.link/20260505-usbtmc-iin-size-v3-1-a36113f62db7@igalia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei-Cheng Chen [Tue, 5 May 2026 11:26:30 +0000 (19:26 +0800)]
xhci: tegra: Fix ghost USB device on dual-role port unplug
When a USB device is unplugged from the dual-role port, the device-mode
path in tegra_xhci_id_work() explicitly clears both SS and HS port power
via direct hub_control ClearPortFeature(POWER) calls. This preempts the
xHCI controller's normal disconnect processing -- PORT_CSC is never
generated, the USB core never sees the disconnect, and the device remains
in its internal tree as a ghost visible in lsusb.
Add an otg_set_port_power flag to control whether the dual-role switch
path performs explicit port power management. SoCs that need it
(Tegra124 / Tegra210 / Tegra186) set the flag; later SoCs (Tegra194 and
beyond) rely on the PHY mode change to handle disconnect naturally and
skip all port power calls.
Within the port power path, otg_reset_sspi additionally gates the SSPI
reset sequence on host-mode entry for SoCs that require it.
Flags set per SoC:
Tegra124, Tegra186 -> otg_set_port_power
Tegra210 -> otg_set_port_power, otg_reset_sspi
Tegra194 and later -> (none)
Kai Aizen [Thu, 30 Apr 2026 17:56:43 +0000 (20:56 +0300)]
usb: gadget: uvc: hold opts->lock across XU walks in uvc_function_bind
uvc_function_bind() walks &opts->extension_units twice without holding
opts->lock:
- directly, for the iExtension string-descriptor fixup loop;
- indirectly, four times via uvc_copy_descriptors() (once per speed),
where the helper iterates uvc->desc.extension_units (which aliases
&opts->extension_units) to size and emit XU descriptors.
The configfs side (uvcg_extension_make / uvcg_extension_drop, in
drivers/usb/gadget/function/uvc_configfs.c) takes opts->lock around its
list_add_tail / list_del operations. A privileged userspace process
that holds the configfs subtree open and writes the gadget UDC name
to bind the function while concurrently rmdir()'ing an extensions
subdir can race uvcg_extension_drop() against the bind-time list walks
and dereference a freed struct uvcg_extension.
Hold opts->lock from the start of the XU string-descriptor fixup
through the last uvc_copy_descriptors() call, releasing on the
descriptor-error path via a new error_unlock label that drops the
lock before falling through to the existing error label. This
matches the locking discipline of the configfs callbacks and removes
the only remaining unsynchronised reader of the XU list during bind.
Reachability: only privileged processes that can mount configfs and
write to gadget UDC files can trigger the race, so this is a
correctness fix rather than a security boundary.
Fixes: 0525210c9840 ("usb: gadget: uvc: Allow definition of XUs in configfs") Cc: stable <stable@kernel.org> Signed-off-by: Kai Aizen <kai.aizen.dev@gmail.com> Link: https://patch.msgid.link/20260430175643.67120-1-kai.aizen.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guangshuo Li [Mon, 27 Apr 2026 15:36:51 +0000 (23:36 +0800)]
usb: gadget: net2280: Fix double free in probe error path
usb_initialize_gadget() installs gadget_release() as the release
callback for the embedded gadget device. The struct net2280 instance is
therefore released through gadget_release() when the gadget device's last
reference is dropped.
The probe error path calls net2280_remove(), which tears down the
partially initialized device and drops the gadget reference with
usb_put_gadget(). Calling kfree(dev) afterwards can free the same object
again.
Drop the explicit kfree() and let the gadget device release callback
handle the final free. This issue was found by a static analysis tool
I am developing.
Guangshuo Li [Mon, 13 Apr 2026 14:21:19 +0000 (22:21 +0800)]
usb: gadget: f_hid: fix device reference leak in hidg_alloc()
hidg_alloc() initializes hidg->dev with device_initialize() before
calling dev_set_name(). If dev_set_name() fails, the function currently
jumps to err_unlock and returns without calling put_device().
This leaves the device reference unbalanced and prevents hidg_release()
from being called. Calling put_device() here is also safe, since
hidg_release() only frees resources owned by hidg.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Route the dev_set_name() failure path through err_put_device so the
device reference is dropped properly.
Fixes: 89ff3dfac604 ("usb: gadget: f_hid: fix f_hidg lifetime vs cdev") Cc: stable <stable@kernel.org> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Johan Hovold johan@kernel.org Link: https://patch.msgid.link/20260413142119.2977716-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: musb: omap2430: Fix use-after-free in omap2430_probe()
In omap2430_probe(), of_node_put(np) is called prematurely before the
last access to np, leading to a use-after-free if the node's reference
count drops to zero. Move the of_node_put() calls after the last use of
np in both the success and error paths.
Georgi Djakov [Fri, 22 May 2026 07:41:01 +0000 (10:41 +0300)]
Merge branch 'icc-misc' into icc-next
* icc-misc
interconnect: Do not create empty devres on missing interconnects
interconnect: Move MODULE_DEVICE_TABLE next to the table itself
dt-bindings: interconnect: qcom,sdm660: Disallow clocks when appropriate
dt-bindings: interconnect: qcom,sm6115: Drop incorrect children if:then: block
dt-bindings: interconnect: qcom,sm6115: Restrict children and clocks
interconnect: qcom: Fix indentation
interconnect: qcom: Restrict drivers per ARM/ARM64
The ESP out-of-place fast path appends the trailer in esp_output_head()
before esp_output_tail() allocates the destination page frag. The
head-side gate currently checks skb->data_len and tailen separately, but
the tail code allocates a single destination frag from the combined
post-trailer skb->data_len.
Reject the page-frag fast path when the combined aligned length exceeds a
page. Otherwise skb_page_frag_refill() may fall back to a single page while
the destination sg still spans the combined skb->data_len.
Restore this combined-length page gate for both IPv4 and IPv6.
Fixes: 5bd8baab087d ("esp: limit skb_page_frag_refill use to a single page") Cc: stable@vger.kernel.org Signed-off-by: Lin Ma <malin89@huawei.com> Signed-off-by: Chenyuan Mi <michenyuan@huawei.com> Signed-off-by: Jingguo Tan <tanjingguo@huawei.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
e521588 [Wed, 20 May 2026 07:27:17 +0000 (09:27 +0200)]
esp: fix page frag reference leak on skb_to_sgvec failure
In esp_output_tail(), when esp->inplace is false, the old skb page frags
are replaced with a new page from the xfrm page_frag cache. The source
scatterlist (sg) is built from the old frags before the replacement, and
esp_ssg_unref() is responsible for releasing the old page references
after the crypto operation completes.
However, if the second skb_to_sgvec() call (which builds the destination
scatterlist from the new page) fails, the code jumps to error_free which
only calls kfree(tmp). The old page frag references captured in the
source scatterlist are never released:
1. sg[] is built from old frags via skb_to_sgvec() (no extra get_page)
2. nr_frags is set to 1 and frag[0] is replaced with the new page
3. Second skb_to_sgvec() fails -> goto error_free
4. kfree(tmp) frees the sg[] memory but old frags are not unref'd
5. kfree_skb() only releases frag[0] (the new page), not the old ones
Fix this by adding a bool parameter to esp_ssg_unref() that, when true,
unconditionally unrefs the source scatterlist frags without checking
req->src and req->dst, since those fields are not yet initialized by
aead_request_set_crypt() at the point of the error. Existing callers
pass false to preserve the original behavior.
The same issue exists in both esp4 and esp6 as the code is identical.
Bibo Mao [Fri, 22 May 2026 07:05:12 +0000 (15:05 +0800)]
LoongArch: KVM: Move some variable declarations to paravirt.h
Some variables relative with paravirt feature are declared in the header
file asm/qspinlock.h, however this file can be included only when option
CONFIG_SMP is on. There is compiling warnings if CONFIG_SMP is off since
variables are not declared.
Move these variable declarations to header file asm/paravirt.h to avoid
compiling warnings.
Fixes: c43dce6f13fb ("LoongArch: KVM: Make vcpu_is_preempted() as a macro rather than function") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605061313.O8Hswm2b-lkp@intel.com/ Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Tiezhu Yang [Fri, 22 May 2026 07:05:07 +0000 (15:05 +0800)]
LoongArch: kprobes: Fix handling of fatal unrecoverable recursions
KPROBE_HIT_SS and KPROBE_REENTER are two types of fatal recursions that
can not be safely recovered in kprobes.
KPROBE_HIT_SS means that a kprobe is hit during single-stepping. At
this point, the architecture-specific single-step context is already
active. Nested single-stepping would corrupt the state, as the kprobe
control block (kcb) and hardware registers cannot safely store multiple
levels of stepping state.
KPROBE_REENTER means that a third-level recursion occurs when a probe
is hit while the system is already handling a nested probe (second-
level). The kcb only provides a single slot (prev_kprobe) to backup the
state. When a third probe is hit, there is no more space to save the
state without corrupting the first-level backup.
Kprobes work by replacing instructions with breakpoints. In order to
execute the original instruction and continue, it must be moved to a
temporary "single-step" slot. Since there is no backup space left to
set up this slot safely, the CPU would be forced to return to the same
original breakpoint address, triggering an endless loop.
Currently, the code only prints a warning and returns. This leads to
an infinite re-entry loop as the CPU repeatedly hits the same trap and
a "stuck" CPU core because preemption was disabled at the start of the
handler and never re-enabled in this early return path.
Fix the logic by:
1. Merging KPROBE_HIT_SS and KPROBE_REENTER cases, as both represent
fatal recursions that cannot be safely recovered.
2. Replacing WARN_ON_ONCE() with BUG() to terminate the system. This
aligns LoongArch with other architectures (x86, arm64, riscv) and
prevents stack overflow while providing diagnostic information.
Tiezhu Yang [Fri, 22 May 2026 07:05:07 +0000 (15:05 +0800)]
LoongArch: kprobes: Use larch_insn_text_copy() to patch instructions
On SMP systems, kprobe handlers would occasionally fail to execute on
certain CPU cores. The issue is hard to reproduce and typically occurs
randomly under high system load.
The root cause is a software-side instruction hazard. According to the
LoongArch Reference Manual, while the cache coherency is maintained by
hardware, software must explicitly use the "IBAR" instruction to ensure
the instruction fetch unit (IFU) observes the effects of recent stores.
The current arch_arm_kprobe() and arch_disarm_kprobe() only execute the
"IBAR" barrier (via flush_insn_slot -> local_flush_icache_range) on the
local CPU. This leaves a vulnerable window where remote CPU cores may
continue executing stale instructions from their pipelines or prefetch
buffers, as they have not executed an "IBAR" since the code modification.
Switch to larch_insn_text_copy() to fix this:
1. Synchronization: It uses stop_machine_cpuslocked() to synchronize all
online CPUs, ensuring no CPU is executing the target code area during
modification.
2. Visibility: By passing cpu_online_mask to stop_machine_cpuslocked(),
the callback text_copy_cb() is executed on all online cores. Each CPU
core invokes local_flush_icache_range() to execute "IBAR", clearing
instruction hazards system-wide and ensuring the "break" instruction
is visible to the fetch units of all cores.
3. Robustness: It properly manages memory write permissions (ROX/RW) for
the kernel text segment during patching, ensuring compatibility with
CONFIG_STRICT_KERNEL_RWX.
Lad Prabhakar [Tue, 19 May 2026 16:08:25 +0000 (17:08 +0100)]
drm: renesas: rz-du: Add support for RZ/T2H SoC
The RZ/T2H (R9A09G077) SoC includes a DU with a DPI interface,
supporting resolutions up to WXGA with two RPFs for layer blending.
Unlike earlier RZ/G2L SoCs, RZ/T2H requires explicit assertion of a
DPI output-enable signal (DU_MCR0_DPI_EN) during CRTC startup.
Lad Prabhakar [Tue, 19 May 2026 16:08:24 +0000 (17:08 +0100)]
drm: renesas: rz-du: Move mode_valid logic to per-SoC clock limits
Move pixel clock validation from a fixed encoder check to per SoC
constraints stored in rzg2l_du_device_info.
Pixel clock limits differ across SoCs in the RZ DU family and cannot be
expressed by a single shared rule. For example, RZ/G2UL and RZ/G2L limit
the DPAD0 pixel clock to a narrow window, while other SoCs such as
RZ/T2H require a wider operating range.
Add mode_clock_min and mode_clock_max fields to rzg2l_du_device_info to
describe the supported pixel clock range for each SoC. Update
rzg2l_du_encoder_mode_valid() to check these bounds when evaluating
DPAD0 outputs, returning MODE_CLOCK_LOW when the pixel clock falls
below mode_clock_min and MODE_CLOCK_HIGH when it exceeds mode_clock_max.
Populate the pixel clock limits for both the RZ/G2UL (R9A07G043U) and
RZ/G2L (R9A07G044) variants to a minimum of 20875 kHz and a maximum of
83500 kHz.
Takashi Iwai [Fri, 22 May 2026 06:25:18 +0000 (08:25 +0200)]
Merge tag 'asoc-fix-v7.1-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.1
A bigger batch of fixes than usual due to -next not happeing last week,
this is mostly stuff for laptops - a lot of quirks and small fixes,
mainly for x86 and SoundWire. Nothing too big or exciting individually,
just two week's worth.
Lad Prabhakar [Tue, 19 May 2026 16:08:23 +0000 (17:08 +0100)]
drm: renesas: rz-du: Make DU reset control optional for RZ/T2H support
Update the DU CRTC initialisation to request the reset control using
devm_reset_control_get_optional_shared(). On RZ/T2H SoCs the DU block does
not expose a reset line, and treating the reset as mandatory prevents the
driver from probing on those platforms.
Lad Prabhakar [Tue, 19 May 2026 16:08:22 +0000 (17:08 +0100)]
dt-bindings: display: renesas,rzg2l-du: Add RZ/T2H and RZ/N2H support
Document the Display Unit (DU) support for the RZ/T2H and RZ/N2H SoCs.
The DU block on RZ/T2H is functionally equivalent to the RZ/G2UL DU and
supports the DPI interface, but includes SoC-specific register differences
and has no reset control. Add a dedicated compatible string to represent
this variant and update the allOf constraints accordingly.
As the DU implementation on RZ/N2H matches RZ/T2H, describe it using an
RZ/N2H specific compatible string with the RZ/T2H compatible as fallback.
Feng Tang [Tue, 12 May 2026 08:55:09 +0000 (16:55 +0800)]
dma-contiguous: add kconfig option to setup numa cma area if not configured explicitly
There was a report on a multi-numa-nodes arm64 server that when IOMMU
is disabled, the dma_alloc_coherent() function always returns memory
from node 0 even for devices attaching to other nodes, while they can
get local dma memory when IOMMU is on with the same API.
The reason is, when IOMMU is disabled, the dma_alloc_coherent() will
go the direct way and call dma_alloc_contiguous(). The system doesn't
have any explicit cma setting (like per-numa cma), and only has a
default 64MB cma reserved area (on node 0), where kernel will try
first to allocate memory from.
Robin Murphy suggested to setup pernuma cma or disable cma, which did
solve the issue. While there is still concern that for customers
which don't have much kernel knowledge, they could still suffer from
this silently as some architectures enable cma area by default (not
an issue for X86 though, which set CONFIG_CMA_SIZE_MBYTES to 0 by
default) for most Linux distributions.
One thought is to follow the current cma reserving policy for platform
with 'CONFIG_DMA_NUMA_CMA=y', that if the numa cma (either the 'numa cma'
or 'cma pernuma' method) is not explicitly configured, and the platform
really has multiple NUMA nodes, set it up according to size of default
'dma_contiguous_default_area'. This way, the default behavior of
platform with one NUMA node is kept unchanged (say embedded/small
devices don't need to allocate extra memory), while the general dma
locality is improved.
Add a new bool kernel config CONFIG_CMA_SIZE_PERNUMA to control whether
to enable it. Even when the config is enabled, user can still disable
it by kernel-cmdline setting like "numa_cma=0:0" or "cma_pernuma=0".
Reported-by: Changrong Chen <chenchangrong.ccr@alibaba-inc.com> Suggested-by: Ying Huang <ying.huang@linux.alibaba.com> Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com> Link: https://lore.kernel.org/r/20260512085509.83002-1-feng.tang@linux.alibaba.com Link: https://lore.kernel.org/all/20260520222742.GA1607511@ax162/
[mszyprow: squashed changes from both links, added __initdata attribute
to the numa_cma_configured variable] Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Richard Acayan [Wed, 13 May 2026 17:25:49 +0000 (13:25 -0400)]
arm64: dts: qcom: add support for pixel 3a xl with the tianma panel
The Pixel 3a XL has variants with either a Samsung Display Controller (SDC)
panel or a Tianma panel. Add the device tree for the variant with the
Tianma panel.
Richard Acayan [Wed, 13 May 2026 17:25:48 +0000 (13:25 -0400)]
arm64: dts: qcom: sdm670-google: add common device tree include
The Pixel 3a XL can be supported by reusing most of the device tree from
the Pixel 3a. Move the common elements to a common device tree include
like with other devices.
Since the original devicetree should only specify non-XL properties, it
needs to be completely rewritten. Also change the SPDX license
identifier from GPL-2.0 (which was deprecated as it can be
misinterpreted as GPLv2 or later) into GPL-2.0-only.
arm64: dts: qcom: monaco-arduino-monza: Add Bluetooth UART node
The QCA2066 Bluetooth chip is powered by a board-level 3.3 V supply
provided by the hardware. This change connects the Bluetooth
controller via UART10, and the corresponding GPIO is used to enable
the Bluetooth chip.
basic function test step:
- bluetoothctl power on/off
- bluetoothctl scan bredr/le
- bluetoothctl pair <remote device address>
- bluetoothctl connect <remote device address>
low-state test and state:
- rtcwake -d /dev/rtc0 -m no -s 30 && systemctl suspend
Pengyu Luo [Tue, 3 Mar 2026 15:01:51 +0000 (23:01 +0800)]
clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time
Parking disp{0,1}_cc_mdss_mdp_clk_src clk broke simplefb on HUAWEI
Gaokun3, the image will stuck at grey for seconds until msm takes
over framebuffer. Use clk_rcg2_shared_no_init_park_ops to skip it.
Add the qfprom efuse node and describe where the GPU speedbin fuse is
located on Milos.
Note that for SM7635-AB at least, the value is "221", the max frequency
for this is 1050MHz. There's another speedbin out there for 1150MHz but
we do not know the value for it so just document in this commit.
Once the value is discovered we should add the speedbins to the A810
Adreno entry and update devicetree.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260331-milos-qfprom-v1-2-36017cc642db@pm.me Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Jie Gan [Wed, 20 May 2026 01:42:45 +0000 (09:42 +0800)]
arm64: dts: qcom: glymur: add coresight nodes
Add CoreSight nodes to enable trace paths like TPDM->ETF/STM->ETF.
These devices are part of the AOSS, CDSP, QDSS, PCIe5, TraceNoc and
some small subsystems, such as GCC, IPCC, PMU and so on.
Delete cti_wpss DT node on Mahua since this device will cause NoC issue
on Mahua device.
Dmitry Baryshkov [Wed, 20 May 2026 09:54:37 +0000 (12:54 +0300)]
arm64: dts: qcom: qcs6490-rb3gen2: add rmtfs node
Downstream kernels for RB3 Gen2 don't specify the RMTFS address, instead
the kernel is supposed to allocate rmtfs buffers dynamically. The
upstream kernel doesn't support dynamic allocation of RMTFS buffers, so
use the fixed allocation. The RMTFS node (and corresponding interface)
is required for the modem DSP to work (which otherwise would crash).
Bjorn Andersson [Fri, 22 May 2026 02:57:10 +0000 (21:57 -0500)]
Merge branch '20260227061544.1785978-1-praveen.talari@oss.qualcomm.com' into drivers-for-7.2
Merge the refactoring and helper functions in the Qualcomm GENI Serial
Engine driver through a topic branch.
These changes will provide the ability to add support managing power and
performance for the GENI instances in platforms where these are
controlled as SCMI resources.
The patches are merged through a topic branch to avoid conflicts with other
changes, while making them available to other subsystems.
Praveen Talari [Fri, 27 Feb 2026 06:15:38 +0000 (11:45 +0530)]
soc: qcom: geni-se: Introduce helper APIs for performance control
The GENI Serial Engine (SE) drivers (I2C, SPI, and SERIAL) currently
manage performance levels and operating points directly. This resulting
in code duplication across drivers. such as configuring a specific level
or find and apply an OPP based on a clock frequency.
Introduce two new helper APIs, geni_se_set_perf_level() and
geni_se_set_perf_opp(), addresses this issue by providing a streamlined
method for the GENI Serial Engine (SE) drivers to find and set the OPP
based on the desired performance level, thereby eliminating redundancy.
Praveen Talari [Fri, 27 Feb 2026 06:15:37 +0000 (11:45 +0530)]
soc: qcom: geni-se: Introduce helper API for attaching power domains
The GENI Serial Engine drivers (I2C, SPI, and SERIAL) currently handle
the attachment of power domains. This often leads to duplicated code
logic across different driver probe functions.
Introduce a new helper API, geni_se_domain_attach(), to centralize
the logic for attaching "power" and "perf" domains to the GENI SE
device.
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.
Praveen Talari [Fri, 27 Feb 2026 06:15:35 +0000 (11:45 +0530)]
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.
Praveen Talari [Fri, 27 Feb 2026 06:15:34 +0000 (11:45 +0530)]
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.
Praveen Talari [Fri, 27 Feb 2026 06:15:33 +0000 (11:45 +0530)]
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.
Praveen Talari [Fri, 27 Feb 2026 06:15:32 +0000 (11:45 +0530)]
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.
Anup Kulkarni [Tue, 19 May 2026 06:49:54 +0000 (12:19 +0530)]
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.
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: 41b6e8db400c ("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>
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.
Dmitry Baryshkov [Thu, 21 May 2026 23:22:07 +0000 (02:22 +0300)]
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.
Byungchul Park [Fri, 15 May 2026 03:47:01 +0000 (12:47 +0900)]
Revert "mm: introduce a new page type for page pool in page type"
This reverts commit db359fccf212 ("mm: introduce a new page type for page
pool in page type") and a part of 735a309b4bfb9e ("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 735a309b4bfb9e ("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: db359fccf212 ("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>
Sunny Patel [Fri, 1 May 2026 11:51:16 +0000 (17:21 +0530)]
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: a30b48bf1b24 ("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>
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: 3f2c788a1314 ("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/ Link: https://lore.kernel.org/all/20260316104536.558108-1-kartikey406@gmail.com/T/ 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>
Alexandre Ghiti [Mon, 18 May 2026 08:28:19 +0000 (10:28 +0200)]
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: 940b01fc8dc1 ("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>
SeongJae Park [Mon, 18 May 2026 15:25:58 +0000 (08:25 -0700)]
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.
Dev Jain [Mon, 18 May 2026 06:36:56 +0000 (12:06 +0530)]
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: 354dffd29575 ("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>
Richard Chang [Tue, 12 May 2026 07:49:18 +0000 (07:49 +0000)]
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().
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: f405066a1f0d ("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>
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.
Linpu Yu [Sun, 10 May 2026 05:43:30 +0000 (13:43 +0800)]
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.
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: 03f595668017 ("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>
Lorenzo Stoakes [Tue, 12 May 2026 16:06:43 +0000 (17:06 +0100)]
Revert "mm/hugetlbfs: update hugetlbfs to use mmap_prepare"
This reverts commit ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use
mmap_prepare") with conflict resolution to account for changes in commit ea52cb24cd3f ("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: ea52cb24cd3f ("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>
Ian Ray [Wed, 6 May 2026 06:33:35 +0000 (09:33 +0300)]
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>
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:
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.
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>
Junyi Liu [Tue, 19 May 2026 07:12:04 +0000 (16:12 +0900)]
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>
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: 1baff47b81f9 ("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>
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: b9ab7217dd7d ("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>
Chancel Liu [Tue, 31 Mar 2026 01:24:50 +0000 (10:24 +0900)]
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.
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.
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.
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.
Mark Brown [Thu, 21 May 2026 23:16:33 +0000 (00:16 +0100)]
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.
Peter Ujfalusi [Wed, 20 May 2026 15:06:39 +0000 (18:06 +0300)]
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.
Peter Ujfalusi [Wed, 20 May 2026 15:06:38 +0000 (18:06 +0300)]
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.
Mark Brown [Thu, 21 May 2026 23:15:05 +0000 (00:15 +0100)]
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.
Jakub Kicinski [Thu, 21 May 2026 23:00:06 +0000 (16:00 -0700)]
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
====================
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 77d2fa54a945 ("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.
Vineeth Pillai [Fri, 15 May 2026 13:59:41 +0000 (09:59 -0400)]
HID: Use trace_call__##name() at guarded tracepoint call sites
Replace trace_foo() with the new trace_call__foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_call__foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Original v2 series:
https://lore.kernel.org/linux-trace-kernel/20260323160052.17528-1-vineeth@bitbyteword.org/
Parts of the original v2 series have already been merged in mainline.
This patch is being reposted as a follow-up cleanup for the remaining
unmerged pieces.
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <bentiss@kernel.org> Link: https://patch.msgid.link/20260515135941.2238861-1-vineeth@bitbyteword.org Suggested-by: Steven Rostedt <rostedt@goodmis.org> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org> Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Vineeth Pillai [Fri, 15 May 2026 14:01:21 +0000 (10:01 -0400)]
cpufreq: amd-pstate: Use trace_call__##name() at guarded tracepoint call site
Replace trace_foo() with the new trace_call__foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_call__foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Cc: Huang Rui <ray.huang@amd.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20260515140121.2239414-1-vineeth@bitbyteword.org Suggested-by: Steven Rostedt <rostedt@goodmis.org> Suggested-by: Peter Zijlstra <peterz@infradead.org> Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
projects / thirdparty / linux.git / log
