* Re: [PATCH v2 15/20] drm/drv: Call drm_mode_config_create_state() by default
From: Dmitry Baryshkov @ 2026-04-21 15:57 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, 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: <dd39f423-1598-4749-8c95-98b8daf69680@suse.de>
On Tue, Apr 21, 2026 at 05:33:12PM +0200, Thomas Zimmermann wrote:
>
>
> Am 21.04.26 um 15:38 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> > > Almost all drivers, and our documented skeleton, call
> > > drm_mode_config_reset() prior to calling drm_dev_register() to
> > > initialize its DRM object states.
> > >
> > > Now that we have drm_mode_config_create_state() to create that initial
> > > state if it doesn't exist, we can call it directly in
> > > drm_dev_register(). That way, we know that the initial atomic state will
> > > always be allocated without any boilerplate.
> > >
> > > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 2915118436ce8a6640cfb0c59936031990727ed1..820106d56ab399a39cac56d98662b5ddbcae8ded
> > > 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -1097,10 +1097,14 @@ int drm_dev_register(struct drm_device *dev,
> > > unsigned long flags)
> > > if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> > > ret = drm_modeset_register_all(dev);
> > > if (ret)
> > > goto err_unload;
> > > +
> > > + ret = drm_mode_config_create_state(dev);
> > > + if (ret)
> > > + goto err_unload;
> >
> > Way too late. Lets rather go through drivers and call this where they
> > currently call drm_mode_config_reset() for initialization. This can be a
> > single-patch mass conversion IMHO.
>
> On a second thought, can't we modify the suspend code and leave the reset
> as-is for now? I'd still be interested to use reset as a means of
> initializing the hardware or loading state on probe. So keeping the _reset()
> calls in place might be helpful for that.
But isn't it the expected behaviour? The driver can reset(), but if
it didn't, the default would be to create empty working state. In the
end, the drivers also can call this function to create the state, don't
they (and then perform the readout logic)?
>
> What's the long-term plan here?
>
> Best regards
> Thomas
>
> >
> > Best regards
> > Thomas
> >
> > > }
> > > drm_panic_register(dev);
> > > drm_client_sysrq_register(dev);
> > > DRM_INFO("Initialized %s %d.%d.%d for %s on minor %d\n",
> > >
> >
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 20/20] drm/bridge_connector: Convert to atomic_create_state
From: Dmitry Baryshkov @ 2026-04-21 15:58 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, 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, Laurent Pinchart
In-Reply-To: <20260320-drm-mode-config-init-v2-20-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:27PM +0100, Maxime Ripard wrote:
> The connector created by drm_bridge_connector only initializes a
> pristine state in reset, which is equivalent to that atomic_create_state
> would expect. Let's convert to it.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/display/drm_bridge_connector.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v2] arm64/irqflags: __always_inline the arch_local_irq_*() helpers
From: Breno Leitao @ 2026-04-21 15:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, mark.rutland
Cc: leo.bras, leo.yan, linux-arm-kernel, linux-kernel, palmer,
paulmck, puranjay, usama.arif, rmikey, kernel-team, Breno Leitao
The arch_local_irq_*() wrappers in <asm/irqflags.h> dispatch between two
underlying primitives: the __daif_* path on most systems, and the
__pmr_* path on builds that use GIC PMR-based masking (Pseudo-NMI). The
leaf primitives are already __always_inline, but the wrappers themselves
are plain "static inline".
That is unsafe for noinstr callers: nothing prevents the compiler from
emitting an out-of-line copy of e.g. arch_local_irq_disable(), and an
out-of-line copy can be instrumented (ftrace, kcov, sanitizers), which
breaks the noinstr contract on the entry/idle paths that rely on these
helpers.
x86 hit and fixed exactly this class of bug in commit 7a745be1cc90
("x86/entry: __always_inline irqflags for noinstr").
Force-inline all of the arch_local_irq_*() wrappers so they cannot be
emitted out-of-line:
- arch_local_irq_enable()
- arch_local_irq_disable()
- arch_local_save_flags()
- arch_irqs_disabled_flags()
- arch_irqs_disabled()
- arch_local_irq_save()
- arch_local_irq_restore()
The primary motivation is noinstr safety. There is a useful side effect
for fleet-wide profiling: when the wrapper is emitted out-of-line,
samples taken inside it during the post-WFI IRQ unmask in
default_idle_call() are attributed to arch_local_irq_enable rather than
default_idle_call(), and the FP-unwinder loses default_idle_call() from
the chain.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Changes in v2:
- Expand the functions that uses always_inline in arm64
- Link to v1: https://patch.msgid.link/20260420-arm64_always_inline-v1-1-dba919cf46bc@debian.org
---
arch/arm64/include/asm/irqflags.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
index d4d7451c2c129..a8cb5a5c93b78 100644
--- a/arch/arm64/include/asm/irqflags.h
+++ b/arch/arm64/include/asm/irqflags.h
@@ -40,7 +40,7 @@ static __always_inline void __pmr_local_irq_enable(void)
barrier();
}
-static inline void arch_local_irq_enable(void)
+static __always_inline void arch_local_irq_enable(void)
{
if (system_uses_irq_prio_masking()) {
__pmr_local_irq_enable();
@@ -68,7 +68,7 @@ static __always_inline void __pmr_local_irq_disable(void)
barrier();
}
-static inline void arch_local_irq_disable(void)
+static __always_inline void arch_local_irq_disable(void)
{
if (system_uses_irq_prio_masking()) {
__pmr_local_irq_disable();
@@ -90,7 +90,7 @@ static __always_inline unsigned long __pmr_local_save_flags(void)
/*
* Save the current interrupt enable state.
*/
-static inline unsigned long arch_local_save_flags(void)
+static __always_inline unsigned long arch_local_save_flags(void)
{
if (system_uses_irq_prio_masking()) {
return __pmr_local_save_flags();
@@ -109,7 +109,7 @@ static __always_inline bool __pmr_irqs_disabled_flags(unsigned long flags)
return flags != GIC_PRIO_IRQON;
}
-static inline bool arch_irqs_disabled_flags(unsigned long flags)
+static __always_inline bool arch_irqs_disabled_flags(unsigned long flags)
{
if (system_uses_irq_prio_masking()) {
return __pmr_irqs_disabled_flags(flags);
@@ -128,7 +128,7 @@ static __always_inline bool __pmr_irqs_disabled(void)
return __pmr_irqs_disabled_flags(__pmr_local_save_flags());
}
-static inline bool arch_irqs_disabled(void)
+static __always_inline bool arch_irqs_disabled(void)
{
if (system_uses_irq_prio_masking()) {
return __pmr_irqs_disabled();
@@ -160,7 +160,7 @@ static __always_inline unsigned long __pmr_local_irq_save(void)
return flags;
}
-static inline unsigned long arch_local_irq_save(void)
+static __always_inline unsigned long arch_local_irq_save(void)
{
if (system_uses_irq_prio_masking()) {
return __pmr_local_irq_save();
@@ -187,7 +187,7 @@ static __always_inline void __pmr_local_irq_restore(unsigned long flags)
/*
* restore saved IRQ state
*/
-static inline void arch_local_irq_restore(unsigned long flags)
+static __always_inline void arch_local_irq_restore(unsigned long flags)
{
if (system_uses_irq_prio_masking()) {
__pmr_local_irq_restore(flags);
---
base-commit: bee6ea30c48788e18348309f891ed8afbf7702ac
change-id: 20260420-arm64_always_inline-6bc9dd3c17e6
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply related
* Re: [PATCH v2 16/20] drm/atomic: Drop private obj state allocation
From: Dmitry Baryshkov @ 2026-04-21 15:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, 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, Laurent Pinchart
In-Reply-To: <20260320-drm-mode-config-init-v2-16-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:23PM +0100, Maxime Ripard wrote:
> Now that drm_dev_register() calls drm_mode_config_create_state() for
> every modeset driver, the private obj states will be initialized at
> driver registration automatically if they haven't already.
>
> Thus, the explicit initial allocation we have in
> drm_atomic_private_obj_init() is now redundant, and we can remove it.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic.c | 7 -------
> 1 file changed, 7 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 10/20] drm/crtc: Add new atomic_create_state callback
From: Dmitry Baryshkov @ 2026-04-21 16:01 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, 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: <20260320-drm-mode-config-init-v2-10-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:17PM +0100, Maxime Ripard wrote:
> 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 tate, 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 crtcs.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 47 +++++++++++++++++++++++++++++++
> drivers/gpu/drm/drm_mode_config.c | 21 +++++++++++++-
> include/drm/drm_atomic_state_helper.h | 4 +++
> include/drm/drm_crtc.h | 13 +++++++++
> 4 files changed, 84 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 14/20] drm/mode-config: Create drm_mode_config_create_state()
From: Dmitry Baryshkov @ 2026-04-21 16:02 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, 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: <20260320-drm-mode-config-init-v2-14-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:21PM +0100, Maxime Ripard wrote:
> drm_mode_config_reset() can be used to create the initial state, but
> also to return to the initial state, when doing a suspend/resume cycle
> for example.
>
> It also affects both the software and the hardware, and drivers can
> choose to reset the hardware as well. Most will just create an empty
> state and the synchronisation between hardware and software states will
> effectively be done when the first commit is done.
>
> That dual role can be harmful, since some objects do need to be
> initialized but also need to be preserved across a suspend/resume cycle.
> drm_private_obj are such objects for example.
>
> Thus, let's create another helper for drivers to call to initialize
> their state when the driver is loaded, so we can make
> drm_mode_config_reset() only about handling suspend/resume and similar.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic.c | 12 +++++-
> drivers/gpu/drm/drm_mode_config.c | 87 +++++++++++++++++++++++++++++++++++++++
> include/drm/drm_mode_config.h | 1 +
> 3 files changed, 98 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 12/18] KVM: arm64: selftests: Add missing GIC CDEN to no-vgic-v5 selftest
From: Joey Gouly @ 2026-04-21 16:02 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260415115559.2227718-13-maz@kernel.org>
On Wed, Apr 15, 2026 at 12:55:53PM +0100, Marc Zyngier wrote:
> From: Sascha Bischoff <sascha.bischoff@arm.com>
>
> The selftest mistakenly omitted the GIC CDEN instruction from the
> testing. Add it in.
Compared against the list of instructions in the spec.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
>
> Fixes: ce29261ec648 ("KVM: arm64: selftests: Add no-vgic-v5 selftest")
> Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> tools/testing/selftests/kvm/arm64/no-vgic.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/kvm/arm64/no-vgic.c b/tools/testing/selftests/kvm/arm64/no-vgic.c
> index b14686ef17d12..e09e3fac904f4 100644
> --- a/tools/testing/selftests/kvm/arm64/no-vgic.c
> +++ b/tools/testing/selftests/kvm/arm64/no-vgic.c
> @@ -159,6 +159,7 @@ static void guest_code_gicv5(void)
> check_gicv5_gic_op(CDAFF);
> check_gicv5_gic_op(CDDI);
> check_gicv5_gic_op(CDDIS);
> + check_gicv5_gic_op(CDEN);
> check_gicv5_gic_op(CDEOI);
> check_gicv5_gic_op(CDHM);
> check_gicv5_gic_op(CDPEND);
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2] arm64/irqflags: __always_inline the arch_local_irq_*() helpers
From: Leonardo Bras @ 2026-04-21 16:07 UTC (permalink / raw)
To: Breno Leitao
Cc: Leonardo Bras, Catalin Marinas, Will Deacon, mark.rutland,
leo.yan, linux-arm-kernel, linux-kernel, palmer, paulmck,
puranjay, usama.arif, rmikey, kernel-team
In-Reply-To: <20260421-arm64_always_inline-v2-1-c59d1400514d@debian.org>
On Tue, Apr 21, 2026 at 08:58:57AM -0700, Breno Leitao wrote:
> The arch_local_irq_*() wrappers in <asm/irqflags.h> dispatch between two
> underlying primitives: the __daif_* path on most systems, and the
> __pmr_* path on builds that use GIC PMR-based masking (Pseudo-NMI). The
> leaf primitives are already __always_inline, but the wrappers themselves
> are plain "static inline".
>
> That is unsafe for noinstr callers: nothing prevents the compiler from
> emitting an out-of-line copy of e.g. arch_local_irq_disable(), and an
> out-of-line copy can be instrumented (ftrace, kcov, sanitizers), which
> breaks the noinstr contract on the entry/idle paths that rely on these
> helpers.
>
> x86 hit and fixed exactly this class of bug in commit 7a745be1cc90
> ("x86/entry: __always_inline irqflags for noinstr").
>
> Force-inline all of the arch_local_irq_*() wrappers so they cannot be
> emitted out-of-line:
>
> - arch_local_irq_enable()
> - arch_local_irq_disable()
> - arch_local_save_flags()
> - arch_irqs_disabled_flags()
> - arch_irqs_disabled()
> - arch_local_irq_save()
> - arch_local_irq_restore()
>
> The primary motivation is noinstr safety. There is a useful side effect
> for fleet-wide profiling: when the wrapper is emitted out-of-line,
> samples taken inside it during the post-WFI IRQ unmask in
> default_idle_call() are attributed to arch_local_irq_enable rather than
> default_idle_call(), and the FP-unwinder loses default_idle_call() from
> the chain.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> Changes in v2:
> - Expand the functions that uses always_inline in arm64
> - Link to v1: https://patch.msgid.link/20260420-arm64_always_inline-v1-1-dba919cf46bc@debian.org
> ---
> arch/arm64/include/asm/irqflags.h | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
> index d4d7451c2c129..a8cb5a5c93b78 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -40,7 +40,7 @@ static __always_inline void __pmr_local_irq_enable(void)
> barrier();
> }
>
> -static inline void arch_local_irq_enable(void)
> +static __always_inline void arch_local_irq_enable(void)
> {
> if (system_uses_irq_prio_masking()) {
> __pmr_local_irq_enable();
> @@ -68,7 +68,7 @@ static __always_inline void __pmr_local_irq_disable(void)
> barrier();
> }
>
> -static inline void arch_local_irq_disable(void)
> +static __always_inline void arch_local_irq_disable(void)
> {
> if (system_uses_irq_prio_masking()) {
> __pmr_local_irq_disable();
> @@ -90,7 +90,7 @@ static __always_inline unsigned long __pmr_local_save_flags(void)
> /*
> * Save the current interrupt enable state.
> */
> -static inline unsigned long arch_local_save_flags(void)
> +static __always_inline unsigned long arch_local_save_flags(void)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_local_save_flags();
> @@ -109,7 +109,7 @@ static __always_inline bool __pmr_irqs_disabled_flags(unsigned long flags)
> return flags != GIC_PRIO_IRQON;
> }
>
> -static inline bool arch_irqs_disabled_flags(unsigned long flags)
> +static __always_inline bool arch_irqs_disabled_flags(unsigned long flags)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_irqs_disabled_flags(flags);
> @@ -128,7 +128,7 @@ static __always_inline bool __pmr_irqs_disabled(void)
> return __pmr_irqs_disabled_flags(__pmr_local_save_flags());
> }
>
> -static inline bool arch_irqs_disabled(void)
> +static __always_inline bool arch_irqs_disabled(void)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_irqs_disabled();
> @@ -160,7 +160,7 @@ static __always_inline unsigned long __pmr_local_irq_save(void)
> return flags;
> }
>
> -static inline unsigned long arch_local_irq_save(void)
> +static __always_inline unsigned long arch_local_irq_save(void)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_local_irq_save();
> @@ -187,7 +187,7 @@ static __always_inline void __pmr_local_irq_restore(unsigned long flags)
> /*
> * restore saved IRQ state
> */
> -static inline void arch_local_irq_restore(unsigned long flags)
> +static __always_inline void arch_local_irq_restore(unsigned long flags)
> {
> if (system_uses_irq_prio_masking()) {
> __pmr_local_irq_restore(flags);
>
> ---
> base-commit: bee6ea30c48788e18348309f891ed8afbf7702ac
> change-id: 20260420-arm64_always_inline-6bc9dd3c17e6
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
>
Looks correct to what was discussed in V1. FWIW:
Reviewed-by: Leonardo Bras <leo.bras@arm.com>
^ permalink raw reply
* Re: [PATCH RFC 0/4] arm64: rockchip: The hunt for exact pixel clocks on RK3576
From: Maxime Ripard @ 2026-04-21 16:10 UTC (permalink / raw)
To: Brian Masney
Cc: Sebastian Reichel, Alexey Charkov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Pavel Zhovner, Andy Yan,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
linux-clk, Cristian Ciocaltea
In-Reply-To: <aeZOMnZfBcBHzR8c@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4443 bytes --]
Hi Brian, Alexey,
On Mon, Apr 20, 2026 at 12:02:58PM -0400, Brian Masney wrote:
> On Sat, Apr 18, 2026 at 12:24:57AM +0200, Sebastian Reichel wrote:
> > On Fri, Apr 17, 2026 at 07:11:43PM +0400, Alexey Charkov wrote:
> > > Dear all,
> > >
> > > Need the help of the collective wisdom of the community.
> > >
> > > The problem I'm trying to solve is reliably obtaining the exact pixel
> > > clock for arbitrary display modes supported by the RK3576 SoC.
> > >
> > > Rockchip RK3576 has three display output processors VP0~VP2, each
> > > supporting different ranges of display modes, roughly as follows:
> > > - VP0: 4K 120Hz
> > > - VP1: 2.5k 60Hz
> > > - VP2: 1080p 60Hz
Do any of those have an additional multiplier or divider after the PLL?
I'm asking because 4k@120Hz is 1188MHz, and 1080p@60Hz is 148.5 (so 1188
/ 8). 2.5k @ 60 might be a bit more problematic, but my point is that
for HDMI/DP, most resolutions all have a pixel clock that are multiples
of 148.5MHz.
If you manage to get the PLL to the highest you need (1188MHz), and then
apply dividers, you don't need to change the PLL frequency anymore.
> > > Each one obviously needs a pixel clock. The required frequencies for the
> > > pixel clocks vary greatly depending on the display mode, and need to be
> > > matched within a tight tolerance, or else many displays will refuse to
> > > work. E.g. the preferred (maximum) display mode out of VP1 is particularly
> > > awkward, because it requires a pixel clock of 248.88 MHz, which cannot
> > > be obtained using integer dividers from its default clock source (GPLL
> > > at 1188 MHz), and the nearest approximation is 237.6 MHz, which is well
> > > outside the tolerance of e.g. DP specification, resulting in a blank
> > > screen on most displays by default.
> > >
> > > The clock sources are of course configurable, in particular there are muxes
> > > connected to each VP for selecting the source of the pixel clock:
> > > - Each VP can take the clock either from the (single!) HDMI PHY or from
> > > its dedicated dclk_vpX_src mux
> > > - The dclk_vpX_src mux can select the clock from a number of system PLLs
> > > (GPLL, CPLL, VPLL, BPLL, LPLL)
> > >
> > > While the system PLLs can be configured to output a wide range of
> > > frequencies, they are shared between many system components. E.g. on the
> > > current mainline kernel on one of my RK3576 boards I've got the following:
> > > GPLL: 1188 MHz, enable count 20
> > > CPLL: 1000 MHz, enable count 17
> > > VPLL: 594 MHz, enable count 0 (yaay!)
> > > BPLL, LPLL: 816 MHz, enable count 0 (but these last ones don't have
> > > predividers, so are less flexible)
> > >
> > > So ultimately there is exactly one free fractional PLL (VPLL) which can be
> > > used to generate arbitrary pixel clocks, but we have up to three consumers
> > > trying to drive different display modes from it (e.g. HDMI on VP0, DP on
> > > VP1 and MIPI DSI on VP2). We also want to be able to adjust the PLL output
> > > frequency on the fly to satisfy the requirements of the selected display
> > > mode.
> > >
> > > And this is where I'm stuck. Trying to satisfy the requirements of up to
> > > three consumers while changing the PLL frequency on the fly sounds like
> > > a poorly tractable mathematical problem (is it 3-SAT?). We can take the
> > > HDMI output out of the equation, because it can be driven from the HDMI
> > > PHY (which is capable of arbitrary rates) instead of the mux, but that
> > > makes the decision of which dclk source to use for a VP block dependent on
> > > which downstream consumer is connected to it (HDMI vs. something else).
> >
> > It becomes more messy: The HDMI PHY cannot be used as clock source
> > for modes exceeding 4K@60Hz.
> >
> > > Even then we somehow need two devices to cooperate in picking a PLL
> > > frequency that satisfies the requirements of both of them, and change to it
> > > without display corruption. I'm not even sure if the CCF has mechanisms
> > > for that?..
It's not *just* the CCF though. You will disrupt the other, already
active display, which might affect the user because the screen will
blank, throw off the vblank timings and thus userspace, etc.
Brian's solution is great progress on that front already, but if you can
just save yourself the trouble, I'd advise you to do that instead :)
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/9] ASoC: mediatek: mt2701: add HDMI audio memif, FE and BE DAIs
From: Daniel Golle @ 2026-04-21 16:12 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jaroslav Kysela,
Takashi Iwai, Arnd Bergmann, Cyril Chao,
Nícolas F. R. A. Prado, Kuninori Morimoto, Eugen Hristev,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <95e1067c-3c8e-4dd4-997d-f3be9d2cba29@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
On Mon, Apr 20, 2026 at 07:08:01PM +0100, Mark Brown wrote:
> On Mon, Apr 20, 2026 at 02:13:34AM +0100, Daniel Golle wrote:
>
> > +static int mt2701_afe_hdmi_trigger(struct snd_pcm_substream *substream, int cmd,
> > + struct snd_soc_dai *dai)
> > +{
> > + struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
> > +
> > + switch (cmd) {
> > + case SNDRV_PCM_TRIGGER_START:
> > + case SNDRV_PCM_TRIGGER_RESUME:
> > + /* Ungate HDMI and SPDIF power islands. */
> > + regmap_update_bits(afe->regmap, AUDIO_TOP_CON0,
> > + AUDIO_TOP_CON0_PDN_HDMI_CK |
> > + AUDIO_TOP_CON0_PDN_SPDIF_CK, 0);
>
> It looks like we have clock API clocks for HDMI and S/PDIF on this SoC
> (see clk-mt2701-aud.c) - are there going to be problem with peering
> directly at the register? We do manage some clocks via the clock API
> but not those ones.
Yeah, you are right. That came from a super-old vendor driver and I
didn't realise the exact same gate bits are alrady driven by the
clock driver. I'll drop that and prepare v3...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: dts: amlogic: add support for X98Q
From: Ferass El Hafidi @ 2026-04-21 16:33 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, robh, krzk+dt, conor+dt,
neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260421155328.26359-3-christian.koever-draxl@student.uibk.ac.at>
On Tue, 21 Apr 2026 15:53, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>Add dts enabling core hardware for the Amediatech X98Q.
>
You should explain what the Amediatech X98Q is. You did this in the v2's
cover letter, but it should additionally go in here too so it's visible
in git commits in the kernel. What hardware does it have? Maybe also what is
enabled in the DT?
>Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>---
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
> 2 files changed, 250 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
><...>
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH v3 0/2] Add support for Amediatech X98Q (Amlogic S905W2)
From: Ferass El Hafidi @ 2026-04-21 16:37 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, robh, krzk+dt, conor+dt,
neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260421155328.26359-1-christian.koever-draxl@student.uibk.ac.at>
On Tue, 21 Apr 2026 15:53, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>Changes in v3:
>- Change position of the entry in the amlogic.yaml.
>- Change formatting of the Amlogic W150S1 Wi-Fi module comment.
>- Fix several formatting issues.
>
>Changes in v2:
>- Split dt-bindings and dts changes into separate patches.
>- Updated model string to match documented vendor prefix.
>- Put vddio_sd states array in a single line.
>- Added a comment for the unsupported Amlogic W150S1 Wi-Fi module.
>
Where did the rest of the cover letter go?
>Christian Stefan Kövér-Draxl (2):
> dt-bindings: arm: amlogic: add support for Amediatech X98Q
> arm64: dts: amlogic: add support for X98Q
>
> .../devicetree/bindings/arm/amlogic.yaml | 7 +
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
> 3 files changed, 257 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>
>--
>2.53.0
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Stop queue allocation retry at PAGE_SIZE
From: Will Deacon @ 2026-04-21 16:38 UTC (permalink / raw)
To: Robin Murphy; +Cc: leo.jiang1224, joro, iommu, linux-arm-kernel
In-Reply-To: <0fdf4b1f-90f2-4f69-9d2b-dc5f608e9c1c@arm.com>
On Tue, Apr 21, 2026 at 04:56:47PM +0100, Robin Murphy wrote:
> On 18/04/2026 6:31 am, leo.jiang1224@foxmail.com wrote:
> > From: LoserJL <leo.jiang1224@foxmail.com>
> >
> > In arm_smmu_init_one_queue(), the loop reduces max_n_shift if
> > dmam_alloc_coherent() fails. However, since dmam_alloc_coherent()
> > allocates at least PAGE_SIZE, retrying with a smaller size after
> > a PAGE_SIZE failure is logically redundant.
>
> Says who? It's certainly not a guarantee offered by the DMA API itself, and
> indeed some allocation paths can definitely still allocate less than a page
> - e.g. anything which hits a per-device or global coherent pool.
>
> > Moreover, if a sub-page retry were to succeed due to concurrent memory
> > release, the hardware would be configured with a smaller queue depth
> > despite a full page being allocated. This leads to inefficient memory
> > usage and unnecessary hardware performance limitation.
> >
> > Terminate the loop once qsz reaches PAGE_SIZE to ensure logical
> > consistency and optimal hardware configuration.
>
> That's really not an argument - even if an allocator does happen to
> over-allocate for the requested size, that is hardly the caller's concern;
> and as far as "optimal" queue sizes go in this case, those very much depend
> on the number of CPUs issuing commands and volume of expected stall/PRI
> events - in many cases PAGE_SIZE would already be far too small to really
> work well.
>
> Also note that if we _were_ to fail to allocate a PAGE_SIZE or smaller
> queue, there would be very little chance of the subsequent allocation(s) for
> the stream table succeeding, so realistically the driver is probably going
> to end up failing to probe in such circumstances anyway.
That's all true, but tbf I think I just fscked up the comparison in
d25f6ead162e ("iommu/arm-smmu-v3: Increase maximum size of queues") so
I'm not against fixing that up even though the "rationale" given by
Loser doesn't make a whole lot of sense.
Will
^ permalink raw reply
* [PATCH] KVM: arm64: Treat ID_AA64DFR0_EL1.PMUVer as an unsigned field
From: Jing Zhang @ 2026-04-21 16:41 UTC (permalink / raw)
To: KVM, KVMARM, ARMLinux, Marc Zyngier, Oliver Upton
Cc: Joey Gouly, Suzuki K Poulose, Zenghui Yu, Paolo Bonzini,
Jing Zhang
ID_AA64DFR0_EL1.PMUVer is an unsigned 4-bit field, but was historically
marked as signed in the cpufeature table. This led
kvm_init_host_debug_data() to fail detection of PMUv3 implementation on
systems with PMUv3p8 or newer, as the signed extraction of the field
(e.g., 0b1000 for PMUv3p8) would result in a negative value.
Fix this by marking the field as unsigned in the ftr_id_aa64dfr0 table
and updating the KVM initialization code to use unsigned extraction.
While at it, ensure that both the 'Not Implemented' (0b0000) and
'Implementation Defined' (0b1111) values are correctly handled as
indicating the absence of a standard PMUv3.
Signed-off-by: Jing Zhang <jingzhangos@google.com>
---
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/kvm/debug.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 32c2dbcc0c641..1b5e37a1a41b4 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -565,7 +565,7 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
* We can instantiate multiple PMU instances with different levels
* of support.
*/
- S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_EL1_PMUVer_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_EL1_PMUVer_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_EL1_DebugVer_SHIFT, 4, 0x6),
ARM64_FTR_END,
};
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 3ad6b7c6e4ba7..2834d7ef9dedb 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -75,8 +75,10 @@ static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)
void kvm_init_host_debug_data(void)
{
u64 dfr0 = read_sysreg(id_aa64dfr0_el1);
+ u64 pmuver;
- if (cpuid_feature_extract_signed_field(dfr0, ID_AA64DFR0_EL1_PMUVer_SHIFT) > 0)
+ pmuver = cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_PMUVer_SHIFT);
+ if (pmuv3_implemented(pmuver))
*host_data_ptr(nr_event_counters) = FIELD_GET(ARMV8_PMU_PMCR_N,
read_sysreg(pmcr_el0));
--
2.54.0.rc1.555.g9c883467ad-goog
^ permalink raw reply related
* Re: [PATCH v4 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Conor Dooley @ 2026-04-21 16:43 UTC (permalink / raw)
To: linux-kernel-dev
Cc: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown,
linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm
In-Reply-To: <20260421-add-mcu-fan-khadas-vim4-v4-1-447114a28f2d@aliel.fr>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Tue, Apr 21, 2026 at 01:49:18PM +0200, Ronald Claveau via B4 Relay wrote:
> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>
> The Khadas VIM4 MCU register is slightly different
> from previous boards' MCU.
> This board also features a switchable power source for its fan.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Treat ID_AA64DFR0_EL1.PMUVer as an unsigned field
From: Marc Zyngier @ 2026-04-21 16:45 UTC (permalink / raw)
To: Jing Zhang
Cc: KVM, KVMARM, ARMLinux, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Paolo Bonzini
In-Reply-To: <20260421164112.2448553-1-jingzhangos@google.com>
On Tue, 21 Apr 2026 17:41:12 +0100,
Jing Zhang <jingzhangos@google.com> wrote:
>
> ID_AA64DFR0_EL1.PMUVer is an unsigned 4-bit field, but was historically
> marked as signed in the cpufeature table. This led
> kvm_init_host_debug_data() to fail detection of PMUv3 implementation on
> systems with PMUv3p8 or newer, as the signed extraction of the field
> (e.g., 0b1000 for PMUv3p8) would result in a negative value.
>
> Fix this by marking the field as unsigned in the ftr_id_aa64dfr0 table
> and updating the KVM initialization code to use unsigned extraction.
> While at it, ensure that both the 'Not Implemented' (0b0000) and
> 'Implementation Defined' (0b1111) values are correctly handled as
> indicating the absence of a standard PMUv3.
>
> Signed-off-by: Jing Zhang <jingzhangos@google.com>
https://lore.kernel.org/all/20260305-james-kvm-pmuver-sign-v2-0-ee80a125af9b@linaro.org/
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Conor Dooley @ 2026-04-21 17:05 UTC (permalink / raw)
To: Ronald Claveau
Cc: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260421-add-thermal-t7-vim4-v3-1-a2e7215ed003@aliel.fr>
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
On Tue, Apr 21, 2026 at 09:19:43AM +0200, Ronald Claveau wrote:
> Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
>
> Unlike existing variants which use a phandle to the ao-secure syscon,
> the T7 relies on a secure monitor interface described by a phandle and
> a sensor index argument.
>
> The T7 integrates multiple thermal sensors, all accessed through the
> same SMC call. The sensor index argument is required to identify which
> sensor's calibration data the secure monitor should return, as a single
> SM_THERMAL_CALIB_READ command serves all of them.
>
> Introduce the amlogic,secure-monitor property as a phandle-array and
> make amlogic,ao-secure or amlogic,secure-monitor conditionally required
> depending on the compatible.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: arm: amlogic: add support for Amediatech X98Q
From: Conor Dooley @ 2026-04-21 17:13 UTC (permalink / raw)
To: christian.koever-draxl
Cc: robh, krzk+dt, conor+dt, neil.armstrong, khilman, jbrunet,
martin.blumenstingl, devicetree, linux-amlogic, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260421155328.26359-2-christian.koever-draxl@student.uibk.ac.at>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On Tue, Apr 21, 2026 at 05:53:27PM +0200, christian.koever-draxl@student.uibk.ac.at wrote:
> From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
> Add the board binding for the Amediatech X98Q TV box
>
> Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net v4 2/2] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
From: Lorenzo Bianconi @ 2026-04-21 17:15 UTC (permalink / raw)
To: Paolo Abeni
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <210f5d0b-6232-4c0f-adff-3a97d54159b3@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
> On 4/17/26 8:36 AM, Lorenzo Bianconi wrote:
> > @@ -1055,8 +1058,33 @@ static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
> > e->dma_addr = 0;
> > e->skb = NULL;
> > list_add_tail(&e->list, &q->tx_list);
> > +
> > + /* Reset DMA descriptor */
> > + WRITE_ONCE(desc->ctrl, 0);
> > + WRITE_ONCE(desc->addr, 0);
> > + WRITE_ONCE(desc->data, 0);
> > + WRITE_ONCE(desc->msg0, 0);
> > + WRITE_ONCE(desc->msg1, 0);
> > + WRITE_ONCE(desc->msg2, 0);
>
> Sashiko has some complains on this patch that look legit to me.
>
> Also the pre-existing issues mentioned WRT patch 1/2 makes such patch
> IMHO almost ineffective, I think you should address them in the same series.
>
> Note that you should have commented on sashiko review on the ML, it
> would have saved a significant amount of time on us.
Since this series is marked as 'Changes Requested', it is not clear to me what
next steps are. I guess we have two possible approach here:
1) - Post patch 1/2 ("net: airoha: Move ndesc initialization at
end of airoha_qdma_init_tx()") with the series available upstream
(not merged yet) in [0] where I am fixing similar issues for
airoha_qdma_init_rx_queue() and airoha_qdma_tx_irq_init().
- Post patch 2/2 ("net: airoha: Add missing bits in
airoha_qdma_cleanup_tx_queue()") with a fix for airoha_ndo_stop() waiting
for TX/RX DMA engine to complete before running
airoha_qdma_cleanup_tx_queue().
2) - Since all the issues rised by Sashiko are not strictly related to this
series and they are already fixed in pending patches, just apply the fixes
separately without the needs to repost this series.
Which approach do you prefer?
Regards,
Lorenzo
[0] https://patchwork.kernel.org/project/netdevbpf/cover/20260420-airoha_qdma_init_rx_queue-fix-v2-0-d99347e5c18d@kernel.org/
>
> /P
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net v4 2/2] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
From: Paolo Abeni @ 2026-04-21 17:32 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <aeewoVjN7EHLZTW_@lore-desk>
On 4/21/26 7:15 PM, Lorenzo Bianconi wrote:
>> On 4/17/26 8:36 AM, Lorenzo Bianconi wrote:
>>> @@ -1055,8 +1058,33 @@ static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
>>> e->dma_addr = 0;
>>> e->skb = NULL;
>>> list_add_tail(&e->list, &q->tx_list);
>>> +
>>> + /* Reset DMA descriptor */
>>> + WRITE_ONCE(desc->ctrl, 0);
>>> + WRITE_ONCE(desc->addr, 0);
>>> + WRITE_ONCE(desc->data, 0);
>>> + WRITE_ONCE(desc->msg0, 0);
>>> + WRITE_ONCE(desc->msg1, 0);
>>> + WRITE_ONCE(desc->msg2, 0);
>>
>> Sashiko has some complains on this patch that look legit to me.
>>
>> Also the pre-existing issues mentioned WRT patch 1/2 makes such patch
>> IMHO almost ineffective, I think you should address them in the same series.
>>
>> Note that you should have commented on sashiko review on the ML, it
>> would have saved a significant amount of time on us.
>
> Since this series is marked as 'Changes Requested', it is not clear to me what
> next steps are. I guess we have two possible approach here:
>
> 1) - Post patch 1/2 ("net: airoha: Move ndesc initialization at
> end of airoha_qdma_init_tx()") with the series available upstream
> (not merged yet) in [0] where I am fixing similar issues for
> airoha_qdma_init_rx_queue() and airoha_qdma_tx_irq_init().
> - Post patch 2/2 ("net: airoha: Add missing bits in
> airoha_qdma_cleanup_tx_queue()") with a fix for airoha_ndo_stop() waiting
> for TX/RX DMA engine to complete before running
> airoha_qdma_cleanup_tx_queue().
>
> 2) - Since all the issues rised by Sashiko are not strictly related to this
> series and they are already fixed in pending patches, just apply the fixes
> separately without the needs to repost this series.
Given the current flood on the ML I think option 2 could be the better.
Note that the tree is currently in Jakub's hands and he can very legitly
disagree.
/P
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Conor Dooley @ 2026-04-21 17:57 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <OSQPR06MB725251546BFEB158F9AA1C4D8B2C2@OSQPR06MB7252.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 8325 bytes --]
Billy, Linus,
On Tue, Apr 21, 2026 at 06:15:44AM +0000, Billy Tsai wrote:
> > > > > > > + properties:
> > > > > > > + function:
> > > > > > > + enum:
> > > > > > > + - EMMC
> > > > > > > + - JTAGDDR
> > > > > > > + - JTAGM0
> > > > > > > + - JTAGPCIEA
> > > > > > > + - JTAGPCIEB
> > > > > > > + - JTAGPSP
> > > > > > > + - JTAGSSP
> > > > > > > + - JTAGTSP
> > > > > > > + - JTAGUSB3A
> > > > > > > + - JTAGUSB3B
> > > > > > > + - PCIERC0PERST
> > > > > > > + - PCIERC1PERST
> > > > > > > + - TSPRSTN
> > > > > > > + - UFSCLKI
> > > > > > > + - USB2AD0
> > > > > > > + - USB2AD1
> > > > > > > + - USB2AH
> > > > > > > + - USB2AHP
> > > > > > > + - USB2AHPD0
> > > > > > > + - USB2AXH
> > > > > > > + - USB2AXH2B
> > > > > > > + - USB2AXHD1
> > > > > > > + - USB2AXHP
> > > > > > > + - USB2AXHP2B
> > > > > > > + - USB2AXHPD1
> > > > > > > + - USB2BD0
> > > > > > > + - USB2BD1
> > > > > > > + - USB2BH
> > > > > > > + - USB2BHP
> > > > > > > + - USB2BHPD0
> > > > > > > + - USB2BXH
> > > > > > > + - USB2BXH2A
> > > > > > > + - USB2BXHD1
> > > > > > > + - USB2BXHP
> > > > > > > + - USB2BXHP2A
> > > > > > > + - USB2BXHPD1
> > > > > > > + - USB3AXH
> > > > > > > + - USB3AXH2B
> > > > > > > + - USB3AXHD
> > > > > > > + - USB3AXHP
> > > > > > > + - USB3AXHP2B
> > > > > > > + - USB3AXHPD
> > > > > > > + - USB3BXH
> > > > > > > + - USB3BXH2A
> > > > > > > + - USB3BXHD
> > > > > > > + - USB3BXHP
> > > > > > > + - USB3BXHP2A
> > > > > > > + - USB3BXHPD
> > > > > > > + - VB
> > > > > > > + - VGADDC
> > > > > > > +
> > > > > > > + groups:
> > > > > > > + enum:
> > > > > > > + - EMMCCDN
> > > > > > > + - EMMCG1
> > > > > > > + - EMMCG4
> > > > > > > + - EMMCG8
> > > > > > > + - EMMCWPN
> > > > > > > + - JTAG0
> > > > > > > + - PCIERC0PERST
> > > > > > > + - PCIERC1PERST
> > > > > > > + - TSPRSTN
> > > > > > > + - UFSCLKI
> > > > > > > + - USB2A
> > > > > > > + - USB2AAP
> > > > > > > + - USB2ABP
> > > > > > > + - USB2ADAP
> > > > > > > + - USB2AH
> > > > > > > + - USB2AHAP
> > > > > > > + - USB2B
> > > > > > > + - USB2BAP
> > > > > > > + - USB2BBP
> > > > > > > + - USB2BDBP
> > > > > > > + - USB2BH
> > > > > > > + - USB2BHBP
> > > > > > > + - USB3A
> > > > > > > + - USB3AAP
> > > > > > > + - USB3ABP
> > > > > > > + - USB3B
> > > > > > > + - USB3BAP
> > > > > > > + - USB3BBP
> > > > > > > + - VB0
> > > > > > > + - VB1
> > > > > > > + - VGADDC
> > > > > > > + pins:
> > > > > > > + enum:
> > > > > > > + - AB13
> > > > > > > + - AB14
> > > > > > > + - AC13
> > > > > > > + - AC14
> > > > > > > + - AD13
> > > > > > > + - AD14
> > > > > > > + - AE13
> > > > > > > + - AE14
> > > > > > > + - AE15
> > > > > > > + - AF13
> > > > > > > + - AF14
> > > > > > > + - AF15
>
> > > > > > Why do you have groups and pins?
> > > > > > Is it valid in your device to have groups and pins in the same node?
>
> > > > > The intent is to support both group-based mux selection and
> > > > > configuration, as well as per-pin configuration.
>
> > > > > In our hardware:
> > > > > - `function` + `groups` are used for pinmux selection.
> > > > > - `pins` is used for per-pin configuration (e.g. drive strength,
> > > > > bias settings).
> > > > > - `groups` may also be used for group-level configuration.
>
> > > > > As a result, both `groups` and `pins` may appear in the same node,
> > > > > but they serve different purposes and do not conflict:
> > > > > - `groups` selects the mux function and may apply configuration to
> > > > > the entire group.
> > > > > - `pins` allows overriding or specifying configuration for individual
> > > > > pins.
>
> > > > > In most cases, only one of them is needed, but both are allowed when
> > > > > both group-level and per-pin configuration are required.
>
> > > > To be honest, that sounds like your groups are not sufficiently
> > > > granular and should be reduced such that you can use them for pin
> > > > settings.
>
> > > The intent was to keep the binding flexible, but in practice the mixed
> > > use of `groups` and `pins` in the same node is not expected to be used.
> > >
> > > Given that, I agree this flexibility is unnecessary and makes the
> > > binding semantics less clear. I'll rework the binding to make the
> > > expected usage explicit rather than allowing combinations that do not
> > > correspond to a real use case.
> > >
> > > In particular, I'll split the constraints as follows:
> > >
> > > - For pinmux, the presence of `function` will require `groups`, and
> > > `pins` will not be allowed. This reflects the hardware design, where
> > > the groups are defined by the pins affected by a given mux expression
> > >
> > > - For pin configuration, exactly one of `groups` or `pins` will be
> > > required (using oneOf), so that configuration is applied either at
> > > group level or per-pin, but not both.
> > >
> > >
> > > - if:
> > > required:
> > > - function
> > > then:
> > > required:
> > > - groups
> > > not:
> > > required:
> > > - pins
> > > else:
> > > oneOf:
> > > - required:
> > > - groups
> > > not:
> > > required:
> > > - pins
> > > - required:
> > > - pins
> > > not:
> > > required:
> > > - groups
> > > Does this match what you had in mind?
>
> > It's an improvement I think, but I am wondering why you cannot do
> > without pins entirely and apply pinconf stuff at the group level?
> > Of course that may not be possible with the current groups, but if you
> > made the groups more granular, would it be possible?
>
> Within a given group, it is not always the case that all pins share the
> same configuration requirements (e.g. drive strength or bias settings),
> so applying pinconf purely at the group level would be too restrictive.
Right. That's pretty normal.
> Making the groups more granular to match all possible configuration
> combinations would not reflect the actual mux granularity and would
> significantly increase the number of groups.
>
> For example, we have encountered a timing issue due to the PCB layout,
> where only the eMMC clock pin requires a different drive strength:
>
> # The EMMCG4 group includes pins AC14, AE15, AD14, AE14, AF14, AB13
> # AC14: clock
> # AE15: command
> # AD14–AB13: data
>
> pinconf_emmc_clk: emmc-clk-pinconf {
> pins = "AC14";
> drive-strength = <8>;
> };
>
> In this case, applying pin configuration at the group level would affect
> all pins in the group, which is not desirable. Allowing per-pin
> configuration via `pins` is therefore necessary.
>
> For this reason, `groups` is used for mux selection, while `pins` is
> required to express per-pin configuration where needed.
Right, yeah, I figured your objection to it was because of how
annoyingly small it would make the groups. I suppose the alternative is
going without groups and always using pins.
Having groups and pins seems really suboptimal to me, but there are
some other bindings where this is done. Linus, what is your take on
nodes supporting both? I'm biased towards having a more straightforward
binding but if you think this mix makes sense then I'll defer to your
vastly greater experience with these devices.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH/RFC 00/14] R-Car X5H Ironhide SCMI CPG/MDLC remapping
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
Hi all,
TL;DR:
Describe hardware in DT, and perform the mapping to SCMI in Linux.
The Renesas R-Car X5H-based Ironhide board is the first Renesas
SoC/board combination that implements the ARM System Control and
Management Interface (SCMI).
This means Linux can no longer perform various system operations (e.g.
clock, power domain, and reset control) by accessing the hardware
directly. Instead, these operations are abstracted according to various
SCMI sub-protocols, and Linux has to send messages to an SCMI-compliant
firmware running on a System Control Processor (SCP).
More specifically, the R-Car X5H SCP FW SCMI controls access to:
1. Core clocks and module clocks,
2. Module resets,
3. Power domains,
4. System power.
The latter is not relevant for this discussion.
Using SCMI also has an impact on the board DTS: besides the addition of
a firmware/scmi node with protocol-specific subnodes, devices using
SCMI-abstracted system resources now have to refer to these resources
using resource specifiers containing phandles to the SCMI protocol
subnodes, and firmware-specific object IDs[1].
Unfortunately we encountered several issues with this:
- The clock, reset, and power domain IDs are not stable, and may
change from one SCP firmware release to another, causing DTB
incompatibilities,
- There may be different SCP firmware lineages, e.g. proprietary and
certified variants, and FLOSS variants,
- SCMI features and quirks may differ across firmware versions,
- Not all quirks can be handled as SCMI quirks,
- Some core clocks do not support the CLOCK_ATTRIBUTES command, and
thus are not accessible to Linux, while Linux may need them,
requiring dummy clocks,
- Some module clocks are not accessible to Linux, or report a zero
clock rate and have no parent, while several existing drivers need
to know their clock rates,
- SCMI does not support the concept of a clock domain, so existing
drivers can no longer rely on Runtime PM, but need to be changed to
explicit management of functional clocks,
- Some clocks and power domains are critical and must not be disabled,
or even touched,
- Some module resets are reserved, and operating them returns an
error,
- U-Boot IPL (Initial Program Loader) needs a proper hardware
description in DT, not using SCMI.
During last OSSJ/LPC, Marek Vasut pondered if we could keep our own ID
lists stable, and perform a mapping to the IDs used by the actual SCMI
implementation running on the system. This was also briefly discussed
at LPC[2]. After some refining of the initial idea, this series takes a
slightly different approach, by:
1. Describing the actual hardware components in DT, plus a minimum
SCMI glue,
2. Mapping DT hardware descriptions to SCMI-backed objects (or
replacements in case they are unusable), in Linux drivers, based on
the detected firmware version.
This has the following advantages:
1. The DT ABI is stable,
2. Current and future firmware quirks can be handled in driver code,
3. If ever needed, the Clock Pulse Generator (CPG) and Module
Controller (MDLC) drivers can be extended to program the hardware
directly if SCMI is not present,
4. U-Boot IPL can use almost the same DTS; it just needs stripping of
SCMI-related nodes and properties.
This series is based on renesas-drivers-2026-04-14-v7.0, which includes
a.o. the scmi/for-linux-next branch. It consists of multiple parts:
1. Patches 1-3 add various quirks to the SCMI driver code,
2. Patch 4 enables more SCMI protocols on R-Car X5H Ironhide,
3. Patches 5-8 add new interfaces needed by the remapping drivers,
4. Patches 9-10 add DT bindings for the R-Car X5H Clock Pulse Generator
(CPG) and Module Controller (MDLC) blocks,
5. Patches 11-12 add remapping drivers for the R-Car X5H Clock Pulse
Generator (CPG) and Module Controller (MDLC) blocks,
6. Patches 13-14 add DTS description for R-Car X5H Ironhide.
Dependencies:
- Lifting "#define SCMI_MAX_NUM_RATES 16" (e.g. scmi/for-linux-next),
- "[PATCH v4 0/3] soc: renesas: add MFIS driver"[3],
- R-Car X5H MFIS and Ironhide SCMI DTS enablement (not yet posted).
For testing, I have pushed this series and its dependencies to the
topic/rcar-x5h-ironhide-scmi-cpg-mdlc-remapping-v1 branch of
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
With this, Ironhide can boot into a serial console shell from a ramdisk,
without needing any of "clk_ignore_unused" and "pd_ignore_unused".
FTR, alternative locations to do remapping that we considered:
- Inside the SCMI clock, reset, and power-domain drivers,
- Inside the subsystem driver core (e.g. of_parse_clkspec()),
- Inside the OF driver core,
- Inside the DTB.
Remapping inside DT is usually done through a nexus node (see Devicetree
Specification, Section 2.5 Nexus Nodes and Specifier Mapping), using
"<specifier>-map", "<specifier>-map-mask", and
"<specifier>-map-pass-thru" properties. Linux has support for e.g.
remapping interrupts (open-coded in drivers/of/irq.c), and gpios or pwms
(using the of_parse_phandle_with_args_map()) helper. So far there is no
support for remapping clocks or power domains, but at least for clocks
patches have been posted[4]. Then the remapping can be done by adding
e.g. "clocks-map{,-mask,-pass-thru}" properties with translation data
to the CPG/MDLC DT node, using a DT overlay. The DT overlay could be
applied by the firmware or bootloader (e.g. in in fitImage script), or
even by the CPG/MDLC Linux driver at runtime (based on detected SCP
firmware version). Consumer nodes do not need to be modified.
Note that such translations can only support simple cases. If e.g. a
workaround is needed to map a single DT clock to multiple SCMI clocks,
this cannot be done using a simple translation table.
While a DT overlay is quite flexible and can also do other fixup, it is
less user-friendly than doing the remapping in a Linux driver.
Thanks for your comments!
[1] Documentation/devicetree/bindings/firmware/arm,scmi.yaml
[2] "Firmware ABI stability" at Linux Plumbers Conference 2025
https://lpc.events/event/19/contributions/2153/
[3] "[PATCH v4 0/3] soc: renesas: add MFIS driver"
https://lore.kernel.org/20260402112709.13002-1-wsa+renesas@sang-engineering.com/
[4] "[PATCH] clk: Add support for clock nexus dt bindings"
https://lore.kernel.org/20260129201003.288605-1-miquel.raynal@bootlin.com/
Geert Uytterhoeven (14):
firmware: arm_scmi: quirk: Handle bad power domains on R-Car X5H
firmware: arm_scmi: quirk: Handle bad clocks on R-Car X5H
firmware: arm_scmi: quirk: Handle critical clocks on R-Car X5H
arm64: dts: renesas: ironhide: Enable SCMI devpd, sys, and reset
firmware: arm_scmi: Add scmi_get_base_info()
of: property: fw_devlink: Add support for firmware
pmdomain: Make genpd_get_from_provider() public
reset: Add reset_controller_get_provider()
dt-bindings: clock: Document Renesas R-Car X5H Clock Pulse Generator
dt-bindings: power: Document Renesas R-Car X5H Module Controller
clk: renesas: Add R-Car X5H CPG SCMI remapping driver
pmdomain: renesas: Add R-Car X5H MDLC SCMI remapping driver
arm64: dts: renesas: r8a78000: Add CPG/MDLC nodes
arm64: dts: renesas: ironhide: Add CPG/MDLC firmware properties
.../bindings/clock/renesas,r8a78000-cpg.yaml | 62 +
.../bindings/power/renesas,r8a78000-mdlc.yaml | 63 +
.../boot/dts/renesas/r8a78000-ironhide.dts | 130 +++
arch/arm64/boot/dts/renesas/r8a78000.dtsi | 300 ++++-
drivers/clk/renesas/Kconfig | 4 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r8a78000-cpg.c | 335 ++++++
drivers/firmware/arm_scmi/clock.c | 37 +
drivers/firmware/arm_scmi/driver.c | 31 +
drivers/firmware/arm_scmi/power.c | 20 +
drivers/firmware/arm_scmi/quirks.c | 12 +
drivers/firmware/arm_scmi/quirks.h | 4 +
drivers/of/property.c | 2 +
drivers/pmdomain/core.c | 4 +-
drivers/pmdomain/renesas/Kconfig | 4 +
drivers/pmdomain/renesas/Makefile | 1 +
drivers/pmdomain/renesas/r8a78000-mdlc.c | 1021 +++++++++++++++++
drivers/reset/core.c | 11 +
drivers/soc/renesas/Kconfig | 1 +
.../dt-bindings/clock/renesas,r8a78000-cpg.h | 15 +
.../dt-bindings/power/renesas,r8a78000-mdlc.h | 16 +
include/linux/pm_domain.h | 7 +
include/linux/reset-controller.h | 6 +
include/linux/scmi_protocol.h | 8 +
24 files changed, 2068 insertions(+), 27 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a78000-cpg.yaml
create mode 100644 Documentation/devicetree/bindings/power/renesas,r8a78000-mdlc.yaml
create mode 100644 drivers/clk/renesas/r8a78000-cpg.c
create mode 100644 drivers/pmdomain/renesas/r8a78000-mdlc.c
create mode 100644 include/dt-bindings/clock/renesas,r8a78000-cpg.h
create mode 100644 include/dt-bindings/power/renesas,r8a78000-mdlc.h
--
2.43.0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH/RFC 01/14] firmware: arm_scmi: quirk: Handle bad power domains on R-Car X5H
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Renesas R-Car X5H SCP FW SDKv4.28.0, v4.31.0, and v4.32.0 advertise a
few power domains that crash the system when touched or powered off.
Add a quirk to prevent such crashes.
As the SCMI power domain IDs are identical for all three versions, the
quirk can be shared.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Preventing power off could be handled in the MDLC driver, but no-touch
cannot.
---
drivers/firmware/arm_scmi/power.c | 20 ++++++++++++++++++++
drivers/firmware/arm_scmi/quirks.c | 3 +++
drivers/firmware/arm_scmi/quirks.h | 1 +
3 files changed, 24 insertions(+)
diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
index bb5062ab8280e02b..81b9035aa5a2eafe 100644
--- a/drivers/firmware/arm_scmi/power.c
+++ b/drivers/firmware/arm_scmi/power.c
@@ -12,6 +12,7 @@
#include "protocols.h"
#include "notify.h"
+#include "quirks.h"
/* Updated only after ALL the mandatory features for that version are merged */
#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x30001
@@ -150,6 +151,23 @@ scmi_power_domain_attributes_get(const struct scmi_protocol_handle *ph,
return ret;
}
+#define QUIRK_RCAR_X5H_4_28_BAD_DOMAINS \
+ ({ \
+ switch (domain) { \
+ /* Do not touch */ \
+ case 29: /* PD_RC08 */ \
+ case 92: /* PD_ACL0 */ \
+ case 116: /* PD_CMN */ \
+ return -EPERM; \
+ \
+ /* Do not power off */ \
+ case 76: /* PD_AC00 */ \
+ if (state == SCMI_POWER_STATE_GENERIC_OFF) \
+ return -EPERM; \
+ break; \
+ } \
+ })
+
static int scmi_power_state_set(const struct scmi_protocol_handle *ph,
u32 domain, u32 state)
{
@@ -157,6 +175,8 @@ static int scmi_power_state_set(const struct scmi_protocol_handle *ph,
struct scmi_xfer *t;
struct scmi_power_set_state *st;
+ SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, QUIRK_RCAR_X5H_4_28_BAD_DOMAINS);
+
ret = ph->xops->xfer_get_init(ph, POWER_STATE_SET, sizeof(*st), 0, &t);
if (ret)
return ret;
diff --git a/drivers/firmware/arm_scmi/quirks.c b/drivers/firmware/arm_scmi/quirks.c
index 2b38ba3f59a13c9e..c1a2f58505c1a757 100644
--- a/drivers/firmware/arm_scmi/quirks.c
+++ b/drivers/firmware/arm_scmi/quirks.c
@@ -172,6 +172,8 @@ struct scmi_quirk {
/* Global Quirks Definitions */
DEFINE_SCMI_QUIRK(clock_rates_triplet_out_of_spec, NULL, NULL, NULL);
DEFINE_SCMI_QUIRK(perf_level_get_fc_force, "Qualcomm", NULL, "0x20000-");
+DEFINE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, "Renesas", NULL,
+ "0x10a0000-0x10e0000", "renesas,r8a78000");
/*
* Quirks Pointers Array
@@ -182,6 +184,7 @@ DEFINE_SCMI_QUIRK(perf_level_get_fc_force, "Qualcomm", NULL, "0x20000-");
static struct scmi_quirk *scmi_quirks_table[] = {
__DECLARE_SCMI_QUIRK_ENTRY(clock_rates_triplet_out_of_spec),
__DECLARE_SCMI_QUIRK_ENTRY(perf_level_get_fc_force),
+ __DECLARE_SCMI_QUIRK_ENTRY(power_rcar_x5h_4_28_bad_domains),
NULL
};
diff --git a/drivers/firmware/arm_scmi/quirks.h b/drivers/firmware/arm_scmi/quirks.h
index d8ba60b956522d04..108c8d11f6043a61 100644
--- a/drivers/firmware/arm_scmi/quirks.h
+++ b/drivers/firmware/arm_scmi/quirks.h
@@ -48,5 +48,6 @@ static inline void scmi_quirks_enable(struct device *dev, const char *vend,
/* Quirk delarations */
DECLARE_SCMI_QUIRK(clock_rates_triplet_out_of_spec);
DECLARE_SCMI_QUIRK(perf_level_get_fc_force);
+DECLARE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains);
#endif /* _SCMI_QUIRKS_H */
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 02/14] firmware: arm_scmi: quirk: Handle bad clocks on R-Car X5H
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Renesas R-Car X5H SCP FW SDKv4.28.0, v4.31.0, and v4.32.0 expose a few
clocks that do not support the CLOCK_ATTRIBUTES or CLOCK_DESCRIBE_RATES
command. Since commit 0d8b0c8068a8ff5f ("firmware: arm_scmi: Harden
clock protocol initialization") in scmi/for-linux-next (next-20260319
and later), scmi_clock_attributes_get() or
scmi_clock_describe_rates_get() failures are no longer ignored, but
prevent the SCMI clock driver from initializing.
Hence add a quirk to ignore such failures, like before. As the quirk
handling is harmless for unaffected systems, make it generic for all
R-Car X5H systems using SCP FW SDKv4.28.0 or later.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/firmware/arm_scmi/clock.c | 14 ++++++++++++++
drivers/firmware/arm_scmi/quirks.c | 3 +++
drivers/firmware/arm_scmi/quirks.h | 1 +
3 files changed, 18 insertions(+)
diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index ce6f968925af38c0..d530882a0bac88c3 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -1232,6 +1232,18 @@ static const struct scmi_protocol_events clk_protocol_events = {
.num_events = ARRAY_SIZE(clk_events),
};
+#define QUIRK_RCAR_X5H_NO_ATTRIBUTES \
+ ({ \
+ if (ret == -EREMOTEIO || ret == -EOPNOTSUPP) \
+ continue; \
+ })
+
+#define QUIRK_RCAR_X5H_NO_RATES \
+ ({ \
+ if (ret == -EOPNOTSUPP) \
+ ret = 0; \
+ })
+
static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
{
int clkid, ret;
@@ -1256,10 +1268,12 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
for (clkid = 0; clkid < cinfo->num_clocks; clkid++) {
cinfo->clkds[clkid].id = clkid;
ret = scmi_clock_attributes_get(ph, clkid, cinfo);
+ SCMI_QUIRK(clock_rcar_x5h_no_attributes, QUIRK_RCAR_X5H_NO_ATTRIBUTES);
if (ret)
return ret;
ret = scmi_clock_describe_rates_get(ph, clkid, cinfo);
+ SCMI_QUIRK(clock_rcar_x5h_no_attributes, QUIRK_RCAR_X5H_NO_RATES);
if (ret)
return ret;
}
diff --git a/drivers/firmware/arm_scmi/quirks.c b/drivers/firmware/arm_scmi/quirks.c
index c1a2f58505c1a757..e27c21b14220ab5f 100644
--- a/drivers/firmware/arm_scmi/quirks.c
+++ b/drivers/firmware/arm_scmi/quirks.c
@@ -171,6 +171,8 @@ struct scmi_quirk {
/* Global Quirks Definitions */
DEFINE_SCMI_QUIRK(clock_rates_triplet_out_of_spec, NULL, NULL, NULL);
+DEFINE_SCMI_QUIRK(clock_rcar_x5h_no_attributes, "Renesas", NULL, "0x10a0000-",
+ "renesas,r8a78000");
DEFINE_SCMI_QUIRK(perf_level_get_fc_force, "Qualcomm", NULL, "0x20000-");
DEFINE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, "Renesas", NULL,
"0x10a0000-0x10e0000", "renesas,r8a78000");
@@ -183,6 +185,7 @@ DEFINE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, "Renesas", NULL,
*/
static struct scmi_quirk *scmi_quirks_table[] = {
__DECLARE_SCMI_QUIRK_ENTRY(clock_rates_triplet_out_of_spec),
+ __DECLARE_SCMI_QUIRK_ENTRY(clock_rcar_x5h_no_attributes),
__DECLARE_SCMI_QUIRK_ENTRY(perf_level_get_fc_force),
__DECLARE_SCMI_QUIRK_ENTRY(power_rcar_x5h_4_28_bad_domains),
NULL
diff --git a/drivers/firmware/arm_scmi/quirks.h b/drivers/firmware/arm_scmi/quirks.h
index 108c8d11f6043a61..67818b6cf0909f8e 100644
--- a/drivers/firmware/arm_scmi/quirks.h
+++ b/drivers/firmware/arm_scmi/quirks.h
@@ -47,6 +47,7 @@ static inline void scmi_quirks_enable(struct device *dev, const char *vend,
/* Quirk delarations */
DECLARE_SCMI_QUIRK(clock_rates_triplet_out_of_spec);
+DECLARE_SCMI_QUIRK(clock_rcar_x5h_no_attributes);
DECLARE_SCMI_QUIRK(perf_level_get_fc_force);
DECLARE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains);
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 03/14] firmware: arm_scmi: quirk: Handle critical clocks on R-Car X5H
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Renesas R-Car X5H SCP FW SDKv4.28.0, v4.31.0, and v4.32.0 advertise a
few clocks that crash the system when disabled. Add quirks to prevent
such crashes.
As SCMI clock IDs are identical for SDKv4.31.0 and v4.32.0, the quirk
for these two versions can be shared.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Some of these could be handled by improving hardware descriptions in DT,
or by the CPG and MDLC drivers.
---
drivers/firmware/arm_scmi/clock.c | 23 +++++++++++++++++++++++
drivers/firmware/arm_scmi/quirks.c | 6 ++++++
drivers/firmware/arm_scmi/quirks.h | 2 ++
3 files changed, 31 insertions(+)
diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index d530882a0bac88c3..4fec8c3216df7a51 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -920,6 +920,26 @@ scmi_clock_config_set_v2(const struct scmi_protocol_handle *ph, u32 clk_id,
return ret;
}
+#define QUIRK_RCAR_X5H_4_28_CRIT_CLOCKS \
+ ({ \
+ switch (clk_id) { \
+ case 468: /* MDLC_INTAP0 */ \
+ case 498: /* MDLC_APRTMGINT0 */ \
+ case 840: /* CLK_ZD_APU0 */ \
+ return -EPERM; \
+ } \
+ })
+
+#define QUIRK_RCAR_X5H_4_31_CRIT_CLOCKS \
+ ({ \
+ switch (clk_id) { \
+ case 464: /* MDLC_INTAP0 */ \
+ case 494: /* MDLC_APRTMGINT0 */ \
+ case 836: /* CLK_ZD_APU0 */ \
+ return -EPERM; \
+ } \
+ })
+
static int scmi_clock_enable(const struct scmi_protocol_handle *ph, u32 clk_id,
bool atomic)
{
@@ -950,6 +970,9 @@ static int scmi_clock_disable(const struct scmi_protocol_handle *ph, u32 clk_id,
if (clk->state_ctrl_forbidden)
return -EACCES;
+ SCMI_QUIRK(clock_rcar_x5h_4_28_crit_clocks, QUIRK_RCAR_X5H_4_28_CRIT_CLOCKS);
+ SCMI_QUIRK(clock_rcar_x5h_4_31_crit_clocks, QUIRK_RCAR_X5H_4_31_CRIT_CLOCKS);
+
return ci->clock_config_set(ph, clk_id, CLK_STATE_DISABLE,
NULL_OEM_TYPE, 0, atomic);
}
diff --git a/drivers/firmware/arm_scmi/quirks.c b/drivers/firmware/arm_scmi/quirks.c
index e27c21b14220ab5f..4ca6d06f85ebc7b2 100644
--- a/drivers/firmware/arm_scmi/quirks.c
+++ b/drivers/firmware/arm_scmi/quirks.c
@@ -173,6 +173,10 @@ struct scmi_quirk {
DEFINE_SCMI_QUIRK(clock_rates_triplet_out_of_spec, NULL, NULL, NULL);
DEFINE_SCMI_QUIRK(clock_rcar_x5h_no_attributes, "Renesas", NULL, "0x10a0000-",
"renesas,r8a78000");
+DEFINE_SCMI_QUIRK(clock_rcar_x5h_4_28_crit_clocks, "Renesas", NULL, "0x10a0000",
+ "renesas,r8a78000");
+DEFINE_SCMI_QUIRK(clock_rcar_x5h_4_31_crit_clocks, "Renesas", NULL,
+ "0x10d0000-0x10e0000", "renesas,r8a78000");
DEFINE_SCMI_QUIRK(perf_level_get_fc_force, "Qualcomm", NULL, "0x20000-");
DEFINE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, "Renesas", NULL,
"0x10a0000-0x10e0000", "renesas,r8a78000");
@@ -186,6 +190,8 @@ DEFINE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, "Renesas", NULL,
static struct scmi_quirk *scmi_quirks_table[] = {
__DECLARE_SCMI_QUIRK_ENTRY(clock_rates_triplet_out_of_spec),
__DECLARE_SCMI_QUIRK_ENTRY(clock_rcar_x5h_no_attributes),
+ __DECLARE_SCMI_QUIRK_ENTRY(clock_rcar_x5h_4_28_crit_clocks),
+ __DECLARE_SCMI_QUIRK_ENTRY(clock_rcar_x5h_4_31_crit_clocks),
__DECLARE_SCMI_QUIRK_ENTRY(perf_level_get_fc_force),
__DECLARE_SCMI_QUIRK_ENTRY(power_rcar_x5h_4_28_bad_domains),
NULL
diff --git a/drivers/firmware/arm_scmi/quirks.h b/drivers/firmware/arm_scmi/quirks.h
index 67818b6cf0909f8e..56adb5fa87de0127 100644
--- a/drivers/firmware/arm_scmi/quirks.h
+++ b/drivers/firmware/arm_scmi/quirks.h
@@ -48,6 +48,8 @@ static inline void scmi_quirks_enable(struct device *dev, const char *vend,
/* Quirk delarations */
DECLARE_SCMI_QUIRK(clock_rates_triplet_out_of_spec);
DECLARE_SCMI_QUIRK(clock_rcar_x5h_no_attributes);
+DECLARE_SCMI_QUIRK(clock_rcar_x5h_4_28_crit_clocks);
+DECLARE_SCMI_QUIRK(clock_rcar_x5h_4_31_crit_clocks);
DECLARE_SCMI_QUIRK(perf_level_get_fc_force);
DECLARE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains);
--
2.43.0
^ permalink raw reply related
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