* [PATCH v4 5/5] KVM: arm64: Validate the offset to the mem access descriptor
From: Mostafa Saleh @ 2026-05-20 20:49 UTC (permalink / raw)
To: op-tee, linux-kernel, kvmarm, linux-arm-kernel
Cc: maz, oupton, joey.gouly, suzuki.poulose, catalin.marinas,
jens.wiklander, sumit.garg, sebastianene, vdonnefort,
sudeep.holla, Mostafa Saleh
In-Reply-To: <20260520204948.2440882-1-smostafa@google.com>
From: Sebastian Ene <sebastianene@google.com>
Prevent the pKVM hypervisor from making assumptions that the
endpoint memory access descriptor (EMAD) comes right after the
FF-A memory region header.
Prior to FF-A version 1.1 the header of the memory region
didn't contain an offset to the endpoint memory access descriptor.
The layout of a memory transaction looks like this from 1.1 onward:
Type | Field name | Offset
[ Header | ffa_mem_region | 0
EMAD 1 | ffa_mem_region_attributes) | ffa_mem_region.ep_mem_offset
]
Verify that the offset to the first endpoint memory access descriptor
is within the mailbox buffer bounds.
[@Mostafa, Add missing call to ffa_rx_release() and use fraglen
as the max buffer size as it is the only intialised part]
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index e6aa2bfa63b1..38f35887e846 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -479,7 +479,7 @@ static void __do_ffa_mem_xfer(const u64 func_id,
struct ffa_mem_region_attributes *ep_mem_access;
struct ffa_composite_mem_region *reg;
struct ffa_mem_region *buf;
- u32 offset, nr_ranges, checked_offset;
+ u32 offset, nr_ranges, checked_offset, em_mem_access_off;
int ret = 0;
if (addr_mbz || npages_mbz || fraglen > len ||
@@ -508,8 +508,13 @@ static void __do_ffa_mem_xfer(const u64 func_id,
buf = hyp_buffers.tx;
memcpy(buf, host_buffers.tx, fraglen);
- ep_mem_access = (void *)buf +
- ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ if (em_mem_access_off + sizeof(struct ffa_mem_region_attributes) > fraglen) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out_unlock;
+ }
+
+ ep_mem_access = (void *)buf + em_mem_access_off;
offset = ep_mem_access->composite_off;
if (!offset || buf->ep_count != 1 || buf->sender_id != HOST_FFA_ID) {
ret = FFA_RET_INVALID_PARAMETERS;
@@ -576,7 +581,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
DECLARE_REG(u32, flags, ctxt, 3);
struct ffa_mem_region_attributes *ep_mem_access;
struct ffa_composite_mem_region *reg;
- u32 offset, len, fraglen, fragoff;
+ u32 offset, len, fraglen, fragoff, em_mem_access_off;
struct ffa_mem_region *buf;
int ret = 0;
u64 handle;
@@ -599,8 +604,14 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
len = res->a1;
fraglen = res->a2;
- ep_mem_access = (void *)buf +
- ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ if (em_mem_access_off + sizeof(struct ffa_mem_region_attributes) > fraglen) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ ffa_rx_release(res);
+ goto out_unlock;
+ }
+
+ ep_mem_access = (void *)buf + em_mem_access_off;
offset = ep_mem_access->composite_off;
/*
* We can trust the SPMD to get this right, but let's at least
--
2.54.0.669.g59709faab0-goog
^ permalink raw reply related
* [PATCH v4 4/5] KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim()
From: Mostafa Saleh @ 2026-05-20 20:49 UTC (permalink / raw)
To: op-tee, linux-kernel, kvmarm, linux-arm-kernel
Cc: maz, oupton, joey.gouly, suzuki.poulose, catalin.marinas,
jens.wiklander, sumit.garg, sebastianene, vdonnefort,
sudeep.holla, Mostafa Saleh
In-Reply-To: <20260520204948.2440882-1-smostafa@google.com>
Sashiko (locally) reports out of bound write possiblity if SPMD
returns an invalid data.
While SPMD is considered trusted, pKVM does some basic checks,
for offset to be less than or equal len.
However, that is incorrect as even if the offset is smaller than
len pKVM can still access out of bound memory in the next
ffa_host_unshare_ranges().
Split this check into 2:
1- Check that the fixed portion of the descriptor fits.
2- After getting reg, check the variable array size addr_range_cnt
fits.
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 1af722771178..e6aa2bfa63b1 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -607,7 +607,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
* check that we end up with something that doesn't look _completely_
* bogus.
*/
- if (WARN_ON(offset > len ||
+ if (WARN_ON(offset + CONSTITUENTS_OFFSET(0) > len ||
fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE)) {
ret = FFA_RET_ABORTED;
ffa_rx_release(res);
@@ -641,6 +641,11 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
goto out_unlock;
reg = (void *)buf + offset;
+ if (WARN_ON(offset + CONSTITUENTS_OFFSET(reg->addr_range_cnt) > len)) {
+ ret = FFA_RET_ABORTED;
+ goto out_unlock;
+ }
+
/* If the SPMD was happy, then we should be too. */
WARN_ON(ffa_host_unshare_ranges(reg->constituents,
reg->addr_range_cnt));
--
2.54.0.669.g59709faab0-goog
^ permalink raw reply related
* Re: [PATCH v2 4/7] mm/vmalloc: Extend page table walk to support larger page_shift sizes and eliminate page table rewalk
From: Barry Song @ 2026-05-20 20:56 UTC (permalink / raw)
To: Mike Rapoport
Cc: Wen Jiang, linux-mm, linux-arm-kernel, catalin.marinas, will,
akpm, urezki, Xueyuan.chen21, dev.jain, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <177927799624.3551615.1232032128494296554.b4-review@b4>
On Wed, May 20, 2026 at 7:53 PM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Thu, 14 May 2026 17:41:05 +0800, Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
>
> Hi,
>
> > vmap_pages_range_noflush_walk() (formerly vmap_small_pages_range_noflush())
> > provides a clean interface by taking struct page **pages and mapping them
> > via direct PTE iteration. This avoids the page table rewalk seen when
> > using vmap_range_noflush() for page_shift values other than PAGE_SHIFT.
> >
> > Extend it to support larger page_shift values, and add PMD- and
> > contiguous-PTE mappings as well. Rename it to vmap_pages_range_noflush_walk()
> > since it now handles more than just small pages.
> >
> > For vmalloc() allocations with VM_ALLOW_HUGE_VMAP, we no longer need to
> > iterate over pages one by one via vmap_range_noflush(), which would
> > otherwise lead to page table rewalk. The code is now unified with the
> > PAGE_SHIFT case by simply calling vmap_pages_range_noflush_walk().
>
> After this patch we have two very simalar page table walkers:
> vmap_pages_range_noflush_walk() and vmap_range_noflush().
>
> The subtly differ at what levels they try huge mappings, how they
> account page table modifucations and, at last vmap_range_noflush() is
> left without support for contiguous mappings.
>
> Is there a fundamental reason to have two page walkers?
> Is there a reason not to support contiguous mappings in
> vmap_range_noflush()?
Hi Mike,
They are two completely different cases. In one case, you have a contiguous
physical address range for ioremap(). Since the range is fully contiguous,
many things can be simplified. We already support large mappings there, but
this patchset still improves performance through larger batching.
In the other case, you have a pages[] array whose pages are not physically
contiguous as a whole. You iterate over the pages and attempt to create large
mappings whenever a subset of adjacent pages happens to be physically
contiguous.
Best Regards
Barry
^ permalink raw reply
* Re: [PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel
From: Waiman Long @ 2026-05-20 21:01 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Catalin Marinas, Will Deacon, Mark Rutland, Clark Williams,
Steven Rostedt, linux-arm-kernel, linux-kernel, linux-rt-devel
In-Reply-To: <20260520061920.XCqBHe0x@linutronix.de>
On 5/20/26 2:19 AM, Sebastian Andrzej Siewior wrote:
> On 2026-05-19 18:25:24 [-0400], Waiman Long wrote:
>> Commit d8bb6718c4db ("arm64: Make debug exception handlers visible from
>> RCU") introduces debug_exception_enter() and debug_exception_exit()
>> where preemption is explicitly disabled. With a PREEMPT_RT debug kernel,
>> the following bug report can happen.
> …
>
> What kernel is this? I have backport (which is being tested) for v6.6
> and v6.12, the patches are from v6.17-rc1.
The kernel backtrace is produced using the latest v7.1-rc4 kernel. There
are a number of changes to the debug_exception_enter() and
debug_exception_exit() functions over the years, but the preemption
disable code remains since its introduction in v5.3.
BTW, what v6.17-rc1 patches are you talking about?
-Longman
^ permalink raw reply
* Re: [PATCH 5/6] firmware: samsung: acpm: Add TMU protocol support
From: Alexey Klimov @ 2026-05-20 21:01 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Krzysztof Kozlowski, Michael Turquette, Stephen Boyd, Lee Jones,
Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, jyescas, kernel-team, Krzysztof Kozlowski
In-Reply-To: <73f18a2c-e729-45d7-9376-7c0e60ed35c7@linaro.org>
Hi Tudor,
On Tue May 19, 2026 at 4:46 PM BST, Tudor Ambarus wrote:
> Hi, Alexey,
>
> On 5/18/26 2:24 PM, Alexey Klimov wrote:
>> Thinking further about this I'd humbly suggest that even
>>
>> if (fw_err >= 0)
>> return 0;
>>
>> pr_debug_ratelimited("ACPM tmu call returned: %x\n", fw_err);
>> or pr_debug(...);
>>
>> if (fw_err == -1)
>> return -EACCES;
>>
>> some debug message would do.
>> Perhaps we need some convertation, for instance as it is done in scmi
>> code (scmi_to_linux_errno(), scmi_linux_errmap[]). But I don't have any
>> data for mapping acpm errors to some human meanings.
>
> I did that for the pmic helpers. I don't need any debug prints for
> gs101 TMU as I have clear instructions from firmware: 0 for success,
> -1 for error.
This doesn't look like a right approach for upstreaming a ACPM TMU
framework.
You are trying to submit a gs101-specific implementation masquerading
it as a generic ACPM TMU framework, while explicitly pushing the
refactoring work onto the next developer to add support for other
SoCs in this generic ACPM code.
The ACPM TMU protocol implementation on Exynos850 is different: it uses
different error codes, and half of the calls in this 'generic' driver
are not even implemented in the Exynos850 firmware. Relying on a
hardcoded if (fw_err == -1) in a driver named generic ACPM is broken
by design and may silently swallow critical firmware errors on other
SoCs.
What about such options below?
- rename the driver to reflect reality: rename this specifically to
gs101-acpm-tmu-something to reflect that it is tailored for gs101-s;
or
- abstract the firmware error handling paths through driver_data or
a dedicated ops structure now, so that other SoCs can cleanly hook into
it without having to rewrite the logic later.
Maybe we can utilise build info date from SRAM initdata base to
distinguish between different version of ACPM firmware implementations.
Sadly I was told that specs doesn't provide any version info.
Or probe for implemented calls but that may break ACPM firmware
potentially.
You also mentioned that there are capabilities returned by TMU init
call. Maybe that one can be used somehow.
Thanks,
Alexey
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Matthew Wilcox @ 2026-05-20 21:04 UTC (permalink / raw)
To: Barry Song
Cc: Liam R. Howlett, Suren Baghdasaryan, Lorenzo Stoakes, 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_4yKxg1QugcsJi3WD0KVGJKe-zXycgm5D6cRi9vWtNcpDQ@mail.gmail.com>
On Wed, May 20, 2026 at 06:01:56AM +0800, Barry Song wrote:
> > 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?
>
> Not the case — the actual situation is (if we modify the
> current kernel to perform I/O without releasing VMA read locks):
>
> thread 1 PF: lock vma1 read ---- IO ----- ;
> thread 2 PF: lock vma2 read ----- IO ----- ;
> thread 3 PF: lock vma3 read ---- IO ----- ;
> thread 4 fork: mmap_lock_write ---- lock vma1, vma2, vma3 write ;
> thread 5 : take mmap_lock for any read/write reason
>
> Now you can see that thread 4 has to wait for the I/O of
> VMA1, VMA2, and VMA3 to complete, and thread 5 then has to
> wait for thread 4 to release mmap_lock. Both thread 4 and
> thread 5 can become extremely slow, because I/O may be stuck
> anywhere in the bio/request queue or filesystem GC.
>
> So now we have two choices:
>
> 1. Change fork() to avoid taking the vma write lock for vma1/2/3 where possible;
> 2. Keep the current kernel behavior and drop the VMA lock before I/O:
Option 3: Say that this is a very silly thing to optimise for. I have a
hard time believing that any application will care about the latency of
fork(), or the latency of page faults while it's in the middle of fork().
Multithreaded applications just don't fork that often!
^ permalink raw reply
* Re: [PATCH v4 1/2] media: nxp: imx8-isi: Add virtual channel support
From: Laurent Pinchart @ 2026-05-20 21:09 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Aisheng Dong, linux-media,
imx, linux-arm-kernel, linux-kernel, Guoniu Zhou
In-Reply-To: <20260508-isi_vc-v4-1-feee39c63939@oss.nxp.com>
Hello Guoniu,
Thank you for the patch.
On Fri, May 08, 2026 at 11:05:40AM +0800, Guoniu Zhou wrote:
> From: Guoniu Zhou <guoniu.zhou@nxp.com>
>
> The ISI supports different numbers of virtual channels depending on the
> platform. i.MX95 supports 8 virtual channels, and i.MX8QXP/QM support 4
> virtual channels. They are used in multiple camera use cases, such as
> surround view. Other platforms (such as i.MX8/MN/MP/ULP/91/93) don't
> support virtual channels, and the VC_ID bits are marked as read-only.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> ---
> Changes in v4:
> - Fix VC boundary check: use num_vc (virtual channels count) instead of
> num_channels (ISI pipelines count)
> - Set VC to 0 when frame descriptor has no entries
> - Move platform-specific comments to block style to fix line length warnings
>
> Changes in v3:
> - Add num_vc field to platform data to indicate VC support
> - Clear VC_ID_1 bit after reading CHNL_CTRL for proper VC switching
> - Set VC_ID_1 only on platforms with num_vc > 4
> - Improve mxc_isi_get_vc() error handling
> - Add back CHNL_CTRL_BLANK_PXL and document platform-specific register fields
> ---
> .../media/platform/nxp/imx8-isi/imx8-isi-core.c | 3 ++
> .../media/platform/nxp/imx8-isi/imx8-isi-core.h | 4 ++
> drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c | 14 ++++-
> .../media/platform/nxp/imx8-isi/imx8-isi-pipe.c | 59 ++++++++++++++++++++++
> .../media/platform/nxp/imx8-isi/imx8-isi-regs.h | 12 +++--
> 5 files changed, 88 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
> index 4bf8570e1b9e..837ac7046cf2 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
> @@ -318,6 +318,7 @@ static const struct mxc_isi_plat_data mxc_imx95_data = {
> .model = MXC_ISI_IMX95,
> .num_ports = 4,
> .num_channels = 8,
> + .num_vc = 8,
> .reg_offset = 0x10000,
> .ier_reg = &mxc_imx8_isi_ier_v2,
> .set_thd = &mxc_imx8_isi_thd_v1,
> @@ -329,6 +330,7 @@ static const struct mxc_isi_plat_data mxc_imx8qm_data = {
> .model = MXC_ISI_IMX8QM,
> .num_ports = 5,
> .num_channels = 8,
> + .num_vc = 4,
> .reg_offset = 0x10000,
> .ier_reg = &mxc_imx8_isi_ier_qm,
> .set_thd = &mxc_imx8_isi_thd_v1,
> @@ -340,6 +342,7 @@ static const struct mxc_isi_plat_data mxc_imx8qxp_data = {
> .model = MXC_ISI_IMX8QXP,
> .num_ports = 5,
> .num_channels = 6,
> + .num_vc = 4,
> .reg_offset = 0x10000,
> .ier_reg = &mxc_imx8_isi_ier_v2,
> .set_thd = &mxc_imx8_isi_thd_v1,
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
> index 14d63ec36416..195c28dbd151 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
> @@ -169,6 +169,7 @@ struct mxc_isi_plat_data {
> enum model model;
> unsigned int num_ports;
> unsigned int num_channels;
> + unsigned int num_vc; /* Number of VCs, 0 = no VC support */
> unsigned int reg_offset;
> const struct mxc_isi_ier_reg *ier_reg;
> const struct mxc_isi_set_thd *set_thd;
> @@ -257,6 +258,9 @@ struct mxc_isi_pipe {
> u8 acquired_res;
> u8 chained_res;
> bool chained;
> +
> + /* Virtual channel ID for the ISI channel */
> + u8 vc;
I try not to store such values in global structures, when the purpose is
to pass them between functions in a direct call stack. You can instead
return the vc value from mxc_isi_get_vc(), pass it to
mxc_isi_channel_config() and from there to
mxc_isi_channel_set_control().
> };
>
> struct mxc_isi_m2m {
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c
> index 0187d4ab97e8..ecd0c2ef28b6 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c
> @@ -308,6 +308,11 @@ static void mxc_isi_channel_set_control(struct mxc_isi_pipe *pipe,
> mutex_lock(&pipe->lock);
>
> val = mxc_isi_read(pipe, CHNL_CTRL);
> +
> + /* Clear the VC_ID_1 bit on platforms supporting more than 4 VCs. */
> + if (pipe->isi->pdata->num_vc > 4)
> + val &= ~CHNL_CTRL_VC_ID_1_MASK;
> +
Please move this just after the next statement, we usually start with
generic statements followed by conditional ones.
> val &= ~(CHNL_CTRL_CHNL_BYPASS | CHNL_CTRL_CHAIN_BUF_MASK |
> CHNL_CTRL_SRC_TYPE_MASK | CHNL_CTRL_MIPI_VC_ID_MASK |
> CHNL_CTRL_SRC_INPUT_MASK);
> @@ -338,7 +343,14 @@ static void mxc_isi_channel_set_control(struct mxc_isi_pipe *pipe,
> } else {
> val |= CHNL_CTRL_SRC_TYPE(CHNL_CTRL_SRC_TYPE_DEVICE);
> val |= CHNL_CTRL_SRC_INPUT(input);
> - val |= CHNL_CTRL_MIPI_VC_ID(0); /* FIXME: For CSI-2 only */
> + val |= CHNL_CTRL_MIPI_VC_ID(pipe->vc); /* FIXME: For CSI-2 only */
> +
> + /*
> + * On platforms with more than 4 VCs (i.MX95), the VC ID is
> + * split across VC_ID_0 (bits 7:6) and VC_ID_1 (bit 16).
> + */
> + if (pipe->isi->pdata->num_vc > 4)
> + val |= CHNL_CTRL_VC_ID_1(pipe->vc >> 2);
> }
>
> mxc_isi_write(pipe, CHNL_CTRL, val);
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
> index a41c51dd9ce0..e6da254a9ef0 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
> @@ -232,6 +232,61 @@ static inline struct mxc_isi_pipe *to_isi_pipe(struct v4l2_subdev *sd)
> return container_of(sd, struct mxc_isi_pipe, sd);
> }
>
> +static int mxc_isi_get_vc(struct mxc_isi_pipe *pipe)
> +{
> + struct mxc_isi_crossbar *xbar = &pipe->isi->crossbar;
> + struct device *dev = pipe->isi->dev;
> + struct v4l2_mbus_frame_desc fd = { };
> + unsigned int source_pad = xbar->num_sinks + pipe->id;
> + unsigned int max_vc;
> + unsigned int i;
> + int ret;
> +
> + ret = v4l2_subdev_call(&xbar->sd, pad, get_frame_desc,
> + source_pad, &fd);
> + if (ret == -ENOIOCTLCMD) {
Is this needed ? If we swap patches 1/2 and 2/2, the get_frame_desc
operation should always be available on the source.
> + /*
> + * If remote subdev doesn't implement get_frame_desc.
> + * Assume virtual channel 0.
> + */
> + pipe->vc = 0;
> + return 0;
> + }
> + if (ret < 0) {
> + dev_err(dev, "Failed to get source frame desc from pad %u\n",
> + source_pad);
> + return ret;
> + }
> +
> + if (!fd.num_entries) {
> + pipe->vc = 0;
> + return 0;
> + }
Similarly, can this happen ?
> +
> + /* Find stream 0 in the frame descriptor */
> + for (i = 0; i < fd.num_entries; i++) {
> + if (fd.entry[i].stream == 0)
> + break;
> + }
> +
> + if (i == fd.num_entries) {
> + dev_err(dev, "Failed to find stream from source frame desc\n");
> + return -EINVAL;
I think -EPIPE would be more appropriate, this indicates the pipeline
isn't correctly configured.
> + }
> +
> + max_vc = pipe->isi->pdata->num_vc ? : 1;
> +
> + /* Check virtual channel range */
> + if (fd.entry[i].bus.csi2.vc >= max_vc) {
> + dev_err(dev, "Virtual channel %u exceeds maximum %u\n",
> + fd.entry[i].bus.csi2.vc, max_vc - 1);
> + return -EINVAL;
Same here.
> + }
> +
> + pipe->vc = fd.entry[i].bus.csi2.vc;
> + return 0;
> +}
> +
> int mxc_isi_pipe_enable(struct mxc_isi_pipe *pipe)
> {
> struct mxc_isi_crossbar *xbar = &pipe->isi->crossbar;
> @@ -280,6 +335,10 @@ int mxc_isi_pipe_enable(struct mxc_isi_pipe *pipe)
>
> v4l2_subdev_unlock_state(state);
>
> + ret = mxc_isi_get_vc(pipe);
> + if (ret)
> + return ret;
> +
> /* Configure the ISI channel. */
> mxc_isi_channel_config(pipe, input, &in_size, &scale, &crop,
> sink_info->encoding, src_info->encoding);
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-regs.h b/drivers/media/platform/nxp/imx8-isi/imx8-isi-regs.h
> index 1b65eccdf0da..e795f4daf3ff 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-regs.h
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-regs.h
> @@ -6,6 +6,7 @@
> #ifndef __IMX8_ISI_REGS_H__
> #define __IMX8_ISI_REGS_H__
>
> +#include <linux/bitfield.h>
> #include <linux/bits.h>
>
> /* ISI Registers Define */
> @@ -19,9 +20,14 @@
> #define CHNL_CTRL_CHAIN_BUF_NO_CHAIN 0
> #define CHNL_CTRL_CHAIN_BUF_2_CHAIN 1
> #define CHNL_CTRL_SW_RST BIT(24)
> -#define CHNL_CTRL_BLANK_PXL(n) ((n) << 16)
> -#define CHNL_CTRL_BLANK_PXL_MASK GENMASK(23, 16)
> -#define CHNL_CTRL_MIPI_VC_ID(n) ((n) << 6)
> +/*
> + * CHNL_CTRL_BLANK_PXL: i.MX8{QM,QXP} only
> + * CHNL_CTRL_VC_ID_1, CHNL_CTRL_VC_ID_1_MASK: i.MX95 only
> + */
> +#define CHNL_CTRL_BLANK_PXL(n) FIELD_PREP(GENMASK(23, 16), (n))
> +#define CHNL_CTRL_VC_ID_1(n) FIELD_PREP(BIT(16), (n))
> +#define CHNL_CTRL_VC_ID_1_MASK BIT(16)
> +#define CHNL_CTRL_MIPI_VC_ID(n) FIELD_PREP(GENMASK(7, 6), (n))
> #define CHNL_CTRL_MIPI_VC_ID_MASK GENMASK(7, 6)
> #define CHNL_CTRL_SRC_TYPE(n) ((n) << 4)
> #define CHNL_CTRL_SRC_TYPE_MASK BIT(4)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [GIT PULL] soc: fixes for 7.1
From: Arnd Bergmann @ 2026-05-20 21:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: soc, linux-arm-kernel, linux-kernel
The following changes since commit 7fd2df204f342fc17d1a0bfcd474b24232fb0f32:
Linux 7.1-rc2 (2026-05-03 14:21:25 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-fixes-7.1
for you to fetch changes up to 1fcf4149418e7a8f8253dd74059d56340795503f:
Merge tag 'riscv-dt-fixes-for-v7.1-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes (2026-05-08 15:33:36 +0200)
----------------------------------------------------------------
soc: fixes for 7.1
The ff-a firmware driver gets 11 individual bugfixes for a number
of issues with robustness to buggy firmware or client implementations.
Another firmware fix address suspend to RAM via PSCI firmware.
The final code change is for the old Arm Integrator reference
platform that recently started exposing an old NULL pointer
dereference bug.
The MAINTAINERS file gets two updates, notably James Tai and Yu-Chun
Lin are stepping up as co-maintainers for the Realtek platform.
The remaining patches are all for devicetree files. Two of these
are for riscv boards, the rest are all for enesas Arm platforms,
addressing build time checking issues as well as minor configuration
problems.
----------------------------------------------------------------
Arnd Bergmann (3):
Merge tag 'renesas-fixes-for-v7.1-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/fixes
Merge tag 'ffa-fixes-7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Merge tag 'riscv-dt-fixes-for-v7.1-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes
Conor Dooley (1):
riscv: dts: microchip: fix icicle i2c pinctrl configuration
Geert Uytterhoeven (1):
arm64: dts: renesas: r8a78000: Fix SCIF brg_int clocks
Guenter Roeck (1):
ARM: integrator: Fix early initialization
Jai Luthra (1):
riscv: dts: starfive: jh7110: Drop CAMSS node
Konrad Dybcio (1):
firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
Krzysztof Kozlowski (1):
ARM: realtek: MAINTAINERS: Include pin controller drivers
Marek Vasut (10):
arm64: dts: renesas: draak/ebisu-panel: Fix missing cells and reg in DTO
arm64: dts: renesas: salvator-panel: Fix missing cells and reg in DTO
arm64: dts: renesas: rz-smarc-cru-csi-ov5645: Fix missing cells and reg in CSI2 subnode
arm64: dts: renesas: rz-smarc-du-adv7513-smarc: Fix missing cells and reg in DU subnode
ARM: dts: renesas: r8a7778: Add missing unit address to bus node
ARM: dts: renesas: r8a7779: Add missing unit address to bus node
ARM: dts: renesas: r8a7792: Add missing unit address to bus node
ARM: dts: renesas: r7s72100: Add missing unit address to bus node
ARM: dts: renesas: genmai: Drop superfluous cells
ARM: dts: renesas: rskrza1: Drop superfluous cells
Sudeep Holla (11):
firmware: arm_ffa: Check for NULL FF-A ID table while driver registration
firmware: arm_ffa: Skip free_pages on RX buffer alloc failure
firmware: arm_ffa: Avoid collapsing NPI work from different CPUs
firmware: arm_ffa: Fix per-vcpu self notifications handling in workqueue
firmware: arm_ffa: Unregister bus notifier on teardown for FF-A v1.0
firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies
firmware: arm_ffa: Keep framework RX release under lock
firmware: arm_ffa: Validate framework notification message layout
firmware: arm_ffa: Align RxTx buffer size before mapping
firmware: arm_ffa: Snapshot notifier callbacks under lock
firmware: arm_ffa: Fix sched-recv callback partition lookup
Tommaso Merciai (2):
arm64: dts: renesas: r9a09g057: Add #mux-state-cells to usb2{0,1}phyrst
arm64: dts: renesas: r9a09g056: Add #mux-state-cells to usb20phyrst
Yu-Chun Lin (1):
MAINTAINERS: Add maintainers for ARM/REALTEK ARCHITECTURE
MAINTAINERS | 5 +-
arch/arm/boot/dts/renesas/r7s72100-genmai.dts | 3 -
arch/arm/boot/dts/renesas/r7s72100-rskrza1.dts | 2 -
arch/arm/boot/dts/renesas/r7s72100.dtsi | 2 +-
arch/arm/boot/dts/renesas/r8a7778.dtsi | 2 +-
arch/arm/boot/dts/renesas/r8a7779.dtsi | 2 +-
arch/arm/boot/dts/renesas/r8a7792.dtsi | 2 +-
arch/arm/mach-versatile/integrator_cp.c | 13 +-
.../dts/renesas/draak-ebisu-panel-aa104xd12.dtso | 5 +
arch/arm64/boot/dts/renesas/r8a78000.dtsi | 8 +-
arch/arm64/boot/dts/renesas/r9a09g056.dtsi | 1 +
arch/arm64/boot/dts/renesas/r9a09g057.dtsi | 2 +
.../boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi | 5 +
.../boot/dts/renesas/rz-smarc-du-adv7513.dtsi | 5 +
.../boot/dts/renesas/salvator-panel-aa104xd12.dtso | 5 +
.../boot/dts/microchip/mpfs-icicle-kit-fabric.dtsi | 10 --
.../boot/dts/microchip/mpfs-icicle-kit-prod.dts | 10 ++
arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts | 19 +++
arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 27 +---
arch/riscv/boot/dts/starfive/jh7110.dtsi | 28 ----
drivers/firmware/arm_ffa/bus.c | 4 +-
drivers/firmware/arm_ffa/driver.c | 144 +++++++++++++++------
drivers/firmware/psci/psci.c | 10 ++
23 files changed, 183 insertions(+), 131 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Barry Song @ 2026-05-20 21:14 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Liam R. Howlett, Suren Baghdasaryan, Lorenzo Stoakes, 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: <ag4h87CBd-gph9zX@casper.infradead.org>
On Thu, May 21, 2026 at 5:05 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Wed, May 20, 2026 at 06:01:56AM +0800, Barry Song wrote:
> > > 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?
> >
> > Not the case — the actual situation is (if we modify the
> > current kernel to perform I/O without releasing VMA read locks):
> >
> > thread 1 PF: lock vma1 read ---- IO ----- ;
> > thread 2 PF: lock vma2 read ----- IO ----- ;
> > thread 3 PF: lock vma3 read ---- IO ----- ;
> > thread 4 fork: mmap_lock_write ---- lock vma1, vma2, vma3 write ;
> > thread 5 : take mmap_lock for any read/write reason
> >
> > Now you can see that thread 4 has to wait for the I/O of
> > VMA1, VMA2, and VMA3 to complete, and thread 5 then has to
> > wait for thread 4 to release mmap_lock. Both thread 4 and
> > thread 5 can become extremely slow, because I/O may be stuck
> > anywhere in the bio/request queue or filesystem GC.
> >
> > So now we have two choices:
> >
> > 1. Change fork() to avoid taking the vma write lock for vma1/2/3 where possible;
> > 2. Keep the current kernel behavior and drop the VMA lock before I/O:
>
> Option 3: Say that this is a very silly thing to optimise for. I have a
> hard time believing that any application will care about the latency of
> fork(), or the latency of page faults while it's in the middle of fork().
> Multithreaded applications just don't fork that often!
My understanding is that we should not blame applications here. This is 2026:
there are basically only two kinds of applications — single-threaded and
multi-threaded — and single-threaded applications are nearly extinct.
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Matthew Wilcox @ 2026-05-20 21:15 UTC (permalink / raw)
To: Barry Song
Cc: Liam R. Howlett, Suren Baghdasaryan, Lorenzo Stoakes, 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_4zA8afu0xXy0WS+tMe-eesDX1W6UBmfAsuouUpcAgK8JQ@mail.gmail.com>
On Thu, May 21, 2026 at 05:14:20AM +0800, Barry Song wrote:
> My understanding is that we should not blame applications here. This is 2026:
> there are basically only two kinds of applications — single-threaded and
> multi-threaded — and single-threaded applications are nearly extinct.
all of the applications i run are either single threaded or don't fork.
what multithreaded applications call fork?
^ permalink raw reply
* Re: [PATCH v4 2/2] media: nxp: imx8-isi: Implement get_frame_desc for crossbar subdev
From: Laurent Pinchart @ 2026-05-20 21:22 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Aisheng Dong, linux-media,
imx, linux-arm-kernel, linux-kernel, Guoniu Zhou
In-Reply-To: <20260508-isi_vc-v4-2-feee39c63939@oss.nxp.com>
Hello Guoniu,
Thank you for the patch.
On Fri, May 08, 2026 at 11:05:41AM +0800, Guoniu Zhou wrote:
> From: "Guoniu.zhou" <guoniu.zhou@nxp.com>
>
> Implement the get_frame_desc pad operation for the crossbar subdevice
> to propagate frame descriptor information from the source subdevice to
> downstream ISI channels.
>
> This allows the ISI driver to retrieve virtual channel information and
> other stream parameters from the connected upstream, which is required
> for proper virtual channel routing on platforms supporting multiple VCs.
Have you looked at v4l2_subdev_get_frame_desc_passthrough(), could it be
used instead of a manual implementation ? This could be either direct
usage of v4l2_subdev_get_frame_desc_passthrough(), or with minor
additional customization (first calling the unlocked helper
__v4l2_subdev_get_frame_desc_passthrough() and updating the descriptors.
> Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com>
> ---
> Changes in v4:
> - Use %d instead of %u for ret variable in error messages
> - Fix potential -ENOIOCTLCMD leak by resetting ret to 0 on continue
>
> Changes in v3:
> - New patch added based on feedback from Laurent Pinchart
> ---
> .../platform/nxp/imx8-isi/imx8-isi-crossbar.c | 98 ++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> index 605a45124103..b5eff191b2d5 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> @@ -306,6 +306,103 @@ static int mxc_isi_crossbar_set_fmt(struct v4l2_subdev *sd,
> return 0;
> }
>
> +static int mxc_isi_get_frame_desc(struct v4l2_subdev *sd, unsigned int pad,
> + struct v4l2_mbus_frame_desc *fd)
> +{
> + struct mxc_isi_crossbar *xbar = to_isi_crossbar(sd);
> + struct device *dev = xbar->isi->dev;
> + struct v4l2_subdev_route *route;
> + struct v4l2_subdev_state *state;
> + int ret = 0;
> +
> + if (pad < xbar->num_sinks)
> + return -EINVAL;
> +
> + memset(fd, 0, sizeof(*fd));
> +
> + state = v4l2_subdev_lock_and_get_active_state(sd);
> +
> + /*
> + * Iterate over all active routes. For each route going through the
> + * requested source pad, get the frame descriptor from the connected
> + * source subdev, find the corresponding stream entry, and add it to
> + * the output frame descriptor with the routed stream ID.
> + */
> + for_each_active_route(&state->routing, route) {
> + struct v4l2_mbus_frame_desc source_fd;
> + struct v4l2_subdev *remote_sd;
> + struct media_pad *remote_pad;
> + unsigned int i;
> +
> + if (route->source_pad != pad)
> + continue;
> +
> + /* Find the remote subdev connected to this sink pad */
> + remote_pad = media_pad_remote_pad_first(&xbar->pads[route->sink_pad]);
> + if (!remote_pad) {
> + dev_dbg(dev, "no remote pad connected to crossbar input %u\n",
> + route->sink_pad);
> + continue;
> + }
> +
> + remote_sd = media_entity_to_v4l2_subdev(remote_pad->entity);
> + if (!remote_sd) {
> + dev_err(dev, "no subdev connected to crossbar input %u\n",
> + route->sink_pad);
> + ret = -EPIPE;
> + goto out_unlock;
> + }
> +
> + /* Get frame descriptor from the remote subdev */
> + ret = v4l2_subdev_call(remote_sd, pad, get_frame_desc,
> + remote_pad->index, &source_fd);
> + if (ret == -ENOIOCTLCMD) {
> + dev_dbg(dev, "%s:%u does not support frame descriptors\n",
> + remote_sd->entity.name, remote_pad->index);
> + ret = 0;
> + continue;
> + }
> + if (ret < 0) {
> + dev_err(dev, "failed to get frame desc from %s:%u: %d\n",
> + remote_sd->entity.name, remote_pad->index, ret);
> + goto out_unlock;
> + }
> +
> + if (fd->num_entries == 0)
> + fd->type = source_fd.type;
> +
> + /* Find the source frame descriptor entry matching the sink stream */
> + for (i = 0; i < source_fd.num_entries; i++) {
> + if (source_fd.entry[i].stream == route->sink_stream)
> + break;
> + }
> +
> + if (i == source_fd.num_entries) {
> + dev_err(dev, "stream %u not found in frame desc from %s:%u\n",
> + route->sink_stream, remote_sd->entity.name,
> + remote_pad->index);
> + ret = -EPIPE;
> + goto out_unlock;
> + }
> +
> + if (fd->num_entries >= ARRAY_SIZE(fd->entry)) {
> + dev_err(dev, "frame descriptor is full\n");
> + ret = -ENOSPC;
> + goto out_unlock;
> + }
> +
> + /* Copy the entry and update the stream ID */
> + fd->entry[fd->num_entries] = source_fd.entry[i];
> + fd->entry[fd->num_entries].stream = route->source_stream;
> + fd->num_entries++;
> + }
> +
> +out_unlock:
> + v4l2_subdev_unlock_state(state);
> +
> + return ret;
> +}
> +
> static int mxc_isi_crossbar_set_routing(struct v4l2_subdev *sd,
> struct v4l2_subdev_state *state,
> enum v4l2_subdev_format_whence which,
> @@ -404,6 +501,7 @@ static const struct v4l2_subdev_pad_ops mxc_isi_crossbar_subdev_pad_ops = {
> .enum_mbus_code = mxc_isi_crossbar_enum_mbus_code,
> .get_fmt = v4l2_subdev_get_fmt,
> .set_fmt = mxc_isi_crossbar_set_fmt,
> + .get_frame_desc = mxc_isi_get_frame_desc,
> .set_routing = mxc_isi_crossbar_set_routing,
> .enable_streams = mxc_isi_crossbar_enable_streams,
> .disable_streams = mxc_isi_crossbar_disable_streams,
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/8] mm: Add ptep_try_install() for lockless empty-slot installs
From: David Hildenbrand (Arm) @ 2026-05-20 21:22 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Tejun Heo, David Vernet, Andrea Righi, Changwoo Min,
Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
Martin KaFai Lau, Kumar Kartikeya Dwivedi, Catalin Marinas,
Will Deacon, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, Andrew Morton, Mike Rapoport, Emil Tsalapatis,
sched-ext, bpf, X86 ML, linux-arm-kernel, linux-mm, LKML
In-Reply-To: <CAADnVQ+j4o0Xy+cykSdx9txSqCouy0yHFaA09qTJp3OVF3VaRA@mail.gmail.com>
>>
>> At least in apply_range_clear_cb() one could similarly switch to
>> ptep_try_install() to at least have both these paths handle races in a
>> reasonable way. (having to handle when ptep_try_install() is not really implemented)
>
> You mean to use ptep_get_and_clear() ?
> Makes sense to me.
Yes, using also an atomic to replace it.
I recall that ptep_get_and_clear() might not be atomic, but I guess it is on the
architectures where ptep_try_install() is currently implemented.
>
>> Anyhow, the documentation of ptep_try_install() must clearly spell out that this
>> must be used very carefully, and only in special kernel page tables, never user
>> page tables. There are likely other scenarios we should document (caller must
>> prevent concurrent page table teardown somehow, and must be prepared to handle
>> races if other code is not using atomics).
>>
>> To highlight that, we should likely consider adding a "kernel" in the name, like
>> "ptep_try_install_kernel()".
>>
>> I am also not sure if "install" is the right terminology and whether it should
>> instead be "ptep_try_set()". (set_pte_at is the non-atomic interface right now)
>
> I suggested using the ptep_try_set() name too :)
>
>> Further note that last time I talked to Linus about arch helpers, he preferred
>>
>> #define ptep_try_install ptep_try_install
>>
>> over __HAVE_ARCH_PTEP_TRY_INSTALL
>
> ok.
> I guess __HAVE_ARCH_PTEP_GET_AND_CLEAR is legacy ?
Yeah ... and we have plenty of legacy around :)
--
Cheers,
David
^ permalink raw reply
* [PATCH v4 0/5] arm_mpam: resctrl: Counter Assignment (ABMC)
From: Ben Horgan @ 2026-05-20 21:24 UTC (permalink / raw)
To: ben.horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jic23, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, zengheng4, x86
Version 4 of this series addresses a few review comments and some concerns
of the sashiko bot.
From the cover letter of v3:
Removing the rfc tag as the resctrl precursors [1] have been queued in tip
x86/cache. Due to that dependency, it would be good for this to also go through
x86/cache.
This series adds support for memory bandwidth monitoring.
Please review and test.
Changelogs in patches.
[1] https://lore.kernel.org/all/20260506082855.3694761-1-ben.horgan@arm.com/
Description from the initial cover letter:
The MPAM counter assignment (ABMC emulation) changes that were dropped from
the resctrl glue series due to some missing precursors in resctrl. Counter
assignment enables bandwidth monitoring in systems that have fewer
monitors than resctrl monitor groups.
rfc v1: https://lore.kernel.org/lkml/20260225205436.3571756-1-ben.horgan@arm.com/
rfc v2: https://lore.kernel.org/lkml/20260319165540.381410-1-ben.horgan@arm.com/
v3: https://lore.kernel.org/linux-arm-kernel/20260511154147.557481-1-ben.horgan@arm.com/
The code can be found at:
https://gitlab.arm.com/linux-arm/linux-bh.git mpam_abmc_v4
Ben Horgan (2):
arm_mpam: resctrl: Pre-allocate assignable monitors
arm64: mpam: Add memory bandwidth usage (MBWU) documentation
James Morse (3):
arm_mpam: resctrl: Pick classes for use as MBM counters
arm_mpam: resctrl: Add resctrl_arch_config_cntr() for ABMC use
arm_mpam: resctrl: Add resctrl_arch_cntr_read() &
resctrl_arch_reset_cntr()
Documentation/arch/arm64/mpam.rst | 17 ++
drivers/resctrl/mpam_internal.h | 6 +-
drivers/resctrl/mpam_resctrl.c | 308 +++++++++++++++++++++++++++---
3 files changed, 308 insertions(+), 23 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v4 2/5] arm_mpam: resctrl: Pre-allocate assignable monitors
From: Ben Horgan @ 2026-05-20 21:24 UTC (permalink / raw)
To: ben.horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jic23, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, zengheng4, x86
In-Reply-To: <20260520212458.1797221-1-ben.horgan@arm.com>
MPAM is able to emulate ABMC, i.e. mbm_event mode, by making memory
bandwidth monitors assignable. Rather than supporting the 'default'
mbm_assign_mode always use 'mbm_event' mode even if there are sufficient
memory bandwidth monitors. The per monitor event configuration is only
provided by resctrl when in 'mbm_event' mode and so only allowing
'mbm_event' mode will make it easier to support per-monitor event
configuration for MPAM. For the moment, the only event supported is
mbm_total_event with no bandwidth type configuration. The 'mbm_assign_mode'
file will still show 'default' when there is no support for memory
bandwidth monitoring.
The monitors need to be allocated from the driver, and mapped to whichever
control/monitor group resctrl wants to use them with.
Add a second array to hold the monitor values indexed by resctrl's cntr_id.
When CDP is in use, two monitors are needed so the available number of
counters halves. Platforms with one monitor will have zero monitors when
CDP is in use.
Co-developed-by: James Morse <james.morse@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
Changes since rfc v1:
abmc enabled even if enough counters
Helpers from dropped free running commits
carry on with zero counters if using cdp
set config bits
use kmalloc_objs
drop tags for rework
Configure mbm_cntr_configurable, mbm_cntr_assign_fixed
Changes since rfc v2:
Don't set mon->assigned_counters to an error pointer
Fix mpam_resctrl_teardown_mon()
Remove free running check
Separate cleanup allocations, e.g. __free(), from the rest
Restrict scope on err in mpam_resctrl_monitor_init()
Changes since v3:
Correct NULL check in mpam_resctrl_teardown_mon() (Shaopeng)
variable allocation ordering in mpam_resctrl_pick_domain_id() (Shaopeng)
Move mon.* assignments from mpam_resctrl_monitor_sync_abmc_vals()
to mpam_resctrl_monitor_init_abmc() counters (Sashiko)
use kvmalloc_obj() for allocations that may be big on some
platforms (Sashiko)
---
drivers/resctrl/mpam_internal.h | 6 +-
drivers/resctrl/mpam_resctrl.c | 139 +++++++++++++++++++++++++++++++-
2 files changed, 141 insertions(+), 4 deletions(-)
diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/mpam_internal.h
index 1914aefdcba9..7a166b395b5a 100644
--- a/drivers/resctrl/mpam_internal.h
+++ b/drivers/resctrl/mpam_internal.h
@@ -411,7 +411,11 @@ struct mpam_resctrl_res {
struct mpam_resctrl_mon {
struct mpam_class *class;
- /* per-class data that resctrl needs will live here */
+ /* Array of allocated MBWU monitors, indexed by (closid, rmid). */
+ int *mbwu_idx_to_mon;
+
+ /* Array of assigned MBWU monitors, indexed by idx argument. */
+ int *assigned_counters;
};
static inline int mpam_alloc_csu_mon(struct mpam_class *class)
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index f70fa65d39e4..a13eb232a19d 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -75,6 +75,8 @@ static DECLARE_WAIT_QUEUE_HEAD(wait_cacheinfo_ready);
*/
static bool resctrl_enabled;
+static unsigned int l3_num_allocated_mbwu = ~0;
+
bool resctrl_arch_alloc_capable(void)
{
struct mpam_resctrl_res *res;
@@ -140,7 +142,7 @@ int resctrl_arch_cntr_read(struct rdt_resource *r, struct rdt_l3_mon_domain *d,
bool resctrl_arch_mbm_cntr_assign_enabled(struct rdt_resource *r)
{
- return false;
+ return (r == &mpam_resctrl_controls[RDT_RESOURCE_L3].resctrl_res);
}
int resctrl_arch_mbm_cntr_assign_set(struct rdt_resource *r, bool enable)
@@ -185,6 +187,18 @@ static void resctrl_reset_task_closids(void)
read_unlock(&tasklist_lock);
}
+static void mpam_resctrl_monitor_sync_abmc_vals(struct rdt_resource *l3)
+{
+ l3->mon.num_mbm_cntrs = l3_num_allocated_mbwu;
+ if (cdp_enabled)
+ l3->mon.num_mbm_cntrs /= 2;
+
+ /*
+ * Continue as normal even if enabling cdp causes there to be
+ * zero counters. This avoid giving resctrl mixed messages.
+ */
+}
+
int resctrl_arch_set_cdp_enabled(enum resctrl_res_level rid, bool enable)
{
u32 partid_i = RESCTRL_RESERVED_CLOSID, partid_d = RESCTRL_RESERVED_CLOSID;
@@ -244,6 +258,7 @@ int resctrl_arch_set_cdp_enabled(enum resctrl_res_level rid, bool enable)
WRITE_ONCE(arm64_mpam_global_default, mpam_get_regval(current));
resctrl_reset_task_closids();
+ mpam_resctrl_monitor_sync_abmc_vals(l3);
for_each_possible_cpu(cpu)
mpam_set_cpu_defaults(cpu, partid_d, partid_i, 0, 0);
@@ -613,6 +628,9 @@ static bool class_has_usable_mbwu(struct mpam_class *class)
if (!mpam_has_feature(mpam_feat_msmon_mbwu, cprops))
return false;
+ if (!cprops->num_mbwu_mon)
+ return false;
+
return true;
}
@@ -935,6 +953,52 @@ static void mpam_resctrl_pick_mba(void)
}
}
+static void __free_mbwu_mon(struct mpam_class *class, int *array,
+ u16 num_mbwu_mon)
+{
+ for (int i = 0; i < num_mbwu_mon; i++) {
+ if (array[i] < 0)
+ continue;
+
+ mpam_free_mbwu_mon(class, array[i]);
+ array[i] = ~0;
+ }
+}
+
+static int __alloc_mbwu_mon(struct mpam_class *class, int *array,
+ u16 num_mbwu_mon)
+{
+ for (int i = 0; i < num_mbwu_mon; i++) {
+ int mbwu_mon = mpam_alloc_mbwu_mon(class);
+
+ if (mbwu_mon < 0) {
+ __free_mbwu_mon(class, array, num_mbwu_mon);
+ return mbwu_mon;
+ }
+ array[i] = mbwu_mon;
+ }
+
+ l3_num_allocated_mbwu = min(l3_num_allocated_mbwu, num_mbwu_mon);
+
+ return 0;
+}
+
+static int *__alloc_mbwu_array(struct mpam_class *class, u16 num_mbwu_mon)
+{
+ int err;
+
+ int *array __free(kvfree) = kvmalloc_objs(*array, num_mbwu_mon);
+ if (!array)
+ return ERR_PTR(-ENOMEM);
+
+ memset(array, -1, num_mbwu_mon * sizeof(*array));
+
+ err = __alloc_mbwu_mon(class, array, num_mbwu_mon);
+ if (err)
+ return ERR_PTR(err);
+ return_ptr(array);
+}
+
static void counter_update_class(enum resctrl_event_id evt_id,
struct mpam_class *class)
{
@@ -1089,6 +1153,43 @@ static int mpam_resctrl_pick_domain_id(int cpu, struct mpam_component *comp)
return comp->comp_id;
}
+/*
+ * This must run after all event counters have been picked so that any free
+ * running counters have already been allocated.
+ */
+static int mpam_resctrl_monitor_init_abmc(struct mpam_resctrl_mon *mon)
+{
+ struct mpam_resctrl_res *res = &mpam_resctrl_controls[RDT_RESOURCE_L3];
+ size_t num_rmid = resctrl_arch_system_num_rmid_idx();
+ struct rdt_resource *l3 = &res->resctrl_res;
+ struct mpam_class *class = mon->class;
+ u16 num_mbwu_mon;
+ int *cntrs;
+
+ int *rmid_array __free(kvfree) = kvmalloc_objs(*rmid_array, num_rmid);
+ if (!rmid_array) {
+ pr_debug("Failed to allocate RMID array\n");
+ return -ENOMEM;
+ }
+ memset(rmid_array, -1, num_rmid * sizeof(*rmid_array));
+
+ num_mbwu_mon = class->props.num_mbwu_mon;
+ cntrs = __alloc_mbwu_array(mon->class, num_mbwu_mon);
+ if (IS_ERR(cntrs))
+ return PTR_ERR(cntrs);
+ mon->assigned_counters = cntrs;
+ mon->mbwu_idx_to_mon = no_free_ptr(rmid_array);
+
+ l3->mon.mbm_cntr_assignable = true;
+ l3->mon.mbm_assign_on_mkdir = true;
+ l3->mon.mbm_cntr_configurable = false;
+ l3->mon.mbm_cntr_assign_fixed = true;
+
+ mpam_resctrl_monitor_sync_abmc_vals(l3);
+
+ return 0;
+}
+
static int mpam_resctrl_monitor_init(struct mpam_resctrl_mon *mon,
enum resctrl_event_id type)
{
@@ -1133,8 +1234,21 @@ static int mpam_resctrl_monitor_init(struct mpam_resctrl_mon *mon,
*/
l3->mon.num_rmid = resctrl_arch_system_num_rmid_idx();
- if (resctrl_enable_mon_event(type, false, 0, NULL))
- l3->mon_capable = true;
+ if (type == QOS_L3_MBM_TOTAL_EVENT_ID) {
+ int err;
+
+ err = mpam_resctrl_monitor_init_abmc(mon);
+ if (err)
+ return err;
+
+ static_assert(MAX_EVT_CONFIG_BITS == 0x7f);
+ l3->mon.mbm_cfg_mask = MAX_EVT_CONFIG_BITS;
+ }
+
+ if (!resctrl_enable_mon_event(type, false, 0, NULL))
+ return -EINVAL;
+
+ l3->mon_capable = true;
return 0;
}
@@ -1697,6 +1811,23 @@ void mpam_resctrl_exit(void)
resctrl_exit();
}
+static void mpam_resctrl_teardown_mon(struct mpam_resctrl_mon *mon, struct mpam_class *class)
+{
+ u32 num_mbwu_mon = l3_num_allocated_mbwu;
+
+ if (!mon->mbwu_idx_to_mon)
+ return;
+
+ if (mon->assigned_counters) {
+ __free_mbwu_mon(class, mon->assigned_counters, num_mbwu_mon);
+ kvfree(mon->assigned_counters);
+ mon->assigned_counters = NULL;
+ }
+
+ kvfree(mon->mbwu_idx_to_mon);
+ mon->mbwu_idx_to_mon = NULL;
+}
+
/*
* The driver is detaching an MSC from this class, if resctrl was using it,
* pull on resctrl_exit().
@@ -1719,6 +1850,8 @@ void mpam_resctrl_teardown_class(struct mpam_class *class)
for_each_mpam_resctrl_mon(mon, eventid) {
if (mon->class == class) {
mon->class = NULL;
+
+ mpam_resctrl_teardown_mon(mon, class);
break;
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/5] arm_mpam: resctrl: Pick classes for use as MBM counters
From: Ben Horgan @ 2026-05-20 21:24 UTC (permalink / raw)
To: ben.horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jic23, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, zengheng4, x86, Shaopeng Tan,
Jonathan Cameron
In-Reply-To: <20260520212458.1797221-1-ben.horgan@arm.com>
From: James Morse <james.morse@arm.com>
resctrl has two types of bandwidth counters, NUMA-local and global. MPAM
can only count globally; either using MSC at the L3 cache or in the memory
controllers. When global and local equate to the same thing continue just
to call it global.
Pick the corresponding MPAM classes to back the MBM counters. As resctrl
requires all monitors to be at the L3 cache, we can only use the counters
at the memory controllers when they have the same topology as the L3 cache
and the traffic they see if the same. In particular, for the bandwidth
counters at the memory controllers to be exposed to resctrl it is required
there is a single L3 cache and a single NUMA node as otherwise cross NUMA
traffic will be counted at the wrong instance.
Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Tested-by: Zeng Heng <zengheng4@huawei.com>
Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
Changes since rfc v1:
Move finding any_mon_comp into monitor boilerplate patch
Move mpam_resctrl_get_domain_from_cpu() into monitor boilerplate
Remove free running check
Trim commit message
Changes since v3:
Extra paragraph in commit message
---
drivers/resctrl/mpam_resctrl.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index 226ff6f532fa..f70fa65d39e4 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -606,6 +606,16 @@ static bool cache_has_usable_csu(struct mpam_class *class)
return true;
}
+static bool class_has_usable_mbwu(struct mpam_class *class)
+{
+ struct mpam_props *cprops = &class->props;
+
+ if (!mpam_has_feature(mpam_feat_msmon_mbwu, cprops))
+ return false;
+
+ return true;
+}
+
/*
* Calculate the worst-case percentage change from each implemented step
* in the control.
@@ -983,6 +993,22 @@ static void mpam_resctrl_pick_counters(void)
break;
}
}
+
+ if (class_has_usable_mbwu(class) &&
+ topology_matches_l3(class) &&
+ traffic_matches_l3(class)) {
+ pr_debug("class %u has usable MBWU, and matches L3 topology and traffic\n",
+ class->level);
+
+ /*
+ * We can't distinguish traffic by destination so
+ * we don't know if it's staying on the same NUMA
+ * node. Hence, we can't calculate mbm_local except
+ * when we only have one L3 and it's equivalent to
+ * mbm_total and so always use mbm_total.
+ */
+ counter_update_class(QOS_L3_MBM_TOTAL_EVENT_ID, class);
+ }
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/5] arm_mpam: resctrl: Add resctrl_arch_config_cntr() for ABMC use
From: Ben Horgan @ 2026-05-20 21:24 UTC (permalink / raw)
To: ben.horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jic23, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, zengheng4, x86, Jonathan Cameron
In-Reply-To: <20260520212458.1797221-1-ben.horgan@arm.com>
From: James Morse <james.morse@arm.com>
ABMC, mbm_event mode, has a helper resctrl_arch_config_cntr() for changing
the mapping between 'cntr_id' and a CLOSID/RMID pair.
Add the helper.
For MPAM this is done by updating the mon->mbwu_idx_to_mon[] array, and as
usual CDP means it needs doing in three different ways.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
Changes since new rfc:
Mention mbm_event mode in commit message
Changes since v3:
Warning bound (Sashiko)
---
drivers/resctrl/mpam_resctrl.c | 44 +++++++++++++++++++++++++++++-----
1 file changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index a13eb232a19d..1f9a8ae157ca 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -127,12 +127,6 @@ void resctrl_arch_reset_cntr(struct rdt_resource *r, struct rdt_l3_mon_domain *d
{
}
-void resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_l3_mon_domain *d,
- enum resctrl_event_id evtid, u32 rmid, u32 closid,
- u32 cntr_id, bool assign)
-{
-}
-
int resctrl_arch_cntr_read(struct rdt_resource *r, struct rdt_l3_mon_domain *d,
u32 unused, u32 rmid, int cntr_id,
enum resctrl_event_id eventid, u64 *val)
@@ -1076,6 +1070,44 @@ static void mpam_resctrl_pick_counters(void)
}
}
+static void __config_cntr(struct mpam_resctrl_mon *mon, u32 cntr_id,
+ enum resctrl_conf_type cdp_type, u32 closid, u32 rmid,
+ bool assign)
+{
+ u32 mbwu_idx, mon_idx = resctrl_get_config_index(cntr_id, cdp_type);
+
+ WARN_ON_ONCE(mon_idx >= l3_num_allocated_mbwu);
+
+ closid = resctrl_get_config_index(closid, cdp_type);
+ mbwu_idx = resctrl_arch_rmid_idx_encode(closid, rmid);
+
+ if (assign)
+ mon->mbwu_idx_to_mon[mbwu_idx] = mon->assigned_counters[mon_idx];
+ else
+ mon->mbwu_idx_to_mon[mbwu_idx] = -1;
+}
+
+void resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_l3_mon_domain *d,
+ enum resctrl_event_id evtid, u32 rmid, u32 closid,
+ u32 cntr_id, bool assign)
+{
+ struct mpam_resctrl_mon *mon = &mpam_resctrl_counters[evtid];
+
+ if (!mon->mbwu_idx_to_mon || !mon->assigned_counters) {
+ pr_debug("monitor arrays not allocated\n");
+ return;
+ }
+
+ if (cdp_enabled) {
+ __config_cntr(mon, cntr_id, CDP_CODE, closid, rmid, assign);
+ __config_cntr(mon, cntr_id, CDP_DATA, closid, rmid, assign);
+ } else {
+ __config_cntr(mon, cntr_id, CDP_NONE, closid, rmid, assign);
+ }
+
+ resctrl_arch_reset_rmid(r, d, closid, rmid, evtid);
+}
+
static int mpam_resctrl_control_init(struct mpam_resctrl_res *res)
{
struct mpam_class *class = res->class;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 4/5] arm_mpam: resctrl: Add resctrl_arch_cntr_read() & resctrl_arch_reset_cntr()
From: Ben Horgan @ 2026-05-20 21:24 UTC (permalink / raw)
To: ben.horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jic23, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, zengheng4, x86, Jonathan Cameron
In-Reply-To: <20260520212458.1797221-1-ben.horgan@arm.com>
From: James Morse <james.morse@arm.com>
When used in 'mbm_event' mode, ABMC emulation, resctrl uses arch hooks to
read and reset the memory bandwidth utilization (MBWU) counters.
Add these.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
Changes since rfc v1:
Move __reset_mon() and reset_mon_cdp_safe() helpers here
support mbwu in __read_mon()
Mention mbm_event mode in commit message
Changes since v3:
USE_PREALLOCATED_IDX, separate h/w counters are needed for code and data
when cdp_enabled is true
---
drivers/resctrl/mpam_resctrl.c | 99 +++++++++++++++++++++++++++++-----
1 file changed, 86 insertions(+), 13 deletions(-)
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index 1f9a8ae157ca..d236ecd38aa3 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -121,19 +121,6 @@ void resctrl_arch_reset_rmid(struct rdt_resource *r, struct rdt_l3_mon_domain *d
{
}
-void resctrl_arch_reset_cntr(struct rdt_resource *r, struct rdt_l3_mon_domain *d,
- u32 closid, u32 rmid, int cntr_id,
- enum resctrl_event_id eventid)
-{
-}
-
-int resctrl_arch_cntr_read(struct rdt_resource *r, struct rdt_l3_mon_domain *d,
- u32 unused, u32 rmid, int cntr_id,
- enum resctrl_event_id eventid, u64 *val)
-{
- return -EOPNOTSUPP;
-}
-
bool resctrl_arch_mbm_cntr_assign_enabled(struct rdt_resource *r)
{
return (r == &mpam_resctrl_controls[RDT_RESOURCE_L3].resctrl_res);
@@ -463,6 +450,14 @@ static int __read_mon(struct mpam_resctrl_mon *mon, struct mpam_component *mon_c
/* Shift closid to account for CDP */
closid = resctrl_get_config_index(closid, cdp_type);
+ if (mon_idx == USE_PRE_ALLOCATED) {
+ int mbwu_idx = resctrl_arch_rmid_idx_encode(closid, rmid);
+
+ mon_idx = mon->mbwu_idx_to_mon[mbwu_idx];
+ if (mon_idx == -1)
+ return -ENOENT;
+ }
+
if (irqs_disabled()) {
/* Check if we can access this domain without an IPI */
return -EIO;
@@ -535,6 +530,84 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain_hdr *hdr,
closid, rmid, val);
}
+/* MBWU counters when in ABMC mode */
+int resctrl_arch_cntr_read(struct rdt_resource *r, struct rdt_l3_mon_domain *d,
+ u32 closid, u32 rmid, int mon_idx,
+ enum resctrl_event_id eventid, u64 *val)
+{
+ struct mpam_resctrl_mon *mon = &mpam_resctrl_counters[eventid];
+ struct mpam_resctrl_dom *l3_dom;
+ struct mpam_component *mon_comp;
+
+ if (!mpam_is_enabled())
+ return -EINVAL;
+
+ if (eventid == QOS_L3_OCCUP_EVENT_ID || !mon->class)
+ return -EINVAL;
+
+ l3_dom = container_of(d, struct mpam_resctrl_dom, resctrl_mon_dom);
+ mon_comp = l3_dom->mon_comp[eventid];
+
+ return read_mon_cdp_safe(mon, mon_comp, mpam_feat_msmon_mbwu,
+ USE_PRE_ALLOCATED, closid, rmid, val);
+}
+
+static void __reset_mon(struct mpam_resctrl_mon *mon, struct mpam_component *mon_comp,
+ int mon_idx,
+ enum resctrl_conf_type cdp_type, u32 closid, u32 rmid)
+{
+ struct mon_cfg cfg = { };
+
+ if (!mpam_is_enabled())
+ return;
+
+ /* Shift closid to account for CDP */
+ closid = resctrl_get_config_index(closid, cdp_type);
+
+ if (mon_idx == USE_PRE_ALLOCATED) {
+ int mbwu_idx = resctrl_arch_rmid_idx_encode(closid, rmid);
+
+ mon_idx = mon->mbwu_idx_to_mon[mbwu_idx];
+ }
+
+ if (mon_idx == -1)
+ return;
+ cfg.mon = mon_idx;
+ mpam_msmon_reset_mbwu(mon_comp, &cfg);
+}
+
+static void reset_mon_cdp_safe(struct mpam_resctrl_mon *mon, struct mpam_component *mon_comp,
+ int mon_idx, u32 closid, u32 rmid)
+{
+ if (cdp_enabled) {
+ __reset_mon(mon, mon_comp, mon_idx, CDP_CODE, closid, rmid);
+ __reset_mon(mon, mon_comp, mon_idx, CDP_DATA, closid, rmid);
+ } else {
+ __reset_mon(mon, mon_comp, mon_idx, CDP_NONE, closid, rmid);
+ }
+}
+
+/* Reset an assigned counter */
+void resctrl_arch_reset_cntr(struct rdt_resource *r, struct rdt_l3_mon_domain *d,
+ u32 closid, u32 rmid, int cntr_id,
+ enum resctrl_event_id eventid)
+{
+ struct mpam_resctrl_mon *mon = &mpam_resctrl_counters[eventid];
+ struct mpam_resctrl_dom *l3_dom;
+ struct mpam_component *mon_comp;
+
+ if (!mpam_is_enabled())
+ return;
+
+ if (eventid == QOS_L3_OCCUP_EVENT_ID || !mon->class)
+ return;
+
+ l3_dom = container_of(d, struct mpam_resctrl_dom, resctrl_mon_dom);
+ mon_comp = l3_dom->mon_comp[eventid];
+
+ reset_mon_cdp_safe(mon, mon_comp, USE_PRE_ALLOCATED, closid, rmid);
+}
+
/*
* The rmid realloc threshold should be for the smallest cache exposed to
* resctrl.
--
2.43.0
^ permalink raw reply related
* [PATCH v4 5/5] arm64: mpam: Add memory bandwidth usage (MBWU) documentation
From: Ben Horgan @ 2026-05-20 21:24 UTC (permalink / raw)
To: ben.horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jic23, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, zengheng4, x86
In-Reply-To: <20260520212458.1797221-1-ben.horgan@arm.com>
Memory bandwidth monitoring make uses of MBWU monitors and is now exposed
to the user via resctrl. Add some documentation so the user knows what to
expect.
Co-developed-by: James Morse <james.morse@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
Documentation/arch/arm64/mpam.rst | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/Documentation/arch/arm64/mpam.rst b/Documentation/arch/arm64/mpam.rst
index 570f51a8d4eb..208ff17068c4 100644
--- a/Documentation/arch/arm64/mpam.rst
+++ b/Documentation/arch/arm64/mpam.rst
@@ -65,6 +65,23 @@ The supported features are:
there is at least one CSU monitor on each MSC that makes up the L3 group.
Exposing CSU counters from other caches or devices is not supported.
+* Memory Bandwidth Usage (MBWU) on or after the L3 cache. resctrl uses the
+ L3 cache-id to identify where the memory bandwidth is measured. For this
+ reason the platform must have an L3 cache with cache-id's supplied by
+ firmware. (It doesn't need to support MPAM.)
+
+ Memory bandwidth monitoring makes use of MBWU monitors in each MSC that
+ makes up the L3 group. If the memory bandwidth monitoring is on the memory
+ rather than the L3 then there must be a single global L3 as otherwise it
+ is unknown which L3 the traffic came from.
+
+ To expose 'mbm_total_bytes', the topology of the group of MSC chosen must
+ match the topology of the L3 cache so that the cache-id's can be
+ repainted. For example: Platforms with Memory bandwidth monitors on
+ CPU-less NUMA nodes cannot expose 'mbm_total_bytes' as these nodes do not
+ have a corresponding L3 cache. 'mbm_local_bytes' is not exposed as MPAM
+ cannot distinguish local traffic from global traffic.
+
Reporting Bugs
==============
If you are not seeing the counters or controls you expect please share the
--
2.43.0
^ permalink raw reply related
* [PATCH] ARM: footbridge: remove redundant checks for CONFIG_NEW_LEDS
From: Ethan Nelson-Moore @ 2026-05-20 21:26 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Ethan Nelson-Moore, Russell King
Code in mach-footbridge checks for both CONFIG_NEW_LEDS and
CONFIG_LEDS_CLASS. CONFIG_LEDS_CLASS depends on CONFIG_NEW_LEDS, and
therefore checking for both is unnecessary. Remove the checks for
CONFIG_NEW_LEDS.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
| 2 +-
| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--git a/arch/arm/mach-footbridge/ebsa285.c b/arch/arm/mach-footbridge/ebsa285.c
index a65554b1c1d8..2e23c35a4f28 100644
--- a/arch/arm/mach-footbridge/ebsa285.c
+++ b/arch/arm/mach-footbridge/ebsa285.c
@@ -19,7 +19,7 @@
#include "common.h"
/* LEDs */
-#if defined(CONFIG_NEW_LEDS) && defined(CONFIG_LEDS_CLASS)
+#ifdef CONFIG_LEDS_CLASS
#define XBUS_AMBER_L BIT(0)
#define XBUS_GREEN_L BIT(1)
#define XBUS_RED_L BIT(2)
--git a/arch/arm/mach-footbridge/netwinder-hw.c b/arch/arm/mach-footbridge/netwinder-hw.c
index a33f4c3b9505..14989d557ebf 100644
--- a/arch/arm/mach-footbridge/netwinder-hw.c
+++ b/arch/arm/mach-footbridge/netwinder-hw.c
@@ -701,7 +701,7 @@ static void netwinder_restart(enum reboot_mode mode, const char *cmd)
}
/* LEDs */
-#if defined(CONFIG_NEW_LEDS) && defined(CONFIG_LEDS_CLASS)
+#ifdef CONFIG_LEDS_CLASS
struct netwinder_led {
struct led_classdev cdev;
u8 mask;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/8] mm: Add ptep_try_install() for lockless empty-slot installs
From: David Hildenbrand (Arm) @ 2026-05-20 21:29 UTC (permalink / raw)
To: Tejun Heo
Cc: Alexei Starovoitov, David Vernet, Andrea Righi, Changwoo Min,
Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
Martin KaFai Lau, Kumar Kartikeya Dwivedi, Catalin Marinas,
Will Deacon, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, Andrew Morton, Mike Rapoport, Emil Tsalapatis,
sched-ext, bpf, X86 ML, linux-arm-kernel, linux-mm, LKML
In-Reply-To: <ag3_qpKObFOLKgbR@slm.duckdns.org>
On 5/20/26 20:38, Tejun Heo wrote:
> On Wed, May 20, 2026 at 10:41:15AM +0200, David Hildenbrand (Arm) wrote:
>> And that should be carefully documented.
>
> Will do.
>
>>> The fault handler has to install _some_ page and let kernel continue.
>>> Scratch page or arena page doesn't matter. Potentially different CPUs
>>> will see different page. It's not a concern at all.
>>> bpf prog is buggy, but the kernel will continue to work without a glitch.
>>> bpf runtime will disable and unload misbehaving prog.
>>
>> Having one page table walker overwrite a scratch page on race is just rather ...
>> questionable locking design, that just screams for problems long-term, really.
>>
>> At least in apply_range_clear_cb() one could similarly switch to
>> ptep_try_install() to at least have both these paths handle races in a
>> reasonable way. (having to handle when ptep_try_install() is not really implemented)
>
> Hmm... wouldn't that be more confusing on apply_range_clear_cb() side?
> Whether it maintains the current behavior (if collide with scratch, try
> again with scratch as the original value) or flip the behavior (fail if
> scratch), that extra logic is spurious, and those tend to confuse people as
> they force asking why it has to be that specific way. If the goal is
> documenting the subtlety, wouldn't a detailed comment serve the purpose
> better?
I would let all operations that can happen concurrently work with atomics, not
just a single one.
Alexei correctly concluded that ptep_get_and_clear() might be one option that
should do on x86 and arm64 from a quick glimpse.
>
>> Anyhow, the documentation of ptep_try_install() must clearly spell out that this
>> must be used very carefully, and only in special kernel page tables, never user
>> page tables. There are likely other scenarios we should document (caller must
>> prevent concurrent page table teardown somehow, and must be prepared to handle
>> races if other code is not using atomics).
>>
>> To highlight that, we should likely consider adding a "kernel" in the name, like
>> "ptep_try_install_kernel()".
>>
>> I am also not sure if "install" is the right terminology and whether it should
>> instead be "ptep_try_set()". (set_pte_at is the non-atomic interface right now)
>
> So, ptep_try_set_kernel()?
I guess we could do that, but we don't have a lot of existing functions that are
specific to kernel page tables ... only pte_offset_kernel() and
pte_alloc_one_kernel()/pte_free_kernel().
The most important part is getting the documentation right.
We should probably document that code concurrently clearing PTEs should be using
ptep_get_and_clear().
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v7 1/2] media: dt-bindings: Add CSI Pixel Formatter DT bindings
From: Laurent Pinchart @ 2026-05-20 21:33 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Frank Li, imx, linux-media, devicetree,
linux-arm-kernel, linux-kernel, Guoniu Zhou, Krzysztof Kozlowski
In-Reply-To: <20260518-csi_formatter-v7-1-562b750557e3@oss.nxp.com>
Hi Guoniu,
Thank you for the patch.
On Mon, May 18, 2026 at 10:19:46AM +0800, Guoniu Zhou wrote:
> From: Guoniu Zhou <guoniu.zhou@nxp.com>
>
> The i.MX95 CSI pixel formatting module uses packet info, pixel and
> non-pixel data from the CSI-2 host controller and reformat them to
> match Pixel Link(PL) definition.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> ---
> Changes in v7:
> - Change compatible to imx95-csi-formatter as IP is i.MX95 specific per Marco's suggestion
> Link: https://lore.kernel.org/linux-media/20260511-csi_formatter-v6-0-01028e312e2b@oss.nxp.com/T/#mcd135b3de179b3cb69daa1fd6e0e8e27c85b3332
> ---
> .../bindings/media/fsl,imx95-csi-formatter.yaml | 87 ++++++++++++++++++++++
> 1 file changed, 87 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml b/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml
> new file mode 100644
> index 000000000000..28adea06c494
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml
> @@ -0,0 +1,87 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/fsl,imx95-csi-formatter.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: i.MX95 CSI Pixel Formatter
> +
> +maintainers:
> + - Guoniu Zhou <guoniu.zhou@nxp.com>
> +
> +description:
> + The CSI pixel formatting module found on i.MX95 uses packet info, pixel
> + and non-pixel data from the CSI-2 host controller and reformat them to
> + match Pixel Link(PL) definition.
> +
> +properties:
> + compatible:
> + const: fsl,imx95-csi-formatter
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description: MIPI CSI-2 RX IDI interface
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
What properties defined in video-interfaces.yaml do you expect ? The
example below does not use any, and the driver in 2/2 doesn't appear to
parse any either.
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: Pixel Link Interface
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - power-domains
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/nxp,imx95-clock.h>
> +
> + formatter@20 {
> + compatible = "fsl,imx95-csi-formatter";
> + reg = <0x20 0x100>;
> + clocks = <&cameramix_csr IMX95_CLK_CAMBLK_CSI2_FOR0>;
> + power-domains = <&scmi_devpd 3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + endpoint {
> + remote-endpoint = <&mipi_csi_0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + endpoint {
> + remote-endpoint = <&isi_in_2>;
> + };
> + };
> + };
> + };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: David Hildenbrand (Arm) @ 2026-05-20 21:35 UTC (permalink / raw)
To: Matthew Wilcox, Barry Song
Cc: Liam R. Howlett, Suren Baghdasaryan, Lorenzo Stoakes, akpm,
linux-mm, 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: <ag4kj84EcKqamdB-@casper.infradead.org>
On 5/20/26 23:15, Matthew Wilcox wrote:
> On Thu, May 21, 2026 at 05:14:20AM +0800, Barry Song wrote:
>> My understanding is that we should not blame applications here. This is 2026:
>> there are basically only two kinds of applications — single-threaded and
>> multi-threaded — and single-threaded applications are nearly extinct.
>
> all of the applications i run are either single threaded or don't fork.
> what multithreaded applications call fork?
Traditionally the problem was random libraries using fork+execve to launch other
programs ... instead of using alternatives like posix_spwan (some use cases
require more work done before execve and cannot yet switch to that). I'd hope
that that is less of a problem on Android.
I assume Android zygote might be multi threaded? Maybe sshd as well? Systemd?
But I'd be surprised if there are really performance implications.
Not sure about webbroswers .... I think most of them switched to fork servers,
where I would assume fork servers would be single-threaded.
So, yeah, getting a clear understanding how this ends up being a problem on
Android would be great.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Yang Shi @ 2026-05-20 21:39 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Lorenzo Stoakes, Suren Baghdasaryan, Barry Song, Matthew Wilcox,
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: <e6d1017a-e4c5-493e-bfca-932c6d64eaac@kernel.org>
On Wed, May 20, 2026 at 3:34 AM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 5/19/26 14:53, Lorenzo Stoakes wrote:
> > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan 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.
> >
> > Not sure if you noticed but I did raise concerns ;)
> >
> > I wonder if you've confused the fault path and fork here, as I think Barry has
> > been a little unclear on that.
> >
> > What's being suggested in this thread is to fundamentally change fork behaviour
> > so it's different from the entire history of the kernel (or - presumably - at
> > least recent history :)
> I don't want fork() to become different in that regard.
>
> There is already a slight difference with vs. without per-VMA locks, because
> there is a window in-between us taking the write mmap_lock and all the per-VMA
> locks. I raised that previously [1] and assumed that it is probably fine.
>
> I also raised in the past why I think we must not allow concurrent page faults,
> at least as soon as anonymous memory is involved [2].
Thanks for sharing the context, it is quite helpful to understand the
race conditions. Because Lorenzo also raised the concern about page
fault race, I will reply to all the concerns regarding page fault race
together in this thread.
IIUC, there is already some sort of race with per vma lock. Before per
vma lock, mmap_lock did lock everything. So page fault happened either
before fork or after fork. But page fault can happen on other VMAs
which have not been lock'ed yet during fork with per vma lock. For
example, we have 3 VMAs, we lock the first VMA, but page fault still
can happen on the other 2 VMAs during fork if they already have
anon_vma. This is the status quo now, but it seems not harmful.
The bad race shared by David is caused by racing with copy page. So it
seems like it will be fine as long as we serialize copy page against
page fault if I don't miss anything. Since we decide whether to copy
page or not by checking vma->anon_vma, so it seems fine to not take
vma lock if vma->anon_vma is NULL. This will not introduce more race
either because setting up a new anon_vma in page fault or madvise
requires taking mmap_lock according to the earlier discussions.
Thanks,
Yang
>
> ... and I raised that this is pretty much slower by design right now: "Well, the
> design decision that CONFIG_PER_VMA_LOCK made for now to make page faults fast
> and to make blocking any page faults from happening to be slower ..." [3]
>
> [1] https://lore.kernel.org/all/970295ab-e85d-7af3-76e6-df53a5c52f8b@redhat.com/
> [2] https://lore.kernel.org/all/7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com/
> [3] https://lore.kernel.org/all/2efa2c89-3765-721d-2c3c-00590054aa5b@redhat.com/
>
> --
> Cheers,
>
> David
>
^ permalink raw reply
* Re: [PATCH 09/10] [v6 omap] ARM: dts: omap2: add stlc4560 spi-wireless node
From: Johannes Berg @ 2026-05-20 21:39 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: linux-kernel, Arnd Bergmann, Christian Lamparter, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Thomas Bogendoerfer, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, Matti Vaittinen, Florian Fainelli, Jonas Gorski,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-wireless, linux-omap,
linux-arm-kernel, linux-mips, linux-sh, linux-input, linux-leds,
netdev, Krzysztof Kozlowski
In-Reply-To: <20260520183815.2510387-10-arnd@kernel.org>
On Wed, 2026-05-20 at 20:38 +0200, Arnd Bergmann wrote:
>
> v1 through v5: adaptations that correspond to the binding updates
FWIW, I had just applied v5 of these three patches today, but didn't
send out a pull request yet. I'll do that tomorrow morning.
johannes
^ permalink raw reply
* Re: [PATCH 09/10] [v6 omap] ARM: dts: omap2: add stlc4560 spi-wireless node
From: Andreas Kemnade @ 2026-05-20 21:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, linux-kernel, Arnd Bergmann, Christian Lamparter,
Johannes Berg, Aaro Koskinen, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Bogendoerfer, John Paul Adrian Glaubitz,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Lee Jones, Pavel Machek, Matti Vaittinen,
Florian Fainelli, Jonas Gorski, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-wireless, linux-omap, linux-arm-kernel, linux-mips,
linux-sh, linux-input, linux-leds, netdev, Krzysztof Kozlowski
In-Reply-To: <20260520183815.2510387-10-arnd@kernel.org>
On Wed, 20 May 2026 20:38:14 +0200
Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Converted from the platform_device creation in board-n8x0.c.
>
> Link: https://lore.kernel.org/all/20230314163201.955689-1-arnd@kernel.org/
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v6: no changes
> v1 through v5: adaptations that correspond to the binding updates
> ---
> arch/arm/boot/dts/ti/omap/omap2.dtsi | 4 ++++
> arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi | 12 ++++++++++++
> 2 files changed, 16 insertions(+)
>
Reviewed-by: Andreas Kemnade <andreas@kemnade.info>
^ 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