* Re: [PATCH 04/10] [v2] sh: select legacy gpiolib interface
From: John Paul Adrian Glaubitz @ 2026-05-21 6:49 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: linux-kernel, Arnd Bergmann, Christian Lamparter, Johannes Berg,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Bogendoerfer, 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
In-Reply-To: <20260520183815.2510387-5-arnd@kernel.org>
Hi Arnd,
On Wed, 2026-05-20 at 20:38 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Many board files on sh reference the legacy gpiolib interfaces that
> are becoming optional. To ensure the boards can keep building, select
> CONFIG_GPIOLIB_LEGACY on each of the boards that have one of the
> hardcoded calls.
>
> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2: no changes. Adrian said he'll pick it up for 7.2, but so
> far the patch is not in linux-next yet, so I'm including it
> for completeness here.
Sorry, I hadn't gotten around to pick the changes for v7.2 yet. I can
pick it up this weekend as I was planning to review and merge some
patches this weekend.
I have received quite a lot of patches for SH recently, so it will take
some time to dig myself through the queue.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* [PATCH v3] usb: gadget: aspeed_udc: avoid past-the-end iterator in dequeue
From: Maoyi Xie @ 2026-05-21 6:54 UTC (permalink / raw)
To: Andrew Jeffery, Neal Liu
Cc: Greg Kroah-Hartman, Benjamin Herrenschmidt, Joel Stanley,
Andrew Lunn, Alan Stern, linux-aspeed, linux-arm-kernel,
linux-usb, linux-kernel
In-Reply-To: <20260519080213.1932516-1-maoyixie.tju@gmail.com>
ast_udc_ep_dequeue() declares the loop cursor `req` outside the
list_for_each_entry(). After the loop it tests `&req->req != _req`
to decide whether the request was found. If the queue holds no
match, `req` is past-the-end. It then aliases
container_of(&ep->queue, struct ast_udc_request, queue) via offset
cancellation. Whether that synthetic address equals `_req` depends
on heap layout. The function can return 0 without dequeueing
anything.
Default `rc` to -EINVAL and set it to 0 only inside the match
branch. `req` is no longer read after the loop, so the past-the-end
dereference goes away. No extra cursor variable or post-loop test
is needed.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Suggested-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
v3: Switch to Andrew Jeffery's shape: default rc to -EINVAL, set
rc=0 inside the match branch, drop the post-loop check. Smaller
diff, no extra cursor variable, no goto. Same semantic fix as v2.
v2: https://lore.kernel.org/linux-usb/20260519080213.1932516-1-maoyixie.tju@gmail.com/
v1: https://lore.kernel.org/linux-usb/20260518073403.1285339-1-maoyi.xie@ntu.edu.sg/
drivers/usb/gadget/udc/aspeed_udc.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/udc/aspeed_udc.c b/drivers/usb/gadget/udc/aspeed_udc.c
index 7fc6696b7694..75f9c831b21a 100644
--- a/drivers/usb/gadget/udc/aspeed_udc.c
+++ b/drivers/usb/gadget/udc/aspeed_udc.c
@@ -694,7 +694,7 @@ static int ast_udc_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
struct ast_udc_dev *udc = ep->udc;
struct ast_udc_request *req;
unsigned long flags;
- int rc = 0;
+ int rc = -EINVAL;
spin_lock_irqsave(&udc->lock, flags);
@@ -704,14 +704,11 @@ static int ast_udc_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
list_del_init(&req->queue);
ast_udc_done(ep, req, -ESHUTDOWN);
_req->status = -ECONNRESET;
+ rc = 0;
break;
}
}
- /* dequeue request not found */
- if (&req->req != _req)
- rc = -EINVAL;
-
spin_unlock_irqrestore(&udc->lock, flags);
return rc;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/8] mm: Add ptep_try_set() for lockless empty-slot installs
From: Andrea Righi @ 2026-05-21 7:00 UTC (permalink / raw)
To: Tejun Heo
Cc: David Vernet, Changwoo Min, Alexei Starovoitov, Andrii Nakryiko,
Daniel Borkmann, Martin KaFai Lau, Kumar Kartikeya Dwivedi,
Peter Zijlstra, Catalin Marinas, Will Deacon, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, Andrew Morton,
David Hildenbrand, Mike Rapoport, Emil Tsalapatis, sched-ext, bpf,
x86, linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <20260520235052.4180316-2-tj@kernel.org>
Hi Tejun,
On Wed, May 20, 2026 at 01:50:45PM -1000, Tejun Heo wrote:
> Add ptep_try_set(ptep, new_pte): atomically set *ptep to new_pte iff it is
> currently pte_none(). Returns true on success, false if the slot was already
> populated or the arch has no implementation.
>
> The intended caller is the upcoming bpf_arena kernel-side fault recovery
> path. The install runs from a page fault that can be nested under locks
> held by the faulting kernel caller (e.g. a BPF program holding
> raw_res_spin_lock_irqsave on its arena's spinlock), so trylock-and-retry
> would A-A deadlock. Lock-free cmpxchg is the only viable option, which
> constrains this helper to special kernel page tables where concurrent
> writers cooperate via atomic accessors.
>
> The generic version in <linux/pgtable.h> returns false. x86 and arm64
> override with try_cmpxchg-based implementations on the underlying pteval.
> Other architectures get the false stub - the callers there already fall
> through to oops.
>
> v2: Rename to ptep_try_set(). Tighten kerneldoc for kernel-PTE use.
> (David, Alexei)
>
> Suggested-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Suggested-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: David Hildenbrand <david@kernel.org>
> ---
> arch/arm64/include/asm/pgtable.h | 8 ++++++++
> arch/x86/include/asm/pgtable.h | 8 ++++++++
> include/linux/pgtable.h | 26 ++++++++++++++++++++++++++
> 3 files changed, 42 insertions(+)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 9029b81ccbe8..a129be91ef2c 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -1830,6 +1830,14 @@ static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
> return __ptep_get_and_clear(mm, addr, ptep);
> }
>
> +static inline bool ptep_try_set(pte_t *ptep, pte_t new_pte)
> +{
> + pteval_t old = 0;
> +
> + return try_cmpxchg(&pte_val(*ptep), &old, pte_val(new_pte));
> +}
> +#define ptep_try_set ptep_try_set
> +
> #define test_and_clear_young_ptes test_and_clear_young_ptes
> static inline bool test_and_clear_young_ptes(struct vm_area_struct *vma,
> unsigned long addr, pte_t *ptep, unsigned int nr)
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index 13e3e9a054cb..047e273a4eab 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -1284,6 +1284,14 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm,
> } while (!try_cmpxchg((long *)&ptep->pte, (long *)&old_pte, *(long *)&new_pte));
> }
>
> +static inline bool ptep_try_set(pte_t *ptep, pte_t new_pte)
> +{
> + pte_t old_pte = __pte(0);
> +
> + return try_cmpxchg((long *)&ptep->pte, (long *)&old_pte, *(long *)&new_pte);
> +}
Minor nit (feel free to ignore), on x86 pte_none() is defined as:
static inline int pte_none(pte_t pte)
{
return !(pte.pte & ~(_PAGE_KNL_ERRATUM_MASK));
}
With:
#if defined(CONFIG_X86_64) || defined(CONFIG_X86_PAE)
#define _PAGE_KNL_ERRATUM_MASK (_PAGE_DIRTY | _PAGE_ACCESSED)
#else
#define _PAGE_KNL_ERRATUM_MASK 0
#endif
If that mask has the D/A bits set, try_cmpxchg(..., &old=0, ...) will reject a
PTE that has only those bits set, even though pte_none() would return true. I
think this is fine for the bpf_arena use case, since hardware shouldn't set A/D
for fresh pages that the BPF prog hasn't touched.
Maybe it's worth adding a comment (something along these lines)?
/*
* Note: strictly-zero compare is narrower than pte_none() (see pte_none() and
* _PAGE_KNL_ERRATUM_MASK), but the gap is harmless in practice: HW shouldn't
* set _PAGE_DIRTY | _PAGE_ACCESSED bits on entries the caller never touched.
*/
Other than that, looks good to me.
Reviewed-by: Andrea Righi <arighi@nvidia.com>
Thanks,
-Andrea
> +#define ptep_try_set ptep_try_set
> +
> #define flush_tlb_fix_spurious_fault(vma, address, ptep) do { } while (0)
>
> #define __HAVE_ARCH_PMDP_SET_ACCESS_FLAGS
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index cdd68ed3ae1a..d68374f404c1 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -1036,6 +1036,32 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addres
> }
> #endif
>
> +#ifndef ptep_try_set
> +/**
> + * ptep_try_set - atomically set an empty kernel PTE
> + * @ptep: page table entry
> + * @new_pte: value to install
> + *
> + * Atomically set *@ptep to @new_pte iff *@ptep is pte_none(). Return
> + * true on success, false if the slot was already populated or the
> + * arch has no implementation.
> + *
> + * For special kernel page tables only - never user page tables. The
> + * caller must prevent concurrent teardown of @ptep and must accept
> + * that other writers may race. Concurrent clearers must use
> + * ptep_get_and_clear() so racing accesses agree on the outcome.
> + *
> + * Architectures opt in by providing a cmpxchg-based override and
> + * defining ptep_try_set as an identity macro. The generic stub
> + * returns false, which is correct for callers that fall through to
> + * oops on failure.
> + */
> +static inline bool ptep_try_set(pte_t *ptep, pte_t new_pte)
> +{
> + return false;
> +}
> +#endif
> +
> #ifndef wrprotect_ptes
> /**
> * wrprotect_ptes - Write-protect PTEs that map consecutive pages of the same
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v2 0/2] KVM: arm64: nv: Reduce FP/SVE overhead on exception/exception return
From: Marc Zyngier @ 2026-05-21 7:07 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm, Marc Zyngier
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Mark Rutland, Will Deacon, Fuad Tabba
In-Reply-To: <20260520085036.541666-1-maz@kernel.org>
On Wed, 20 May 2026 09:50:34 +0100, Marc Zyngier wrote:
> This is the second version of this short series optimising away a lot
> of unnecessary FPSIMD/SVE context switch with NV.
>
> * From v1 [1]:
>
> - New commit message on patch #2 (Mark)
>
> [...]
Applied to next, thanks!
[1/2] KVM: arm64: nv: Track L2 to L1 exception emulation
commit: 27ae400e6e888153ded1ad807a94a94e506dd2df
[2/2] KVM: arm64: nv: Don't save/restore FP register during a nested ERET or exception
commit: 435c466196148ae116f616e6cda97c33281defc2
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v5 8/8] arm64: defconfig: Enable the raspberrypi otp driver as module
From: Krzysztof Kozlowski @ 2026-05-21 7:09 UTC (permalink / raw)
To: Gregor Herburger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Ray Jui, Scott Branden,
Broadcom internal kernel review list, Eric Anholt, Stefan Wahren,
Srinivas Kandagatla, Kees Cook, Gustavo A. R. Silva,
Thomas Weißschuh
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening
In-Reply-To: <20260520-rpi-otp-driver-v5-8-b26e5908eeac@linutronix.de>
On 20/05/2026 16:28, Gregor Herburger wrote:
> Enable the newly add Raspberry Pi OTP driver as module to allow access
> to the otp registers.
... on foo bar board?
Otherwise, why do we want it in upstream?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 7/8] dt-bindings: raspberrypi,bcm2835-firmware: Drop unnecessary select
From: Krzysztof Kozlowski @ 2026-05-21 7:11 UTC (permalink / raw)
To: Gregor Herburger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Ray Jui, Scott Branden,
Broadcom internal kernel review list, Eric Anholt, Stefan Wahren,
Srinivas Kandagatla, Kees Cook, Gustavo A. R. Silva,
Thomas Weißschuh
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Conor Dooley
In-Reply-To: <20260520-rpi-otp-driver-v5-7-b26e5908eeac@linutronix.de>
On 20/05/2026 16:27, Gregor Herburger wrote:
> The select schema is not necessary because the
> raspberrypi,bcm2835-firmware compatible is already matched by the
> compatible string values.
This is wrong. The select was not because of that. Select was needed
because of simple-mfd, but dtschema was changed, so please rephrase:
The "select" in schema is not necessary anymore since dtschema drops
simple-mfd when constructing the select/filter query for schemas with
compatibles.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Yi Liu @ 2026-05-21 7:31 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Nicolin Chen, will, robin.murphy, bhelgaas, joro, praan, baolu.lu,
kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, linux-pci, dan.j.williams, jonathan.cameron, vsethi,
linux-cxl, nirmoyd
In-Reply-To: <20260520143410.GV3602937@nvidia.com>
On 5/20/26 22:34, Jason Gunthorpe wrote:
> On Wed, May 20, 2026 at 09:12:31PM +0800, Yi Liu wrote:
>> On 4/27/26 13:54, Nicolin Chen wrote:
>>> Controlled by the IOMMU driver, ATS is usually enabled "on demand" when a
>>> given PASID on a device is attached to an I/O page table. This is working
>>> even when a device has no translation on its RID (i.e., the RID is IOMMU
>>> bypassed).
>>
>> nit: this description seems not accurate. Intel iommu driver enables ATS
>> in the probe_device() phase. mind tweak a bit to avoid misleading
>> message. :)
>
> It probably shouldn't do this, it should follow ARM and have it
> dynamic during domain attach.
Agreed that making it dynamic during domain attach is a better
direction. However, even framing it that way, the description tying ATS
enablement to PASID attachment is still architecturally specific to ARM
SMMUv3, and doesn't hold as a general statement. :)
> For security we need ATS disabled for blocking domains at a minimum.
Agreed on the security model.
One more data point worth discussing: today Intel's IOMMU driver enables
ATS at probe time, which has two effects — enabling the PCI ATS
capability on the device, and setting the DTE bit in the scalable-mode
PASID-table entry. When a RID or PASID is subsequently attached to a
blocking domain, the corresponding PASID-table entry has its Present (P)
bit cleared.
Per the VT-d spec (condition SPT.2), with P=0:
- Translation Requests (with or without PASID) complete successfully,
but return R=W=U=S=0 to the device — effectively a no-access result.
- Untranslated Requests receive UR.
- Translated Requests are N/A.
So while neither the PCI ATS capability nor the DTE bit is explicitly
cleared when a blocking domain is attached, ATS-related transactions
don't produce any usable result from the device's perspective.
Does this hardware behavior satisfy the security expectation you have in
mind? Or do you still require that both the DTE bit and the PCI ATS
capability be explicitly disabled when a blocking domain is in effect?
Regards,
Yi Liu
^ permalink raw reply
* Re: [PATCH v3 0/6] KVM: arm64: Don't perform vgic-v2 lazy init on timer injection
From: Marc Zyngier @ 2026-05-21 7:23 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, Marc Zyngier
Cc: Deepanshu Kartikey, Steffen Eiden, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu
In-Reply-To: <20260520100200.543845-1-maz@kernel.org>
On Wed, 20 May 2026 11:01:54 +0100, Marc Zyngier wrote:
> This is the third version of this series aiming at fixing issues with
> vgic-v2 being initialised from non-preemptible context.
>
> * From v2 [2]:
>
> - Remove the PMU's irq level cache which was hidding in plain sight
>
> [...]
Applied to next, thanks!
[1/6] KVM: arm64: timer: Repaint kvm_timer_{should,irq_can}_fire() to kvm_timer_{pending,enabled}()
commit: 68a612d4dbc7f2b9dac731c79676a21fce573d29
[2/6] KVM: arm64: Simplify userspace notification of interrupt state
commit: 0d27b4b351493cb2fe1f87cd152856704d4e141d
[3/6] KVM: arm64: timer: Kill the per-timer irq level cache
commit: ac7002031852ab8f75b3debb1a4c4b2d1ff5a26c
[4/6] KVM: arm64: pmu: Kill the PMU interrupt level cache
commit: 2772383afc5c65d6242f62947b5c184ffb049359
[5/6] KVM: arm64: vgic-v2: Force vgic init on injection outside the run loop
commit: 1a8685ed8cd1ded20d0c81070a49b1cddf70481d
[6/6] KVM: arm64: vgic-v2: Don't init the vgic on in-kernel interrupt injection
commit: 958023d269e0312d10da85a6a49438d2e107dead
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [RESEND v4] ASoC: dt-bindings: imx-card: Complete the full list of supported DAI formats
From: Chancel Liu @ 2026-05-21 7:22 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt, Frank.Li, s.hauer
Cc: kernel, festevam, shengjiu.wang, linux-sound, devicetree, imx,
linux-arm-kernel, linux-kernel
Currently this binding only lists i2s and dsp_b formats that are used
by existing sound cards. However, DT bindings should describe the full
hardware capabilities rather than only the formats of current usage.
The SAI audio controller of i.MX audio sound card supports multiple DAI
formats, including:
- i2s
- left_j
- right_j
- dsp_a
- dsp_b
- pdm
- msb
- lsb
Complete the full list of formats supported by i.MX audio sound card to
ensure the binding correctly describes hardware.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v4:
- Completed the full list of DAI formats (i2s, left_j, right_j, dsp_a,
dsp_b, pdm, msb, lsb) supported by i.MX sound card.
- Rewrote commit message to focus on describing hardware capability
rather than current usage.
Changes in v3:
- Rewrote commit message completely to describe hardware requirements.
Explicitly documented why only dsp_a is added and why other formats
are not included.
- Rebased on latest code base. No functional changes.
Changes in v2:
- Updated commit message to explain current support for i2s and dsp_b
formats and new support for dsp_a. No code changes.
Documentation/devicetree/bindings/sound/imx-audio-card.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
index 5424d4f16f52..950e3eab2942 100644
--- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
+++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
@@ -37,7 +37,13 @@ patternProperties:
items:
enum:
- i2s
+ - left_j
+ - right_j
+ - dsp_a
- dsp_b
+ - pdm
+ - msb
+ - lsb
dai-tdm-slot-num: true
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v2 1/1] arm64: dts: ti: k3-j7: Reserve memory for LPM meta data
From: Richard GENOUD @ 2026-05-21 7:27 UTC (permalink / raw)
To: Nishanth Menon
Cc: Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Udit Kumar, Abhash Kumar,
Beleswar Padhi, Thomas Richard, Gregory CLEMENT, Thomas Petazzoni,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260505125945.mxucy4cfpno2x66z@slacking>
Hi Nishanth,
Le 05/05/2026 à 14:59, Nishanth Menon a écrit :
> On 18:03-20260427, Richard Genoud (TI) wrote:
>> From: Prasanth Babu Mantena <p-mantena@ti.com>
>>
>> For TI SOCs J7200, J784S4, J722S, J721s2 which support low power modes,
>> a chunk of memory is reserved for LPM meta data, which is needed for
>> saving ATF context and the certificate information of ATF and OPTEE and
>> DM image. This LPM metadata area is firewalled to be accessed only by
>> TIFS.
>>
>> U-Boot/TIFS will use this area to save and restore:
>> - ATF context
>> - ATF certificate information
>> - OPTEE certificate information
>> - DM image
>
> DM image is loaded from storage, correct?
Actually, after being loaded from storage at boot time by U-Boot R5 SPL,
the DM image is copied in this memory, so that it doesn't have to be
loaded from storage at resume. (This speeds up the resume time)
For the context:
At resume, U-Boot R5 SPL is executed and detects that the board is
resuming (with a flag set in the PMIC), then it:
- brings out of retention the DDR
- retrieves the LPM memory region from DTS
- authenticates certificates from LPM memory region and applies firewalls
- asks TIFS to restore TFA and its own minimal context
- starts TFA on remote proc
- loads back DM image from memory and jumps to DM
>>
>> https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html#lpm-msg-lpm-save-addr
>>
>> U-Boot has to parse and retrieve this area from the device tree, thus
>> @lpm-memory node are used instead of the generic @memory.
>>
>> Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
>> Signed-off-by: Richard Genoud (TI) <richard.genoud@bootlin.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 6 ++++++
>> arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 6 ++++++
>> arch/arm64/boot/dts/ti/k3-j722s-evm.dts | 6 ++++++
>> arch/arm64/boot/dts/ti/k3-j742s2-evm.dts | 9 +++++++++
>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 9 ++++++---
>
> Split this up into platform wise. I dont understand why you'd not modify
> the ipc-firmware.dtsi and use the phandle similar to https://lore.kernel.org/all/20260318-topic-am62a-ioddr-dt-v6-19-v3-4-c41473cb23c3@baylibre.com/
The wkup_r5fss0_core0_memory_region can't be used in our case because
the DM memory isn't retained during suspend.
For Sitara, the LPM metadata are stored in the DM DDR, but here, as the
DM memory is not kept during suspend, the LPM meta-data is stored in
another memory region, so I don't think I can use this phandle.
>
> Split the patches per ipc-firmware.dtsi as required.
>
>> 5 files changed, 33 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
>> index 5a8c2e707fde..756928a2d411 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
>> @@ -40,6 +40,12 @@ mcu_r5fss0_core0_memory_region: memory@a0100000 {
>> reg = <0x00 0xa0100000 0x00 0xf00000>;
>> no-map;
>> };
>> +
>> + lpm_memory_region: lpm-memory@a4800000 {
>
> vignesh already flagged this in previous revision - just use phandle
> reference in u-boot and make this memory@
I would happily use the phandle, but as this memory is not related to
the DM DDR, I don't think I can.
Thanks!
Regards,
Richard
>
>> + reg = <0x00 0xa4800000 0x00 0x00300000>;
>> + no-map;
>> + bootph-all;
>> + };
>> };
>>
>> mux0: mux-controller-0 {
>> diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
>> index 12a38dd1514b..ceab8f057640 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
>> @@ -42,6 +42,12 @@ mcu_r5fss0_core0_memory_region: memory@a0100000 {
>> reg = <0x00 0xa0100000 0x00 0xf00000>;
>> no-map;
>> };
>> +
>> + lpm_memory_region: lpm-memory@a9c00000 {
>> + reg = <0x00 0xa9c00000 0x00 0x00300000>;
>> + no-map;
>> + bootph-all;
>> + };
>> };
>>
>> mux0: mux-controller-0 {
>> diff --git a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
>> index e66330c71593..eebc5cc7d4cd 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
>> @@ -63,6 +63,12 @@ wkup_r5fss0_core0_memory_region: memory@a0100000 {
>> reg = <0x00 0xa0100000 0x00 0xf00000>;
>> no-map;
>> };
>> +
>> + lpm_memory_region: lpm-memory@a6c00000 {
>> + reg = <0x00 0xa6c00000 0x00 0x00300000>;
>> + no-map;
>> + bootph-all;
>> + };
>> };
>>
>> vmain_pd: regulator-0 {
>> diff --git a/arch/arm64/boot/dts/ti/k3-j742s2-evm.dts b/arch/arm64/boot/dts/ti/k3-j742s2-evm.dts
>> index fcb7f05d7faf..d0752c8a6b37 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j742s2-evm.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-j742s2-evm.dts
>> @@ -23,4 +23,13 @@ memory@80000000 {
>> device_type = "memory";
>> bootph-all;
>> };
>> +
>> +};
>> +
>> +&reserved_memory {
>> + lpm_memory_region: lpm-memory@ab000000 {
>> + reg = <0x00 0xab000000 0x00 0x00300000>;
>> + no-map;
>> + bootph-all;
>> + };
>> };
>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> index 6c7458c76f53..114594f37f0b 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> @@ -23,10 +23,13 @@ memory@80000000 {
>> device_type = "memory";
>> bootph-all;
>> };
>> +};
>>
>> - reserved_memory: reserved-memory {
>> - #address-cells = <2>;
>> - #size-cells = <2>;
>> +&reserved_memory {
>> + lpm_memory_region: lpm-memory@ac000000 {
>> + reg = <0x00 0xac000000 0x00 0x00300000>;
>> + no-map;
>> + bootph-all;
>> };
>> };
>>
>
^ permalink raw reply
* Re: [PATCH 7/8] sched_ext: Sub-allocator over kernel-claimed BPF arena pages
From: Peter Zijlstra @ 2026-05-21 7:27 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, David Hildenbrand, Mike Rapoport,
Emil Tsalapatis, sched-ext, bpf, x86, linux-arm-kernel, linux-mm,
linux-kernel
In-Reply-To: <eaeb316b7a45956ed5f335050e6e9538@kernel.org>
On Wed, May 20, 2026 at 01:47:32PM -1000, Tejun Heo wrote:
> Hello,
>
> On Mon, May 18, 2026 at 04:26:11PM -0700, Alexei Starovoitov wrote:
> > Well, this gen_pool based allocator of arena memory is a temporary hack.
> > It's ok for rare allocation like in this at scx init time, but not suitable
> > for active arena management. We don't need to expose it beyond scx.
>
> I see. Peter, as Alexei is already prototyping a slab-based arena
> allocator, how about keeping the gen_pool layer scx-local for now? Once
> the proper allocator lands, scx can switch to it and the custom piece
> goes away.
OK.
^ permalink raw reply
* [PATCH v7 2/2] arm64: dts: cix: add sky1 DMA-350 node with channel IRQ entries
From: Jun Guo @ 2026-05-21 7:29 UTC (permalink / raw)
To: peter.chen, fugang.duan, robh, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li
Cc: dmaengine, devicetree, linux-kernel, cix-kernel-upstream,
linux-arm-kernel, Jun Guo
In-Reply-To: <20260521072924.3000282-1-jun.guo@cixtech.com>
Describe the DMA-350 channel interrupt sources in DT using 8
interrupt entries, while all entries map to the same GIC SPI
as wired on this platform.
Signed-off-by: Jun Guo <jun.guo@cixtech.com>
---
arch/arm64/boot/dts/cix/sky1.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/cix/sky1.dtsi b/arch/arm64/boot/dts/cix/sky1.dtsi
index bb5cfb1f2113..823adeef51f1 100644
--- a/arch/arm64/boot/dts/cix/sky1.dtsi
+++ b/arch/arm64/boot/dts/cix/sky1.dtsi
@@ -444,6 +444,20 @@ iomuxc: pinctrl@4170000 {
reg = <0x0 0x04170000 0x0 0x1000>;
};
+ fch_dmac: dma-controller@4190000 {
+ compatible = "arm,dma-350";
+ reg = <0x0 0x4190000 0x0 0x10000>;
+ interrupts = <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>;
+ #dma-cells = <1>;
+ };
+
mbox_ap2se: mailbox@5060000 {
compatible = "cix,sky1-mbox";
reg = <0x0 0x05060000 0x0 0x10000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v7 1/2] dmaengine: arm-dma350: enable ANYCH interrupt for shared IRQ wiring
From: Jun Guo @ 2026-05-21 7:29 UTC (permalink / raw)
To: peter.chen, fugang.duan, robh, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li
Cc: dmaengine, devicetree, linux-kernel, cix-kernel-upstream,
linux-arm-kernel, Jun Guo
In-Reply-To: <20260521072924.3000282-1-jun.guo@cixtech.com>
Enable DMANSECCTRL.INTREN_ANYCHINTR during probe so channel
interrupts are propagated when integrators wire DMA-350 channels
onto a shared IRQ line.
Signed-off-by: Jun Guo <jun.guo@cixtech.com>
---
drivers/dma/arm-dma350.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/dma/arm-dma350.c b/drivers/dma/arm-dma350.c
index 84220fa83029..09403aca8bb0 100644
--- a/drivers/dma/arm-dma350.c
+++ b/drivers/dma/arm-dma350.c
@@ -13,6 +13,11 @@
#include "dmaengine.h"
#include "virt-dma.h"
+#define DMANSECCTRL 0x200
+
+#define NSEC_CTRL 0x0c
+#define INTREN_ANYCHINTR_EN BIT(0)
+
#define DMAINFO 0x0f00
#define DMA_BUILDCFG0 0xb0
@@ -582,6 +587,10 @@ static int d350_probe(struct platform_device *pdev)
dmac->dma.device_issue_pending = d350_issue_pending;
INIT_LIST_HEAD(&dmac->dma.channels);
+ reg = readl_relaxed(base + DMANSECCTRL + NSEC_CTRL);
+ writel_relaxed(reg | INTREN_ANYCHINTR_EN,
+ base + DMANSECCTRL + NSEC_CTRL);
+
/* Would be nice to have per-channel caps for this... */
memset = true;
for (int i = 0; i < nchan; i++) {
--
2.34.1
^ permalink raw reply related
* [PATCH v7 0/2] dmaengine: arm-dma350: handle shared channel IRQ wiring on sky1
From: Jun Guo @ 2026-05-21 7:29 UTC (permalink / raw)
To: peter.chen, fugang.duan, robh, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li
Cc: dmaengine, devicetree, linux-kernel, cix-kernel-upstream,
linux-arm-kernel, Jun Guo
This series updates DMA-350 support for the SKY1 integration where all
DMA
channel interrupt outputs are wired to the same GIC SPI.
Patch 1 enables DMANSECCTRL.INTREN_ANYCHINTR in the driver so
per-channel
interrupt status is propagated even when channels share one parent IRQ
line.
Patch 2 adds the SKY1 DMA-350 DT node and describes the channel
interrupt
sources using 8 channel entries, while all entries map to the same SPI.
Tested on CIX SKY1 with dmatest:
% echo 2000 > /sys/module/dmatest/parameters/timeout
% echo 1 > /sys/module/dmatest/parameters/iterations
% echo "" > /sys/module/dmatest/parameters/channel
% echo 1 > /sys/module/dmatest/parameters/run
Changes in v7:
- Modify the commit log format for the driver patch.
Changes in v6:
- Drop the dt-binding update and keep the existing 8-channel interrupt
schema.
- Simplify driver change to a minimal fix:
enable DMANSECCTRL.INTREN_ANYCHINTR.
- Update SKY1 DT node to describe 8 channel interrupt entries mapped
to one SPI.
Changes in v5:
- Fix the formatting issue in the AI tag.
- Remove the unnecessary "cix,sky1-dma-350".
Changes in v4:
- Reword binding text to align with kernel style.
- Revise the AI attribution to the standard format.
- Remove redundant links from the commit log.
Changes in v3:
- Rework binding compatible description to match generic-first model.
- Keep interrupts schema support for both 1-IRQ and 8-IRQ topologies.
- Drop SoC match-data dependency for IRQ mode selection.
- Detect IRQ topology via platform_irq_count() in probe path.
- Refactor IRQ handling into a shared channel handler.
- Enable DMANSECCTRL.INTREN_ANYCHINTR only in combined IRQ mode.
Changes in v2:
- Update to kernel standards, enhance patch description, and refactor
driver to use match data for hardware differentiation instead of
compatible strings.
Jun Guo (2):
dmaengine: arm-dma350: enable ANYCH interrupt for shared IRQ wiring
arm64: dts: cix: add sky1 DMA-350 node with channel IRQ entries
arch/arm64/boot/dts/cix/sky1.dtsi | 14 ++++++++++++++
drivers/dma/arm-dma350.c | 9 +++++++++
2 files changed, 23 insertions(+)
--
2.34.1
^ permalink raw reply
* [RFC PATCH 0/2] arm64: add SMCCC cache invalidation backend for memregion users
From: Srirangan Madhavan @ 2026-05-21 7:30 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla
Cc: conor, jic23, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams,
Srirangan Madhavan
This series adds an arm64 backend for memregion cache invalidation users
based on the Arm SMCCC cache clean+invalidate interface.
Per DEN0028, this interface targets systems where a Normal Cacheable
memory region can be modified in ways that are not handled by usual PE
coherency mechanisms, and where VA-based CMOs may be too slow or
insufficient for large ranges and/or system-cache implementations.
Representative use cases include device-backed memory state transitions
where stale CPU/system cache lines must be invalidated reliably (for
example secure erase, reset/offline flows, and dynamic memory
reconfiguration).
Patch 1 introduces the Arm SMCCC cache clean/invalidate function IDs and
transient return codes needed by callers [1].
Patch 2 adds an arm64 cache maintenance provider that:
- discovers SMCCC support and attributes at init time
- registers with the generic cache coherency framework used by
cpu_cache_invalidate_memregion()
- handles transient BUSY/RATE_LIMITED responses with bounded retries
- coalesces waiters when firmware reports a global operation type
This patch set does not add a software fallback path; when firmware does
not implement the SMCCC cache maintenance interface, the provider is not
registered and existing behavior is preserved.
Reference:
[1] https://developer.arm.com/documentation/den0028/latest
Srirangan Madhavan (2):
arm64: smccc: add cache clean/invalidate IDs and return codes
arm64: mm: add SMCCC-backed cache invalidate provider
MAINTAINERS | 1 +
arch/arm64/mm/Makefile | 1 +
arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++
include/linux/arm-smccc.h | 17 ++-
tools/include/linux/arm-smccc.h | 17 ++-
5 files changed, 212 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/mm/cache_maint.c
base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
--
2.43.0
^ permalink raw reply
* [RFC PATCH 1/2] arm64: smccc: add cache clean/invalidate IDs and return codes
From: Srirangan Madhavan @ 2026-05-21 7:30 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla
Cc: conor, jic23, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams,
Srirangan Madhavan
In-Reply-To: <20260521073047.320614-1-smadhavan@nvidia.com>
Define SMCCC Arch function IDs for CLEAN_INV_MEMREGION and its ATTRIBUTES
call, and add RATE_LIMITED/BUSY return codes from DEN0028 for callers that
need transient error handling.
Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
---
include/linux/arm-smccc.h | 17 +++++++++++++++--
tools/include/linux/arm-smccc.h | 17 +++++++++++++++--
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 50b47eba7d01..cca9adbcc433 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -105,6 +105,18 @@
ARM_SMCCC_SMC_32, \
0, 0x3fff)
+#define ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_ARCH, \
+ 0x5)
+
+#define ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_ARCH, \
+ 0x6)
+
#define ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
ARM_SMCCC_SMC_32, \
@@ -294,13 +306,14 @@
0x53)
/*
- * Return codes defined in ARM DEN 0070A
- * ARM DEN 0070A is now merged/consolidated into ARM DEN 0028 C
+ * Return codes defined by Arm SMCCC (DEN0028).
*/
#define SMCCC_RET_SUCCESS 0
#define SMCCC_RET_NOT_SUPPORTED -1
#define SMCCC_RET_NOT_REQUIRED -2
#define SMCCC_RET_INVALID_PARAMETER -3
+#define SMCCC_RET_RATE_LIMITED -4
+#define SMCCC_RET_BUSY -5
#ifndef __ASSEMBLY__
diff --git a/tools/include/linux/arm-smccc.h b/tools/include/linux/arm-smccc.h
index 63ce9bebccd3..65fd4630e739 100644
--- a/tools/include/linux/arm-smccc.h
+++ b/tools/include/linux/arm-smccc.h
@@ -96,6 +96,18 @@
ARM_SMCCC_SMC_32, \
0, 0x3fff)
+#define ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_ARCH, \
+ 0x5)
+
+#define ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_64, \
+ ARM_SMCCC_OWNER_ARCH, \
+ 0x6)
+
#define ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
ARM_SMCCC_SMC_32, \
@@ -182,12 +194,13 @@
0x53)
/*
- * Return codes defined in ARM DEN 0070A
- * ARM DEN 0070A is now merged/consolidated into ARM DEN 0028 C
+ * Return codes defined by Arm SMCCC (DEN0028).
*/
#define SMCCC_RET_SUCCESS 0
#define SMCCC_RET_NOT_SUPPORTED -1
#define SMCCC_RET_NOT_REQUIRED -2
#define SMCCC_RET_INVALID_PARAMETER -3
+#define SMCCC_RET_RATE_LIMITED -4
+#define SMCCC_RET_BUSY -5
#endif /*__LINUX_ARM_SMCCC_H*/
--
2.43.0
^ permalink raw reply related
* [RFC PATCH 2/2] arm64: mm: add SMCCC-backed cache invalidate provider
From: Srirangan Madhavan @ 2026-05-21 7:30 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla
Cc: conor, jic23, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams,
Srirangan Madhavan
In-Reply-To: <20260521073047.320614-1-smadhavan@nvidia.com>
Add an arm64 cache maintenance backend that discovers SMCCC cache
clean+invalidate support, queries attributes, handles transient BUSY and
RATE_LIMITED responses with bounded retries, and registers with the generic
cache coherency framework.
Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
---
MAINTAINERS | 1 +
arch/arm64/mm/Makefile | 1 +
arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++++++
3 files changed, 182 insertions(+)
create mode 100644 arch/arm64/mm/cache_maint.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 2fb1c75afd16..33c35f8e6e40 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25383,6 +25383,7 @@ M: Jonathan Cameron <jic23@kernel.org>
S: Maintained
T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
F: Documentation/devicetree/bindings/cache/
+F: arch/arm64/mm/cache_maint.c
F: drivers/cache
F: include/linux/cache_coherency.h
F: lib/cache_maint.c
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index c26489cf96cd..b247dc5dfd45 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_TRANS_TABLE) += trans_pgd-asm.o
obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
obj-$(CONFIG_ARM64_MTE) += mteswap.o
obj-$(CONFIG_ARM64_GCS) += gcs.o
+obj-$(CONFIG_ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION) += cache_maint.o
KASAN_SANITIZE_physaddr.o += n
obj-$(CONFIG_KASAN) += kasan_init.o
diff --git a/arch/arm64/mm/cache_maint.c b/arch/arm64/mm/cache_maint.c
new file mode 100644
index 000000000000..ea7dd30d5dfa
--- /dev/null
+++ b/arch/arm64/mm/cache_maint.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026 NVIDIA Corporation
+ *
+ * Arm64 cache maintenance provider using SMCCC cache clean+invalidate calls.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/cache_coherency.h>
+#include <linux/cleanup.h>
+#include <linux/delay.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/mutex.h>
+#include <linux/nmi.h>
+
+#define SMCCC_CACHE_MAX_RETRIES 5
+#define SMCCC_CACHE_MAX_DELAY_US 20000
+
+/* DEN0028 v1.7: bit[0] == 1 means implementation flushes all caches globally */
+#define SMCCC_CACHE_ATTR_GLOBAL_OP BIT(0)
+
+struct arm64_smccc_cache {
+ /* Must be first member */
+ struct cache_coherency_ops_inst cci;
+ struct mutex lock; /* Serializes SMCCC cache maintenance calls. */
+ u32 latency_us;
+ u32 rate_limit;
+ bool global_op;
+ u64 global_flush_gen;
+};
+
+static struct arm64_smccc_cache *arm64_smccc_cache;
+
+static int smccc_cache_status_to_errno(s32 status)
+{
+ switch (status) {
+ case SMCCC_RET_SUCCESS:
+ return 0;
+ case SMCCC_RET_NOT_SUPPORTED:
+ case SMCCC_RET_NOT_REQUIRED:
+ return -EOPNOTSUPP;
+ case SMCCC_RET_INVALID_PARAMETER:
+ return -EINVAL;
+ case SMCCC_RET_RATE_LIMITED:
+ return -EAGAIN;
+ case SMCCC_RET_BUSY:
+ return -EBUSY;
+ default:
+ return -EIO;
+ }
+}
+
+static int smccc_cache_delay_us(const struct arm64_smccc_cache *cache)
+{
+ u64 delay_us = 0;
+
+ if (cache->rate_limit)
+ delay_us = DIV_ROUND_UP_ULL(USEC_PER_SEC, cache->rate_limit);
+
+ if (cache->latency_us)
+ delay_us = max_t(u64, delay_us, cache->latency_us);
+
+ if (!delay_us)
+ delay_us = 1000;
+
+ return min_t(u64, delay_us, SMCCC_CACHE_MAX_DELAY_US);
+}
+
+static int arm64_smccc_cache_wbinv(struct cache_coherency_ops_inst *cci,
+ struct cc_inval_params *invp)
+{
+ struct arm64_smccc_cache *cache =
+ container_of(cci, struct arm64_smccc_cache, cci);
+ struct arm_smccc_res res = {};
+ int delay_us = smccc_cache_delay_us(cache);
+ u64 gen = 0;
+ s32 status;
+ int ret;
+ int i;
+
+ if (!invp->size)
+ return -EINVAL;
+
+ if (cache->global_op)
+ gen = READ_ONCE(cache->global_flush_gen);
+
+ guard(mutex)(&cache->lock);
+
+ /*
+ * If firmware reports a global operation type, a successful operation
+ * covers every request that was already waiting behind it. Skip if the
+ * generation advanced while this request was waiting to enter the
+ * serialized firmware call path.
+ */
+ if (cache->global_op && gen != READ_ONCE(cache->global_flush_gen))
+ return 0;
+
+ for (i = 0; i < SMCCC_CACHE_MAX_RETRIES; i++) {
+ /* Long firmware operations can trigger watchdog checks. */
+ touch_nmi_watchdog();
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION,
+ invp->addr, invp->size, 0UL, &res);
+ status = (s32)res.a0;
+ ret = smccc_cache_status_to_errno(status);
+ if (!ret) {
+ if (cache->global_op) {
+ WRITE_ONCE(cache->global_flush_gen,
+ cache->global_flush_gen + 1);
+ }
+ return 0;
+ }
+
+ if (ret != -EBUSY && ret != -EAGAIN)
+ return ret;
+
+ usleep_range(delay_us, delay_us + 100);
+ }
+
+ return -EBUSY;
+}
+
+static const struct cache_coherency_ops arm64_smccc_cache_ops = {
+ .wbinv = arm64_smccc_cache_wbinv,
+};
+
+static int __init arm64_smccc_cache_init(void)
+{
+ struct arm_smccc_res res = {};
+ s32 status;
+ int ret;
+
+ if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_1)
+ return -ENODEV;
+
+ if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE)
+ return -ENODEV;
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION, &res);
+ status = (s32)res.a0;
+ if (status < 0)
+ return -ENODEV;
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES, &res);
+ status = (s32)res.a0;
+ if (status < 0)
+ return -ENODEV;
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES, &res);
+ status = (s32)res.a0;
+ if (status)
+ return -ENODEV;
+
+ arm64_smccc_cache =
+ cache_coherency_ops_instance_alloc(&arm64_smccc_cache_ops,
+ struct arm64_smccc_cache,
+ cci);
+ if (!arm64_smccc_cache)
+ return -ENOMEM;
+
+ mutex_init(&arm64_smccc_cache->lock);
+ arm64_smccc_cache->latency_us = lower_32_bits(res.a2);
+ arm64_smccc_cache->rate_limit = lower_32_bits(res.a3);
+ arm64_smccc_cache->global_op = !!(res.a1 & SMCCC_CACHE_ATTR_GLOBAL_OP);
+
+ ret = cache_coherency_ops_instance_register(&arm64_smccc_cache->cci);
+ if (ret) {
+ cache_coherency_ops_instance_put(&arm64_smccc_cache->cci);
+ arm64_smccc_cache = NULL;
+ return ret;
+ }
+
+ pr_info("SMCCC cache clean+invalidate provider registered\n");
+ return 0;
+}
+arch_initcall(arm64_smccc_cache_init);
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/3] media: meson: Fix memory leak in error path in
From: Anand Moon @ 2026-05-21 7:34 UTC (permalink / raw)
To: Neil Armstrong, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Hans Verkuil,
Maxime Jourdan,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:STAGING SUBSYSTEM,
moderated list:ARM/Amlogic Meson SoC support, open list
Cc: Sashiko
Following chamges try to fix the memory leak reported by Sashiko
Pre-existing issues:
- [Critical] The `sess->esparser_queue_work` work item is not canceled
before freeing the session context, leading to a potential Use-After-Free
vulnerability.
- [High] The patch attempts to fix a memory leak reported by kmemleak,
but misdiagnoses the root cause and leaves the primary memory leak
(the V4L2 control handler) unresolved.
- [High] The driver does not verify if `kthread_run()` returns an `ERR_PTR`,
leading to a kernel panic when `kthread_stop()` is called.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260520045905.6ACBA1F000E9@smtp.kernel.org/#t
Thanks
-Anand
Anand Moon (3):
media: meson: vdec: Fix memory leak in error path of vdec_open
media: meson: vdec: Add error handling for recycle thread creation
media: meson: vdec: Cancel esparser work in error and stop paths
drivers/staging/media/meson/vdec/vdec.c | 27 +++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
base-commit: 8bc67e4db64aa72732c474b44ea8622062c903f0
--
2.50.1
^ permalink raw reply
* [PATCH v4 1/3] media: meson: vdec: Fix memory leak in error path of vdec_open
From: Anand Moon @ 2026-05-21 7:34 UTC (permalink / raw)
To: Neil Armstrong, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Hans Verkuil,
Maxime Jourdan,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:STAGING SUBSYSTEM,
moderated list:ARM/Amlogic Meson SoC support, open list
Cc: Sashiko, Nicolas Dufresne
In-Reply-To: <20260521073449.10057-1-linux.amoon@gmail.com>
The vdec_open() function previously jumped directly to err_m2m_release
when vdec_init_ctrls() failed, skipping release of the m2m context.
This caused a resource leak.
Fix it by introducing a proper err_m2m_ctx_release label that calls
v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device.
Also free the v4l2 control handler memory allocated by vdec_init_ctrls()
in vdec_close().
This was identified via kmemleak:
unreferenced object 0xffff0000205d6878 (size 8):
comm "v4l_id", pid 5289, jiffies 4294938580
hex dump (first 8 bytes):
40 d2 49 18 00 00 ff ff @.I.....
backtrace (crc d3204599):
kmemleak_alloc+0xc8/0xf0
__kvmalloc_node_noprof+0x60c/0x850
v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev]
vdec_open+0x1f4/0x788 [meson_vdec]
v4l2_open+0x144/0x460 [videodev]
chrdev_open+0x1ac/0x500
do_dentry_open+0x3f0/0xfe8
vfs_open+0x68/0x320
do_open+0x2d8/0x9a8
path_openat+0x1d0/0x4f0
do_filp_open+0x190/0x380
do_sys_openat2+0xf8/0x1b0
__arm64_sys_openat+0x13c/0x1e8
invoke_syscall+0xdc/0x268
el0_svc_common.constprop.0+0x178/0x258
do_el0_svc+0x4c/0x70
Cc: Nicolas Dufresne <nicolas@ndufresne.ca>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260520045905.6ACBA1F000E9@smtp.kernel.org/#t
Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver")
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
v4: update the commit message to add v4l2_ctrl_handler_free() in vdec_close()
to adderss the issue:
This isn't a bug introduced by this patch, but does vdec_close() properly
free the v4l2 control handler memory allocated by vdec_init_ctrls() here?
v3: https://lore.kernel.org/all/20260520044046.7553-1-linux.amoon@gmail.com/
update the commit messagee.
v2: https://lore.kernel.org/all/20260321065408.209723-1-linux.amoon@gmail.com/
updated the commit message, applied the suggestion from sashiko below.
[3] https://sashiko.dev/#/patchset/20260321065408.209723-1-linux.amoon%40gmail.com
v1: https://lore.kernel.org/all/20260304100557.126488-1-linux.amoon@gmail.com/
tried to address the issue reported by Nicolas improve the commit message.
---
drivers/staging/media/meson/vdec/vdec.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
index 4b77ec1af5a7..9244fb09eb36 100644
--- a/drivers/staging/media/meson/vdec/vdec.c
+++ b/drivers/staging/media/meson/vdec/vdec.c
@@ -889,7 +889,7 @@ static int vdec_open(struct file *file)
ret = vdec_init_ctrls(sess);
if (ret)
- goto err_m2m_release;
+ goto err_m2m_ctx_release;
sess->pixfmt_cap = formats[0].pixfmts_cap[0];
sess->fmt_out = &formats[0];
@@ -913,6 +913,8 @@ static int vdec_open(struct file *file)
return 0;
+err_m2m_ctx_release:
+ v4l2_m2m_ctx_release(sess->m2m_ctx);
err_m2m_release:
v4l2_m2m_release(sess->m2m_dev);
err_free_sess:
@@ -926,6 +928,7 @@ static int vdec_close(struct file *file)
v4l2_m2m_ctx_release(sess->m2m_ctx);
v4l2_m2m_release(sess->m2m_dev);
+ v4l2_ctrl_handler_free(&sess->ctrl_handler);
v4l2_fh_del(&sess->fh, file);
v4l2_fh_exit(&sess->fh);
--
2.50.1
^ permalink raw reply related
* [PATCH v4 2/3] media: meson: vdec: Add error handling for recycle thread creation
From: Anand Moon @ 2026-05-21 7:34 UTC (permalink / raw)
To: Neil Armstrong, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Hans Verkuil,
Maxime Jourdan,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:STAGING SUBSYSTEM,
moderated list:ARM/Amlogic Meson SoC support, open list
Cc: Sashiko, Nicolas Dufresne
In-Reply-To: <20260521073449.10057-1-linux.amoon@gmail.com>
Add proper error handling for kthread_run() in vdec_start_streaming().
If thread creation fails and returns an ERR_PTR, record the error,
reset sess->recycle_thread to NULL, and unwind resources via err_cleanup.
This prevents later calls to kthread_stop() in vdec_stop_streaming() from
dereferencing an ERR_PTR and causing a kernel panic. Fix this by adding the
label and invoking vdec_poweroff() to prevent hardware power leaks.
Additionally, reorder the error path to properly mirror the allocation
sequence clear the streamon status flags before emptying the M2M buffers
to avoid race conditions, and ensure DMA buffers are released gracefully
relative to the hardware state lifecycle.
Cc: Nicolas Dufresne <nicolas@ndufresne.ca>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260520045905.6ACBA1F000E9@smtp.kernel.org/#t
Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver")
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
v4: new patch
[Severity: High]
This isn't a bug introduced by this patch, but does the driver verify if
kthread_run() returns an ERR_PTR when starting the recycle thread?
If thread creation fails in vdec_start_streaming() and returns an ERR_PTR,
could a later call to kthread_stop(sess->recycle_thread) in
vdec_stop_streaming() attempt to dereference that ERR_PTR and cause a
kernel panic?
---
drivers/staging/media/meson/vdec/vdec.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
index 9244fb09eb36..8615a935e86d 100644
--- a/drivers/staging/media/meson/vdec/vdec.c
+++ b/drivers/staging/media/meson/vdec/vdec.c
@@ -337,29 +337,37 @@ static int vdec_start_streaming(struct vb2_queue *q, unsigned int count)
sess->sequence_cap = 0;
sess->sequence_out = 0;
- if (vdec_codec_needs_recycle(sess))
+ if (vdec_codec_needs_recycle(sess)) {
sess->recycle_thread = kthread_run(vdec_recycle_thread, sess,
"vdec_recycle");
+ if (IS_ERR(sess->recycle_thread)) {
+ ret = PTR_ERR(sess->recycle_thread);
+ sess->recycle_thread = NULL;
+ goto err_cleanup;
+ }
+ }
sess->status = STATUS_INIT;
core->cur_sess = sess;
schedule_work(&sess->esparser_queue_work);
return 0;
+err_cleanup:
+ vdec_poweroff(sess);
vififo_free:
dma_free_coherent(sess->core->dev, sess->vififo_size,
sess->vififo_vaddr, sess->vififo_paddr);
bufs_done:
- while ((buf = v4l2_m2m_src_buf_remove(sess->m2m_ctx)))
- v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
- while ((buf = v4l2_m2m_dst_buf_remove(sess->m2m_ctx)))
- v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
-
if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
sess->streamon_out = 0;
else
sess->streamon_cap = 0;
+ while ((buf = v4l2_m2m_src_buf_remove(sess->m2m_ctx)))
+ v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
+ while ((buf = v4l2_m2m_dst_buf_remove(sess->m2m_ctx)))
+ v4l2_m2m_buf_done(buf, VB2_BUF_STATE_QUEUED);
+
return ret;
}
--
2.50.1
^ permalink raw reply related
* [PATCH v4 3/3] media: meson: vdec: Cancel esparser work in error and stop paths
From: Anand Moon @ 2026-05-21 7:34 UTC (permalink / raw)
To: Neil Armstrong, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Maxime Jourdan,
Hans Verkuil,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:STAGING SUBSYSTEM,
moderated list:ARM/Amlogic Meson SoC support, open list
Cc: Sashiko, Nicolas Dufresne
In-Reply-To: <20260521073449.10057-1-linux.amoon@gmail.com>
Ensure that esparser_queue_work is canceled before freeing the
session context. Add cancel_work_sync() in both the error path
of vdec_close() and vdec_start_streaming() and in vdec_stop_streaming().
This prevents background work from dereferencing a freed sess
structure and triggering a use-after-free.
Cc: Nicolas Dufresne <nicolas@ndufresne.ca>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260520045905.6ACBA1F000E9@smtp.kernel.org/#t
Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver")
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
v4: new patch
If vdec_close() calls kfree(sess) without first stopping or synchronizing
with this background work via cancel_work_sync(), could a concurrently
running esparser_queue_all_src() dereference the freed sess structure and
trigger a use-after-free?
---
drivers/staging/media/meson/vdec/vdec.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
index 8615a935e86d..a57bd4a8e33c 100644
--- a/drivers/staging/media/meson/vdec/vdec.c
+++ b/drivers/staging/media/meson/vdec/vdec.c
@@ -358,6 +358,8 @@ static int vdec_start_streaming(struct vb2_queue *q, unsigned int count)
dma_free_coherent(sess->core->dev, sess->vififo_size,
sess->vififo_vaddr, sess->vififo_paddr);
bufs_done:
+ cancel_work_sync(&sess->esparser_queue_work);
+
if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
sess->streamon_out = 0;
else
@@ -415,6 +417,7 @@ static void vdec_stop_streaming(struct vb2_queue *q)
if (vdec_codec_needs_recycle(sess))
kthread_stop(sess->recycle_thread);
+ cancel_work_sync(&sess->esparser_queue_work);
vdec_poweroff(sess);
vdec_free_canvas(sess);
dma_free_coherent(sess->core->dev, sess->vififo_size,
@@ -937,6 +940,7 @@ static int vdec_close(struct file *file)
v4l2_m2m_ctx_release(sess->m2m_ctx);
v4l2_m2m_release(sess->m2m_dev);
v4l2_ctrl_handler_free(&sess->ctrl_handler);
+ cancel_work_sync(&sess->esparser_queue_work);
v4l2_fh_del(&sess->fh, file);
v4l2_fh_exit(&sess->fh);
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Mukesh Savaliya @ 2026-05-21 7:40 UTC (permalink / raw)
To: Carlos Song (OSS), o.rempel, kernel, andi.shyti, Frank.Li,
s.hauer, festevam, carlos.song, haibo.chen
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260520101504.2885873-1-carlos.song@oss.nxp.com>
Hi Carlos,
On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
> From: Carlos Song <carlos.song@nxp.com>
>
> Mark the I2C adapter as suspended during system suspend to block further
> transfers, and resume it on system resume. This prevents potential hangs
> when the hardware is powered down but clients still attempt I2C transfers.
>
Code changes looks fine to me but have comment on commit log.
It seems, you are adding support of _noirq() callbacks to allow
transfers during suspend/resume noirq phase of PM.
Would it make sense if you can write "Replace system PM callbacks with
noirq PM callbacks" OR "Allow transfers during _noirq phase of the PM
ops" instead of "mark I2C adapter when hardware is powered down" ?
> Fixes: 358025ac091e ("i2c: imx: make controller available until system suspend_noirq() and from resume_noirq()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Carlos Song <carlos.song@nxp.com>
> ---
> Change for v3:
> - Add hrtimer_cancel in i2c_imx_suspend_noirq to cancel slave_timer for
> safe suspend in i2c slave mode.
> Change for v2:
> - Call i2c_mark_adapter_suspended() before pm_runtime_force_suspend()
> to prevent potential deadlock if a transfer is active during suspend.
> - Roll back with i2c_mark_adapter_resumed() if pm_runtime_force_suspend()
> fails.
> ---
[...]
^ permalink raw reply
* Re: [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
From: Baolu Lu @ 2026-05-21 7:39 UTC (permalink / raw)
To: Joonwon Kang, jgg, will, robin.murphy, joro, jpb
Cc: Alexander.Grest, amhetre, easwar.hariharan, jacob.jun.pan, kees,
kevin.tian, nicolinc, praan, smostafa, tglx, mingo, bp,
dave.hansen, x86, hpa, peterz, sohil.mehta, kas,
alexander.shishkin, ryasuoka, xin, linux-kernel, iommu,
linux-arm-kernel
In-Reply-To: <20260520150743.727106-1-joonwonkang@google.com>
On 5/20/26 23:07, Joonwon Kang wrote:
> For SVA, the IOMMU core always allocates PASID from the global PASID
> space. The use of this global PASID space comes from the limitation of
> the ENQCMD instruction in Intel CPUs that it fetches its PASID operand
> from IA32_PASID, which is per-process; when a process wants to
> communicate with multiple devices with the ENQCMD instruction, it cannot
> change its PASID for each device without the kernel's intervention. Also
> note that ARM introduced a similar instruction, which is ST64BV0.
>
> Due to this nature, SVA with ARM SMMU v3 has been found not working in
> our environment when other modules/devices compete for PASID. The
> environment looks as follows:
>
> - The device is not a PCIe device.
> - The device is to use SVA.
> - The supported SSID/PASID space is very small for the device; only 1 to
> 3 SSIDs are supported.
>
> With this setup, when other modules have allocated all the PASIDs that
> our device is expected to use from the global PASID space via APIs like
> iommu_alloc_global_pasid() or iommu_sva_bind_device(), SVA binding to
> our device fails due to the lack of available PASIDs.
>
> This commit resolves the issue by allowing device driver to maintain its
> own PASID space and assign a PASID from that for the process-device bond
> via a new API called `iommu_sva_bind_device_pasid(dev, mm, pasid)`. Doing
> that, however, will disallow the process to execute the ENQCMD-like
> instructions at EL0. It is because the process cannot change its PASID in
> IA32_PASID(or ACCDATA_EL1 on ARM) for each device without the kernel's
> intervention. For this reason, calling `iommu_sva_bind_device()` and then
> `iommu_sva_bind_device_pasid()` for the same process will not be allowed
> and vice versa.
>
> Currently, there is a limitation that a process simultaneously doing SVA
> with multiple devices with different PASIDs is not supported. So, calling
> `iommu_sva_bind_device_pasid()` multiple times for the same process with
> different devices will not be allowed for now while that for
> `iommu_sva_bind_device()` will be.
>
> Another limitation is that a process cannot do `iommu_sva_bind_device()`
> if it has ever done `iommu_sva_bind_device_pasid()` even though it has
> been unbound after use.
>
> Suggested-by: Jason Gunthorpe<jgg@ziepe.ca>
> Suggested-by: Kevin Tian<kevin.tian@intel.com>
> Signed-off-by: Joonwon Kang<joonwonkang@google.com>
> ---
> v2: Reuse iommu_mm->pasid after SVA bound by iommu_sva_bind_device_pasid()
> is unbound.
> v1: Initial version.
>
> arch/x86/kernel/traps.c | 9 +--
> drivers/iommu/iommu-sva.c | 151 +++++++++++++++++++++++++++++---------
> include/linux/iommu.h | 14 +++-
> 3 files changed, 134 insertions(+), 40 deletions(-)
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 0ca3912ecb7f..0131c8e5fb10 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -857,13 +857,12 @@ static bool try_fixup_enqcmd_gp(void)
> return false;
>
> /*
> - * If the mm has not been allocated a
> - * PASID, the #GP can not be fixed up.
> + * If the mm has not been allocated a PASID or ENQCMD has been
> + * disallowed, the #GP can not be fixed up.
> */
> - if (!mm_valid_pasid(current->mm))
> - return false;
> -
> pasid = mm_get_enqcmd_pasid(current->mm);
> + if (pasid == IOMMU_PASID_INVALID)
> + return false;
>
> /*
> * Did this thread already have its PASID activated?
> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> index bc7c7232a43e..a83333651ad0 100644
> --- a/drivers/iommu/iommu-sva.c
> +++ b/drivers/iommu/iommu-sva.c
> @@ -10,6 +10,9 @@
>
> #include "iommu-priv.h"
>
> +/* Whether pasid is to be allocated from the global PASID space */
> +#define IOMMU_PASID_GLOBAL_ANY IOMMU_NO_PASID
> +
> static DEFINE_MUTEX(iommu_sva_lock);
> static bool iommu_sva_present;
> static LIST_HEAD(iommu_sva_mms);
> @@ -17,10 +20,11 @@ static struct iommu_domain *iommu_sva_domain_alloc(struct device *dev,
> struct mm_struct *mm);
>
> /* Allocate a PASID for the mm within range (inclusive) */
> -static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct device *dev)
> +static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm,
> + struct device *dev,
> + ioasid_t pasid)
> {
> struct iommu_mm_data *iommu_mm;
> - ioasid_t pasid;
>
> lockdep_assert_held(&iommu_sva_lock);
>
> @@ -30,8 +34,27 @@ static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct de
> iommu_mm = mm->iommu_mm;
> /* Is a PASID already associated with this mm? */
> if (iommu_mm) {
> + if ((pasid == IOMMU_PASID_GLOBAL_ANY && !iommu_mm->pasid_global) ||
> + (pasid != IOMMU_PASID_GLOBAL_ANY && iommu_mm->pasid_global))
> + return ERR_PTR(-EBUSY);
> +
> + if (!iommu_mm->pasid_global) {
> + if (list_empty(&iommu_mm->sva_domains))
> + iommu_mm->pasid = pasid;
> +
> + if (pasid != iommu_mm->pasid) {
> + /*
> + * Currently, a process simultaneously doing
> + * SVA with multiple devices with different
> + * PASIDs is not supported.
> + */
I am a bit confused by the change in this helper and the comments above.
Currently, when an mm is bound to a device, it uses a PASID allocated
from the global pool. That implies that all devices access the
application's address space with the same PASID. Now we want to extend
this by allowing the device driver to manage the PASID for SVA, which
should mean different devices might use different PASIDs to access the
application's address space. But this does not seem to match the logic
in this helper.
Perhaps I overlooked something?
> + return ERR_PTR(-ENOSPC);
> + }
> + }
> +
> if (iommu_mm->pasid >= dev->iommu->max_pasids)
> return ERR_PTR(-EOVERFLOW);
> +
> return iommu_mm;
> }
Thanks,
baolu
^ permalink raw reply
* Re: [PATCH v8 1/5] dt-bindings: clock: airoha: Add PHY binding for Serdes port
From: Krzysztof Kozlowski @ 2026-05-21 7:41 UTC (permalink / raw)
To: Christian Marangi
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Lorenzo Bianconi, Felix Fietkau, linux-clk, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <20260520150912.11614-2-ansuelsmth@gmail.com>
On Wed, May 20, 2026 at 05:09:06PM +0200, Christian Marangi wrote:
> Add PHY cell property for Serdes port selection. Currently supported only
> for Airoha AN7581 SoC, that support up to 4 Serdes port.
>
> The Serdes port can support both PCIe, USB3 or Ethernet mode.
>
> - PCIe1 Serdes can support PCIe or Ethernet mode.
> - PCIe2 Serdes can support PCIe or Ethernet mode.
> - USB1 Serdes can support USB3 or HSGMII mode.
> - USB2 Serdes can support USB3 or PCIe mode.
>
> Add bindings to permit correct reference of the Serdes ports in DT.
> Values are just symbolic and enumerates the Serdes port with a specific
> number for precise reference.
>
> The available Serdes port can be selected following the dt-binding header
> in [2].
>
> [2] <include/dt-bindings/soc/airoha,scu-ssr.h>
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> .../devicetree/bindings/clock/airoha,en7523-scu.yaml | 9 +++++++++
> include/dt-bindings/soc/airoha,scu-ssr.h | 11 +++++++++++
> 2 files changed, 20 insertions(+)
> create mode 100644 include/dt-bindings/soc/airoha,scu-ssr.h
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 2/5] dt-bindings: phy: Add documentation for Airoha AN7581 USB PHY
From: Krzysztof Kozlowski @ 2026-05-21 7:44 UTC (permalink / raw)
To: Christian Marangi
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Lorenzo Bianconi, Felix Fietkau, linux-clk, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <20260520150912.11614-3-ansuelsmth@gmail.com>
On Wed, May 20, 2026 at 05:09:07PM +0200, Christian Marangi wrote:
> Add documentation for Airoha AN7581 USB PHY that describe the USB PHY
> for the USB controller.
>
> Airoha AN7581 SoC support a maximum of 2 USB port. The USB 2.0 mode is
> always supported. The USB 3.0 mode is optional and depends on the Serdes
> mode currently configured on the system for the relevant USB port.
>
> To correctly calibrate, the USB 2.0 port require correct value in
> "airoha,usb2-monitor-clk-sel" property. Both the 2 USB 2.0 port permit
> selecting one of the 4 monitor clock for calibration (internal clock not
> exposed to the system) but each port have only one of the 4 actually
> connected in HW hence the correct value needs to be specified in DT
> based on board and the physical port. Normally it's monitor clock 1 for
> USB1 and monitor clock 2 for USB2.
>
> To correctly setup the Serdes mode attached to the USB 3.0 mode, a phys
> property is required with the phandle pointing to the correct Serdes port
> provided by the SCU node.
^^^ here - required but:
> + phys:
> + items:
> + - description: phandle to Serdes PHY
> +
> + '#phy-cells':
> + description: The cell contains the mode, PHY_TYPE_USB2 or PHY_TYPE_USB3,
> + as defined in dt-bindings/phy/phy.h.
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - airoha,usb2-monitor-clk-sel
'phys' is not required? I think you need it to configure the serdes
correctly, no?
> + - '#phy-cells'
> +
> +additionalProperties: false
Best regards,
Krzysztof
^ 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