* Re: [PATCH 2/4] arm64: dts: imx95: switch usb3 controller to flattened model
From: Xu Yang @ 2026-04-23 10:26 UTC (permalink / raw)
To: Frank Li
Cc: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, devicetree,
imx, linux-arm-kernel, linux-kernel, jun.li
In-Reply-To: <aehGKE8qLXiBKvvB@lizhi-Precision-Tower-5810>
On Tue, Apr 21, 2026 at 11:53:12PM -0400, Frank Li wrote:
> On Tue, Apr 21, 2026 at 06:55:01PM +0800, Xu Yang wrote:
> > Switch to use flattened model for USB3 controller. To enable USB
> > controller with restricted DMA access range to work correctly, add a
> > pseudo simple-bus to constrain the dma address.
>
> i.mx95 should fix >4G dma space's problem. Does it impact other no-nxp
> boards?
Yes, i.MX95 has fixed >3G address DMA access problem.
It's another issue. HSIO domain only support 36 bit bus access. If not use smmu,
no any issue. If use smmu, it will allocate memory space of 36 bit < iova < 48bit.
HSIO can't handle this case.
>
> Need do break compatible judgement such as
>
> i.MX95 is new SoC and still is heave development. The break compatible is
> accepable at development early phase.
>
> You can rephrase it.
OK.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [RFC PATCH v2 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-23 10:29 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
sudeep.holla, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene
In-Reply-To: <865x5i13dl.wl-maz@kernel.org>
Hi Marc,
> On Wed, 22 Apr 2026 17:24:49 +0100,
> Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> >
> > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > Otherwise, pKVM cannot negotiate the FF-A version or
> > obtain RX/TX buffer information, leading to failures in FF-A calls.
> >
> > During FF-A driver initialization, check whether pKVM has been initialized.
> > If pKVM isn't initailised, register notifier and do initialisation
> > of FF-A driver when pKVM is initialized.
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> > arch/arm64/include/asm/virt.h | 11 ++++++++++
> > arch/arm64/kvm/arm.c | 21 ++++++++++++++++++
> > arch/arm64/kvm/pkvm.c | 2 ++
> > drivers/firmware/arm_ffa/common.h | 4 ++--
> > drivers/firmware/arm_ffa/driver.c | 36 ++++++++++++++++++++++++++++++-
> > drivers/firmware/arm_ffa/smccc.c | 2 +-
> > 6 files changed, 72 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> > index b51ab6840f9c..ad038a3b8727 100644
> > --- a/arch/arm64/include/asm/virt.h
> > +++ b/arch/arm64/include/asm/virt.h
> > @@ -68,6 +68,8 @@
> > #include <asm/sysreg.h>
> > #include <asm/cpufeature.h>
> >
> > +struct notifier_block;
> > +
> > /*
> > * __boot_cpu_mode records what mode CPUs were booted in.
> > * A correctly-implemented bootloader must start all CPUs in the same mode:
> > @@ -166,6 +168,15 @@ static inline bool is_hyp_nvhe(void)
> > return is_hyp_mode_available() && !is_kernel_in_hyp_mode();
> > }
> >
> > +enum kvm_arm_event {
> > + PKVM_INITIALISED,
> > + KVM_ARM_EVENT_MAX,
> > +};
>
> Well, no.
>
> You are adding a whole infrastructure for something that happens
> *once* in the lifetime of the system. What's next? D-Bus?
>
> We already have a dependency mechanism, which I pointed to you last
> time, and that you conveniently ignored. If that's not working for
> you, then consider improving it.
>
> If we had a whole set of in-kernel users depending on some global KVM
> state change, we could look into it. But they are none, and all KVM
> state changes are per-vcpu rather global.
>
> So I'm not entertaining this invasive infrastructure for something so
> limited.
I think I misunderstood your suggestion at first — I wasn’t ignoring it,
and I apologise for that.
I initially considered hooking into /dev/kvm registration,
but there doesn’t seem to be a dedicated class or bus notifier for misc devices:
- https://lore.kernel.org/all/aecf57rWloQwDh6v@e129823.arm.com/
Also, as I understand it, to make use of device_link,
FF-A would need to represent itself (and pKVM) as proper devices.
However, even if we rely on notifiers for when the pKVM device and
FF-A device are added, the ordering becomes problematic.
When the pKVM device is added and probed, the FF-A consumer would add into
deferred list be device core and deferred_probe is triggered later
(during late_initcall).
In other words, once FF-A itself is deferred,
the deferred probe queue would look something like:
(device depending on FF-A) → (some FF-A device) → (FF-A core)
especially since finalise_pkvm() runs at late_initcall_sync.
Unfortunately, deferred_probe_initcall() (also at late_initcall) only
calls driver_deferred_probe_trigger() twice. In this scenario,
the last device in the chain would not be probed immediately but only after a timeout.
As a result, IMA would also fail to find the device in time.
This is why I felt that device_link might not be suitable in this case —
although I may be misunderstanding something.
If this understanding is correct, I’m not sure what alternative we have,
other than adding some kind of notifier support (bus or class) to
the misc driver, or introducing a custom notifier.
Am I missing something?
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mathias Stearn @ 2026-04-23 10:38 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Thomas Gleixner, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Ingo Molnar,
Mark Rutland, Jinjie Ruan, Blake Oler
In-Reply-To: <20260422131338.GI3102924@noisy.programming.kicks-ass.net>
On Wed, Apr 22, 2026 at 3:13 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, Apr 22, 2026 at 02:56:47PM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 22, 2026 at 11:50:26AM +0200, Mathias Stearn wrote:
> >
> > > Additionally, it breaks tcmalloc specifically by failing to overwrite
> > > the cpu_id_start field at points where it was relied on for
> > > correctness.
> >
> > This specific behaviour was documented as being wrong and running with
> > DEBUG_RSEQ would have flagged it.
> >
> > The tcmalloc issue has been contentious for a long time. The tcmalloc
> > folks relied on something that was documented to be wrong. It has been
> > reported to the tcmalloc people many years ago and if you were to run
> > tcmalloc on most any kernel (very much including 6.19) with
> > DEBUG_RSEQ=y, it would have yelled.
> >
> > The tcmalloc people didn't care. There was a proposal for an RSEQ
> > extension for what they need, and they didn't care. All this should be
> > in their bugzilla or whatever.
> >
> > The RSEQ rework improved performance significantly for everyone, and
> > kept all the documented behaviour (+- arm64 bug). Tcmalloc got screwed
> > over because they relied on implementation behaviour that was
> > specifically documented to be broken. And they didn't care. Google was
> > very much aware of this. And hasn't lifted a finger to remedy it.
>
> Also: https://lore.kernel.org/all/874io5andc.ffs@tglx/
(Sorry for the resend to folks who got this already - I got an alert
that it was rejected by the mailinglists because it contained html so
attempting to resend as plain text)
I won't claim that tcmalloc _should_ be abusing cpu_id_start as it is.
I agree that it seems questionable at best. However, I will strongly
disagree with the following comment in that message:
> What it not longer does is updating the
> CPU number for the preemption case on the same CPU
> because that's just a massive waste of CPU cycles.
I don't think it will cost _any_ cycles to implement what I proposed.
And it especially should have no impact from just enabling rseq on a
thread as glibc now does. It should only result in different
instructions being executed when the program actually _uses_ rseq by
setting the rseq_cs variable to a non-null pointer. I will repeat the
proposal with a bit more commentary in case you missed some of the
details that make it free:
Any time a critical section might be aborted (migration, preemption,
signal delivery, and membarrier IPI), the kernel _already_ must check
the rseq_cs field to see if the thread is in a critical section [and
if it is null because the program isn't using rseq critical sections,
no further action is taken]. This is documented as nulling the pointer
after (I assume to make later checks cheaper) [if this changed, then
it *is* a change in _documented behavior_, not just an implementation
detail]. It would be sufficient for tcmalloc's internal usage if every
time the kernel nulled out rseq_cs, it also wrote the cpu id to
cpu_id_start. [This is one additional store to a cacheline you are
already writing to so it should be ~free on modern OoO CPUs and cheap
on others. There might be a small cost to loading the current cpu, but
since nothing depends on that other than the store, I still expect it
to be ~free]
To make this more concrete, I am proposing adding
unsafe_put_user((u32)task_cpu(t), &t->rseq.usrptr->cpu_id_start, efault);
after each place where you currently do
unsafe_put_user(0ULL, &t->rseq.usrptr->rseq_cs, efault);
in rseq_update_user_cs. Is that something that you would expect to
cause a performance issue?
Again, I'm not claiming that it is "good" that this needs to be done.
But it does seem like a small price to pay to keep existing binaries
working on new kernels. Quoting the first paragraph of
https://docs.kernel.org/admin-guide/reporting-regressions.html:
> “We don’t cause regressions” is the first rule of Linux kernel development; Linux founder and lead developer Linus Torvalds established it himself and ensures it’s obeyed.
I don't see anything on that page that says it doesn't count as a
regression if the userspace program "relied on implementation
behaviour that was specifically documented to be broken".
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Thomas Gleixner @ 2026-04-23 10:39 UTC (permalink / raw)
To: Dmitry Vyukov, Jinjie Ruan, linux-man
Cc: Mark Rutland, Mathias Stearn, Mathieu Desnoyers, Catalin Marinas,
Will Deacon, Boqun Feng, Paul E. McKenney, Chris Kennelly,
regressions, linux-kernel, linux-arm-kernel, Peter Zijlstra,
Ingo Molnar, Blake Oler
In-Reply-To: <CACT4Y+bxnQyHGdVNE1BYTx+Z2-cscLb38HYS9jBM5gPAz8=4bw@mail.gmail.com>
On Thu, Apr 23 2026 at 07:53, Dmitry Vyukov wrote:
> On Thu, 23 Apr 2026 at 03:48, Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
> This part of the rseq man page needs to be fixed as well I think. The
> kernel no longer reliably provides clearing of rseq_cs on preemption,
> right?
>
> https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2#n241
>
> "and set to NULL by the kernel when it restarts an assembly
> instruction sequence block,
> as well as when the kernel detects that it is preempting or delivering
> a signal outside of the range targeted by the rseq_cs."
The kernel clears rseq_cs reliably when user space was interrupted and:
the task was preempted
or
the return from interrupt delivers a signal
If the task invoked a syscall then there is absolutely no reason to do
either of this because syscalls from within a critical section are a
bug and catched when enabling rseq debugging.
The original code did this along with unconditionally updating CPU/MMCID
which resulted in ~15% performance regression on a syscall heavy
database benchmark once glibc started to register rseq.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH net v2 0/2] net: airoha: Fix NULL pointer derefrences in airoha_qdma_cleanup()
From: patchwork-bot+netdevbpf @ 2026-04-23 10:50 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260420-airoha_qdma_init_rx_queue-fix-v2-0-d99347e5c18d@kernel.org>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 20 Apr 2026 10:07:46 +0200 you wrote:
> Fix two possible NULL pointer derefrences in airoha_qdma_cleanup routine
> if airoha_qdma_init() fails.
>
> ---
> Changes in v2:
> - Move page_pool allocation after desc list allocation in
> airoha_qdma_init_rx_queue()
> - Move netif_napi_add_tx() after irq desc queue allocation in
> airoha_qdma_tx_irq_init()
> - Link to v1: https://lore.kernel.org/r/20260417-airoha_qdma_init_rx_queue-fix-v1-0-db9fa5e468e5@kernel.org
>
> [...]
Here is the summary with links:
- [net,v2,1/2] net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()
https://git.kernel.org/netdev/net/c/379050947a18
- [net,v2,2/2] net: airoha: Add size check for TX NAPIs in airoha_qdma_cleanup()
https://git.kernel.org/netdev/net/c/4b91cb65789b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mathias Stearn @ 2026-04-23 10:51 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Dmitry Vyukov, Jinjie Ruan, linux-man, Mark Rutland,
Mathieu Desnoyers, Catalin Marinas, Will Deacon, Boqun Feng,
Paul E. McKenney, Chris Kennelly, regressions, linux-kernel,
linux-arm-kernel, Peter Zijlstra, Ingo Molnar, Blake Oler
In-Reply-To: <87ik9i0xlj.ffs@tglx>
On Thu, Apr 23, 2026 at 12:39 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> The kernel clears rseq_cs reliably when user space was interrupted and:
>
> the task was preempted
> or
> the return from interrupt delivers a signal
>
> If the task invoked a syscall then there is absolutely no reason to do
> either of this because syscalls from within a critical section are a
> bug and catched when enabling rseq debugging.
>
> The original code did this along with unconditionally updating CPU/MMCID
> which resulted in ~15% performance regression on a syscall heavy
> database benchmark once glibc started to register rseq.
Just to be clear TCMalloc does not need either rseq_cs to be cleared
or cpu_id_start to be written to on syscalls because it doesn't do
syscalls from critical sections. It will actually benefit (slightly)
from not updating cpu_id_start on syscalls.
It is specifically in the cases where an rseq would need to be aborted
(preemption, signals, migration, and membarrier IPI with the rseq
flag) that TCMalloc relies on cpu_id_start being written. It does rely
on that write even when not inside the critical section, because it
effectively uses that to detect if there were any would-cause-abort
events in between two critical sections. But since it leaves the
rseq_cs pointer non-null between critical sections, so you dont need
to add _any_ overhead for programs that never make use of rseq after
registration, or add any overhead to syscalls even for those who do.
^ permalink raw reply
* Re: [PATCH v2 08/20] drm/plane: Add new atomic_create_state callback
From: Maxime Ripard @ 2026-04-23 10:54 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Maarten Lankhorst, David Airlie, Simona Vetter, Jonathan Corbet,
Shuah Khan, Dmitry Baryshkov, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <55c24dca-e354-49d1-8eaa-edf66f679428@suse.de>
[-- Attachment #1: Type: text/plain, Size: 3377 bytes --]
On Tue, Apr 21, 2026 at 03:22:22PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> > Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> > to drm_private_obj") introduced a new pattern for allocating drm object
> > states.
> >
> > Instead of relying on the reset() callback, it created a new
> > atomic_create_state hook. This is helpful because reset is a bit
> > overloaded: it's used to create the initial software state, reset it,
> > but also reset the hardware.
> >
> > It can also be used either at probe time, to create the initial state
> > and possibly reset the hardware to an expected default, but also during
> > suspend/resume.
> >
> > Both these cases come with different expectations too: during the
> > initialization, we want to initialize all states, but during
> > suspend/resume, drm_private_states for example are expected to be kept
> > around.
> >
> > And reset() isn't fallible, which makes it harder to handle
> > initialization errors properly.
> >
> > And this is only really relevant for some drivers, since all the helpers
> > for reset only create a new state, and don't touch the hardware at all.
> >
> > It was thus decided to create a new hook that would allocate and
> > initialize a pristine state without any side effect:
> > atomic_create_state to untangle a bit some of it, and to separate the
> > initialization with the actual reset one might need during a
> > suspend/resume.
> >
> > Let's continue the transition to the new pattern with planes.
> >
> > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > ---
> > drivers/gpu/drm/drm_atomic_state_helper.c | 44 +++++++++++++++++++++++++++++++
> > drivers/gpu/drm/drm_mode_config.c | 21 ++++++++++++++-
> > include/drm/drm_atomic_state_helper.h | 4 +++
> > include/drm/drm_plane.h | 13 +++++++++
> > 4 files changed, 81 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 2548d6da13675f63304dc92423c5d225de0447a8..f4ce9d3573cbecf216904db54335e0cf84a01c39 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -319,10 +319,29 @@ void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> > plane->state = plane_state;
> > }
> > EXPORT_SYMBOL(__drm_atomic_helper_plane_reset);
> > +/**
> > + * __drm_atomic_helper_plane_create_state - initializes plane state
> > + * @plane: plane object
> > + * @state: new state to initialize
> > + *
> > + * Initializes the newly allocated @state, usually required when
> > + * initializing the drivers.
> > + *
> > + * @state is assumed to be zeroed.
> > + *
> > + * This is useful for drivers that subclass @drm_plane_state.
> > + */
> > +void __drm_atomic_helper_plane_create_state(struct drm_plane *plane,
> > + struct drm_plane_state *state)
> > +{
> > + __drm_atomic_helper_plane_state_init(state, plane);
> > +}
> > +EXPORT_SYMBOL(__drm_atomic_helper_plane_create_state);
>
> Will this function have another purpuse? Could we just call
> _plane_state_init() directly from anywhere?
Yeah, I guess that makes sense. I'll drop that patch and the similar ones.
Thanks!
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-23 10:56 UTC (permalink / raw)
To: Will Deacon
Cc: Sudeep Holla, Marc Zyngier, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
sebastianene
In-Reply-To: <aene4KFD5kbSbFRm@willie-the-truck>
Hi Will,
> On Wed, Apr 22, 2026 at 02:32:23PM +0100, Yeoreum Yun wrote:
> > Hi All,
> >
> > > > On Tue, Apr 21, 2026 at 07:57:43AM +0100, Yeoreum Yun wrote:
> > > >
> > > > [...]
> > > >
> > > > >
> > > > > Also, the FF-A initialization is not driven by a device probe, but rather
> > > > > happens as part of the bus registration itself,
> > > > > so it does not fit well with a device_link or probe deferral based approach.
> > > > >
> > > > > Instead, perhaps we could go with the idea I mentioned previously:
> > > > > either introduce a notifier, or create a pseudo ffa_device
> > > > > once pKVM initialization has completed, and
> > > > > then let the ffa driver perform the additional initialization from there.
> > > > >
> > > > > Am I missing something?
> > > > >
> > > >
> > > > In order to handle/cleanup some ugliness in interrupt management in the
> > > > FF-A driver, we may introduce DT node eventually. But it will take sometime.
> > >
> > > Unfortunately, I think this DT node wouldn't be helpful to solve
> > > this situation for dependency with the kvm misc device...
> > >
> > > IMHO, current situation, the notifier seems to good option. unless
> > > we make the initcall to recongise this dependency.
> > >
> >
> > I think the best approach for now is to introduce a notifier to handle this situation.
> > If there are no further suggestions, I’ll send a v2 based on:
> > - https://lore.kernel.org/all/aeS4rAeVQ0yJIPYw@e129823.arm.com/
>
> I can't say that I'm a huge fan of that :/
>
> The notifier will literally fire once, for a single listener. That's
> called a function call.
I revisited Marc’s suggestion about using device links
(https://lore.kernel.org/all/87pl3vb5bm.wl-maz@kernel.org/)
but unless I’m misunderstanding something, I don’t think it would be a viable solution:
- https://lore.kernel.org/all/aen0j3qM2k06OdXC@e129823.arm.com/#t
Also, calling functions defined by FF-A from KVM would introduce
an unnecessary module dependency between the KVM and FF-A drivers.
I’ve been trying to find an alternative approach,
but I’m not confident about what would be appropriate.
If you don’t mind, could you share your thoughts on this?
Thanks!
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH] crypto: sun8i-ss - avoid hash and rng references
From: Herbert Xu @ 2026-04-23 11:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Corentin Labbe, David S . Miller, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Eric Biggers, Ovidiu Panait,
linux-crypto, linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <3948e39f-dd20-44e2-b264-dc2a0a88f5b5@app.fastmail.com>
On Thu, Apr 23, 2026 at 12:26:23PM +0200, Arnd Bergmann wrote:
>
> Sure, but I'm not adding new code here, I only reported a regression
> from Eric's (otherwise very nice) cleanup and tried to come up
> with a better workaround than adding another 'select'.
>
> I've tried to rework one driver to use IS_ENABLED() checks now
> instead of the #ifdef, and also replace the for()/switch()
> loop with three separate loops for simplicity. See below for
> what I ended up with compared with my first patch.
>
> I'm still not entirely happy with that version either, especially
> since this is getting beyond a purely mechanical cleanup.
> If you think this is better, I can do it for all three drivers,
> otherwise I'd just send the oneline change to work around the
> third driver link failure the same way that Eric did for the
> other two, and let the sunxi maintainters worry about cleaning
> it up.
Sorry, I made my comment based on your original patch only which
simply added ifdefs.
Now that I see the wider context in the driver, I'm happy to take
your original patch as is.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Mimi Zohar @ 2026-04-23 11:01 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <aem0SSQuE1e3pGOS@e129823.arm.com>
On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
> > On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
> > > > Hi Mimi,
> > > >
> > > > > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > > > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > > > > the TPM driver must be built as built-in and
> > > > > > must be probed before the IMA subsystem is initialized.
> > > > > >
> > > > > > However, when the TPM device operates over the FF-A protocol using
> > > > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > > > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > > > > interface to the tpm_crb driver — has not yet been probed.
> > > > > >
> > > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > > the CRB interface is probed before IMA initialization,
> > > > > > the following conditions must be met:
> > > > > >
> > > > > > 1. The corresponding ffa_device must be registered,
> > > > > > which is done via ffa_init().
> > > > > >
> > > > > > 2. The tpm_crb_driver must successfully probe this device via
> > > > > > tpm_crb_ffa_init().
> > > > > >
> > > > > > 3. The tpm_crb driver using CRB over FF-A can then
> > > > > > be probed successfully. (See crb_acpi_add() and
> > > > > > tpm_crb_ffa_init() for reference.)
> > > > > >
> > > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > > > >
> > > > > > When this occurs, probing the TPM device is deferred.
> > > > > > However, the deferred probe can happen after the IMA subsystem
> > > > > > has already been initialized, since IMA initialization is performed
> > > > > > during late_initcall, and deferred_probe_initcall() is performed
> > > > > > at the same level.
> > > > > >
> > > > > > To resolve this, call ima_init() again at late_inicall_sync level
> > > > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > > > log though TPM device presents in the system.
> > > > > >
> > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > >
> > > > > A lot of change for just detecting whether ima_init() is being called on
> > > > > late_initcall or late_initcall_sync(), without any explanation for all the other
> > > > > changes (e.g. ima_init_core).
> > > > >
> > > > > Please just limit the change to just calling ima_init() twice.
> > > >
> > > > My concern is that ima_update_policy_flags() will be called
> > > > when ima_init() is deferred -- not initialised anything.
> > > > though functionally, it might be okay however,
> > > > I think ima_update_policy_flags() and notifier should work after ima_init()
> > > > works logically.
> > > >
> > > > This change I think not much quite a lot. just wrapper ima_init() with
> > > > ima_init_core() with some error handling.
> > > >
> > > > Am I missing something?
> > >
> > > Also, if we handle in ima_init() only, but it failed with other reason,
> > > we shouldn't call again ima_init() in the late_initcall_sync.
> > >
> > > To handle this, It wouldn't do in the ima_init() but we need to handle
> > > it by caller of ima_init().
> >
> > Only tpm_default_chip() is being called to set the ima_tpm_chip. On failure,
> > instead of going into TPM-bypass mode, return immediately. There are no calls
> > to anything else. Just call ima_init() a second time.
>
> I’m not fully convinced this is sufficient.
>
> What I meant is the case where ima_init() fails due to other
> initialisation steps, not only tpm_default_chip() (e.g. ima_fs_init()).
The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
available at late_initcall. This would be classified as a bug fix and would be
backported. No other changes should be included in this patch.
>
> If it fails at the late_initcall stage for such reasons, then we
> should not call ima_init() again at late_initcall_sync.
>
> For this reason, instead of adding a static variable inside
> ima_init(), I think it would be better to manage the state in the
> caller and introduce something like an ima_initialised flag. Also, if
> initialisation fails for other reasons, the notifier block should be
> unregistered.
Defining a global file static variable, in lieu of a local static variable, is
fine. Defining two functions, one for late_initcall and another for
late_initcall_sync, that do nothing other than call ima_init() is also fine.
Please keep this patch as simple as possible.
>
> I’d also like to ask again whether it is fine to call
> ima_update_policy_flags() and keep the notifier registered in the
> deferred TPM case. While this may be functionally acceptable, it seems
> logically questionable to do so when ima_init() has not completed.
Other than extending the TPM, IMA should behave exactly the same whether there
is a TPM or goes into TPM-bypass mode.
>
> There is also a possibility that a deferred case ultimately fails (e.g.
> deferred at late_initcall, but then failing at late_initcall_sync
> for another reason, even while entering TPM bypass mode). In that case,
> it seems more appropriate to handle this state in the caller of
> ima_init(), rather than inside ima_init() itself.
If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
bypass mode. Please don't make any other changes to the existing IMA behavior
and hide it here behind the late_initcall_sync change.
>
> Am I still missing something?
When your original patch moved the initialization from late_initcall to
late_initcall_sync, you didn't question anything. There's absolutely no
difference between that and calling ima_init twice, as long as on late_initcall
ima_init() returns immediately if the TPM chip isn't defined.
Any other changes are superfluous. Keep the patch simple!
Mimi
^ permalink raw reply
* [PATCH v2] crypto: ixp4xx - fix buffer chain unwind on allocation failure
From: Ruoyu Wang @ 2026-04-23 11:19 UTC (permalink / raw)
To: Herbert Xu, Corentin Labbe, linux-crypto
Cc: Linus Walleij, Imre Kaloz, David S . Miller, linux-arm-kernel,
linux-kernel, Ruoyu Wang
chainup_buffers() builds a linked list of buffer descriptors for a
scatterlist. If dma_pool_alloc() fails while constructing the list, the
current code sets buf to NULL and later dereferences it unconditionally
at the end of the function:
buf->next = NULL;
buf->phys_next = 0;
This can lead to a null-pointer dereference on allocation failure.
If the failure happens after part of the descriptor chain has already
been allocated and DMA-mapped, the partially constructed chain also
needs to be released.
Fix this by terminating the partially constructed chain on allocation
failure and letting the callers unwind it via their existing cleanup
paths. Also fix ablk_perform() to preserve the hook pointers before
checking for failure, so partially built chains can be freed correctly.
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
v2:
- Keep the unwind path in the callers, per Herbert Xu's feedback.
- Terminate the partial chain before returning NULL on allocation failure.
- Save the hook pointers in ablk_perform() before checking the return value.
- Thanks to Herbert Xu for the review.
drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c | 25 ++++++++++++---------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
index fcc0cf4df..5b90cf0fb 100644
--- a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
+++ b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
@@ -884,8 +884,9 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
ptr = sg_virt(sg);
next_buf = dma_pool_alloc(buffer_pool, flags, &next_buf_phys);
if (!next_buf) {
- buf = NULL;
- break;
+ buf->next = NULL;
+ buf->phys_next = 0;
+ return NULL;
}
sg_dma_address(sg) = dma_map_single(dev, ptr, len, dir);
buf->next = next_buf;
@@ -983,7 +984,7 @@ static int ablk_perform(struct skcipher_request *req, int encrypt)
unsigned int nbytes = req->cryptlen;
enum dma_data_direction src_direction = DMA_BIDIRECTIONAL;
struct ablk_ctx *req_ctx = skcipher_request_ctx(req);
- struct buffer_desc src_hook;
+ struct buffer_desc *buf, src_hook;
struct device *dev = &pdev->dev;
unsigned int offset;
gfp_t flags = req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP ?
@@ -1025,22 +1026,24 @@ static int ablk_perform(struct skcipher_request *req, int encrypt)
/* This was never tested by Intel
* for more than one dst buffer, I think. */
req_ctx->dst = NULL;
- if (!chainup_buffers(dev, req->dst, nbytes, &dst_hook,
- flags, DMA_FROM_DEVICE))
- goto free_buf_dest;
- src_direction = DMA_TO_DEVICE;
+ buf = chainup_buffers(dev, req->dst, nbytes, &dst_hook,
+ flags, DMA_FROM_DEVICE);
req_ctx->dst = dst_hook.next;
crypt->dst_buf = dst_hook.phys_next;
+ if (!buf)
+ goto free_buf_dest;
+ src_direction = DMA_TO_DEVICE;
} else {
req_ctx->dst = NULL;
}
req_ctx->src = NULL;
- if (!chainup_buffers(dev, req->src, nbytes, &src_hook, flags,
- src_direction))
- goto free_buf_src;
-
+ buf = chainup_buffers(dev, req->src, nbytes, &src_hook, flags,
+ src_direction);
req_ctx->src = src_hook.next;
crypt->src_buf = src_hook.phys_next;
+ if (!buf)
+ goto free_buf_src;
+
crypt->ctl_flags |= CTL_FLAG_PERFORM_ABLK;
qmgr_put_entry(send_qid, crypt_virt2phys(crypt));
BUG_ON(qmgr_stat_overflow(send_qid));
--
2.43.0
^ permalink raw reply related
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Yeoreum Yun @ 2026-04-23 11:20 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <56a8aab50a3b5ce0a345fc2079fb2abc7d0f1b23.camel@linux.ibm.com>
Hi Mimi,
> On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
> > > On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
> > > > > Hi Mimi,
> > > > >
> > > > > > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > > > > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > > > > > the TPM driver must be built as built-in and
> > > > > > > must be probed before the IMA subsystem is initialized.
> > > > > > >
> > > > > > > However, when the TPM device operates over the FF-A protocol using
> > > > > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > > > > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > > > > > interface to the tpm_crb driver — has not yet been probed.
> > > > > > >
> > > > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > > > the CRB interface is probed before IMA initialization,
> > > > > > > the following conditions must be met:
> > > > > > >
> > > > > > > 1. The corresponding ffa_device must be registered,
> > > > > > > which is done via ffa_init().
> > > > > > >
> > > > > > > 2. The tpm_crb_driver must successfully probe this device via
> > > > > > > tpm_crb_ffa_init().
> > > > > > >
> > > > > > > 3. The tpm_crb driver using CRB over FF-A can then
> > > > > > > be probed successfully. (See crb_acpi_add() and
> > > > > > > tpm_crb_ffa_init() for reference.)
> > > > > > >
> > > > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > > > > >
> > > > > > > When this occurs, probing the TPM device is deferred.
> > > > > > > However, the deferred probe can happen after the IMA subsystem
> > > > > > > has already been initialized, since IMA initialization is performed
> > > > > > > during late_initcall, and deferred_probe_initcall() is performed
> > > > > > > at the same level.
> > > > > > >
> > > > > > > To resolve this, call ima_init() again at late_inicall_sync level
> > > > > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > > > > log though TPM device presents in the system.
> > > > > > >
> > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > > >
> > > > > > A lot of change for just detecting whether ima_init() is being called on
> > > > > > late_initcall or late_initcall_sync(), without any explanation for all the other
> > > > > > changes (e.g. ima_init_core).
> > > > > >
> > > > > > Please just limit the change to just calling ima_init() twice.
> > > > >
> > > > > My concern is that ima_update_policy_flags() will be called
> > > > > when ima_init() is deferred -- not initialised anything.
> > > > > though functionally, it might be okay however,
> > > > > I think ima_update_policy_flags() and notifier should work after ima_init()
> > > > > works logically.
> > > > >
> > > > > This change I think not much quite a lot. just wrapper ima_init() with
> > > > > ima_init_core() with some error handling.
> > > > >
> > > > > Am I missing something?
> > > >
> > > > Also, if we handle in ima_init() only, but it failed with other reason,
> > > > we shouldn't call again ima_init() in the late_initcall_sync.
> > > >
> > > > To handle this, It wouldn't do in the ima_init() but we need to handle
> > > > it by caller of ima_init().
> > >
> > > Only tpm_default_chip() is being called to set the ima_tpm_chip. On failure,
> > > instead of going into TPM-bypass mode, return immediately. There are no calls
> > > to anything else. Just call ima_init() a second time.
> >
> > I’m not fully convinced this is sufficient.
> >
> > What I meant is the case where ima_init() fails due to other
> > initialisation steps, not only tpm_default_chip() (e.g. ima_fs_init()).
>
> The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
> available at late_initcall. This would be classified as a bug fix and would be
> backported. No other changes should be included in this patch.
Okay.
> >
> > I’d also like to ask again whether it is fine to call
> > ima_update_policy_flags() and keep the notifier registered in the
> > deferred TPM case. While this may be functionally acceptable, it seems
> > logically questionable to do so when ima_init() has not completed.
>
> Other than extending the TPM, IMA should behave exactly the same whether there
> is a TPM or goes into TPM-bypass mode.
>
> >
> > There is also a possibility that a deferred case ultimately fails (e.g.
> > deferred at late_initcall, but then failing at late_initcall_sync
> > for another reason, even while entering TPM bypass mode). In that case,
> > it seems more appropriate to handle this state in the caller of
> > ima_init(), rather than inside ima_init() itself.
>
> If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
> bypass mode. Please don't make any other changes to the existing IMA behavior
> and hide it here behind the late_initcall_sync change.
Okay. you're talking called ima_update_policy_flags() at late_initcall
wouldn't be not a problem even in case of late_initcall_sync's ima_init()
get failed with "TPM-bypass mode".
I see then, I'll make a patch simpler then.
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH 2/2] firmware: zynqmp: Add dynamic CSU register discovery and sysfs interface
From: Michal Simek @ 2026-04-23 11:34 UTC (permalink / raw)
To: Ronak Jain, senthilnathan.thangaraj; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20260408114244.2852015-3-ronak.jain@amd.com>
On 4/8/26 13:42, Ronak Jain wrote:
> Add support for dynamically discovering and exposing Configuration
> Security Unit (CSU) registers through sysfs. Leverage the existing
> PM_QUERY_DATA API to discover available registers at runtime, making
> the interface flexible and maintainable.
>
> Key features:
> - Dynamic register discovery using PM_QUERY_DATA API
> * PM_QID_GET_NODE_COUNT: Query number of available registers
> * PM_QID_GET_NODE_NAME: Query register names by index
> - Automatic sysfs attribute creation under csu_registers/ group
> - Read operations via existing IOCTL_READ_REG API
> - Write operations via existing IOCTL_MASK_WRITE_REG API
> - Firmware-enforced access control (read-only registers reject writes)
>
> The sysfs interface is created at:
> /sys/devices/platform/firmware:zynqmp-firmware/csu_registers/
>
> Currently supported registers include:
> - multiboot (CSU_MULTI_BOOT)
> - idcode (CSU_IDCODE, read-only)
> - pcap-status (CSU_PCAP_STATUS, read-only)
>
> The dynamic discovery approach allows firmware to control which
> registers are exposed without requiring kernel changes, improving
> maintainability and security.
>
> Signed-off-by: Ronak Jain <ronak.jain@amd.com>
> ---
> MAINTAINERS | 10 +
> drivers/firmware/xilinx/Makefile | 2 +-
> drivers/firmware/xilinx/zynqmp-csu-reg.c | 249 +++++++++++++++++++++++
> drivers/firmware/xilinx/zynqmp-csu-reg.h | 18 ++
> drivers/firmware/xilinx/zynqmp.c | 6 +
> include/linux/firmware/xlnx-zynqmp.h | 4 +-
> 6 files changed, 287 insertions(+), 2 deletions(-)
> create mode 100644 drivers/firmware/xilinx/zynqmp-csu-reg.c
> create mode 100644 drivers/firmware/xilinx/zynqmp-csu-reg.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 10d12b51b1f6..37fe2b7e0ccf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -29212,6 +29212,16 @@ F: drivers/dma/xilinx/xdma.c
> F: include/linux/dma/amd_xdma.h
> F: include/linux/platform_data/amd_xdma.h
>
> +XILINX ZYNQMP CSU REGISTER DRIVER
> +M: Senthil Nathan Thangaraj <senthilnathan.thangaraj@amd.com>
> +R: Michal Simek <michal.simek@amd.com>
> +R: Ronak Jain <ronak.jain@amd.com>
> +L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> +S: Maintained
> +F: Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
> +F: drivers/firmware/xilinx/zynqmp-csu-reg.c
> +F: drivers/firmware/xilinx/zynqmp-csu-reg.h
> +
> XILINX ZYNQMP DPDMA DRIVER
> M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> L: dmaengine@vger.kernel.org
> diff --git a/drivers/firmware/xilinx/Makefile b/drivers/firmware/xilinx/Makefile
> index 8db0e66b6b7e..6203f41daaa6 100644
> --- a/drivers/firmware/xilinx/Makefile
> +++ b/drivers/firmware/xilinx/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> # Makefile for Xilinx firmwares
>
> -obj-$(CONFIG_ZYNQMP_FIRMWARE) += zynqmp.o zynqmp-ufs.o zynqmp-crypto.o
> +obj-$(CONFIG_ZYNQMP_FIRMWARE) += zynqmp.o zynqmp-ufs.o zynqmp-crypto.o zynqmp-csu-reg.o
> obj-$(CONFIG_ZYNQMP_FIRMWARE_DEBUG) += zynqmp-debug.o
> diff --git a/drivers/firmware/xilinx/zynqmp-csu-reg.c b/drivers/firmware/xilinx/zynqmp-csu-reg.c
> new file mode 100644
> index 000000000000..1f304ce858b1
> --- /dev/null
> +++ b/drivers/firmware/xilinx/zynqmp-csu-reg.c
> @@ -0,0 +1,249 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Zynq MPSoC CSU Register Access
> + *
> + * Copyright (C) 2026 Advanced Micro Devices, Inc.
> + *
> + * Michal Simek <michal.simek@amd.com>
> + * Ronak Jain <ronak.jain@amd.com>
> + */
> +
> +#include <linux/firmware/xlnx-zynqmp.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +
> +#include "zynqmp-csu-reg.h"
> +
> +/* Node ID for CSU module in firmware */
> +#define CSU_NODE_ID 0
> +
> +/* Maximum number of CSU registers supported */
> +#define MAX_CSU_REGS 50
> +
> +/* Size of register name returned by firmware (3 u32 words = 12 bytes) */
> +#define CSU_REG_NAME_LEN 12
> +
> +/**
> + * struct zynqmp_csu_reg - CSU register information
> + * @id: Register index from firmware
> + * @name: Register name
> + * @attr: Device attribute for sysfs
> + */
> +struct zynqmp_csu_reg {
> + u32 id;
> + char name[CSU_REG_NAME_LEN];
> + struct device_attribute attr;
> +};
> +
> +/**
> + * struct zynqmp_csu_data - Per-device CSU data
> + * @csu_regs: Array of CSU registers
> + * @csu_reg_count: Number of CSU registers
> + * @csu_attr_group: Attribute group for sysfs
> + */
> +struct zynqmp_csu_data {
> + struct zynqmp_csu_reg *csu_regs;
> + int csu_reg_count;
> + struct attribute_group csu_attr_group;
> +};
> +
> +/**
> + * zynqmp_pm_get_node_count() - Get number of supported nodes via QUERY_DATA
> + *
> + * Return: Number of nodes on success, or negative error code
> + */
> +static int zynqmp_pm_get_node_count(void)
> +{
> + struct zynqmp_pm_query_data qdata = {0};
> + u32 ret_payload[PAYLOAD_ARG_CNT];
> + int ret;
> +
> + qdata.qid = PM_QID_GET_NODE_COUNT;
> +
> + ret = zynqmp_pm_query_data(qdata, ret_payload);
> + if (ret)
> + return ret;
> +
> + return ret_payload[1];
> +}
> +
> +/**
> + * zynqmp_pm_get_node_name() - Get node name via QUERY_DATA
> + * @index: Register index
> + * @name: Buffer to store register name
> + *
> + * Return: 0 on success, error code otherwise
> + */
> +static int zynqmp_pm_get_node_name(u32 index, char *name)
> +{
> + struct zynqmp_pm_query_data qdata = {0};
> + u32 ret_payload[PAYLOAD_ARG_CNT];
> + int ret;
> +
> + qdata.qid = PM_QID_GET_NODE_NAME;
> + qdata.arg1 = index;
> +
> + ret = zynqmp_pm_query_data(qdata, ret_payload);
> + if (ret)
> + return ret;
> +
> + memcpy(name, &ret_payload[1], CSU_REG_NAME_LEN);
> + name[CSU_REG_NAME_LEN - 1] = '\0';
> +
> + return 0;
> +}
> +
> +/**
> + * zynqmp_csu_reg_show() - Generic show function for all registers
> + * @dev: Device pointer
> + * @attr: Device attribute
> + * @buf: Output buffer
> + *
> + * Return: Number of bytes written to buffer, or error code
> + */
> +static ssize_t zynqmp_csu_reg_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct zynqmp_csu_reg *reg;
> + u32 value;
> + int ret;
> +
> + /* Use container_of to get register directly */
> + reg = container_of(attr, struct zynqmp_csu_reg, attr);
> +
> + ret = zynqmp_pm_sec_read_reg(CSU_NODE_ID, reg->id, &value);
> + if (ret)
> + return ret;
> +
> + return sysfs_emit(buf, "0x%08x\n", value);
> +}
> +
> +/**
> + * zynqmp_csu_reg_store() - Generic store function for writable registers
> + * @dev: Device pointer
> + * @attr: Device attribute
> + * @buf: Input buffer
> + * @count: Buffer size
> + *
> + * Format: "mask value" - both mask and value required
> + * Example: echo "0xFFFFFFFF 0x12345678" > register
> + *
> + * Return: count on success, error code otherwise
> + */
> +static ssize_t zynqmp_csu_reg_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct zynqmp_csu_reg *reg;
> + u32 mask, value;
> + int ret;
> +
> + reg = container_of(attr, struct zynqmp_csu_reg, attr);
> +
> + if (sscanf(buf, "%x %x", &mask, &value) != 2)
> + return -EINVAL;
> +
> + ret = zynqmp_pm_sec_mask_write_reg(CSU_NODE_ID, reg->id, mask, value);
> + if (ret)
> + return ret;
> +
> + return count;
> +}
> +
> +/**
> + * zynqmp_csu_discover_registers() - Discover CSU registers from firmware
> + * @pdev: Platform device pointer
> + *
> + * This function uses PM_QUERY_DATA to discover all available CSU registers
> + * and creates sysfs group under /sys/devices/platform/firmware:zynqmp-firmware/
> + *
> + * Return: 0 on success, error code otherwise
> + */
> +int zynqmp_csu_discover_registers(struct platform_device *pdev)
> +{
> + struct zynqmp_csu_data *csu_data;
> + struct attribute **attrs;
> + int count, ret, i;
> +
> + ret = zynqmp_pm_is_function_supported(PM_QUERY_DATA, PM_QID_GET_NODE_COUNT);
> + if (ret) {
> + dev_dbg(&pdev->dev, "CSU register discovery not supported by current firmware\n");
> + return 0;
> + }
> +
> + count = zynqmp_pm_get_node_count();
> + if (count < 0)
> + return count;
> + if (count == 0) {
> + dev_dbg(&pdev->dev, "No nodes available from firmware\n");
> + return 0;
> + }
> +
> + /* Validate count to prevent excessive memory allocation */
> + if (count > MAX_CSU_REGS) {
> + dev_err(&pdev->dev, "Register count %d exceeds maximum %d\n",
> + count, MAX_CSU_REGS);
> + return -EINVAL;
> + }
> +
> + dev_dbg(&pdev->dev, "Discovered %d nodes from firmware\n", count);
> +
> + csu_data = devm_kzalloc(&pdev->dev, sizeof(*csu_data), GFP_KERNEL);
> + if (!csu_data)
> + return -ENOMEM;
> +
> + csu_data->csu_reg_count = count;
Where is this used?
> +
> + csu_data->csu_regs = devm_kcalloc(&pdev->dev, count, sizeof(*csu_data->csu_regs),
> + GFP_KERNEL);
> + if (!csu_data->csu_regs) {
> + devm_kfree(&pdev->dev, csu_data);
My bet is that you are freeing this memory because csu is optional and you don't
want to waste memory. Is this correct assumption?
If yes, I think it will be good if you can express this intention in commit
message.
> + return -ENOMEM;
> + }
> +
> + attrs = devm_kcalloc(&pdev->dev, count + 1, sizeof(*attrs), GFP_KERNEL);
> + if (!attrs) {
> + devm_kfree(&pdev->dev, csu_data->csu_regs);
> + devm_kfree(&pdev->dev, csu_data);
> + return -ENOMEM;
> + }
> +
> + for (i = 0; i < count; i++) {
> + struct zynqmp_csu_reg *reg = &csu_data->csu_regs[i];
> + struct device_attribute *dev_attr = ®->attr;
> +
> + reg->id = i;
> +
> + ret = zynqmp_pm_get_node_name(i, reg->name);
> + if (ret) {
> + dev_warn(&pdev->dev, "Failed to get name for register %d\n", i);
> + snprintf(reg->name, sizeof(reg->name), "csu_reg_%d", i);
> + }
> +
> + /* Create sysfs attribute - firmware enforces actual access control */
> + sysfs_attr_init(&dev_attr->attr);
> + dev_attr->attr.name = reg->name;
> + dev_attr->attr.mode = 0644;
You should comment this a little bit. In commit message you are saying that some
of that registers are read only but here you are exposing all of them as rw.
Do you have any interface/attribute/flag where you can find out if this is read
only?
I expect if you try to write to read only firmware driver will just reject it
anyway. If you don't have any flag for it, it would be good to describe this
limiation in commit message.
> + dev_attr->show = zynqmp_csu_reg_show;
> + dev_attr->store = zynqmp_csu_reg_store;
> +
> + attrs[i] = &dev_attr->attr;
> +
> + dev_dbg(&pdev->dev, "Register %d: id=%d name=%s\n", i, reg->id, reg->name);
> + }
> +
> + csu_data->csu_attr_group.name = "csu_registers";
> + csu_data->csu_attr_group.attrs = attrs;
> +
> + ret = devm_device_add_group(&pdev->dev, &csu_data->csu_attr_group);
> + if (ret) {
> + devm_kfree(&pdev->dev, attrs);
> + devm_kfree(&pdev->dev, csu_data->csu_regs);
> + devm_kfree(&pdev->dev, csu_data);
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_csu_discover_registers);
> diff --git a/drivers/firmware/xilinx/zynqmp-csu-reg.h b/drivers/firmware/xilinx/zynqmp-csu-reg.h
> new file mode 100644
> index 000000000000..b12415db3496
> --- /dev/null
> +++ b/drivers/firmware/xilinx/zynqmp-csu-reg.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Xilinx Zynq MPSoC CSU Register Access
> + *
> + * Copyright (C) 2026 Advanced Micro Devices, Inc.
> + *
> + * Michal Simek <michal.simek@amd.com>
> + * Ronak Jain <ronak.jain@amd.com>
> + */
> +
> +#ifndef __ZYNQMP_CSU_REG_H__
> +#define __ZYNQMP_CSU_REG_H__
> +
> +#include <linux/platform_device.h>
> +
> +int zynqmp_csu_discover_registers(struct platform_device *pdev);
> +
> +#endif /* __ZYNQMP_CSU_REG_H__ */
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index fbe8510f4927..b549d07f7497 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -27,6 +27,7 @@
>
> #include <linux/firmware/xlnx-zynqmp.h>
> #include <linux/firmware/xlnx-event-manager.h>
> +#include "zynqmp-csu-reg.h"
> #include "zynqmp-debug.h"
>
> /* Max HashMap Order for PM API feature check (1<<7 = 128) */
> @@ -2120,6 +2121,11 @@ static int zynqmp_firmware_probe(struct platform_device *pdev)
> dev_err_probe(&pdev->dev, PTR_ERR(em_dev), "EM register fail with error\n");
> }
>
> + /* Discover CSU registers dynamically */
> + ret = zynqmp_csu_discover_registers(pdev);
> + if (ret)
> + dev_warn(&pdev->dev, "CSU register discovery failed: %d\n", ret);
> +
> return of_platform_populate(dev->of_node, NULL, NULL, dev);
> }
>
> diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
> index d70dcd462b44..a4b293eb96ce 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -3,7 +3,7 @@
> * Xilinx Zynq MPSoC Firmware layer
> *
> * Copyright (C) 2014-2021 Xilinx
> - * Copyright (C) 2022 - 2025 Advanced Micro Devices, Inc.
> + * Copyright (C) 2022 - 2026 Advanced Micro Devices, Inc.
> *
> * Michal Simek <michal.simek@amd.com>
> * Davorin Mista <davorin.mista@aggios.com>
> @@ -262,6 +262,8 @@ enum pm_query_id {
> PM_QID_CLOCK_GET_NUM_CLOCKS = 12,
> PM_QID_CLOCK_GET_MAX_DIVISOR = 13,
> PM_QID_PINCTRL_GET_ATTRIBUTES = 15,
> + PM_QID_GET_NODE_NAME = 16,
> + PM_QID_GET_NODE_COUNT = 17,
> };
>
> enum rpu_oper_mode {
Thanks,
Michal
^ permalink raw reply
* Re: (subset) [PATCH v3 2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
From: Lee Jones @ 2026-04-23 11:45 UTC (permalink / raw)
To: lee, praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy,
Akashdeep Kaur
Cc: vishalm, sebin.francis, d-gole, k-willis
In-Reply-To: <20260401112257.1248437-3-a-kaur@ti.com>
On Wed, 01 Apr 2026 16:52:57 +0530, Akashdeep Kaur wrote:
> Currently, the TPS65219 driver unconditionally registers a poweroff
> handler. This causes issues on systems where a different component
> (such as TF-A firmware) should handle system poweroff instead.
>
> Make the poweroff handler registration conditional based on the
> "system-power-controller" device tree property. This follows the
> standard kernel pattern where only the designated power controller
> registers for system poweroff operations.
>
> [...]
Applied, thanks!
[2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
commit: 0af600b8e3bced37afa267ac9a7f68e15764f502
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Thomas Gleixner @ 2026-04-23 11:48 UTC (permalink / raw)
To: Mathias Stearn, Peter Zijlstra
Cc: Mathieu Desnoyers, Catalin Marinas, Will Deacon, Boqun Feng,
Paul E. McKenney, Chris Kennelly, Dmitry Vyukov, regressions,
linux-kernel, linux-arm-kernel, Ingo Molnar, Mark Rutland,
Jinjie Ruan, Blake Oler
In-Reply-To: <CAHnCjA2fa+dP1+yCYNQrTXQaW-JdtfMj7wMikwMeeCRg-3NhiA@mail.gmail.com>
On Thu, Apr 23 2026 at 11:24, Mathias Stearn wrote:
> On Wed, Apr 22, 2026 at 3:13 PM Peter Zijlstra <peterz@infradead.org> wrote:
> To make this more concrete, I am proposing adding
>
> unsafe_put_user((u32)task_cpu(t), &t->rseq.usrptr->cpu_id_start, efault);
>
> after each place where you currently do
>
> unsafe_put_user(0ULL, &t->rseq.usrptr->rseq_cs, efault);
>
> in rseq_update_user_cs. Is that something that you would expect to cause a
> performance issue?
That would work and not bring the performance issues back, but:
1) Did you validate that adding the reset into rseq_update_user_cs() is
actually sufficient?
If adding it to rseq_update_user_cs() is not sufficient, then we
have a really serious problem. Because we'd need to go back and do
it unconditionally, which then makes the 15% performance
regression, which happened when glibc enabled rseq, come back
instantaneously. And in that case the damage for tcmalloc() is the
lesser of two evils.
2) The tcmalloc abuse breaks the documented and guaranteed user space
ABI and therefore it makes it impossible for any other library in
an application which uses tcmalloc to rely on the documented and
guaranteed rseq::cpu_id_start/rseq::cpu_id semantics.
Which means, that tcmalloc is holding everybody else hostage.
That's just not acceptable. Not even under the no regression rule.
3) The fact that tcmalloc prevents a user from enabling rseq debugging
is equally unacceptable as it does not allow me to validate my own
rseq magic code in my mongodb client because enabling it will make
the DB I want to test against go away.
Again tcmalloc holds everybody else hostage for no reason at all.
The most amazing part is that tcmalloc uses this to spare two
instruction cycles, but nobody noticed in 8 years how much performance
the unconditional rseq nonsense in the kernel left on the table.
Thanks,
tglx
^ permalink raw reply
* [GIT PULL] soc: late changes for 7.1
From: Arnd Bergmann @ 2026-04-23 12:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: soc, linux-kernel, linux-arm-kernel
The following changes since commit 8242c709d4ba858c483ef7ef3cc2dc1280f5383c:
Merge tag 'soc-arm-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc (2026-04-16 20:45:14 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc-late-7.1
for you to fetch changes up to dd5dc1917473f398949b95f6b77c60d4d8eb1d97:
Merge tag 'amlogic-fixes-v7.1-rc' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into soc/late2 (2026-04-23 10:02:27 +0200)
----------------------------------------------------------------
soc: late changes for 7.1
These are the contents that arrived during the easter vacation and didn't
make it into the last 7.0 bugfixes or the first set of branches for the
merge window. Aside from a reset controller bugfix and an update to the
MAINTAINERS entry, this is all devicetree changes.
The Marvell devicetree updates contain the usual minor updates and bugfixes,
along with a two larger but trivial patches to drop unused dtsi files,
the single broadcom fix addresses a build time warning introduced during
the merge window.
The freescale, amlogic, and apple changes missed the last fixes branch
for 7.0.
----------------------------------------------------------------
Anand Moon (1):
arm64: dts: amlogic: meson-axg: Add missing cache information to cpu0
Arnd Bergmann (5):
Merge branch 'arm/fixes' into soc/late2
Merge tag 'mvebu-dt64-7.1-1' of https://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into soc/late2
ARM: dts: bcm4709: fix bus range assignment
Merge tag 'apple-soc-fixes-7.0' of https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux into soc/late2
Merge tag 'amlogic-fixes-v7.1-rc' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into soc/late2
Axel Flordal (1):
arm64: dts: apple: Fix spelling error
Elad Nachman (3):
arm64: dts: a7k: use phy handle
dt-bindings: arm64: add Marvell 7k COMe boards
dt-bindings: arm64: add Marvell 7k COMe boards
Gabor Juhos (6):
arm64: dts: marvell: armada-3720: drop 'marvell,xenon-emmc' properties
arm64: dts: marvell: armada-37xx: align 'phy-names' of EHCI node with DT schema
arm64: dts: marvell: armada-37xx: drop redundant status property
arm64: dts: marvell: armada-37xx: drop 'marvell,usb-misc-reg' from USB host nodes
arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names
arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node
Geert Uytterhoeven (1):
arm64: dts: amlogic: s6: Drop CPU masks from GICv3 PPI interrupts
Jun Yan (1):
arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
Krzysztof Kozlowski (5):
Merge tag 'imx-fixes-7.0-2nd' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into arm/fixes
Merge tag 'reset-fixes-for-v7.0-3' of https://git.pengutronix.de/git/pza/linux into arm/fixes
Merge tag 'mvebu-fixes-7.0-1' of https://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/fixes
Documentation/process: maintainer-soc: Trim from trivial ask-DT
Documentation/process: maintainer-soc: Document purpose of defconfigs
Nick Xie (2):
arm64: dts: amlogic: t7: khadas-vim4: fix memory layout for 8GB RAM
arm64: dts: amlogic: t7: khadas-vim4: fix board model name
Peng Fan (14):
arm64: dts: imx8mp-debix-model-a: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-debix-som-a: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-navqp: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-icore-mx8mp: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-edm-g: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-aristainetos3a-som-v1: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-nitrogen-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-sr-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-ultra-mach-sbc: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-dhcom-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-data-modul-edm-sbc: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT
Rob Herring (Arm) (1):
arm/arm64: dts: marvell: Drop unused .dtsi
Robert Marko (1):
arm64: dts: marvell: uDPU: add ethernet aliases
Ronald Claveau (2):
reset: amlogic: t7: Fix null reset ops
arm64: dts: amlogic: Fix GIC register ranges for Amlogic T7
Sasha Finkelstein (2):
mailmap: Update Sasha Finkelstein's email address
dt-bindings: Update Sasha Finkelstein's email address
.mailmap | 1 +
.../bindings/arm/marvell/armada-7k-8k.yaml | 11 ++
.../display/apple,h7-display-pipe-mipi.yaml | 2 +-
.../bindings/display/apple,h7-display-pipe.yaml | 2 +-
.../bindings/display/panel/apple,summit.yaml | 2 +-
.../devicetree/bindings/gpu/apple,agx.yaml | 2 +-
.../input/touchscreen/apple,z2-multitouch.yaml | 2 +-
.../bindings/nvmem/apple,spmi-nvmem.yaml | 2 +-
.../devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 2 +-
.../devicetree/bindings/spmi/apple,spmi.yaml | 2 +-
Documentation/process/maintainer-soc.rst | 12 +-
MAINTAINERS | 2 +-
.../boot/dts/broadcom/bcm4709-netgear-r8000.dts | 1 -
arch/arm/boot/dts/marvell/armada-380.dtsi | 148 ---------------------
arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi | 10 +-
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 6 +-
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 4 +-
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 6 +
.../boot/dts/amlogic/meson-gxl-s905d-p230.dts | 3 +-
arch/arm64/boot/dts/apple/spi1-nvram.dtsi | 2 +-
.../arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi | 4 +-
.../arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi | 2 +-
.../arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi | 2 +-
.../freescale/imx8mp-aristainetos3a-som-v1.dtsi | 2 +-
.../dts/freescale/imx8mp-data-modul-edm-sbc.dts | 2 +-
.../boot/dts/freescale/imx8mp-debix-model-a.dts | 2 +-
.../dts/freescale/imx8mp-debix-som-a-bmb-08.dts | 2 +-
.../boot/dts/freescale/imx8mp-debix-som-a.dtsi | 2 +-
.../arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp-edm-g.dtsi | 2 +-
.../boot/dts/freescale/imx8mp-icore-mx8mp.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp-navqp.dts | 2 +-
.../boot/dts/freescale/imx8mp-nitrogen-som.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi | 4 +-
.../boot/dts/freescale/imx8mp-ultra-mach-sbc.dts | 4 +-
.../boot/dts/marvell/armada-3720-atlas-v5.dts | 1 -
.../boot/dts/marvell/armada-3720-espressobin.dtsi | 1 -
arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi | 7 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 9 +-
.../boot/dts/marvell/armada-7020-comexpress.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-8020.dtsi | 20 ---
.../boot/dts/marvell/cn9130-db-comexpress.dtsi | 96 -------------
drivers/reset/amlogic/reset-meson.c | 1 +
43 files changed, 81 insertions(+), 314 deletions(-)
delete mode 100644 arch/arm/boot/dts/marvell/armada-380.dtsi
delete mode 100644 arch/arm64/boot/dts/marvell/armada-8020.dtsi
delete mode 100644 arch/arm64/boot/dts/marvell/cn9130-db-comexpress.dtsi
diff --git a/.mailmap b/.mailmap
index 7d6fb567ba5e..74cc837befef 100644
--- a/.mailmap
+++ b/.mailmap
@@ -741,6 +741,7 @@ Sarangdhar Joshi <spjoshi@codeaurora.org>
Saravana Kannan <saravanak@kernel.org> <skannan@codeaurora.org>
Saravana Kannan <saravanak@kernel.org> <saravanak@google.com>
Sascha Hauer <s.hauer@pengutronix.de>
+Sasha Finkelstein <k@chaosmail.tech> <fnkl.kernel@gmail.com>
Sahitya Tummala <quic_stummala@quicinc.com> <stummala@codeaurora.org>
Sathishkumar Muruganandam <quic_murugana@quicinc.com> <murugana@codeaurora.org>
Satya Priya <quic_skakitap@quicinc.com> <quic_c_skakit@quicinc.com> <skakit@codeaurora.org>
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
index 4bc7454a5d3a..7e77310da626 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
@@ -21,6 +21,17 @@ properties:
- const: marvell,armada-ap806-dual
- const: marvell,armada-ap806
+ - description:
+ Falcon (DB-98CX85x0) Development board COM Express Carrier plus
+ Armada 7020 SoC COM Express CPU module
+ items:
+ - const: marvell,armada7020-falcon-carrier
+ - const: marvell,db-falcon-carrier
+ - const: marvell,armada7020-cpu-module
+ - const: marvell,armada7020
+ - const: marvell,armada-ap806-dual
+ - const: marvell,armada-ap806
+
- description: Armada 7040 SoC
items:
- enum:
diff --git a/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml b/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml
index 5e6da66499a5..d7c822df8a94 100644
--- a/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml
+++ b/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple pre-DCP display controller MIPI interface
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description:
The MIPI controller part of the pre-DCP Apple display controller
diff --git a/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml b/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml
index 102fb1804c0c..571fa32db2cf 100644
--- a/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml
+++ b/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple pre-DCP display controller
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description:
A secondary display controller used to drive the "touchbar" on
diff --git a/Documentation/devicetree/bindings/display/panel/apple,summit.yaml b/Documentation/devicetree/bindings/display/panel/apple,summit.yaml
index f081755325e9..1c1ba59467f3 100644
--- a/Documentation/devicetree/bindings/display/panel/apple,summit.yaml
+++ b/Documentation/devicetree/bindings/display/panel/apple,summit.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple "Summit" display panel
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description:
An OLED panel used as a touchbar on certain Apple laptops.
diff --git a/Documentation/devicetree/bindings/gpu/apple,agx.yaml b/Documentation/devicetree/bindings/gpu/apple,agx.yaml
index 05af942ad174..59989d8bd1cb 100644
--- a/Documentation/devicetree/bindings/gpu/apple,agx.yaml
+++ b/Documentation/devicetree/bindings/gpu/apple,agx.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple SoC GPU
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml b/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml
index 402ca6bffd34..44158e89e818 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple touchscreens attached using the Z2 protocol
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description: A series of touschscreen controllers used in Apple products
diff --git a/Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml b/Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml
index 80b5a6cdcec9..4ca75ed07a54 100644
--- a/Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml
@@ -9,7 +9,7 @@ title: Apple SPMI NVMEM
description: Exports a series of SPMI registers as NVMEM cells
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
allOf:
- $ref: nvmem.yaml#
diff --git a/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml b/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
index 04519b0c581d..d8f4f9ffe884 100644
--- a/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
@@ -8,7 +8,7 @@ title: Apple FPWM controller
maintainers:
- asahi@lists.linux.dev
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description: PWM controller used for keyboard backlight on ARM Macs
diff --git a/Documentation/devicetree/bindings/spmi/apple,spmi.yaml b/Documentation/devicetree/bindings/spmi/apple,spmi.yaml
index ba524f1eb704..3e5b14bc8c31 100644
--- a/Documentation/devicetree/bindings/spmi/apple,spmi.yaml
+++ b/Documentation/devicetree/bindings/spmi/apple,spmi.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple SPMI controller
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description: A SPMI controller present on most Apple SoCs
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
index 7d6bad989ad8..a3a90a7d4c68 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -169,8 +169,6 @@ more information on the validation of devicetrees.
For new platforms, or additions to existing ones, ``make dtbs_check`` should not
add any new warnings. For RISC-V and Samsung SoC, ``make dtbs_check W=1`` is
required to not add any new warnings.
-If in any doubt about a devicetree change, reach out to the devicetree
-maintainers.
Branches and Pull Requests
~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -209,3 +207,13 @@ The subject line of a pull request should begin with "[GIT PULL]" and made using
a signed tag, rather than a branch. This tag should contain a short description
summarising the changes in the pull request. For more detail on sending pull
requests, please see Documentation/maintainer/pull-requests.rst.
+
+Defconfigs purpose
+~~~~~~~~~~~~~~~~~~
+
+Defconfigs are primarily used by the kernel developers, because distros have
+their own configs. A change adding new CONFIG options to a defconfig should
+explain why the kernel developers in general would want such option, e.g. by
+providing a name of an upstream-supported machine/board using that new option.
+This implies that enabling options in defconfig for non-upstream machines shall
+not be accepted.
diff --git a/MAINTAINERS b/MAINTAINERS
index d41dc26280b1..71f6968fa695 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8691,7 +8691,7 @@ F: include/linux/host1x.h
F: include/uapi/drm/tegra_drm.h
DRM DRIVERS FOR PRE-DCP APPLE DISPLAY OUTPUT
-M: Sasha Finkelstein <fnkl.kernel@gmail.com>
+M: Sasha Finkelstein <k@chaosmail.tech>
R: Janne Grunau <j@jannau.net>
L: dri-devel@lists.freedesktop.org
L: asahi@lists.linux.dev
diff --git a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
index d170c71cbd76..e85693fba16a 100644
--- a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
+++ b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
@@ -139,7 +139,6 @@ &pcie_bridge1 {
pcie@0,0 {
device_type = "pci";
reg = <0x0000 0 0 0 0>;
- bus-range = <0x01 0xff>;
#address-cells = <3>;
#size-cells = <2>;
diff --git a/arch/arm/boot/dts/marvell/armada-380.dtsi b/arch/arm/boot/dts/marvell/armada-380.dtsi
deleted file mode 100644
index e94f22b0e9b5..000000000000
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi
index 8ef631939033..ab3acef2b147 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi
@@ -53,10 +53,10 @@ pwrc: power-controller {
timer {
compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
};
psci {
@@ -84,7 +84,7 @@ gic: interrupt-controller@ff200000 {
interrupt-controller;
reg = <0x0 0xff200000 0 0x10000>,
<0x0 0xff240000 0 0x80000>;
- interrupts = <GIC_PPI 9 0xf04>;
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
apb: bus@fe000000 {
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index fffdab96b12e..f4c953034be3 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -8,7 +8,7 @@
#include "amlogic-t7.dtsi"
/ {
- model = "Khadas vim4";
+ model = "Khadas VIM4";
compatible = "khadas,vim4", "amlogic,a311d2", "amlogic,t7";
aliases {
@@ -17,7 +17,9 @@ aliases {
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x2 0x0>; /* 8 GB */
+ reg = <0x0 0x0 0x0 0xE0000000
+ 0x1 0x0 0x0 0xE0000000
+ 0x2 0x0 0x0 0x40000000>; /* 8 GB */
};
reserved-memory {
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 6510068bcff9..d523cbc0ed22 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -213,7 +213,9 @@ gic: interrupt-controller@fff01000 {
#address-cells = <0>;
interrupt-controller;
reg = <0x0 0xfff01000 0 0x1000>,
- <0x0 0xfff02000 0 0x0100>;
+ <0x0 0xfff02000 0 0x2000>,
+ <0x0 0xfff04000 0 0x2000>,
+ <0x0 0xfff06000 0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index cc72491eaf6f..f1f53fd98ae2 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -72,6 +72,12 @@ cpu0: cpu@0 {
compatible = "arm,cortex-a53";
reg = <0x0 0x0>;
enable-method = "psci";
+ d-cache-line-size = <32>;
+ d-cache-size = <0x8000>;
+ d-cache-sets = <32>;
+ i-cache-line-size = <32>;
+ i-cache-size = <0x8000>;
+ i-cache-sets = <32>;
next-level-cache = <&l2>;
clocks = <&scpi_dvfs 0>;
dynamic-power-coefficient = <140>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index 7dffeb5931c9..701de57ff0f3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -84,7 +84,8 @@ external_phy: ethernet-phy@0 {
reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;
interrupt-parent = <&gpio_intc>;
- interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+ /* MAC_INTR on GPIOZ_15 */
+ interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
eee-broken-1000t;
};
};
diff --git a/arch/arm64/boot/dts/apple/spi1-nvram.dtsi b/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
index 9740fbf200f0..d2720b307774 100644
--- a/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
+++ b/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
@@ -2,7 +2,7 @@
//
// Devicetree include for common spi-nor nvram flash.
//
-// Apple uses a consistent configiguration for the nvram on all known M1* and
+// Apple uses a consistent configuration for the nvram on all known M1* and
// M2* devices.
//
// Copyright The Asahi Linux Contributors
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
index 67d22d3768aa..507d1824d99d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
@@ -60,7 +60,7 @@ pmic@25 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pmic>;
interrupt-parent = <&gpio1>;
- interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
regulators {
buck1: BUCK1 {
@@ -194,7 +194,7 @@ MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3
pinctrl_pmic: emtop-pmic-grp {
fsl,pins = <
- MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
+ MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x141
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
index 29b298af0d73..1b5ba3c47164 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
@@ -292,7 +292,7 @@ pinctrl_i2c1_gpio: i2c1gpiogrp {
};
pinctrl_pmic: pmicgrp {
- fsl,pins = <MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x94>;
+ fsl,pins = <MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x1d4>;
};
pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
index 31a3ca137e63..48a687926aa1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
@@ -283,7 +283,7 @@ pinctrl_i2c1_gpio: i2c1gpiogrp {
};
pinctrl_pmic: pmicgrp {
- fsl,pins = <MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x84>;
+ fsl,pins = <MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x1c4>;
};
pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-aristainetos3a-som-v1.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-aristainetos3a-som-v1.dtsi
index f654d866e58c..e7666e54310b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-aristainetos3a-som-v1.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-aristainetos3a-som-v1.dtsi
@@ -903,7 +903,7 @@ MX8MP_IOMUXC_SAI1_MCLK__GPIO4_IO20 0x41
pinctrl_pmic: aristainetos3-pmic-grp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts b/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts
index 7e46537a22a0..cb28cf1cdd23 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts
@@ -1001,7 +1001,7 @@ MX8MP_IOMUXC_SAI3_RXFS__AUDIOMIX_PDM_BIT_STREAM00 0x0
pinctrl_pmic: pmic-grp {
fsl,pins = <
/* PMIC_nINT */
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x40000090
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
index 9422beee30b2..201cf7f5eb0e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
@@ -440,7 +440,7 @@ MX8MP_IOMUXC_SAI5_RXC__I2C6_SDA 0x400001c3
pinctrl_pmic: pmicirqgrp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
index 04619a722906..1471ff361b54 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
@@ -499,7 +499,7 @@ MX8MP_IOMUXC_SAI1_RXD1__GPIO4_IO03 0x140
pinctrl_pmic: pmicgrp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a.dtsi
index 91094c227744..b31e8fe95ca7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a.dtsi
@@ -241,7 +241,7 @@ MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c3
pinctrl_pmic: pmicgrp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
index f8303b7e2bd2..0a6a60670f76 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
@@ -989,7 +989,7 @@ MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20 0x22
pinctrl_pmic: dhcom-pmic-grp {
fsl,pins = <
/* PMIC_nINT */
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x40000090
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-edm-g.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-edm-g.dtsi
index 3f1e0837f349..91b87a7248dd 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-edm-g.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-edm-g.dtsi
@@ -563,7 +563,7 @@ MX8MP_IOMUXC_GPIO1_IO01__GPIO1_IO01 0x41 /* PCIE RST */
pinctrl_pmic: pmicirqgrp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-icore-mx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-icore-mx8mp.dtsi
index a6319824ea2e..69558ffefa9a 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-icore-mx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-icore-mx8mp.dtsi
@@ -132,7 +132,7 @@ MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001c3
pinctrl_pmic: pmicgrp {
fsl,pins = <
- MX8MP_IOMUXC_NAND_CE0_B__GPIO3_IO01 0x41
+ MX8MP_IOMUXC_NAND_CE0_B__GPIO3_IO01 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
index 4a4f7c1adc23..9dedb9f11145 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
@@ -356,7 +356,7 @@ MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c3
pinctrl_pmic: pmicgrp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-nitrogen-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-nitrogen-som.dtsi
index f658309612ef..8465b36d440a 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-nitrogen-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-nitrogen-som.dtsi
@@ -296,7 +296,7 @@ MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c3
pinctrl_pmic: pmicirqgrp {
fsl,pins = <
- MX8MP_IOMUXC_NAND_ALE__GPIO3_IO00 0x41
+ MX8MP_IOMUXC_NAND_ALE__GPIO3_IO00 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
index 3cdb0bc0ab72..c3f7daa773ea 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
@@ -174,7 +174,7 @@ pmic: pmic@25 {
pinctrl-0 = <&pmic_pins>;
pinctrl-names = "default";
interrupt-parent = <&gpio1>;
- interrupts = <3 GPIO_ACTIVE_LOW>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
nxp,i2c-lt-enable;
regulators {
@@ -417,7 +417,7 @@ MX8MP_IOMUXC_SAI1_RXD1__GPIO4_IO03 0x160
pmic_pins: pinctrl-pmic-grp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-ultra-mach-sbc.dts b/arch/arm64/boot/dts/freescale/imx8mp-ultra-mach-sbc.dts
index 9ecec1a41878..3e6f9c88cc20 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-ultra-mach-sbc.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-ultra-mach-sbc.dts
@@ -275,7 +275,7 @@ pmic@25 {
reg = <0x25>;
pinctrl-0 = <&pinctrl_pmic>;
interrupt-parent = <&gpio1>;
- interrupts = <3 GPIO_ACTIVE_LOW>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
/*
* i.MX 8M Plus Data Sheet for Consumer Products
@@ -739,7 +739,7 @@ MX8MP_IOMUXC_GPIO1_IO07__GPIO1_IO07 0x40 /* NFC_INT */
pinctrl_pmic: pmic-grp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x40 /* #PMIC_INT */
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0 /* #PMIC_INT */
>;
};
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-atlas-v5.dts b/arch/arm64/boot/dts/marvell/armada-3720-atlas-v5.dts
index 070d10a705bb..a313d5687789 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-atlas-v5.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-atlas-v5.dts
@@ -82,7 +82,6 @@ &sdhci0 {
mmc-ddr-1_8v;
mmc-hs400-1_8v;
sd-uhs-sdr104;
- marvell,xenon-emmc;
marvell,xenon-tun-count = <9>;
marvell,pad-type = "fixed-1-8v";
vqmmc-supply = <&vsdc_reg>;
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
index fed2dcecb323..37e16fb3a383 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
@@ -78,7 +78,6 @@ &sdhci0 {
bus-width = <8>;
mmc-ddr-1_8v;
mmc-hs400-1_8v;
- marvell,xenon-emmc;
marvell,xenon-tun-count = <9>;
marvell,pad-type = "fixed-1-8v";
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi b/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi
index 242820845707..12deacb741cc 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi
@@ -15,6 +15,11 @@
#include "armada-372x.dtsi"
/ {
+ aliases {
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -156,7 +161,7 @@ ð1 {
&usb3 {
status = "okay";
phys = <&usb2_utmi_otg_phy>;
- phy-names = "usb2-utmi-otg-phy";
+ phy-names = "usb2-phy";
};
&uart0 {
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 87f9367aec12..360fc24fdde2 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -369,11 +369,10 @@ usb3: usb@58000 {
compatible = "marvell,armada3700-xhci",
"generic-xhci";
reg = <0x58000 0x4000>;
- marvell,usb-misc-reg = <&usb32_syscon>;
interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&sb_periph_clk 12>;
- phys = <&comphy0 0>, <&usb2_utmi_otg_phy>;
- phy-names = "usb3-phy", "usb2-utmi-otg-phy";
+ phys = <&usb2_utmi_otg_phy>, <&comphy0 0>;
+ phy-names = "usb2-phy", "usb3-phy";
status = "disabled";
};
@@ -393,10 +392,9 @@ usb32_syscon: system-controller@5d800 {
usb2: usb@5e000 {
compatible = "marvell,armada-3700-ehci";
reg = <0x5e000 0x1000>;
- marvell,usb-misc-reg = <&usb2_syscon>;
interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usb2_utmi_host_phy>;
- phy-names = "usb2-utmi-host-phy";
+ phy-names = "usb";
status = "disabled";
};
@@ -534,7 +532,6 @@ firmware {
armada-3700-rwtm {
compatible = "marvell,armada-3700-rwtm-firmware";
mboxes = <&rwtm 0>;
- status = "okay";
};
};
};
diff --git a/arch/arm64/boot/dts/marvell/armada-7020-comexpress.dtsi b/arch/arm64/boot/dts/marvell/armada-7020-comexpress.dtsi
index 2b5ec4a451e3..0cfcf5f6bde1 100644
--- a/arch/arm64/boot/dts/marvell/armada-7020-comexpress.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-7020-comexpress.dtsi
@@ -70,7 +70,7 @@ &cp0_eth0 {
&cp0_eth1 {
status = "okay";
- phy = <&phy0>;
+ phy-handle = <&phy0>;
phy-mode = "rgmii-id";
};
diff --git a/arch/arm64/boot/dts/marvell/armada-8020.dtsi b/arch/arm64/boot/dts/marvell/armada-8020.dtsi
deleted file mode 100644
index b6fc18876093..000000000000
diff --git a/arch/arm64/boot/dts/marvell/cn9130-db-comexpress.dtsi b/arch/arm64/boot/dts/marvell/cn9130-db-comexpress.dtsi
deleted file mode 100644
index 028496ebc473..000000000000
diff --git a/drivers/reset/amlogic/reset-meson.c b/drivers/reset/amlogic/reset-meson.c
index 84610365a823..c303e8590dd6 100644
--- a/drivers/reset/amlogic/reset-meson.c
+++ b/drivers/reset/amlogic/reset-meson.c
@@ -42,6 +42,7 @@ static const struct meson_reset_param meson_s4_param = {
};
static const struct meson_reset_param t7_param = {
+ .reset_ops = &meson_reset_ops,
.reset_num = 224,
.reset_offset = 0x0,
.level_offset = 0x40,
^ permalink raw reply related
* Re: [PATCH v2 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-23 10:00 UTC (permalink / raw)
To: Krzysztof Kozlowski, Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <161eb29f-2d07-455a-bd74-4f22061b5dfb@kernel.org>
On 4/23/26 11:26 AM, Krzysztof Kozlowski wrote:
> On 23/04/2026 01:33, Marek Vasut wrote:
>> On 4/21/26 10:02 AM, Krzysztof Kozlowski wrote:
>>> On Thu, Apr 16, 2026 at 01:31:40AM +0200, Marek Vasut wrote:
>>>> Add ZT trace bus and ZTR trace clock on the R-Mobile A1.
>>>>
>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>>>> ---
>>>> Cc: Conor Dooley <conor+dt@kernel.org>
>>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>>> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
>>>> Cc: Magnus Damm <magnus.damm@gmail.com>
>>>> Cc: Michael Turquette <mturquette@baylibre.com>
>>>> Cc: Rob Herring <robh@kernel.org>
>>>> Cc: Stephen Boyd <sboyd@kernel.org>
>>>> Cc: devicetree@vger.kernel.org
>>>> Cc: linux-clk@vger.kernel.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Cc: linux-renesas-soc@vger.kernel.org
>>>> ---
>>>> V2: Add ztr/zt clock at the end of the list to match bindings
>>>> ---
>>>> arch/arm/boot/dts/renesas/r8a7740.dtsi | 2 +-
>>>
>>>> include/dt-bindings/clock/r8a7740-clock.h | 2 ++
>>>
>>> This goes to the binding patch.
>>>
>>> Didn't you have also a checkpatch warning?
>> I only got this warning, but the docs 1/4 and includes 3/4 are a
>> separate patch in this series:
>>
>> "
>> WARNING: DT binding docs and includes should be a separate patch. See:
>> Documentation/devicetree/bindings/submitting-patches.rst
>
> So you did not implement it... Include goes with the binding. Always.
> Look at other commits.
The warning says the exact opposite thing , does it not ?
Maybe the warning text needs to be updated ?
^ permalink raw reply
* Re: [PATCH] arm64: smp: Limit nr_cpu_ids under nosmp
From: zhangpengjie (A) @ 2026-04-23 12:05 UTC (permalink / raw)
To: Catalin Marinas
Cc: will, maz, timothy.hayes, lpieralisi, mrigendra.chaubey, arnd,
linux-arm-kernel, linux-kernel, zhanjie9, zhenglifeng1, lihuisong,
yubowen8, linhongye, linuxarm, wangzhi12
In-Reply-To: <aekCUnZAE8bSfNfO@arm.com>
Hi Catalin,
On 4/23/2026 1:16 AM, Catalin Marinas wrote:
> On Wed, Apr 22, 2026 at 05:58:31PM +0800, Pengjie Zhang wrote:
>> Under nosmp (maxcpus=0), arm64 never brings up secondary CPUs.
>>
>> However, arm64 still enumerates firmware-described CPUs during SMP
>> initialization, so secondary CPUs can remain visible to
>> for_each_possible_cpu() users even though they never reach the
>> bringup path in this configuration.
>>
>> This is not just a cosmetic mask mismatch: code iterating over
>> possible CPUs may observe secondary CPU per-CPU state that is never
>> fully initialized under nosmp.
>>
>> Limit nr_cpu_ids to 1 in arch_disable_smp_support() so that
>> secondary CPUs are not set up on arm64 when nosmp/maxcpus=0 is in
>> effect.
>>
>> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>> ---
>> arch/arm64/kernel/smp.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index 1aa324104afb..cc34c68871e9 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -435,6 +435,15 @@ static void __init hyp_mode_check(void)
>> }
>> }
>>
>> +void __init arch_disable_smp_support(void)
>> +{
>> + /*
>> + * Under nosmp/maxcpus=0, only the boot CPU can ever be brought up.
>> + * Limit nr_cpu_ids so that secondary CPUs are never set up.
>> + */
>> + set_nr_cpu_ids(1);
>> +}
> I don't think that's the right fix. We don't have anything like the x86
> ioapic to disable in this function, so no need to implement it. If
> nr_cpu_ids must be 1 with nosmp/maxcpus=0, I'd rather do this in the
> generic code. It need some alignment with other architectures if we are
> to do this early. IOW, is nosmp equivalent to nr_cpus=1?
>
> In the meantime, for arm64, we can do something like below and let the
> generic code set nr_cpu_ids() via start_kernel() -> setup_nr_cpu_ids().
Thanks for the review. I completely agree with your assessment.
My initial thought was to consolidate the nosmp logic in one place,
but you are right—using `arch_disable_smp_support()` here is indeed
an abuse of the callback, as arm64 doesn't have SMP-specific hardware
to tear down like the x86 IOAPIC.
My main concern was specifically that under nosmp/maxcpus=0, secondary
CPUs can still remain visible to `for_each_possible_cpu()` users on
arm64, even though they will never reach the bringup path.
Regarding your question on whether `nosmp` is equivalent to `nr_cpus=1`:
practically, they both result in a uniprocessor system, but historically
they take different paths (`setup_max_cpus=0` vs early `nr_cpu_ids=1`).
Unifying this globally in generic code would indeed require a broader
cross-arch discussion, so your arm64-specific mitigation is the best
way forward right now.
Your proposed alternative in `smp_init_cpus()` is elegant and solves
the mask mismatch perfectly.
I will spin up a v2 incorporating your snippet and will add a
`Suggested-by` tag for you.
Thanks,
Pengjie
> -------------8<-------------------
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 1aa324104afb..7364481cc03a 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -754,6 +754,13 @@ void __init smp_init_cpus(void)
> return;
> }
>
> + /*
> + * For the nosmp/maxcpus=0 case, do not mark the secondary CPUs
> + * possible.
> + */
> + if (!setup_max_cpus)
> + return;
> +
> /*
> * We need to set the cpu_logical_map entries before enabling
> * the cpus so that cpu processor description entries (DT cpu nodes
>
>
^ permalink raw reply
* RE: [PATCH 2/4] arm64: dts: imx95: switch usb3 controller to flattened model
From: Peng Fan @ 2026-04-23 12:07 UTC (permalink / raw)
To: Xu Yang, Frank Li
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Jun Li
In-Reply-To: <cfyvip6atz6hh57iga5gvkzrdxeorv4tuxontvzixflqn36h7h@2awtzkxkn45c>
> Subject: Re: [PATCH 2/4] arm64: dts: imx95: switch usb3 controller to
> flattened model
>
> On Tue, Apr 21, 2026 at 11:53:12PM -0400, Frank Li wrote:
> > On Tue, Apr 21, 2026 at 06:55:01PM +0800, Xu Yang wrote:
> > > Switch to use flattened model for USB3 controller. To enable USB
> > > controller with restricted DMA access range to work correctly, add
> a
> > > pseudo simple-bus to constrain the dma address.
> >
> > i.mx95 should fix >4G dma space's problem. Does it impact other no-
> nxp
> > boards?
>
> Yes, i.MX95 has fixed >3G address DMA access problem.
>
> It's another issue. HSIO domain only support 36 bit bus access. If not
> use smmu, no any issue. If use smmu, it will allocate memory space of
> 36 bit < iova < 48bit.
> HSIO can't handle this case.
If using smmu, iova will be in range {36bit, 48bit}? How?
Thanks
Peng
>
> >
> > Need do break compatible judgement such as
> >
> > i.MX95 is new SoC and still is heave development. The break
> compatible
> > is accepable at development early phase.
> >
> > You can rephrase it.
>
> OK.
>
> Thanks,
> Xu Yang
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Alejandro Colomar @ 2026-04-23 12:11 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Jinjie Ruan, linux-man, Thomas Gleixner, Mark Rutland,
Mathias Stearn, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, regressions,
linux-kernel, linux-arm-kernel, Peter Zijlstra, Ingo Molnar,
Blake Oler, Michael Jeanson
In-Reply-To: <CACT4Y+bxnQyHGdVNE1BYTx+Z2-cscLb38HYS9jBM5gPAz8=4bw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4335 bytes --]
Hello Dmitry,
On 2026-04-23T07:53:55+0200, Dmitry Vyukov wrote:
> On Thu, 23 Apr 2026 at 03:48, Jinjie Ruan <ruanjinjie@huawei.com> wrote:
> >
> > On 4/23/2026 3:47 AM, Thomas Gleixner wrote:
> > > On Wed, Apr 22 2026 at 19:11, Mark Rutland wrote:
> > >> On Wed, Apr 22, 2026 at 07:49:30PM +0200, Thomas Gleixner wrote:
> > >> Conceptually we just need to use syscall_enter_from_user_mode() and
> > >> irqentry_enter_from_user_mode() appropriately.
> > >
> > > Right. I figured that out.
> > >
> > >> In practice, I can't use those as-is without introducing the exception
> > >> masking problems I just fixed up for irqentry_enter_from_kernel_mode(),
> > >> so I'll need to do some similar refactoring first.
> > >
> > > See below.
> > >
> > >> I haven't paged everything in yet, so just to cehck, is there anything
> > >> that would behave incorrectly if current->rseq.event.user_irq were set
> > >> for syscall entry? IIUC it means we'll effectively do the slow path, and
> > >> I was wondering if that might be acceptable as a one-line bodge for
> > >> stable.
> > >
> > > It might work, but it's trivial enough to avoid that. See below. That on
> > > top of 6.19.y makes the selftests pass too.
> >
> > This aligns with my thoughts when convert arm64 to generic syscall
> > entry. Currently, the arm64 entry code does not distinguish between IRQ
> > and syscall entries. It fails to call rseq_note_user_irq_entry() for IRQ
> > entries as the generic entry framework does, because arm64 uses
> > enter_from_user_mode() exclusively instead of
> > irqentry_enter_from_user_mode().
> >
> > https://lore.kernel.org/all/20260320102620.1336796-10-ruanjinjie@huawei.com/
> >
> > >
> > > Thanks,
> > >
> > > tglx
> > > ---
> > > arch/arm64/kernel/entry-common.c | 14 ++++++++++----
> > > 1 file changed, 10 insertions(+), 4 deletions(-)
> > >
> > > --- a/arch/arm64/kernel/entry-common.c
> > > +++ b/arch/arm64/kernel/entry-common.c
> > > @@ -58,6 +58,12 @@ static void noinstr exit_to_kernel_mode(
> > > irqentry_exit(regs, state);
> > > }
> > >
> > > +static __always_inline void arm64_enter_from_user_mode_syscall(struct pt_regs *regs)
> > > +{
> > > + enter_from_user_mode(regs);
> > > + mte_disable_tco_entry(current);
> > > +}
> > > +
> > > /*
> > > * Handle IRQ/context state management when entering from user mode.
> > > * Before this function is called it is not safe to call regular kernel code,
> > > @@ -65,8 +71,8 @@ static void noinstr exit_to_kernel_mode(
> > > */
> > > static __always_inline void arm64_enter_from_user_mode(struct pt_regs *regs)
> > > {
> > > - enter_from_user_mode(regs);
> > > - mte_disable_tco_entry(current);
> > > + arm64_enter_from_user_mode_syscall(regs);
> > > + rseq_note_user_irq_entry();
> > > }
> > >
> > > /*
> > > @@ -717,7 +723,7 @@ static void noinstr el0_brk64(struct pt_
> > >
> > > static void noinstr el0_svc(struct pt_regs *regs)
> > > {
> > > - arm64_enter_from_user_mode(regs);
> > > + arm64_enter_from_user_mode_syscall(regs);
> > > cortex_a76_erratum_1463225_svc_handler();
> > > fpsimd_syscall_enter();
> > > local_daif_restore(DAIF_PROCCTX);
> > > @@ -869,7 +875,7 @@ static void noinstr el0_cp15(struct pt_r
> > >
> > > static void noinstr el0_svc_compat(struct pt_regs *regs)
> > > {
> > > - arm64_enter_from_user_mode(regs);
> > > + arm64_enter_from_user_mode_syscall(regs);
> > > cortex_a76_erratum_1463225_svc_handler();
> > > local_daif_restore(DAIF_PROCCTX);
> > > do_el0_svc_compat(regs);
>
>
> +linux-man
>
> This part of the rseq man page needs to be fixed as well I think. The
> kernel no longer reliably provides clearing of rseq_cs on preemption,
> right?
>
> https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2#n241
+Michael Jeanson
That page seems to be maintained separately, as part of the librseq
project.
Have a lovely day!
Alex
>
> "and set to NULL by the kernel when it restarts an assembly
> instruction sequence block,
> as well as when the kernel detects that it is preempting or delivering
> a signal outside of the range targeted by the rseq_cs."
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mathias Stearn @ 2026-04-23 12:11 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Peter Zijlstra, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Ingo Molnar,
Mark Rutland, Jinjie Ruan, Blake Oler
In-Reply-To: <87fr4l28zn.ffs@tglx>
On Thu, Apr 23, 2026 at 1:48 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> That would work and not bring the performance issues back, but:
>
> 1) Did you validate that adding the reset into rseq_update_user_cs() is
> actually sufficient?
Not yet, although I confirmed with the tcmalloc maintainers that they
thought it would be sufficient before suggesting it. I'm currently
building your patch from upthread to test that out. I can try this
after, although I don't think I'll be able to get to that today. I'll
try to get a coworker to test it though.
> Which means, that tcmalloc is holding everybody else hostage.
> That's just not acceptable. Not even under the no regression rule.
Agree. I don't love the situation either. Or that we need to advise
setting the environment variable to tell glibc not to use rseq. But I
also want our users to be able to use existing mongo binaries on new
kernels.
> 3) The fact that tcmalloc prevents a user from enabling rseq debugging
> is equally unacceptable as it does not allow me to validate my own
> rseq magic code in my mongodb client because enabling it will make
> the DB I want to test against go away.
Glad to hear you use mongodb :)
> The most amazing part is that tcmalloc uses this to spare two
> instruction cycles, but nobody noticed in 8 years how much performance
> the unconditional rseq nonsense in the kernel left on the table.
I am looking into a change to our copy of tcmalloc to have it stop
squatting on cpu_id_start, and will run that through our correctness
and performance tests. I can't promise anything (and I certainly can't
speak for what Google may choose to do), but I share your expectation
that it should be possible with minimal impact. It _is_ more than 2
cycles though, since it extends the load dependency chain by one or
two pointer chases and a bit of ALU ops. I'd guesstimate it will
likely cost on the order of 5-10 cycles per call to malloc or free. I
think we can absorb that, but will need to test.
Of course, even if we make that change, it will only apply to _future_
binaries. That's why we prefer a kernel fix so that users will be able
to run our existing releases (or any containers that use them) on a
modern kernel.
^ permalink raw reply
* Re: [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Andrew Lunn @ 2026-04-23 12:14 UTC (permalink / raw)
To: Jakub Raczynski
Cc: netdev, linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
linux-arm-kernel, linux-stm32
In-Reply-To: <aenhiHCZge2dMBFw@AMDC4622.eu.corp.samsungelectronics.net>
> Question is whether this should then remain that way forever?
> And was it really part of some ABI if no one noticed?
Hard to say. I could also be that people did notice, but after it got
released in a kernel, which makes it ABI. It can be very hard to fix
these issues, if you don't catch them in -rcX kernels.
The other patches in this series look O.K, please drop this one and
repost once net-next is open.
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Andrew
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: David Laight @ 2026-04-23 12:24 UTC (permalink / raw)
To: Mathias Stearn
Cc: Thomas Gleixner, Dmitry Vyukov, Jinjie Ruan, linux-man,
Mark Rutland, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, regressions,
linux-kernel, linux-arm-kernel, Peter Zijlstra, Ingo Molnar,
Blake Oler
In-Reply-To: <CAHnCjA0UBNXfjHw=Y34OrAyGRNUtVF+zWd3ugyX6pd_mCk8K9w@mail.gmail.com>
On Thu, 23 Apr 2026 12:51:22 +0200
Mathias Stearn <mathias@mongodb.com> wrote:
> On Thu, Apr 23, 2026 at 12:39 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> > The kernel clears rseq_cs reliably when user space was interrupted and:
> >
> > the task was preempted
> > or
> > the return from interrupt delivers a signal
> >
> > If the task invoked a syscall then there is absolutely no reason to do
> > either of this because syscalls from within a critical section are a
> > bug and catched when enabling rseq debugging.
> >
> > The original code did this along with unconditionally updating CPU/MMCID
> > which resulted in ~15% performance regression on a syscall heavy
> > database benchmark once glibc started to register rseq.
>
> Just to be clear TCMalloc does not need either rseq_cs to be cleared
> or cpu_id_start to be written to on syscalls because it doesn't do
> syscalls from critical sections. It will actually benefit (slightly)
> from not updating cpu_id_start on syscalls.
>
> It is specifically in the cases where an rseq would need to be aborted
> (preemption, signals, migration, and membarrier IPI with the rseq
> flag) that TCMalloc relies on cpu_id_start being written. It does rely
> on that write even when not inside the critical section, because it
> effectively uses that to detect if there were any would-cause-abort
> events in between two critical sections. But since it leaves the
> rseq_cs pointer non-null between critical sections, so you dont need
> to add _any_ overhead for programs that never make use of rseq after
> registration, or add any overhead to syscalls even for those who do.
>
That sounds like one long rseq sequence where the 'restart' path
detects that some of the operations have already been done.
David
^ permalink raw reply
* Re: [PATCH v1 00/27] KVM: s390: Introduce arm64 KVM
From: Steffen Eiden @ 2026-04-23 12:25 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, kvmarm, linux-arm-kernel, linux-kernel, linux-s390,
Andreas Grapentin, Arnd Bergmann, Catalin Marinas,
Christian Borntraeger, Claudio Imbrenda, David Hildenbrand,
Gautam Gala, Hendrik Brueckner, Janosch Frank, Joey Gouly,
Nina Schoetterl-Glausch, Oliver Upton, Paolo Bonzini,
Suzuki K Poulose, Ulrich Weigand, Will Deacon, Zenghui Yu
In-Reply-To: <86o6jd2925.wl-maz@kernel.org>
Hi Marc & Will,
On Mon, Apr 20, 2026 at 11:57:38AM +0100, Marc Zyngier wrote:
> Hi Steffen, s390 folks,
>
> On Thu, 02 Apr 2026 05:20:56 +0100,
> Steffen Eiden <seiden@linux.ibm.com> wrote:
> >
> > By introducing a novel virtualization acceleration for the ARM architecture on
> > s390 architecture, we aim to expand the platform's software ecosystem. This
> > initial patch series lays the groundwork by enabling KVM-accelerated ARM CPU
> > virtualization on s390. To achieve this, a common KVM layer between s390 and
> > arm64 is introduced (see below for more details). Design considerations of
> > arm64 on the s390 Architecture The s390 virtualization architecture is extended
> > with a set of new instructions dedicated to supporting ARM-based virtual
> > machines. The s390 KVM host acts as EL2 (hypervisor) for a EL1/EL0
> > (OS/application) arm64 guest. To achieve this, the new Start-Arm-Execution
> > (SAE) instruction enables accelerated execution of arm64 VMs. Additional new
> > s390 instructions aLre introduced to query available arm64 features, used to
> > populate the arm64 ID register contents, as well as, new s390 instructions to
> > save/restore various arm64 registers in the VM context.
>
> Apologises for the delay in responding to this, things got delayed a
> bit with the Easter break. Since then, Will and I have been discussing
> this series and what it means for the future of the arm64 port.
>
> By way of opening the discussion, we want to be clear that we are
> supportive of the effort. Our comments here should be seen as areas of
> potential improvement and not as rejection of what you are trying to
> achieve.
>
Thank you for your answer. We are happy to hear that you support our
efforts.
> * Code movement:
>
> The patches you have posted demonstrate that it is possible to
> expose a large amount of arm64-specific code and definition to s390,
> and yet still manage to build both architectures without regression.
> However, the result looks rather messy and may adversely affect
> maintainability on the arm64 side.
>
> The moving of files into shared locations is particularly painful,
> and gets in the way of overall maintainability. Not only does it
> break our comfortable habits, it makes the backporting of fixes
> harder. Importantly, these changes come with no benefit on the
> arm64 side.
>
> Would it be possible to try some other means of reaching the
> arm64-specific files *in situ*, either by making use of relative
> paths, or by using symbolic links? Even better, files that are
> generated on arm64 (such as the sysreg definitions) should equally
> be generated for s390, locally to the s390 part of the tree.
>
Yes, we can do that. Our first iteration had an extensive use of symlinks for
headers. We feared that this approach would gain no big support as it was
quite messy and gave a lot of surface for future errors. So we moved to the
current implementation. For the non-KVM headers I could see moving back to the
symlink approach to reduce the backport & maintainability burden for you.
Preferably, those headers are kept clean of any arm implementation specific
things (e.g. sysreg vs sysreg-defs).
For shared kvm headers and code, we think moving them to the proposed location
helps reducing regression issues when someone changes a function as that
location makes it 100% clear that this is shared code. Tagging a file
as __shared__ by other means (e.g. by a file name suffix) may
be OK for us as well if that reduces your maintenance burden.
The generated (e.g. sysreg) definitions are already generated into the s390
tree:
{outdir}/arch/s390/include/generated/asm/sysreg-gen-defs.h
We just reuse the makefile definitions from arm.
As a side note: We tried to reuse as much arm code as possible - to not
reinvent the wheel - while keeping the arm churn minimal. While going through
the arm code, we tried to spot parts that could benefit from refactoring and
did that. By moving especially the kvm code to another location we wanted to
emphasize that this code is shared between arm and s390 and possibly other
architectures in the future.
We will prototype alternatives including using symlinks and post them soon here.
> But that doesn't mean that we consider that the arm64 tree is
> immutable and that we are not open to change, quite the opposite.
> Most of the KVM/arm64 include files are an unholy mix of arch
> definitions, data structures that have some arch relevance, but also
> code and data that is strictly implementation specific. Splitting
> these (as you already have for some include files) could both help
> with sharing what is actually needed, keep the arm64-specific stuff
> at bay, *and* benefit arm64's overall maintainability. We would need
> some tooling to enforce the split and avoid regressing it, something
> that could happen quickly given the level of activity on arm64. Yet
> another way to achieve this could be to mechanically process the
> arm64 files as part of the s390 build to extract the relevant
> information, and we could help with this.
That is good to hear. We of course also wanted arm to improve with our changes.
>
> Looking a bit more into the distance, it is likely that KVM/arm64
> will grow feature support quicker than s390 can absorb them, and
> that some feature won't ever make any sense of s390 (pKVM, for
> example). We need to establish how these features can be built
> without arm64 being hindered by s390. This is also true when adding
> architectural support for features that don't exist in the s390 view
> of arm64.
Yes, of course s390 should not hinder arm64 to progress. 120% agree! We will
be available in case that happens. However, I do not think this is a big
problem. By defining some arm feature macros to false we already did turn off
few arm features for us at compile time. Compiler optimization is a very good
friend here.
>
> * UAPI and guest API:
>
> Obviously, one of our biggest concerns is the userspace API. We
> appreciate that you want to reuse it as it is, warts and all, and
> directly incorporate additional feature support as it becomes
Yes, implementing the arm64 kvm-UAPI was one of our primary goals so that we
can reuse existing arm64 VMMs e.g. Qemu.
> available. This means that, should any divergence in UAPI appear,
> the source of truth must be on the arm64 side. This has the
> following consequences:
Yes, arm64 is the source of truth for us. That is the exact reason we did not
copy the (UAPI) headers but moved & share them.
>
> - s390 cannot add extensions to the UAPI
>
> - s390 must be compatible with all future arm64 extensions
yes
>
> Similar concerns exist on the guest/hypervisor API, including:
>
> - errata mitigation: this is unsurprisingly a hot topic, which keeps
> causing us some massive headaches. We are particularly concerned
> about errata that need to be disclosed to the guest and acted upon
> via a hypercall. Should there be a need for those, how will we
> coordinate the deployment of such hypercall?
>
> The way it has been deployed so far is that PSCI has grown an
> errata discovery mechanism. ARM assigns function numbers and
> specifies what these hypercalls mitigate. KVM, in turn, takes part
> in implementing the mitigation. We expect that s390 would follow
> the same behaviour, including coordination with ARM for the
> function numbering.
Yes. s390 will follow those things. We are planning to reuse the complete
arm hypercall code including the current (and future) errata detection that
comes with it.
This change will come in one of the future series.
>
> - device assignment: this is unknown territory for us, as we
> commonly use vfio-pci (and more occasionally vfio-platform). How
> would that look for an arm64 guest on s390?
>
We plan to work with virtio-pci and vfio-pci. No plans to assign ccw devices to
arm guests.
> - s390-specific ISA extension: although we obviously cannot control
> how you will decide to expose features to your arm64 guests,
> KVM/arm64 makes a point of forbidding any use of implementation
> specific instruction or system registers. We expect the s390
> implementation to uphold this.
>
We have no plans of using private ISA extensions or deviations.
> - s390-specific hypercalls: aside from the errata handling
> mentioned above, we would very much like to avoid anything that is
> implementation specific, and keep the hypercall space as small as
> possible. In other words, an unenlightened arm64 guest must work
> and continue to work.
Of course an unenlightened arm64 guest must keep working and it should
work with good performance and usability. This is another primary goal of
this project.
Given that we have some history of paravirtual optimizations on s390, we
might propose some hypercalls in the future. But this will then very likely to
the benefit of all arm platforms and implemented on both host variants.
>
> * Overall maintenance
>
> Unsurprisingly, we are not totally familiar with s390. To say that
> there is a learning gap would only be an understatement. So how do
> we make sure we don't break things out of pure ignorance? Is there
> any documentation we can refer to when hacking on code that will
> eventually run on your side of the computing universe?
I am aware of the Kernel Documentation for s390.
Also, for the z/Architecture in general:
Principles of Operation might be a good start to learn about s390 architecture.
Of course we will be available for answering s390 architecture questions.
>
> We need to be able to build and test what we produce. How do we go
> about that? We appreciate that you may not be in a position to help
> with this right now, but at least having a plan would be reassuring.
> This should include things like automatic testing of our CI branches.
> We are happy to test build s390 as part of our maintenance flow, if
> pointed to existing binary toolchains compiled for arm64 and x86,
> together with a typical configuration.
>
For your side:
Cross compiling the kernel is a good starting point. GCC/Clang cross compile
toolchains for s390 are available on all major distros. They are typically
postfixed with ‘-s390x-linux-gnu‘, note the x after s390. defconfig has KVMARM
in it - this should be suitable for testing you do not break s390 compilation.
You can get access to s390 resources for doing native builds in the LinuxONE
community cloud. Those are VMs itself -> run tests are not possible.
https://community.ibm.com/zsystems/l1cc
They also offer permanent access to OSS communities if necessary. We can help
to connect you with those teams.
Another option would be to spin-up a s390 qemu-tcg guest to build the kernel
'native'.
For us:
Yes we are planning to do regular tests to prevent breaking arm. Testing your
CI branches seems to be a good starting point for this. Do you have a few
pointers which are suited best?
> What about debugging? We expect that you'd have to help, should an
> arm64 change cause a regression on s390, as it is fairly unlikely
> that we would be able to reproduce it.
Positive, we will do whatever we can to support you in any way.
>
> Finally, we feel it would be beneficial for both projects to swap
> prisoners and have cross-reviewers in MAINTAINERS, so that there is
> an s390 reviewer added to KVM/arm64, and an arm64 reviewer added to
> KVM/s390.
Great Idea and I like the wording :)
We’ll start with the exchange. I (Steffen) would volunteer to be sent over to you.
I will add myself as kvm/arm64 reviewer in v2 of this series if that is OK for
you.
For the other way we appreciate any volunteers and also will ask around for suitable
people with arm and preferably also s390 knowledge.
>
> It probably would be beneficial to work through some of these things
> face-to-face. Maybe around LPC or KVM Forum if you manage to get
> there? Or some other place/time?
Totally agree, although I would prefer an earlier date (probably virtual) to
get rid of any serious misunderstandings that may be there early.
Surely, we can meet at LPC and/or KVM-forum as well to discuss even more.
Thank you very much for your openness and your constructive, honest
feedback.
Steffen & the KVM/s390 team
>
> Thanks,
>
> Marc and Will
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mathieu Desnoyers @ 2026-04-23 12:29 UTC (permalink / raw)
To: Dmitry Vyukov, Jinjie Ruan, linux-man
Cc: Thomas Gleixner, Mark Rutland, Mathias Stearn, Catalin Marinas,
Will Deacon, Boqun Feng, Paul E. McKenney, Chris Kennelly,
regressions, linux-kernel, linux-arm-kernel, Peter Zijlstra,
Ingo Molnar, Blake Oler
In-Reply-To: <CACT4Y+bxnQyHGdVNE1BYTx+Z2-cscLb38HYS9jBM5gPAz8=4bw@mail.gmail.com>
On 2026-04-23 01:53, Dmitry Vyukov wrote:
[...]
> +linux-man
>
> This part of the rseq man page needs to be fixed as well I think. The
> kernel no longer reliably provides clearing of rseq_cs on preemption,
> right?
>
> https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2#n241
I'm maintaining this manual page in librseq.
>
> "and set to NULL by the kernel when it restarts an assembly
> instruction sequence block,
> as well as when the kernel detects that it is preempting or delivering
> a signal outside of the range targeted by the rseq_cs."
I think you got two things confused here.
1) There is currently a bug on arm64 where it fails to honor the
rseq ABI contract wrt critical section abort. AFAIU there is a
fix proposed for this.
2) Thomas relaxed the implementation of cpu_id_start field updates
so it only stores to the rseq area when the current cpu actually
changes (migration).
So AFAIU the statement in the man page is still fine. It's just arm64
that needs fixing.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ 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