* [PATCH v4 0/2] Enable audio support for J721S2 EVM
From: Moteen Shah @ 2026-05-19 14:23 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
This patch series, adds support for analog audio on J721S2 EVM using
device tree overlays.
Earlier version of the patchset sent upstream[0] was rejected as
its dependency[1], which resolves the DTBS check errors introduced
by [0] also got rejected on the grounds of ABI breakage.
Another solution to fix the DTBS check errors introduced by [0] is
to modify the ti,j721e-system-controller.yaml binding to allow
audio-refclk as clock-controller child. This is done in the first
patch of this series.
Changes sinve v3:
Link to v3: https://lore.kernel.org/all/20260330094459.128648-1-m-shah@ti.com/
- Changed compatible from simple items to oneOf to support both AM62 (legacy)
and J721S2 (primary SoC-specific) compatible strings.
- Pick up missing R/B given in V2 of the patch series by Hari and Rob.
Link to v2: https://lore.kernel.org/all/20260205130707.2033197-1-m-shah@ti.com/
Link to v1: https://lore.kernel.org/all/20260112104536.83309-1-m-shah@ti.com/
Bootlogs: https://gist.github.com/Jamm02/f586087dad227450abe8637e8a688c68
Jayesh Choudhary (1):
arm64: dts: ti: Add audio overlay for k3-j721s2-evm
Moteen Shah (1):
dt-bindings: ti: Update audio-refclk binding and j721e system
controller
.../bindings/clock/ti,am62-audio-refclk.yaml | 8 +-
.../soc/ti/ti,j721e-system-controller.yaml | 6 +-
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721s2-evm-audio.dtso | 161 ++++++++++++++++++
4 files changed, 175 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
--
2.34.1
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Aneesh Kumar K.V @ 2026-05-19 14:17 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Jason Gunthorpe, iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <agxt7SFGT7OLMIah@google.com>
Mostafa Saleh <smostafa@google.com> writes:
> On Tue, May 19, 2026 at 07:30:16PM +0530, Aneesh Kumar K.V wrote:
>> Mostafa Saleh <smostafa@google.com> writes:
>>
>> >> >
>> >> > I am still running more tests, but looking more into it. Setting
>> >> > force_dma_unencrypted() to true for pKVM guests is wrong, as the
>> >> > guest shouldn’t try to decrypt arbitrary memory as it can include
>> >> > sensitive information (for example in case of virtio sub-page
>> >> > allocation) and should strictly rely on the restricted-dma-pool
>> >> > for that.
>> >>
>> >> ??
>> >>
>> >> Where does force_dma_unencrypted() cause arbitary memory passed into
>> >> the DMA API to be decrypted? That should never happen???
>> >
>> > Sorry, maybe arbitrary is not the right expression again :)
>> > I mean that, with emulated devices that use the DMA-API under pKVM,
>> > they will map memory coming from other layers (VFS, net) through
>> > vitrio-block, virtio-net... These can be smaller than a page, and
>> >
>>
>> Don't we PAGE_ALIGN these requests?
>>
>> dma_direct_alloc
>> size = PAGE_ALIGN(size);
>>
>> iommu_dma_alloc_pages
>> size_t alloc_size = PAGE_ALIGN(size);
>>
>>
>
> For allocation, yes, and that's fine because we bring memory from
> the pool.
> But not for mapping, as dma_direct_map_phys(), where the memory is
> allocated from the driver or other parts in the kernel and the page
> may be shared with other kernel components.
>
But if we are using restricted-dma-pool, we also have:
mem->force_bounce = true;
mem->for_alloc = true;
So, will we use the swiotlb buffers for mapping and copy only the shared
content into those swiotlb buffers?
-aneesh
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Liam R. Howlett @ 2026-05-19 14:17 UTC (permalink / raw)
To: Barry Song
Cc: Suren Baghdasaryan, Lorenzo Stoakes, Matthew Wilcox, akpm,
linux-mm, david, vbabka, rppt, mhocko, jack, pfalcato, wanglian,
chentao, lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong,
shikemeng, nphamcs, bhe, youngjun.park, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390,
Nanzhe Zhao
In-Reply-To: <CAGsJ_4zgeE3ebEJ+j7GJFzWVoVYHeiOn4dOoOsmWCLA6s=oECQ@mail.gmail.com>
On 26/05/19 05:14AM, Barry Song wrote:
> On Tue, May 19, 2026 at 3:57 AM Suren Baghdasaryan <surenb@google.com> wrote:
> >
> > On Mon, May 18, 2026 at 4:26 AM Barry Song <baohua@kernel.org> wrote:
> > >
> > > On Mon, May 18, 2026 at 5:47 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> > > >
> > > > On Sun, May 17, 2026 at 04:45:15PM +0800, Barry Song wrote:
> [...]
> > >
> > > I think we either need to fix `fork()`, or keep the current
> > > behavior of dropping the VMA lock before performing I/O.
> >
> > I see. So, this problem arises from the fact that we are changing the
> > pagefaults requiring I/O operation to hold VMA lock...
> > And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> > is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> > anonymous and COW VMAs only while holding mmap_write_lock, preventing
> > any VMA modification. On the surface, that looks ok to me but I might
> > be missing some corner cases. If nobody sees any obvious issues, I
> > think it's worth a try.
From Barry's description, I think what he is saying is that the vma
locking has caused the mmap_lock to become unfair? I think what is
implied is that the per-vma locking may stall mmap_lock writes for
longer than if the mmap_lock was taken in read mode? Barry, is that
correct?
Since Android is doing something (according to Barry) that should not be
done (according to Willy), both of these together are causing slow down?
>
> Thanks. Besides the creation of processes via fork(), I
> am also beginning to worry about the death of processes.
>
> One thing that came to my mind this morning
> is that when lowmemorykiller decides to kill an app, we
> want the memory to be released as quickly as possible so
> the new app or user scenario can get memory sooner.
>
> In that case, if the app being killed is performing I/O
> while holding the VMA lock, the unmapping procedure
> could end up being blocked as well.
>
> If we release the VMA lock as we currently do, we allow
> process exit to proceed.
>
> I haven't thought it through very clearly yet, and I
> may be wrong. I'd like to do more investigation. I hope
> the apps being killed stay very still, but who knows—we
> have so many applications in the market.
>
> Meanwhile, if you have any comments regarding the death
> of processes, they would be very welcome.
The oom killer only cleans out anon/not shared vmas [1]. So, what this
would hold up would be the actual process exit path. Although that
would have resources associated with it, the amount of resources should
be relatively low compared to the amount freed by the oom reaper, right?
The other entry point that's mostly to do with android,
process_mrelease() [2] will end up in the same __oom_reap_task_mm()
function.
So, for the most part, the memory will be freed while the file backed
vma completes IO and that sounds like the right thing to do anyways.
Thanks,
Liam
[1]. https://elixir.bootlin.com/linux/v7.1-rc4/source/mm/oom_kill.c#L547
[2]. https://elixir.bootlin.com/linux/v6.18.6/source/mm/oom_kill.c#L1210
^ permalink raw reply
* Re: [PATCH] clk: sunxi-ng: Use of_device_get_match_data()
From: Brian Masney @ 2026-05-19 14:16 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland,
moderated list:ARM/Allwinner sunXi SoC support,
open list:ARM/Allwinner sunXi SoC support, open list
In-Reply-To: <20260519003950.626727-1-rosenp@gmail.com>
Hi Rosen,
On Mon, May 18, 2026 at 05:39:50PM -0700, Rosen Penev wrote:
> Use of_device_get_match_data() to fetch the RTC CCU match data directly
> instead of open-coding an of_match_device() lookup.
>
> This also lets the driver drop the of_device.h include.
>
> Assisted-by: Codex:GPT-5.5
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
> index f6bfeba009e8..a3cf0dde05be 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
> @@ -9,7 +9,6 @@
> #include <linux/io.h>
> #include <linux/module.h>
> #include <linux/of.h>
> -#include <linux/of_device.h>
>
> #include <linux/clk/sunxi-ng.h>
>
> @@ -353,14 +352,12 @@ int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
> {
> const struct sun6i_rtc_match_data *data;
> struct clk *ext_osc32k_clk = NULL;
> - const struct of_device_id *match;
>
> /* This driver is only used for newer variants of the hardware. */
> - match = of_match_device(sun6i_rtc_ccu_match, dev);
> - if (!match)
> + data = of_device_get_match_data(dev);
sun6i_rtc_ccu_match becomes unused after this change. It'll use the
table associated the dev from drivers/rtc/rtc-sun6i.c.
Brian
> + if (!data)
> return 0;
>
> - data = match->data;
> have_iosc_calibration = data->have_iosc_calibration;
>
> if (data->have_ext_osc32k) {
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-19 14:13 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Marc Zyngier, Will Deacon, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <CABgObfbS-z3OphDna5W_JQPvw+OK=yXJurVMHp1ANZ5uGEgVhQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]
On Tue, 2026-05-19 at 15:53 +0200, Paolo Bonzini wrote:
> On Tue, May 19, 2026 at 3:00 PM David Woodhouse <dwmw2@infradead.org> wrote:
> > Or some guest configurations which have only ever been tested under KVM
> > could have a bug where they *rely* on the registers not being writable,
> > and write values which are inconsistent with the rest of their
> > configuration. Which breaks the moment those registers become writable.
>
> Yeah, just having guests that worked by utter chance - but you still
> don't want to break them - is the case that is most likely. Crappy
> code that runs only under emulation/virtualization appears with
> probability 1 over time.
>
> Is this likely in this specific case---probably not, honestly.
> Christoffer's patch dates back to 2018 (commit d53c2c29ae0d); *back
> then* KVM/Arm was a lot less mature, and people developing for Arm on
> vanilla upstream kernels have moved on from Linux 4.19.
It's not really 2018 though. EC2 is still running kernels with that
older commit reverted because of the breaking change that it
introduced.
So the behaviour corresponding to GICD_IIDR.implementation_rev=1 is
still current for *millions* of guests.
I'm now finding that revert in our tree during a *later* kernel upgrade
and trying to eliminate it.
And sure, I have given the engineers responsible for that a very hard
stare and suggested that they should have fixed it 'properly' in the
first place with a patch like the one we're discussing right now.
And they're looking at this thread and saying "haha no, if fixing
things properly for Arm is this hard then we'll stick with the crappy
approach".
I do not want them to be right. I don't think any of us want that.
> I would still lean towards accepting the code considering the limited
> complexity of the addition (in fact I like it more now that it uses
> IIDR instead of v2_groups_user_writable, but that's taste).
I'm absolutely prepared to have a separate technical discussion about
the v2_groups_user_writable thing for GICv2, which is the second part
of that series.
It seems like the right thing to do, and as far as I can tell, this
code *never* worked with QEMU. But I'm not sure who even cares about
GICv2 any more. I couldn't find hardware and I had to test the whole
thing inside qemu-tcg.
But the 'IIDR defaults to 3 but the *behaviour* doesn't match until you
explicitly *set* it to 3' thing seemed so *egregiously* wrong to me,
that I fixed it anyway.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH] nvmem: rockchip-otp: alloc clks with main struct
From: Srinivas Kandagatla @ 2026-05-19 14:11 UTC (permalink / raw)
To: linux-rockchip, Rosen Penev
Cc: Heiko Stuebner, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408230153.20726-1-rosenp@gmail.com>
On Wed, 08 Apr 2026 16:01:53 -0700, Rosen Penev wrote:
> Use a flexible array member to simplify allocation slightly. No need for
> a separate calloc.
>
>
Applied, thanks!
[1/1] nvmem: rockchip-otp: alloc clks with main struct
commit: 44cf48f1f7c5061e65c48c782b79df6e7f8e0668
Best regards,
--
Srinivas Kandagatla <srini@kernel.org>
^ permalink raw reply
* [PATCH resend] drm: uapi: Add macro for chipset specific event ID region
From: Bence Csokas @ 2026-05-19 14:05 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-arm-kernel, linux-samsung-soc
Cc: Bence Csokas, Daniel Kiss, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Inki Dae,
Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski, Alim Akhtar,
Zack Rusin, Broadcom internal kernel review list
uapi/drm/drm.h states:
Event types 0 - 0x7fffffff are generic DRM events, 0x80000000 and
up are chipset specific.
However, this distinction was not put in the code. To elevate the contract
between the generic DRM framework and the driver from the comment to code,
put this in a macro for clarity and convenience.
Cc: Daniel Kiss <Daniel.Kiss@arm.com>
Signed-off-by: Bence Csokas <bence.csokas@arm.com>
---
Link to v1:
https://lore.kernel.org/lkml/20260408163608.361826-2-bence.csokas@arm.com
include/uapi/drm/drm.h | 8 ++++++++
include/uapi/drm/exynos_drm.h | 4 ++--
include/uapi/drm/virtgpu_drm.h | 2 +-
include/uapi/drm/vmwgfx_drm.h | 2 +-
4 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 27cc159c1d27..aa745e643ef4 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -1419,6 +1419,14 @@ struct drm_event {
* The event payload is a struct drm_event_crtc_sequence.
*/
#define DRM_EVENT_CRTC_SEQUENCE 0x03
+/**
+ * DRM_EVENT_VENDOR_SPECIFIC - vendor/chipset specific event
+ *
+ * These event IDs are reserved for chipset and driver specific events.
+ *
+ * Refer to the chipset driver's header for details and payload struct.
+ */
+#define DRM_EVENT_VENDOR_SPECIFIC(_v) ((_v) | 0x80000000)
struct drm_event_vblank {
struct drm_event base;
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index a51aa1c618c1..8d3156fb129c 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -395,8 +395,8 @@ struct drm_exynos_ioctl_ipp_commit {
DRM_EXYNOS_IPP_COMMIT, struct drm_exynos_ioctl_ipp_commit)
/* Exynos specific events */
-#define DRM_EXYNOS_G2D_EVENT 0x80000000
-#define DRM_EXYNOS_IPP_EVENT 0x80000002
+#define DRM_EXYNOS_G2D_EVENT DRM_EVENT_VENDOR_SPECIFIC(0x0)
+#define DRM_EXYNOS_IPP_EVENT DRM_EVENT_VENDOR_SPECIFIC(0x2)
struct drm_exynos_g2d_event {
struct drm_event base;
diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h
index 9debb320c34b..03e8a0c7f778 100644
--- a/include/uapi/drm/virtgpu_drm.h
+++ b/include/uapi/drm/virtgpu_drm.h
@@ -224,7 +224,7 @@ struct drm_virtgpu_context_init {
* effect. The event size is sizeof(drm_event), since there is no additional
* payload.
*/
-#define VIRTGPU_EVENT_FENCE_SIGNALED 0x90000000
+#define VIRTGPU_EVENT_FENCE_SIGNALED DRM_EVENT_VENDOR_SPECIFIC(0x10000000)
#define DRM_IOCTL_VIRTGPU_MAP \
DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_MAP, struct drm_virtgpu_map)
diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h
index 7d786a0cc835..5e5878384e60 100644
--- a/include/uapi/drm/vmwgfx_drm.h
+++ b/include/uapi/drm/vmwgfx_drm.h
@@ -715,7 +715,7 @@ struct drm_vmw_fence_arg {
/*
* The event type
*/
-#define DRM_VMW_EVENT_FENCE_SIGNALED 0x80000000
+#define DRM_VMW_EVENT_FENCE_SIGNALED DRM_EVENT_VENDOR_SPECIFIC(0x0)
struct drm_vmw_event_fence {
struct drm_event base;
base-commit: ab5fce87a778cb780a05984a2ca448f2b41aafbf
--
2.54.0
^ permalink raw reply related
* [PATCH v1] crypto: Use named initializers for struct i2c_device_id
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-19 14:10 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-crypto, linux-arm-kernel, linux-kernel
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
this patch is part of a bigger quest to use named initializers for
mainly struct i2c_device_id::driver_data to be able to modify
i2c_device_id. See e.g.
https://lore.kernel.org/all/20260518111203.639603-2-u.kleine-koenig@baylibre.com/
for the details.
This patch here isn't critical for this quest, as no driver makes use of
.driver_data, so apart from the better readability this is only about
consistency with other subsystems.
Best regards
Uwe
drivers/crypto/atmel-ecc.c | 2 +-
drivers/crypto/atmel-sha204a.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index 9c380351d2f9..56350454ac29 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -380,7 +380,7 @@ MODULE_DEVICE_TABLE(of, atmel_ecc_dt_ids);
#endif
static const struct i2c_device_id atmel_ecc_id[] = {
- { "atecc508a" },
+ { .name = "atecc508a" },
{ }
};
MODULE_DEVICE_TABLE(i2c, atmel_ecc_id);
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index dbb39ed0cea1..0fcb4692494f 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -210,8 +210,8 @@ static const struct of_device_id atmel_sha204a_dt_ids[] __maybe_unused = {
MODULE_DEVICE_TABLE(of, atmel_sha204a_dt_ids);
static const struct i2c_device_id atmel_sha204a_id[] = {
- { "atsha204" },
- { "atsha204a" },
+ { .name = "atsha204" },
+ { .name = "atsha204a" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(i2c, atmel_sha204a_id);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] clk: stm32: allow STM32MP COMPILE_TEST builds
From: Brian Masney @ 2026-05-19 14:06 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Maxime Coquelin,
Alexandre Torgue, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, open list,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE,
open list:CLANG/LLVM BUILD SUPPORT:Keyword:b(?i:clang|llvm)b
In-Reply-To: <20260518221230.19879-1-rosenp@gmail.com>
Hi Rosen,
On Mon, May 18, 2026 at 03:12:30PM -0700, Rosen Penev wrote:
> COMMON_CLK_STM32MP already allows COMPILE_TEST, but the parent clock
> Makefile only descends into drivers/clk/stm32 for ARCH_STM32. Use the
> STM32MP clock symbol for that directory gate instead.
>
> Building the STM32MP21 and STM32MP25 clock drivers then requires direct
> linux/bitfield.h includes for FIELD_GET(), so add them as part of exposing
> that compile-test coverage.
The second one needs to be it's own separate patch, along with a Fixes
tag.
Brian
>
> Tested with:
> make LLVM=1 ARCH=loongarch drivers/clk/stm32/
>
> Assisted-by: Codex:GPT-5.5
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/clk/Makefile | 2 +-
> drivers/clk/stm32/clk-stm32mp21.c | 1 +
> drivers/clk/stm32/clk-stm32mp25.c | 1 +
> 3 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 9c3a9703ad92..0cd2223de3ca 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -150,7 +150,7 @@ obj-y += spacemit/
> obj-$(CONFIG_PLAT_SPEAR) += spear/
> obj-y += sprd/
> obj-$(CONFIG_ARCH_STI) += st/
> -obj-$(CONFIG_ARCH_STM32) += stm32/
> +obj-$(CONFIG_COMMON_CLK_STM32MP) += stm32/
> obj-y += starfive/
> obj-$(CONFIG_ARCH_SUNXI) += sunxi/
> obj-y += sunxi-ng/
> diff --git a/drivers/clk/stm32/clk-stm32mp21.c b/drivers/clk/stm32/clk-stm32mp21.c
> index c8a37b716bd5..3c143371c77e 100644
> --- a/drivers/clk/stm32/clk-stm32mp21.c
> +++ b/drivers/clk/stm32/clk-stm32mp21.c
> @@ -5,6 +5,7 @@
> */
>
> #include <linux/bus/stm32_firewall_device.h>
> +#include <linux/bitfield.h>
> #include <linux/clk-provider.h>
> #include <linux/io.h>
> #include <linux/platform_device.h>
> diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
> index 52f0e8a12926..cc95fac66449 100644
> --- a/drivers/clk/stm32/clk-stm32mp25.c
> +++ b/drivers/clk/stm32/clk-stm32mp25.c
> @@ -5,6 +5,7 @@
> */
>
> #include <linux/bus/stm32_firewall_device.h>
> +#include <linux/bitfield.h>
> #include <linux/clk-provider.h>
> #include <linux/io.h>
> #include <linux/platform_device.h>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Mostafa Saleh @ 2026-05-19 14:04 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Jason Gunthorpe, iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <yq5ah5o3sdn3.fsf@kernel.org>
On Tue, May 19, 2026 at 07:30:16PM +0530, Aneesh Kumar K.V wrote:
> Mostafa Saleh <smostafa@google.com> writes:
>
> >> >
> >> > I am still running more tests, but looking more into it. Setting
> >> > force_dma_unencrypted() to true for pKVM guests is wrong, as the
> >> > guest shouldn’t try to decrypt arbitrary memory as it can include
> >> > sensitive information (for example in case of virtio sub-page
> >> > allocation) and should strictly rely on the restricted-dma-pool
> >> > for that.
> >>
> >> ??
> >>
> >> Where does force_dma_unencrypted() cause arbitary memory passed into
> >> the DMA API to be decrypted? That should never happen???
> >
> > Sorry, maybe arbitrary is not the right expression again :)
> > I mean that, with emulated devices that use the DMA-API under pKVM,
> > they will map memory coming from other layers (VFS, net) through
> > vitrio-block, virtio-net... These can be smaller than a page, and
> >
>
> Don't we PAGE_ALIGN these requests?
>
> dma_direct_alloc
> size = PAGE_ALIGN(size);
>
> iommu_dma_alloc_pages
> size_t alloc_size = PAGE_ALIGN(size);
>
>
For allocation, yes, and that's fine because we bring memory from
the pool.
But not for mapping, as dma_direct_map_phys(), where the memory is
allocated from the driver or other parts in the kernel and the page
may be shared with other kernel components.
Thanks,
Mostafa
>
> > using force_dma_unencrypted() will share the whole page.
> > And as discussed, that leaks sensitive information to the untrusted
> > host.
> > I am currently investigating passing iova/phys/size
> > to force_dma_unencrypted() and then we can share pages inplace only
> > if possible without leaking extra information.
> > I am trying to get some performance results first. But the tricky part
> > is to get the semantics right, I believe in that case those devices
> > shouldn’t use restricted-dma-pools as those should always force
> > bouncing. Instead bouncing happens through the default SWIOTLB pool,
> > if not possible to decrypt in place.
> >
>
> -aneesh
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Aneesh Kumar K.V @ 2026-05-19 14:00 UTC (permalink / raw)
To: Mostafa Saleh, Jason Gunthorpe
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Catalin Marinas, Jiri Pirko, Petr Tesarik,
Alexey Kardashevskiy, Dan Williams, Xu Yilun, linuxppc-dev,
linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <agxolksC_1nfO34X@google.com>
Mostafa Saleh <smostafa@google.com> writes:
> On Tue, May 19, 2026 at 10:29:11AM -0300, Jason Gunthorpe wrote:
>> On Tue, May 19, 2026 at 11:04:37AM +0000, Mostafa Saleh wrote:
>> > On Thu, May 14, 2026 at 08:13:25PM +0530, Aneesh Kumar K.V wrote:
>> > > >>
>> > > >> What I meant was that we need a generic way to identify a pKVM guest, so
>> > > >> that we can use it in the conditional above.
>> > > >
>> > > > I have this patch, with that I can boot with your series unmodified,
>> > > > but I will need to do more testing.
>> > > >
>> > >
>> > > Thanks, I can add this to the series once you complete the required testing.
>> > >
>> >
>> > I am still running more tests, but looking more into it. Setting
>> > force_dma_unencrypted() to true for pKVM guests is wrong, as the
>> > guest shouldn’t try to decrypt arbitrary memory as it can include
>> > sensitive information (for example in case of virtio sub-page
>> > allocation) and should strictly rely on the restricted-dma-pool
>> > for that.
>>
>> ??
>>
>> Where does force_dma_unencrypted() cause arbitary memory passed into
>> the DMA API to be decrypted? That should never happen???
>
> Sorry, maybe arbitrary is not the right expression again :)
> I mean that, with emulated devices that use the DMA-API under pKVM,
> they will map memory coming from other layers (VFS, net) through
> vitrio-block, virtio-net... These can be smaller than a page, and
>
Don't we PAGE_ALIGN these requests?
dma_direct_alloc
size = PAGE_ALIGN(size);
iommu_dma_alloc_pages
size_t alloc_size = PAGE_ALIGN(size);
> using force_dma_unencrypted() will share the whole page.
> And as discussed, that leaks sensitive information to the untrusted
> host.
> I am currently investigating passing iova/phys/size
> to force_dma_unencrypted() and then we can share pages inplace only
> if possible without leaking extra information.
> I am trying to get some performance results first. But the tricky part
> is to get the semantics right, I believe in that case those devices
> shouldn’t use restricted-dma-pools as those should always force
> bouncing. Instead bouncing happens through the default SWIOTLB pool,
> if not possible to decrypt in place.
>
-aneesh
^ permalink raw reply
* Re: [PATCH] coresight: fix resource leaks on path build failure
From: James Clark @ 2026-05-19 13:57 UTC (permalink / raw)
To: Jie Gan
Cc: coresight, linux-arm-kernel, linux-kernel, Suzuki K Poulose,
Mike Leach, Leo Yan, Alexander Shishkin, Mathieu Poirier,
Tingwei Zhang, Greg Kroah-Hartman
In-Reply-To: <20260513-fix-memory-leak-issue-v1-1-49822d7bc7d4@oss.qualcomm.com>
On 13/05/2026 2:32 am, Jie Gan wrote:
> Two related leaks when _coresight_build_path() encounters an error after
> coresight_grab_device() has already incremented the pm_runtime, module,
> and device references for a node:
>
> 1. In _coresight_build_path(), if kzalloc_obj() for the path node fails
> after coresight_grab_device() succeeds, coresight_drop_device() was
> never called, permanently leaking all three references.
>
> 2. In coresight_build_path(), on failure the partial path was freed with
> kfree(path) instead of coresight_release_path(path). kfree() only
> frees the coresight_path struct itself; it does not iterate path_list
> to call coresight_drop_device() and kfree() for each coresight_node
> already added by deeper recursive calls, leaking both the pm_runtime,
> module, and device references and the node memory for every element
> on the partial path.
>
> Fix both by adding coresight_drop_device() in the OOM unwind of
> _coresight_build_path(), and replacing kfree(path) with
> coresight_release_path(path) in coresight_build_path().
>
> Fixes: 32b0707a4182 ("coresight: Add try_get_module() in coresight_grab_device()")
> Fixes: b3e94405941e ("coresight: associating path with session rather than tracer")
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> drivers/hwtracing/coresight/coresight-core.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index 46f247f73cf6..c1354ea8e11d 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -825,8 +825,10 @@ static int _coresight_build_path(struct coresight_device *csdev,
> return ret;
>
> node = kzalloc_obj(struct coresight_node);
> - if (!node)
> + if (!node) {
> + coresight_drop_device(csdev);
> return -ENOMEM;
> + }
>
> node->csdev = csdev;
> list_add(&node->link, &path->path_list);
> @@ -851,7 +853,7 @@ struct coresight_path *coresight_build_path(struct coresight_device *source,
>
> rc = _coresight_build_path(source, source, sink, path);
> if (rc) {
> - kfree(path);
> + coresight_release_path(path);
> return ERR_PTR(rc);
> }
>
>
> ---
> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
> change-id: 20260513-fix-memory-leak-issue-034b4a45265e
>
> Best regards,
Looks good to me, but sashiko is complaining:
https://sashiko.dev/#/patchset/20260513-fix-memory-leak-issue-v1-1-49822d7bc7d4%40oss.qualcomm.com
I'm trying to understand why it's saying that, but I think the scenario
is that if there are multiple correct paths to a sink, when one path
partially fails and a second path succeeds you could get a path_list
with some garbage entries in it.
That's kind of a different and existing issue to the one you've fixed,
and assumes that multiple paths to one sink are possible, which I'm not
sure is supported?
It might be as easy as breaking the loop early for any return value
other than -ENODEV, but I'll leave it to you to decide whether to do
that here or not.
Reviewed-by: James Clark <james.clark@linaro.org>
^ permalink raw reply
* Re: [PATCH v02] mailbox: pcc: report errors for PCC clients
From: lihuisong (C) @ 2026-05-19 13:54 UTC (permalink / raw)
To: Adam Young, Sudeep Holla, Jassi Brar
Cc: linux-kernel, linux-hwmon, Rafael J . Wysocki, Len Brown,
linux-acpi, Andi Shyti, Guenter Roeck, MyungJoo Ham,
Kyungmin Park, Chanwoo Choi, linux-arm-kernel
In-Reply-To: <20260518193006.27425-1-admiyo@os.amperecomputing.com>
On 5/19/2026 3:30 AM, Adam Young wrote:
> The tx_done callback function has a return code (rc) parameter
> that the tx_done callback can use to determine how to handle an error.
> However the IRQ handler was not setting that value if there is an error.
>
> The following clients are affected:
>
> drivers/acpi/cppc_acpi.c
> drivers/i2c/busses/i2c-xgene-slimpro.c
> drivers/hwmon/xgene-hwmon.c
> drivers/soc/hisilicon/kunpeng_hccs.c
> drivers/devfreq/hisi_uncore_freq.c
>
> All of these only use the error code to report, so they
> are expecting an error code to come thorugh, but they
> do not modify behavior based on this code.
>
> In the case of an error code in the IRQ, the handler was returning
> IRQ_NONE which is not correct: the IRQ handler was matched
> to the IRQ. This mean that multiple error codes returned from
> a PCC triggered interrupt would end up disabling the device.
>
> In addition, if the error code IRQ was coming from a Type4 Device that was
> expecting an IRQ response, that device would then be hung.
>
> Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)")
Not fix above commit.
mbox_chan_txdone() was added in below patch.
Fixes: 9c753f7c953c (mailbox: pcc: Mark Tx as complete in PCC IRQ handler)
> Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
>
> ---
> ---
> drivers/mailbox/pcc.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 636879ae1db7..16b9ce087b9e 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -314,6 +314,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
> {
> struct pcc_chan_info *pchan;
> struct mbox_chan *chan = p;
> + int rc;
>
> pchan = chan->con_priv;
>
> @@ -327,8 +328,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
> if (!pcc_mbox_cmd_complete_check(pchan))
> return IRQ_NONE;
>
> - if (pcc_mbox_error_check_and_clear(pchan))
> - return IRQ_NONE;
> + rc = pcc_mbox_error_check_and_clear(pchan);
I think it is not necessary. This function just return -EIO on failure.
>
> /*
> * Clear this flag after updating interrupt ack register and just
> @@ -337,8 +337,9 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
> * required to avoid any possible race in updatation of this flag.
> */
> pchan->chan_in_use = false;
> - mbox_chan_received_data(chan, NULL);
> - mbox_chan_txdone(chan, 0);
> + if (!rc)
> + mbox_chan_received_data(chan, NULL);
> + mbox_chan_txdone(chan, rc);
@Sudeep, I have always had doubts about the addition of this line of
code in the
commit 9c753f7c953c (mailbox: pcc: Mark Tx as complete in PCC IRQ
handler).
The patch seems to avoid the timeouts in the mailbox core according to
its commit log.
Regardless of whether the command succeeds or fails, each mbox client
driver, like cppc_acpi/acpi_pcc，kunpeng_hccs and so on, is responsible
to call mbox_chan_txdone() to tell mailbox core.
This is done after executing mbox_chan_received_data(). So I think this
line in this function is redundant.
Can you take a look at this agian?
>
> pcc_chan_acknowledge(pchan);
>
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: Paolo Bonzini @ 2026-05-19 13:53 UTC (permalink / raw)
To: David Woodhouse
Cc: Marc Zyngier, Will Deacon, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <593a782c50f3c8656e13b36dfb975a67d43a908e.camel@infradead.org>
On Tue, May 19, 2026 at 3:00 PM David Woodhouse <dwmw2@infradead.org> wrote:
> Or some guest configurations which have only ever been tested under KVM
> could have a bug where they *rely* on the registers not being writable,
> and write values which are inconsistent with the rest of their
> configuration. Which breaks the moment those registers become writable.
Yeah, just having guests that worked by utter chance - but you still
don't want to break them - is the case that is most likely. Crappy
code that runs only under emulation/virtualization appears with
probability 1 over time.
Is this likely in this specific case---probably not, honestly.
Christoffer's patch dates back to 2018 (commit d53c2c29ae0d); *back
then* KVM/Arm was a lot less mature, and people developing for Arm on
vanilla upstream kernels have moved on from Linux 4.19.
I would still lean towards accepting the code considering the limited
complexity of the addition (in fact I like it more now that it uses
IIDR instead of v2_groups_user_writable, but that's taste). However,
there's a huge difference between setting expectations based on 2018
vs 2026 maturity, and perhaps that's why Marc overall is inclined to
put this in the category of pointless bug for bug compatibility?
In any case, there's no arguing over this documentation patch, which
is already a good thing to know.
Thanks,
Paolo
> And those hypothetical cases *do* happen. All of the time. There's a
> massive zoo of guest operating systems; not just the major players like
> Linux, FreeBSD and Windows but a whole bunch of embedded home-grown and
> network appliance kernels.
>
> Nobody is claiming that we shouldn't fix any bug ever.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iommu: arm,smmu: Document optional interconnects property
From: Bibek Kumar Patro @ 2026-05-19 13:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, iommu,
devicetree, linux-kernel
In-Reply-To: <20260518-mellow-robust-caterpillar-93fcaa@quoll>
On 5/18/2026 6:03 PM, Krzysztof Kozlowski wrote:
> On Sat, May 16, 2026 at 06:04:03PM +0530, Bibek Kumar Patro wrote:
>> Some SoC implementations require a bandwidth vote on an interconnect
>
> Then this should be disallowed for other devices in "allOf:".
>
As of now, we still are checking which all SoCs do not need this
interconnects field. So would we need to add the allOf here for now?
>> path before the SMMU register space is accessible. Add the optional
>> 'interconnects' property to the binding to allow platform DT nodes
>> to describe this path.
>>
>> The arm-smmu driver uses these properties to vote for bandwidth before
>> accessing any SMMU registers and releases the vote on runtime suspend.
>>
>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>> ---
>> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> index 06fb5c8e7547cb7a92823adc2772b94f747376a6..5cbf944f2d3e178b3723d4dbaa19ee0d33446979 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> @@ -243,6 +243,15 @@ properties:
>> minItems: 1
>> maxItems: 3
>>
>> + interconnects:
>> + maxItems: 1
>> + description:
>> + Optional interconnect path to the SMMU register space. On some SoCs
>> + the SMMU registers are only accessible after a bandwidth vote has been
>
> Drivers are irrelevant here, drop. Also first sentence is redundant.
> Schema says what is and what is not optional.
>
Sure, got it. I will remove the "driver" quotation and "optional"
wording from both binding description and commit text.
Thanks & regards,
Bibek
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [PATCH v2] KVM: arm64: vgic: free private_irqs when init fails after allocation
From: Michael Bommarito @ 2026-05-19 13:50 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Yao Yuan, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260517181331.367676-1-michael.bommarito@gmail.com>
Companion to commit 250f25367b58 ("KVM: arm64: Tear down vGIC on
failed vCPU creation"), which added the missing kvm_vgic_vcpu_destroy()
call to the kvm_share_hyp() failure path in kvm_arch_vcpu_create(). The
kvm_vgic_vcpu_init() failure path immediately above it has the same
shape and still needs the same cleanup.
Call kvm_vgic_vcpu_destroy() when kvm_vgic_vcpu_init() fails so private
IRQs allocated before a redistributor iodev registration failure are
released before the failed vCPU is freed.
Fixes: 03b3d00a70b5 ("KVM: arm64: vgic: Allocate private interrupts on demand")
Cc: stable@vger.kernel.org
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
Changes in v2:
- Add the Fixes tag Marc agreed with.
- Add Yao's Reviewed-by tag.
- Trim the commit message.
arch/arm64/kvm/arm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 176cbe8baad30..5d5e2f81b9c94 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -554,8 +554,10 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
kvm_destroy_mpidr_data(vcpu->kvm);
err = kvm_vgic_vcpu_init(vcpu);
- if (err)
+ if (err) {
+ kvm_vgic_vcpu_destroy(vcpu);
return err;
+ }
err = kvm_share_hyp(vcpu, vcpu + 1);
if (err)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] spi: atmel: fix DMA channel and bounce buffer leaks
From: Mark Brown @ 2026-05-19 13:48 UTC (permalink / raw)
To: Felix Gu
Cc: Ryan Wanner, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Radu Pirea, Richard Genoud, Wenyou Yang, linux-spi,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260517-atmel-v2-1-36c836be6345@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
On Sun, May 17, 2026 at 06:39:54PM +0800, Felix Gu wrote:
> Changes in v2:
> - Switch to devm-managed variants to fix Claudiu Beznea's comment.
The switch to devm is possibly a bit enthusiastic.
> - host->dma_tx = dma_request_chan(dev, "tx");
> + host->dma_tx = devm_dma_request_chan(dev, "tx");
> if (IS_ERR(host->dma_tx)) {
> - host->dma_rx = dma_request_chan(dev, "rx");
> + host->dma_rx = devm_dma_request_chan(dev, "rx");
> if (IS_ERR(host->dma_rx)) {
> err = PTR_ERR(host->dma_rx);
> /*
> @@ -580,12 +581,27 @@ static int atmel_spi_configure_dma(struct spi_controller *host,
> * requested tx channel.
> */
> dev_dbg(dev, "No RX DMA channel, DMA is disabled\n");
> - goto error;
> + host->dma_rx = NULL;
> + return err;
> }
If the rx allocation fails then instead of jumping to cleanup we'll
return, and since the driver supports PIO operation it'll still be able
to probe...
> -error:
> - if (!IS_ERR(host->dma_rx))
> - dma_release_channel(host->dma_rx);
> - if (!IS_ERR(host->dma_tx))
> - dma_release_channel(host->dma_tx);
...with the tx DMA channel still allocated. This is very much an edge
case though, how much it matters is very questionalble.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v15 0/9] Add Type-C DP support for RK3399 EVB IND board
From: Heikki Krogerus @ 2026-05-19 13:43 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen, Luca Ceresoli,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Kishon Vijay Abraham I, Heiko Stuebner, Sandy Huang, Andy Yan,
Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, linux-usb,
devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel, Chaoyi Chen
In-Reply-To: <20260304094152.92-1-kernel@airkyi.com>
Hi,
On Wed, Mar 04, 2026 at 05:41:43PM +0800, Chaoyi Chen wrote:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> This series focuses on adding Type-C DP support for USBDP PHY and DP
> driver. The USBDP PHY and DP will perceive the changes in cable status
> based on the USB PD and Type-C state machines provided by TCPM. Before
> this, the USBDP PHY and DP controller of RK3399 sensed cable state
> changes through extcon, and devices such as the RK3399 Gru-Chromebook
> rely on them. This series should not break them.
What's the status with this series?
Are these inteded to go via the DRM tree?
thanks,
> ====
> 1. DisplayPort HPD status notify
>
> Before v7, I implemented a variety of DP HPD status notify. However,
> they all had various problems and it was difficult to become a generic
> solution.
>
> Under the guidance of Heikki and Dmitry, a decoupled notification
> method between the TypeC and DRM subsystems was introduced in v7.
> First, a notification is sent when TypeC registers a new altmode.
> Then, a generic DP AUX HPD bridge is implemented on the DRM side.
>
> During v7-v10, we added a new notifier in typec to notify the altmode
> device register event. With the help of Greg and Heikki, we implemented
> the reuse of notifiers for the type bus itself in patch1 of v11.
>
> The USB subsystem related parts have already been merged into the
> usb-next branch in v13 [0][1]. Therefore, this series no longer includes
> these patches starting from v14. Thanks to Greg and Heikki!
>
> [0]: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=67ab45426215c7fdccb65aecd4cac15bbe4dfcbb
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=4dee13db29de6dd869af9b3827e1ff569644e838
>
> That makes it redundant for each Type-C controller driver to implement
> a similar DP AUX HPD bridge in embedded scenarios.
>
> ====
> 2. Altmode switching and orientation switching for USBDP PHY
>
> For USB Type-C interfaces, an external Type-C controller chip assists
> by detecting cable attachment, determining plug orientation, and
> reporting USB PD message. The USB/DP combo PHY supports software
> configurable pin mapping and DisplayPort lane assignment. Based on
> these message, the combo PHY can perform both altmode switching and
> orientation switching via software.
>
> The RK3399 EVB IND board has a Type-C interface DisplayPort. It use
> fusb302 chip as Type-C controller. The connection diagram is shown below:
>
> fusb302 chip +---> USB2.0 PHY ----> DWC3 USB controller
> |
> +---> USB/DP PHY0 +--> CDN-DP controller
> |
> +--> DWC3 USB controller
>
> ====
> 3. Multiple bridge model for RK3399 CDN-DP
>
> The RK3399 has two USB/DP combo PHY and one CDN-DP controller. And
> the CDN-DP can be switched to output to one of the PHYs.
>
> USB/DP PHY0 ---+
> | <----> CDN-DP controller
> USB/DP PHY1 ---+
>
> In previous versions, if both PHY ports were connected to DP,
> the CDN-DP driver would select the first PHY port for output.
>
> On Dmitry's suggestion, we introduced a multi-bridge model to support
> flexible selection of the output PHY port. For each PHY port, a
> separate encoder and bridge are registered.
>
> The change is based on the DRM AUX HPD bridge, rather than the
> extcon approach. This requires the DT to correctly describe the
> connections between the first bridge in bridge chain and DP
> controller. And Once the first bridge is obtained, we can get the
> last bridge corresponding to the USB-C connector, and then set the
> DRM connector's fwnode to the corresponding one to enable HPD
> notification.
>
> ====
> Patch1 add generic USB Type-C DP HPD bridge (Dmitry, Heikki).
> Patch2 add new API drm_aux_bridge_register_from_node() (Neil) .
> Patch3 add new Type-C mode switch for RK3399 USBDP phy binding (Krzysztof).
> Patch4 add typec_mux and typec_switch for RK3399 USBDP PHY.
> Patch5 add DRM AUX bridge support for RK3399 USBDP PHY (Neil).
> Patch6 drops CDN-DP's extcon dependency when Type-C is present (Dmitry).
> Patch7 add multiple bridges to support PHY port selection (Dmitry, Luca).
> Patch8 add missing dp_out port for RK3399 CDN-DP.
> Patch9 add Type-C DP support for RK3399 EVB IND board (Diederik, Peter).
>
> Changes in v15:
> - Link to V14: https://lore.kernel.org/all/20260119073100.143-1-kernel@airkyi.com/
> - Improve clarity by inlining drm_bridge_get() in assignment (Luca).
>
> Changes in v14:
> - Link to V13: https://lore.kernel.org/all/20251208015500.94-1-kernel@airkyi.com/
> - Drop the patches for the USB Type-C subsusytem part, as they have
> already been merged into usb-next.
>
> Changes in v13:
> - Link to V12: https://lore.kernel.org/all/20251204063109.104-1-kernel@airkyi.com/
> - Only register drm dp hpd bridge for typec port altmode device.
>
> Changes in v12:
> - Link to V11: https://lore.kernel.org/all/20251128020405.90-1-kernel@airkyi.com/
> - Add missing Signed-off-by line.
>
> Changes in v11:
> - Link to V10: https://lore.kernel.org/all/20251120022343.250-1-kernel@airkyi.com/
> - Switch to using typec bus notifiers.
>
> Changes in v10:
> - Link to V9: https://lore.kernel.org/all/20251111105040.94-1-kernel@airkyi.com/
> - Notify TYPEC_ALTMODE_UNREGISTERED when altmode removed.
> - Add drm_aux_bridge_register_from_node().
> - Fix refcount usage of drm_bridge.
>
> Changes in v9:
> - Link to V8: https://lore.kernel.org/all/20251029071435.88-1-kernel@airkyi.com/
> - Remove the exposed DRM_AUX_HPD_BRIDGE option, and select
> DRM_AUX_HPD_TYPEC_BRIDGE when it is available.
> - Add usb role switch for Type-C.
> - Remove USB2 PHY in Type-C connection.
> - ...
>
> Changes in v8:
> - Link to V7: https://lore.kernel.org/all/20251023033009.90-1-kernel@airkyi.com/
> - Export all typec device types for identification.
> - Merge generic DP HPD bridge into one module.
> - Fix coding style.
>
> Changes in v7:
> - Link to V6: https://lore.kernel.org/all/20251016022741.91-1-kernel@airkyi.com/
> - Add notifier functions for Type-C core.
> - Add generic USB Type-C DP HPD bridge.
>
> Changes in v6:
> - Link to V5: https://lore.kernel.org/all/20251011033233.97-1-kernel@airkyi.com/
> - Fix depend in Kconfig.
> - Check DP svid in tcphy_typec_mux_set().
> - Remove mode setting in tcphy_orien_sw_set().
> - Rename some variable names.
> - Attach the DP bridge to the next bridge.
>
> Changes in v5:
> - Link to V4: https://lore.kernel.org/all/20250922012039.323-1-kernel@airkyi.com/
> - Remove the calls related to `drm_aux_hpd_bridge_notify()`.
> - Place the helper functions in the same compilation unit.
> - Add more comments about parent device.
> - Add DRM AUX bridge support for RK3399 USBDP PHY
> - By parsing the HPD bridge chain, set the connector's of_node to the
> of_node corresponding to the USB-C connector.
> - Return EDID cache when other port is already enabled.
>
> Changes in v4:
> - Link to V3: https://lore.kernel.org/all/20250729090032.97-1-kernel@airkyi.com/
> - Add default HPD device for DisplayPort altmode.
> - Introduce multiple bridges for CDN-DP.
> - ...
>
> Changes in v3:
> - Link to V2: https://lore.kernel.org/all/20250718062619.99-1-kernel@airkyi.com/
> - Add more descriptions to clarify the role of the PHY in switching.
> - Fix wrong vdo value.
> - Fix port node in usb-c-connector.
>
> Changes in v2:
> - Link to V1: https://lore.kernel.org/all/20250715112456.101-1-kernel@airkyi.com/
> - Reuse dp-port/usb3-port in rk3399-typec-phy binding.
> - Fix compile error when CONFIG_TYPEC is not enabled.
> - Notify DP HPD state by USB/DP PHY.
> - Ignore duplicate HPD events.
> - Add endpoint to link DP PHY and DP controller.
> - Fix devicetree coding style.
>
> Chaoyi Chen (9):
> drm/bridge: Implement generic USB Type-C DP HPD bridge
> drm/bridge: aux: Add drm_aux_bridge_register_from_node()
> dt-bindings: phy: rockchip: rk3399-typec-phy: Support mode-switch
> phy: rockchip: phy-rockchip-typec: Add typec_mux/typec_switch support
> phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge
> drm/rockchip: cdn-dp: Support handle lane info without extcon
> drm/rockchip: cdn-dp: Add multiple bridges to support PHY port
> selection
> arm64: dts: rockchip: Add missing dp_out port for RK3399 CDN-DP
> arm64: dts: rockchip: rk3399-evb-ind: Add support for DisplayPort
>
> .../phy/rockchip,rk3399-typec-phy.yaml | 6 +
> arch/arm64/boot/dts/rockchip/rk3399-base.dtsi | 10 +-
> .../boot/dts/rockchip/rk3399-evb-ind.dts | 147 +++++++
> drivers/gpu/drm/bridge/Kconfig | 10 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/aux-bridge.c | 24 +-
> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 49 +++
> drivers/gpu/drm/rockchip/Kconfig | 1 +
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 349 +++++++++++++---
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 18 +-
> drivers/phy/rockchip/Kconfig | 3 +
> drivers/phy/rockchip/phy-rockchip-typec.c | 373 +++++++++++++++++-
> include/drm/bridge/aux-bridge.h | 6 +
> 13 files changed, 913 insertions(+), 84 deletions(-)
> create mode 100644 drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>
> --
> 2.51.1
--
heikki
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-19 13:42 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Barry Song, Matthew Wilcox, surenb, akpm, linux-mm, liam, vbabka,
rppt, mhocko, jack, pfalcato, wanglian, chentao, lianux.mm,
kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <b65722ee-6476-4038-bfbb-44a32b3544fd@kernel.org>
On Mon, May 18, 2026 at 11:53:37AM +0200, David Hildenbrand (Arm) wrote:
> On 5/17/26 10:45, Barry Song wrote:
> > On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:
> >>
> >> On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:
> >>>
> >>> It doesn’t have to involve unmapping or applying mprotect to
> >>> the entire VMA—just a portion of it is sufficient.
> >>
> >> Yes, but that still fails to answer "does this actually happen". How much
> >> performance is all this complexity in the page fault handler buying us?
> >> If you don't answer this question, I'm just going to go in and rip it
> >> all out.
> >>
> >
> > Hi Matthew (and Lorenzo, Jan, and anyone else who may be
> > waiting for answers),
> >
> > As promised during LSF/MM/BPF, we conducted thorough
> > testing on Android phones to determine whether performing
> > I/O in `filemap_fault()` can block `vma_start_write()`.
> > I wanted to give a quick update on this question.
> >
> > Nanzhe at Xiaomi created tracing scripts and ran various
> > applications on Android devices with I/O performed under
> > the VMA lock in `filemap_fault()`. We found that:
> >
> > 1. There are very few cases where unmap() is blocked by
> > page faults. I assume this is due to buggy user code
> > or poor synchronization between reads and unmap().
> > So I assume it is not a problem.
> >
> > 2. We observed many cases where `vma_start_write()`
> > is blocked by page-fault I/O in some applications.
> > The blocking occurs in the `dup_mmap()` path during
> > fork().
> >
> > With Suren's commit fb49c455323ff ("fork: lock VMAs of
> > the parent process when forking"), we now always hold
> > `vma_write_lock()` for each VMA. Note that the
> > `mmap_lock` write lock is also held, which could lead to
> > chained waiting if page-fault I/O is performed without
> > releasing the VMA lock.
> >
> > My gut feeling is that Suren's commit may be overshooting,
> > so my rough idea is that we might want to do something like
> > the following (we haven't tested it yet and it might be
> > wrong):
> >
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 2311ae7c2ff4..5ddaf297f31a 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -1762,7 +1762,13 @@ __latent_entropy int dup_mmap(struct mm_struct
> > *mm, struct mm_struct *oldmm)
> > for_each_vma(vmi, mpnt) {
> > struct file *file;
> >
> > - retval = vma_start_write_killable(mpnt);
> > + /*
> > + * For anonymous or writable private VMAs, prevent
> > + * concurrent CoW faults.
> > + */
> > + if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) &&
> > + (mpnt->vm_flags & VM_WRITE)))
> > + retval = vma_start_write_killable(mpnt);
>
> Likely is_cow_mapping() is what you would want to check to handle VMAs that
> could have anonymous pages in them.
Yes :) I made pretty much the same comment though I forgot the correct helper :P
>
> --
> Cheers,
>
> David
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Mostafa Saleh @ 2026-05-19 13:41 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Aneesh Kumar K.V, iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <20260519132911.GA7702@ziepe.ca>
On Tue, May 19, 2026 at 10:29:11AM -0300, Jason Gunthorpe wrote:
> On Tue, May 19, 2026 at 11:04:37AM +0000, Mostafa Saleh wrote:
> > On Thu, May 14, 2026 at 08:13:25PM +0530, Aneesh Kumar K.V wrote:
> > > >>
> > > >> What I meant was that we need a generic way to identify a pKVM guest, so
> > > >> that we can use it in the conditional above.
> > > >
> > > > I have this patch, with that I can boot with your series unmodified,
> > > > but I will need to do more testing.
> > > >
> > >
> > > Thanks, I can add this to the series once you complete the required testing.
> > >
> >
> > I am still running more tests, but looking more into it. Setting
> > force_dma_unencrypted() to true for pKVM guests is wrong, as the
> > guest shouldn’t try to decrypt arbitrary memory as it can include
> > sensitive information (for example in case of virtio sub-page
> > allocation) and should strictly rely on the restricted-dma-pool
> > for that.
>
> ??
>
> Where does force_dma_unencrypted() cause arbitary memory passed into
> the DMA API to be decrypted? That should never happen???
Sorry, maybe arbitrary is not the right expression again :)
I mean that, with emulated devices that use the DMA-API under pKVM,
they will map memory coming from other layers (VFS, net) through
vitrio-block, virtio-net... These can be smaller than a page, and
using force_dma_unencrypted() will share the whole page.
And as discussed, that leaks sensitive information to the untrusted
host.
I am currently investigating passing iova/phys/size
to force_dma_unencrypted() and then we can share pages inplace only
if possible without leaking extra information.
I am trying to get some performance results first. But the tricky part
is to get the semantics right, I believe in that case those devices
shouldn’t use restricted-dma-pools as those should always force
bouncing. Instead bouncing happens through the default SWIOTLB pool,
if not possible to decrypt in place.
Thanks,
Mostafa
>
> Jason
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-19 13:39 UTC (permalink / raw)
To: Yang Shi
Cc: Barry Song, Matthew Wilcox, surenb, akpm, linux-mm, david, liam,
vbabka, rppt, mhocko, jack, pfalcato, wanglian, chentao,
lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng,
nphamcs, bhe, youngjun.park, linux-arm-kernel, linux-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <agxfLNuLCAT3F4cW@lucifer>
On Tue, May 19, 2026 at 02:12:10PM +0100, Lorenzo Stoakes wrote:
> On Mon, May 18, 2026 at 02:21:14PM -0700, Yang Shi wrote:
> > Maybe a little bit off topic. This is an interesting idea. It seems
> > possible we don't have to take vma write lock unconditionally. IIUC
> > the write lock is mainly used to serialize against page fault and
> > madvise, right? I got a crazy idea off the top of my head. We may be
>
> Err no, it serialises against literally any modification or read of any
> characteristic of VMAs.
>
> > able to just take vma write lock iff vma->anon_vma is not NULL.
>
> Except if we don't take it and vma->anon_vma is NULL, then somebody can
> anon_vma_prepare() and change vma->anon_vma midway through a fork and completely
> screw up the anon_vma fork hierarchy.
correction: this won't happen as per Barry (see - I managed to confuse myself
here :), since for vma->anon_vma install we take the mmap read lock.
BUT we also have to consider other cases.
>
> So no.
>
> >
> > First of all, write mmap_lock is held, so the vma can't go or be
> > changed under us.
>
> vma->anon_vma can be changed.
Correction: no it can't :)
>
> >
> > Secondly, if vma->anon_vma is NULL, it basically means either no page
> > fault happened or no cow happened, so there is no page table to copy,
> > this is also what copy_page_range() does currently. So we can shrink
> > the critical section to:
>
> Firstly, with no VMA write lock, !vma->anon_vma means a fault can race and
> secondly copy_page_range() checks vma_needs_copy(), there are other cases - PFN
> maps, mixed maps, UFFD W/P (ugh), guard regions.
>
> So yeah this isn't sufficient.
However this is true...
>
> >
> > if (vma->anon_vma) {
> > vma_start_write_killable(src_vma);
> > anon_vma_fork(dst_vma, src_vma);
> > copy_page_range(dst_vma, src_vma);
> > }
>
> Yeah that's totally broken fo reasons above as I said :)
>
> >
> > But page fault can happen before write mmap_lock is taken, when we
> > check vma->anon_vma, it is possible it has not been set up yet. But it
> > seems to be equivalent to page fault after fork and won't break the
> > semantic.
>
> It will totally break how the anon_vma hierarchy works :) See the links at the
> top of https://ljs.io/talks for a link to various slides on anon_vma behaviour
> (it's really a pain to think about because it's a super broken abstraction).
>
> You could end up with a CoW mapping that's unreachable from rmap and you could
> get some nasty issues with page table entries pointing at freed folios :)
Correction: actually we should be safe given mmap read lock on anon_vma install.
>
> >
> > Anyway, just a crazy idea, I may miss some corner cases.
>
> Yeah sorry to push back here but this is just not a viable approach.
>
> And this is forgetting that we have relied on page faults being blocked by fork
> _forever_, who knows what else has baked in assumptions about that
> serialisation.
>
> Forking is one of the nastiest parts of mm and has had multiple, subtle, corner
> case breakages that have been a nightmare to deal with.
>
> So I'm very much against changing this behaviour to try to fix something in the
> fault path.
>
> We should address the fault path issues in the fault path :)
Above still all true though.
>
> >
> > Thanks,
> > Yang
> >
> > }
> >
> > >
> > > Based on the above, we may want to re-check whether fork()
> > > can be blocked by page faults. At the same time, if Suren,
> > > you, or anyone else has any comments, please feel free to
> > > share them.
> > >
> > > Best Regards
> > > Barry
> > >
>
> Cheers, Lorenzo
So still a nope :)
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-05-19 13:39 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <agxETC1rXBUSkWYg@google.com>
On Tue, May 19, 2026 at 11:06:52AM +0000, Mostafa Saleh wrote:
> > > One other interesting case for device-passthrough is non-coherent
> > > devices which then require private pools for bouncing.
> >
> > Why does shared/private matter for bouncing? Why do you need to bounce
> > at all? Do cmo's not work in pkvm guests?
>
> At the moment, in iommu_dma_map_phys(), if a non coherent device
> tries to map an unaligned address or size it will be bounced.
Sure, that's fine.
> In pKVM, dma-iommu is used for assigned devices which operate on
> private memory, so bouncing that through the SWIOTLB would leak
> information from the guest as the SWIOTLB is decrypted.
Yes, a device that can do private access should not be using a shared
SWIOTLB, that should be part of the selection logic inside the SWIOTLB
stuff..
Jason
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-19 13:34 UTC (permalink / raw)
To: Barry Song
Cc: Yang Shi, Matthew Wilcox, surenb, akpm, linux-mm, david, liam,
vbabka, rppt, mhocko, jack, pfalcato, wanglian, chentao,
lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng,
nphamcs, bhe, youngjun.park, linux-arm-kernel, linux-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAGsJ_4w_-Y8qNLDeLX9OWpLpK01YG2bF-N6_mGypgsauvfCvkA@mail.gmail.com>
On Tue, May 19, 2026 at 07:07:37PM +0800, Barry Song wrote:
> On Tue, May 19, 2026 at 5:21 AM Yang Shi <shy828301@gmail.com> wrote:
> >
> > On Sun, May 17, 2026 at 1:45 AM Barry Song <baohua@kernel.org> wrote:
> > >
> > > On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:
> > > >
> > > > On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:
> > > > > On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > > > >
> > > > > > On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:
> > > > > > > 1. There is no deterministic latency for I/O completion. It depends on
> > > > > > > both the hardware and the software stack (bio/request queues and the
> > > > > > > block scheduler). Sometimes the latency is short; at other times it can
> > > > > > > be quite long. In such cases, a high-priority thread performing operations
> > > > > > > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait
> > > > > > > for an unpredictable amount of time.
> > > > > >
> > > > > > But does that actually happen? I find it hard to believe that thread A
> > > > > > unmaps a VMA while thread B is in the middle of taking a page fault in
> > > > > > that same VMA. mprotect() and madvise() are more likely to happen, but
> > > > > > it still seems really unlikely to me.
> > > > >
> > > > > It doesn’t have to involve unmapping or applying mprotect to
> > > > > the entire VMA—just a portion of it is sufficient.
> > > >
> > > > Yes, but that still fails to answer "does this actually happen". How much
> > > > performance is all this complexity in the page fault handler buying us?
> > > > If you don't answer this question, I'm just going to go in and rip it
> > > > all out.
> > > >
> > >
> > > Hi Matthew (and Lorenzo, Jan, and anyone else who may be
> > > waiting for answers),
> > >
> > > As promised during LSF/MM/BPF, we conducted thorough
> > > testing on Android phones to determine whether performing
> > > I/O in `filemap_fault()` can block `vma_start_write()`.
> > > I wanted to give a quick update on this question.
> > >
> > > Nanzhe at Xiaomi created tracing scripts and ran various
> > > applications on Android devices with I/O performed under
> > > the VMA lock in `filemap_fault()`. We found that:
> > >
> > > 1. There are very few cases where unmap() is blocked by
> > > page faults. I assume this is due to buggy user code
> > > or poor synchronization between reads and unmap().
> > > So I assume it is not a problem.
> > >
> > > 2. We observed many cases where `vma_start_write()`
> > > is blocked by page-fault I/O in some applications.
> > > The blocking occurs in the `dup_mmap()` path during
> > > fork().
> > >
> > > With Suren's commit fb49c455323ff ("fork: lock VMAs of
> > > the parent process when forking"), we now always hold
> > > `vma_write_lock()` for each VMA. Note that the
> > > `mmap_lock` write lock is also held, which could lead to
> > > chained waiting if page-fault I/O is performed without
> > > releasing the VMA lock.
> > >
> > > My gut feeling is that Suren's commit may be overshooting,
> > > so my rough idea is that we might want to do something like
> > > the following (we haven't tested it yet and it might be
> > > wrong):
> > >
> > > diff --git a/mm/mmap.c b/mm/mmap.c
> > > index 2311ae7c2ff4..5ddaf297f31a 100644
> > > --- a/mm/mmap.c
> > > +++ b/mm/mmap.c
> > > @@ -1762,7 +1762,13 @@ __latent_entropy int dup_mmap(struct mm_struct
> > > *mm, struct mm_struct *oldmm)
> > > for_each_vma(vmi, mpnt) {
> > > struct file *file;
> > >
> > > - retval = vma_start_write_killable(mpnt);
> > > + /*
> > > + * For anonymous or writable private VMAs, prevent
> > > + * concurrent CoW faults.
> > > + */
> > > + if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) &&
> > > + (mpnt->vm_flags & VM_WRITE)))
> > > + retval = vma_start_write_killable(mpnt);
> > > if (retval < 0)
> > > goto loop_out;
> > > if (mpnt->vm_flags & VM_DONTCOPY) {
> >
> > Maybe a little bit off topic. This is an interesting idea. It seems
> > possible we don't have to take vma write lock unconditionally. IIUC
> > the write lock is mainly used to serialize against page fault and
> > madvise, right? I got a crazy idea off the top of my head. We may be
> > able to just take vma write lock iff vma->anon_vma is not NULL.
> >
> > First of all, write mmap_lock is held, so the vma can't go or be
> > changed under us.
> >
> > Secondly, if vma->anon_vma is NULL, it basically means either no page
> > fault happened or no cow happened, so there is no page table to copy,
> > this is also what copy_page_range() does currently. So we can shrink
> > the critical section to:
> >
> > if (vma->anon_vma) {
> > vma_start_write_killable(src_vma);
> > anon_vma_fork(dst_vma, src_vma);
> > copy_page_range(dst_vma, src_vma);
> > }
> >
> > But page fault can happen before write mmap_lock is taken, when we
> > check vma->anon_vma, it is possible it has not been set up yet. But it
> > seems to be equivalent to page fault after fork and won't break the
> > semantic.
>
> Re-reading Suren's commit log for fb49c455323ff8
> ("fork: lock VMAs of the parent process when forking"),
> it seems that vm_start_write() is used to protect
> against a race where anon_vma changes from NULL to
> non-NULL during fork. In that scenario, we hold the
> mmap_lock write lock, but not vma_start_write(), so a
> concurrent anon_vma_prepare() could still install an
> anon_vma.
>
> " A concurrent page fault on a page newly marked read-only by the page
> copy might trigger wp_page_copy() and a anon_vma_prepare(vma) on the
> source vma, defeating the anon_vma_clone() that wasn't done because the
> parent vma originally didn't have an anon_vma, but we now might end up
> copying a pte entry for a page that has one.
> "
>
> If that is the case, then your change does not work.
>
> Nowadays, nobody calls anon_vma_prepare(vma) directly.
I see callers? Am I imagining them? :)
https://elixir.bootlin.com/linux/v7.0.9/A/ident/anon_vma_prepare
> Instead, vmf_anon_prepare() is used, and we always
> require the mmap_lock read lock before calling
> __anon_vma_prepare(). As a result, anon_vma cannot
> transition from NULL to non-NULL during fork.
Right, yes the mmap read lock is required for that.
>
> So the original race condition has effectively
> disappeared.
Err the page tables? All the other cases which require page table copying?
Concurrent faults mean that copy_page_range() and faulting with vma->anon_vma
_or_ any of the multiple cases mentioned elsewhere.
And who knows what else serialises on that.
>
> You also mentioned the madvise() case. If I understand
> correctly, madvise() should take mmap_lock before
> modifying anon_vma. Only some parts of madvise() can
> support per-VMA locking. Therefore, we probably do not
> need:
>
> if (vma->anon_vma) {
> vma_start_write_killable(src_vma);
> ...
> }
I like how you hand wave the VMA lock operations in madvise() :)
(Maybe) guard regions being present cause page tables to be copied, they're
installed under VMA (read) lock, and can race now.
And it sets traps for future changes - introducing more horrible edge case race
conditions in fork is just a big nope nope nope.
This isn't an area to play around in.
>
> >
> > Anyway, just a crazy idea, I may miss some corner cases.
>
> To me, it seems that we could remove vma_start_write()
> entirely now. Or is that an even crazier idea?
As above that'd be totally broken. NAK.
>
> Thanks
> Barry
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-05-19 13:29 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Aneesh Kumar K.V, iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <agxDxdxynp4KEovA@google.com>
On Tue, May 19, 2026 at 11:04:37AM +0000, Mostafa Saleh wrote:
> On Thu, May 14, 2026 at 08:13:25PM +0530, Aneesh Kumar K.V wrote:
> > >>
> > >> What I meant was that we need a generic way to identify a pKVM guest, so
> > >> that we can use it in the conditional above.
> > >
> > > I have this patch, with that I can boot with your series unmodified,
> > > but I will need to do more testing.
> > >
> >
> > Thanks, I can add this to the series once you complete the required testing.
> >
>
> I am still running more tests, but looking more into it. Setting
> force_dma_unencrypted() to true for pKVM guests is wrong, as the
> guest shouldn’t try to decrypt arbitrary memory as it can include
> sensitive information (for example in case of virtio sub-page
> allocation) and should strictly rely on the restricted-dma-pool
> for that.
??
Where does force_dma_unencrypted() cause arbitary memory passed into
the DMA API to be decrypted? That should never happen???
Jason
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: dts: s32g: add SAR ADC support for s32g2 and s32g3
From: Enric Balletbo i Serra @ 2026-05-19 13:27 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Frank Li,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pengutronix Kernel Team, linux-arm-kernel, imx,
devicetree, linux-kernel, NXP S32 Linux, Christophe Lizzi,
Alberto Ruiz
In-Reply-To: <20260514082639.1181240-2-khristineandreea.barbulescu@oss.nxp.com>
Hi,
On Thu, May 14, 2026 at 10:26 AM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
>
> Add ADC0 and ADC1 for S32G2 and S32G3 SoCs.
>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
Reviewed-by: Enric Balletbo i Serra <eballetb@redhat.com>
Thanks,
Enric
> ---
> arch/arm64/boot/dts/freescale/s32g2.dtsi | 22 +++++++++++++++++++++-
> arch/arm64/boot/dts/freescale/s32g3.dtsi | 22 +++++++++++++++++++++-
> 2 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/s32g2.dtsi b/arch/arm64/boot/dts/freescale/s32g2.dtsi
> index 51d00dac12de..6f1952fbbcfe 100644
> --- a/arch/arm64/boot/dts/freescale/s32g2.dtsi
> +++ b/arch/arm64/boot/dts/freescale/s32g2.dtsi
> @@ -3,7 +3,7 @@
> * NXP S32G2 SoC family
> *
> * Copyright (c) 2021 SUSE LLC
> - * Copyright 2017-2021, 2024-2025 NXP
> + * Copyright 2017-2021, 2024-2026 NXP
> */
>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> @@ -554,6 +554,16 @@ i2c2: i2c@401ec000 {
> status = "disabled";
> };
>
> + adc0: adc@401f8000 {
> + compatible = "nxp,s32g2-sar-adc";
> + reg = <0x401f8000 0x1000>;
> + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 0x41>;
> + dmas = <&edma0 0 32>;
> + dma-names = "rx";
> + status = "disabled";
> + };
> +
> swt4: watchdog@40200000 {
> compatible = "nxp,s32g2-swt";
> reg = <0x40200000 0x1000>;
> @@ -717,6 +727,16 @@ i2c4: i2c@402dc000 {
> status = "disabled";
> };
>
> + adc1: adc@402e8000 {
> + compatible = "nxp,s32g2-sar-adc";
> + reg = <0x402e8000 0x1000>;
> + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 0x41>;
> + dmas = <&edma1 1 32>;
> + dma-names = "rx";
> + status = "disabled";
> + };
> +
> usdhc0: mmc@402f0000 {
> compatible = "nxp,s32g2-usdhc";
> reg = <0x402f0000 0x1000>;
> diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> index e314f3c7d61d..5cfb37c1216a 100644
> --- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
> +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> /*
> - * Copyright 2021-2025 NXP
> + * Copyright 2021-2026 NXP
> *
> * Authors: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
> * Ciprian Costea <ciprianmarian.costea@nxp.com>
> @@ -617,6 +617,16 @@ i2c2: i2c@401ec000 {
> status = "disabled";
> };
>
> + adc0: adc@401f8000 {
> + compatible = "nxp,s32g3-sar-adc", "nxp,s32g2-sar-adc";
> + reg = <0x401f8000 0x1000>;
> + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 0x41>;
> + dmas = <&edma0 0 32>;
> + dma-names = "rx";
> + status = "disabled";
> + };
> +
> swt4: watchdog@40200000 {
> compatible = "nxp,s32g3-swt", "nxp,s32g2-swt";
> reg = <0x40200000 0x1000>;
> @@ -792,6 +802,16 @@ i2c4: i2c@402dc000 {
> status = "disabled";
> };
>
> + adc1: adc@402e8000 {
> + compatible = "nxp,s32g3-sar-adc", "nxp,s32g2-sar-adc";
> + reg = <0x402e8000 0x1000>;
> + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 0x41>;
> + dmas = <&edma1 1 32>;
> + dma-names = "rx";
> + status = "disabled";
> + };
> +
> usdhc0: mmc@402f0000 {
> compatible = "nxp,s32g3-usdhc",
> "nxp,s32g2-usdhc";
> --
> 2.34.1
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox