* [PATCH v2 1/3] MAINTAINERS: Move Peter De Schrijver to CREDITS
From: Thierry Reding @ 2026-04-17 13:15 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, linux-kernel,
Paul Walmsley
From: Thierry Reding <treding@nvidia.com>
Peter sadly passed away a while back. Paul did a much better job at
finding the right words to mourn this loss than I ever could, so I will
leave this link here:
https://lore.kernel.org/lkml/alpine.DEB.2.21.999.2407240345480.11116@utopia.booyaka.com/T/#u
Co-developed-by: Paul Walmsley <pjw@kernel.org>
Co-developed-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Co-developed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v2:
- add more missing entries
CREDITS | 10 ++++++++++
MAINTAINERS | 1 -
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/CREDITS b/CREDITS
index 885fb05d8816..afd1f70b41cf 100644
--- a/CREDITS
+++ b/CREDITS
@@ -3645,7 +3645,17 @@ D: Macintosh IDE Driver
N: Peter De Schrijver
E: stud11@cc4.kuleuven.ac.be
+E: p2@mind.be
+E: peter.de-schrijver@nokia.com
+E: pdeschrijver@nvidia.com
+E: p2@psychaos.be
+D: Apollo Domain workstations
+D: Ariadne and Hydra Amiga Ethernet drivers
+D: IBM PS/2, Microchannel, and Token Ring support
D: Mitsumi CD-ROM driver patches March version
+D: TWL4030 power management and audio codec driver
+D: OMAP power management
+D: NVIDIA Tegra clock and BPMP drivers, among many other things
S: Molenbaan 29
S: B2240 Zandhoven
S: Belgium
diff --git a/MAINTAINERS b/MAINTAINERS
index ef978bfca514..ffe20d770249 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26145,7 +26145,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git
N: [^a-z]tegra
TEGRA CLOCK DRIVER
-M: Peter De Schrijver <pdeschrijver@nvidia.com>
M: Prashant Gaikwad <pgaikwad@nvidia.com>
S: Supported
F: drivers/clk/tegra/
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v6 01/30] mm: Introduce kpkeys
From: Kevin Brodsky @ 2026-04-17 13:10 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-hardening
Cc: linux-kernel, Andrew Morton, Andy Lutomirski, Catalin Marinas,
Dave Hansen, Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Lorenzo Stoakes, Marc Zyngier, Mark Brown,
Matthew Wilcox, Maxwell Bland, Mike Rapoport (IBM),
Peter Zijlstra, Pierre Langlois, Quentin Perret, Rick Edgecombe,
Ryan Roberts, Thomas Gleixner, Vlastimil Babka, Will Deacon,
Yang Shi, Yeoreum Yun, linux-arm-kernel, linux-mm, x86
In-Reply-To: <cf9da9e0-310b-4dc0-81aa-3154077fff85@kernel.org>
On 17/04/2026 14:00, David Hildenbrand (Arm) wrote:
> On 4/15/26 17:50, Kevin Brodsky wrote:
>> On 15/04/2026 15:00, David Hildenbrand (Arm) wrote:
>>> On 2/27/26 18:54, Kevin Brodsky wrote:
>>>> kpkeys is a simple framework to enable the use of protection keys
>>>> (pkeys) to harden the kernel itself. This patch introduces the basic
>>>> API in <linux/kpkeys.h>: a couple of functions to set and restore
>>>> the pkey register and macros to define guard objects.
>>>>
>>>> kpkeys introduces a new concept on top of pkeys: the kpkeys level.
>>>> Each level is associated to a set of permissions for the pkeys
>>>> managed by the kpkeys framework. kpkeys_set_level(lvl) sets those
>>>> permissions according to lvl, and returns the original pkey
>>>> register, to be later restored by kpkeys_restore_pkey_reg(). To
>>>> start with, only KPKEYS_LVL_DEFAULT is available, which is meant
>>>> to grant RW access to KPKEYS_PKEY_DEFAULT (i.e. all memory since
>>>> this is the only available pkey for now).
>>>>
>>>> Because each architecture implementing pkeys uses a different
>>>> representation for the pkey register, and may reserve certain pkeys
>>>> for specific uses, support for kpkeys must be explicitly indicated
>>>> by selecting ARCH_HAS_KPKEYS and defining the following functions in
>>>> <asm/kpkeys.h>, in addition to the macros provided in
>>>> <asm-generic/kpkeys.h>:
>>> I don't quite understand the reason for using levels. Levels sounds like
>>> it would all be in some ordered fashion, where higher levels have access
>>> to lower levels.
>> That was originally the idea indeed, but in practice I don't expect
>> levels to have a strict ordering, as it's not practical for composing
>> features.
>>
>>> Think of that as a key that can unlock all "lower" locks, not just a
>>> single lock.
>>>
>>> Then, the question is about the ordering once we introduce new
>>> keys/locks. With two, it obviously doesn't matter :)
>>>
>>> So naturally I wonder whether levels is really the right abstraction
>>> here, and why we are not simply using "distinct" keys, like
>>>
>>> KPKEY_DEFAULT
>>> KPKEY_PGTABLE
>>> KPKEY_SUPER_SECRET1
>>> KPKEY_SUPER_SECRET2
>>>
>>> Is it because you want KPKEY_PGTABLE also be able to write to KPKEY_DEFAULT?
>> Right, and in general a given level may be able to write to any number
>> of pkeys. That's why I don't want to conflate pkeys and levels. Agreed
>> that "level" might not be the clearest term though, since there's no
>> strict ordering.
> As discussed offline, maybe the right terminology to use here would be
> something like a "context".
>
> You'd be activating/setting a context.
>
> KPKEY_CTX_DEFAULT
> KPKEY_CTX_PGTABLE
> KPKEY_CTX_SUPER_SECRET1
Sounds good to me, that's more accurate than "level" if it is possible
to give access to arbitrary pkeys to each context, which is the current
assumption.
> What is accessible (and how) is defined for each context. For example, I
> would assume that all context allow for read/write access to everything
> that KPKEY_CTX_DEFAULT has access to.
Most contexts would, although as I mentioned in the previous email,
unprivileged contexts such as eBPF programs may be further restricted.
- Kevin
^ permalink raw reply
* Re: [PATCH v2 0/7] thermal: samsung: Add support for Google GS101 TMU
From: Tudor Ambarus @ 2026-04-17 13:06 UTC (permalink / raw)
To: Alexey Klimov, daniel.lezcano
Cc: Rafael J. Wysocki, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Alim Akhtar, Bartlomiej Zolnierkiewicz, Kees Cook,
Gustavo A. R. Silva, Peter Griffin, André Draszik,
willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening
In-Reply-To: <63087cad-a8d1-4ff0-870a-6e1a738ff8b8@linaro.org>
On 4/9/26 3:22 PM, Tudor Ambarus wrote:
> No, it's more than that. When I talked with Daniel about this driver, he
> suggested I shall really focus on using the .set_trips callback instead of
> .set_trip_temp. I'm not sure if it's possible given the static nature of
> the ACPM interface. So it needs a bit of investigation, which I couldn't
> do lately.
FYI, I switched to .set_trips and testing went fine. I'll recheck the
review feedback and resubmit.
Cheers,
ta
^ permalink raw reply
* [PATCH 4/4] KVM: arm64: vgic-v2: Don't init the vgic on in-kernel interrupt injection
From: Marc Zyngier @ 2026-04-17 12:46 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Deepanshu Kartikey, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260417124612.2770268-1-maz@kernel.org>
We how have the lazy init on three paths:
- on first run of a vcpu
- on first injection of an interrupt from userspace
- on first injection of an interrupt from kernel space
Given that we recompute the state of each in-kernel interrupt
every time we are about to enter the guest, we can drop the lazy
init from the kernel injection path.
This solves a bunch of issues related to vgic_lazy_init() being called
in non-preemptible context.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/vgic/vgic.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 1e9fe8764584d..9e29f03d3463c 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -534,11 +534,9 @@ int kvm_vgic_inject_irq(struct kvm *kvm, struct kvm_vcpu *vcpu,
{
struct vgic_irq *irq;
unsigned long flags;
- int ret;
- ret = vgic_lazy_init(kvm);
- if (ret)
- return ret;
+ if (unlikely(!vgic_initialized(kvm)))
+ return 0;
if (!vcpu && irq_is_private(kvm, intid))
return -EINVAL;
--
2.47.3
^ permalink raw reply related
* [PATCH 3/4] KVM: arm64: vgic-v2: Force vgic init on injection from userspace
From: Marc Zyngier @ 2026-04-17 12:46 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Deepanshu Kartikey, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260417124612.2770268-1-maz@kernel.org>
Make sure that any attempt to inject an interrupt from userspace
results in the GICv2 lazy init to take place. This is not currently
necessary as the init is also performed on *any* interrupt injection.
But as we're about to remove that, let's introduce it here.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/arm.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 176cbe8baad30..e856cf4099f42 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -51,6 +51,7 @@
#include <linux/irqchip/arm-gic-v5.h>
+#include "vgic/vgic.h"
#include "sys_regs.h"
static enum kvm_mode kvm_mode = KVM_MODE_DEFAULT;
@@ -1475,6 +1476,12 @@ int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_level,
trace_kvm_irq_line(irq_type, vcpu_id, irq_num, irq_level->level);
+ if (irqchip_in_kernel(kvm)) {
+ int ret = vgic_lazy_init(kvm);
+ if (ret)
+ return ret;
+ }
+
switch (irq_type) {
case KVM_ARM_IRQ_TYPE_CPU:
if (irqchip_in_kernel(kvm))
--
2.47.3
^ permalink raw reply related
* [PATCH 1/4] KVM: arm64: timer: Repaint kvm_timer_should_fire() to kvm_timer_pending()
From: Marc Zyngier @ 2026-04-17 12:46 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Deepanshu Kartikey, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260417124612.2770268-1-maz@kernel.org>
kvm_timer_should_fire() seems to date back to a time where the author
of the timer code didn't seem to have made the word "pending" part of
their vocabulary.
Having since slightly improved on that front, let's rename this predicate
to kvm_timer_pending(), which clearly indicates whether the timer
interrupt is pending or not.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/arch_timer.c | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index cbea4d9ee9552..d6802fc87e085 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -42,7 +42,7 @@ static const u8 default_ppi[] = {
static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx);
static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
struct arch_timer_context *timer_ctx);
-static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx);
+static bool kvm_timer_pending(struct arch_timer_context *timer_ctx);
static void kvm_arm_timer_write(struct kvm_vcpu *vcpu,
struct arch_timer_context *timer,
enum kvm_arch_timer_regs treg,
@@ -224,7 +224,7 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
else
ctx = map.direct_ptimer;
- if (kvm_timer_should_fire(ctx))
+ if (kvm_timer_pending(ctx))
kvm_timer_update_irq(vcpu, true, ctx);
if (userspace_irqchip(vcpu->kvm) &&
@@ -358,7 +358,7 @@ static enum hrtimer_restart kvm_hrtimer_expire(struct hrtimer *hrt)
return HRTIMER_NORESTART;
}
-static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx)
+static bool kvm_timer_pending(struct arch_timer_context *timer_ctx)
{
enum kvm_arch_timers index;
u64 cval, now;
@@ -417,9 +417,9 @@ void kvm_timer_update_run(struct kvm_vcpu *vcpu)
/* Populate the device bitmap with the timer states */
regs->device_irq_level &= ~(KVM_ARM_DEV_EL1_VTIMER |
KVM_ARM_DEV_EL1_PTIMER);
- if (kvm_timer_should_fire(vtimer))
+ if (kvm_timer_pending(vtimer))
regs->device_irq_level |= KVM_ARM_DEV_EL1_VTIMER;
- if (kvm_timer_should_fire(ptimer))
+ if (kvm_timer_pending(ptimer))
regs->device_irq_level |= KVM_ARM_DEV_EL1_PTIMER;
}
@@ -473,21 +473,21 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
/* Only called for a fully emulated timer */
static void timer_emulate(struct arch_timer_context *ctx)
{
- bool should_fire = kvm_timer_should_fire(ctx);
+ bool pending = kvm_timer_pending(ctx);
- trace_kvm_timer_emulate(ctx, should_fire);
+ trace_kvm_timer_emulate(ctx, pending);
- if (should_fire != ctx->irq.level)
- kvm_timer_update_irq(timer_context_to_vcpu(ctx), should_fire, ctx);
+ if (pending != ctx->irq.level)
+ kvm_timer_update_irq(timer_context_to_vcpu(ctx), pending, ctx);
- kvm_timer_update_status(ctx, should_fire);
+ kvm_timer_update_status(ctx, pending);
/*
* If the timer can fire now, we don't need to have a soft timer
* scheduled for the future. If the timer cannot fire at all,
* then we also don't need a soft timer.
*/
- if (should_fire || !kvm_timer_irq_can_fire(ctx))
+ if (pending || !kvm_timer_irq_can_fire(ctx))
return;
soft_timer_start(&ctx->hrtimer, kvm_timer_compute_delta(ctx));
@@ -685,7 +685,7 @@ static void kvm_timer_vcpu_load_gic(struct arch_timer_context *ctx)
* this point and the register restoration, we'll take the
* interrupt anyway.
*/
- kvm_timer_update_irq(vcpu, kvm_timer_should_fire(ctx), ctx);
+ kvm_timer_update_irq(vcpu, kvm_timer_pending(ctx), ctx);
if (irqchip_in_kernel(vcpu->kvm))
phys_active = kvm_vgic_map_is_active(vcpu, timer_irq(ctx));
@@ -706,7 +706,7 @@ static void kvm_timer_vcpu_load_nogic(struct kvm_vcpu *vcpu)
* this point and the register restoration, we'll take the
* interrupt anyway.
*/
- kvm_timer_update_irq(vcpu, kvm_timer_should_fire(vtimer), vtimer);
+ kvm_timer_update_irq(vcpu, kvm_timer_pending(vtimer), vtimer);
/*
* When using a userspace irqchip with the architected timers and a
@@ -917,8 +917,8 @@ bool kvm_timer_should_notify_user(struct kvm_vcpu *vcpu)
vlevel = sregs->device_irq_level & KVM_ARM_DEV_EL1_VTIMER;
plevel = sregs->device_irq_level & KVM_ARM_DEV_EL1_PTIMER;
- return kvm_timer_should_fire(vtimer) != vlevel ||
- kvm_timer_should_fire(ptimer) != plevel;
+ return kvm_timer_pending(vtimer) != vlevel ||
+ kvm_timer_pending(ptimer) != plevel;
}
void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu)
@@ -1006,7 +1006,7 @@ static void unmask_vtimer_irq_user(struct kvm_vcpu *vcpu)
{
struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
- if (!kvm_timer_should_fire(vtimer)) {
+ if (!kvm_timer_pending(vtimer)) {
kvm_timer_update_irq(vcpu, false, vtimer);
if (static_branch_likely(&has_gic_active_state))
set_timer_irq_phys_active(vtimer, false);
@@ -1579,7 +1579,7 @@ static bool kvm_arch_timer_get_input_level(int vintid)
ctx = vcpu_get_timer(vcpu, i);
if (timer_irq(ctx) == vintid)
- return kvm_timer_should_fire(ctx);
+ return kvm_timer_pending(ctx);
}
/* A timer IRQ has fired, but no matching timer was found? */
--
2.47.3
^ permalink raw reply related
* [PATCH 0/4] KVM: arm64: Don't perform vgic-v2 lazy init on timer injection
From: Marc Zyngier @ 2026-04-17 12:46 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Deepanshu Kartikey, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
Syzkaller reported an interesting case [1] showing vgic-v2 being
initialised via the lazy init path on injection from the timer reset
path. Yes, that's convoluted. This resulted in a splat as we could
end-up scheduling in an atomic context.
Deepanshu proposed [2] a simple fix that unconditionally init'd the
GIC on vcpu reset. While this would do the trick, this is only
papering over the real issue.
The situation is that we currently have three ways to lazily init the
vgic:
- on first run of any vcpu
- on access from userspace injecting an interrupt
- on access from the kernel injecting an interrupt
The splat is caused by this last one, and it is interesting to drill
into why we end-up with it.
All guest interrupts generated by the kernel itself are level. Which
means that they cannot be lost unless the generating device is being
interacted with. So there shouldn't be any need to initialise the vgic
for that reason, and we could defer it to the first run of a vcpu.
However, the timers are extra special. Each one has its own little
single bit cache that contains the last level set. And as long as the
level doesn't change, the timer code doesn't call into the interrupt
injection code, making it totally optimal.
A side effect of this optimisation is that the level interrupt
effectively becomes an edge (only the changes are reported). Which
means that the interrupt must be recorded in the vgic, or it be
forever lost. Hence the need to eagerly initialise the GIC at
injection time.
But frankly, there isn't much to gain by having this cache. All we
avoid is a lookup, an uncontended lock, and an early return. The other
interrupts generated by the kernel (PMU, vgic MI) don't have such
cache, and nobody has complained yet.
So let's drop this cache, and remove the vgic init from the kernel
injection. If someone shouts about a loss of performance, then let's
improve the interrupt injection itself, and not paper over it. Also
use this opportunity to repaint kvm_timer_should_fire() as
kvm_timer_pending(), something that is way less ambiguous.
Patches on top of kvmarm-7.1. The reproducer didn't trigger on my
boxes, and syzkaller is down at the moment. But nothing bad happened
in my testing...
[1] https://syzkaller.appspot.com/bug?extid=12b178b7c756664d2518
[2] https://lore.kernel.org/r/20260412080437.38782-1-kartikey406@gmail.com
Marc Zyngier (4):
KVM: arm64: timer: Repaint kvm_timer_should_fire() to
kvm_timer_pending()
KVM: arm64: timer: Kill the per-timer level cache
KVM: arm64: vgic-v2: Force vgic init on injection from userspace
KVM: arm64: vgic-v2: Don't init the vgic on in-kernel interrupt
injection
arch/arm64/kvm/arch_timer.c | 44 ++++++++++++++++++------------------
arch/arm64/kvm/arm.c | 7 ++++++
arch/arm64/kvm/vgic/vgic.c | 6 ++---
include/kvm/arm_arch_timer.h | 5 ----
4 files changed, 31 insertions(+), 31 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH 2/4] KVM: arm64: timer: Kill the per-timer level cache
From: Marc Zyngier @ 2026-04-17 12:46 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Deepanshu Kartikey, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260417124612.2770268-1-maz@kernel.org>
The timer code makes use of a per-timer irq level cache, which
looks like a very minor optimisation to avoid taking a lock upon
updating the GIC view of the interrupt when it is unchanged from
the previous state.
This is coming in the way of more important correctness issues,
so get rid of the cache, which simplifies a couple of minor things.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/arch_timer.c | 18 +++++++++---------
include/kvm/arm_arch_timer.h | 5 -----
2 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index d6802fc87e085..fdc1afff06340 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -446,9 +446,8 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
{
kvm_timer_update_status(timer_ctx, new_level);
- timer_ctx->irq.level = new_level;
trace_kvm_timer_update_irq(vcpu->vcpu_id, timer_irq(timer_ctx),
- timer_ctx->irq.level);
+ new_level);
if (userspace_irqchip(vcpu->kvm))
return;
@@ -466,7 +465,7 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
kvm_vgic_inject_irq(vcpu->kvm, vcpu,
timer_irq(timer_ctx),
- timer_ctx->irq.level,
+ new_level,
timer_ctx);
}
@@ -477,8 +476,7 @@ static void timer_emulate(struct arch_timer_context *ctx)
trace_kvm_timer_emulate(ctx, pending);
- if (pending != ctx->irq.level)
- kvm_timer_update_irq(timer_context_to_vcpu(ctx), pending, ctx);
+ kvm_timer_update_irq(timer_context_to_vcpu(ctx), pending, ctx);
kvm_timer_update_status(ctx, pending);
@@ -677,6 +675,7 @@ static inline void set_timer_irq_phys_active(struct arch_timer_context *ctx, boo
static void kvm_timer_vcpu_load_gic(struct arch_timer_context *ctx)
{
struct kvm_vcpu *vcpu = timer_context_to_vcpu(ctx);
+ bool pending = kvm_timer_pending(ctx);
bool phys_active = false;
/*
@@ -685,12 +684,12 @@ static void kvm_timer_vcpu_load_gic(struct arch_timer_context *ctx)
* this point and the register restoration, we'll take the
* interrupt anyway.
*/
- kvm_timer_update_irq(vcpu, kvm_timer_pending(ctx), ctx);
+ kvm_timer_update_irq(vcpu, pending, ctx);
if (irqchip_in_kernel(vcpu->kvm))
phys_active = kvm_vgic_map_is_active(vcpu, timer_irq(ctx));
- phys_active |= ctx->irq.level;
+ phys_active |= pending;
phys_active |= vgic_is_v5(vcpu->kvm);
set_timer_irq_phys_active(ctx, phys_active);
@@ -699,6 +698,7 @@ static void kvm_timer_vcpu_load_gic(struct arch_timer_context *ctx)
static void kvm_timer_vcpu_load_nogic(struct kvm_vcpu *vcpu)
{
struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
+ bool pending = kvm_timer_pending(vtimer);
/*
* Update the timer output so that it is likely to match the
@@ -706,7 +706,7 @@ static void kvm_timer_vcpu_load_nogic(struct kvm_vcpu *vcpu)
* this point and the register restoration, we'll take the
* interrupt anyway.
*/
- kvm_timer_update_irq(vcpu, kvm_timer_pending(vtimer), vtimer);
+ kvm_timer_update_irq(vcpu, pending, vtimer);
/*
* When using a userspace irqchip with the architected timers and a
@@ -718,7 +718,7 @@ static void kvm_timer_vcpu_load_nogic(struct kvm_vcpu *vcpu)
* being de-asserted, we unmask the interrupt again so that we exit
* from the guest when the timer fires.
*/
- if (vtimer->irq.level)
+ if (pending)
disable_percpu_irq(host_vtimer_irq);
else
enable_percpu_irq(host_vtimer_irq, host_vtimer_irq_flags);
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index bf8cc9589bd09..2c26d457c3510 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -66,11 +66,6 @@ struct arch_timer_context {
*/
bool loaded;
- /* Output level of the timer IRQ */
- struct {
- bool level;
- } irq;
-
/* Who am I? */
enum kvm_arch_timers timer_id;
--
2.47.3
^ permalink raw reply related
* [PATCH v2] drm/mediatek: hdmi: Convert DRM_ERROR() to drm_err()
From: sai madhu @ 2026-04-17 12:27 UTC (permalink / raw)
To: Chun-Kuang Hu
Cc: Philipp Zabel, dri-devel, linux-mediatek, linux-kernel,
linux-arm-kernel, sai madhu
The DRM_ERROR() macro is deprecated in favor of drm_err() which
provides device-specific logging.
Replace DRM_ERROR() with drm_err() in the Mediatek HDMI bridge
driver and pass the drm_device pointer via bridge->dev.
No functional change intended.
Signed-off-by: sai madhu <suryasaimadhu369@gmail.com>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 1ea259854780..4ddcdbf7bc8c 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -981,8 +981,8 @@ static int mtk_hdmi_bridge_attach(struct drm_bridge *bridge,
int ret;
if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
- DRM_ERROR("%s: The flag DRM_BRIDGE_ATTACH_NO_CONNECTOR must be supplied\n",
- __func__);
+ drm_err(bridge->dev,
+ "DRM_BRIDGE_ATTACH_NO_CONNECTOR must be supplied\n");
return -EINVAL;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 6/6] usb: typec: ucsi: huawei-gaokun: pass down HPD_IRQ events
From: Pengyu Luo @ 2026-04-17 12:17 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Nikita Travkin, Yongxing Mou,
dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno
In-Reply-To: <20260416-hpd-irq-events-v1-6-1ab1f1cfb2b2@oss.qualcomm.com>
On Thu, Apr 16, 2026 at 7:22 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> Pass IRQ_HPD events to the HPD bridge, letting those to be delivered to
> the DisplayPort driver.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Pengyu Luo <mitltlatltl@gmail.com>
Best wishes,
Pengyu
^ permalink raw reply
* Re: [PATCH net] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Daniel Golle @ 2026-04-17 12:08 UTC (permalink / raw)
To: Chester A. Unal
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, Christian Marangi,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek,
Frank Wunderlich, John Crispin
In-Reply-To: <C88911FE-2012-4D29-B7F2-6BEA28122854@arinc9.com>
On Fri, Apr 17, 2026 at 07:35:46AM +0000, Chester A. Unal wrote:
> On 17 April 2026 04:55:57 WEST, Daniel Golle <daniel@makrotopia.org> wrote:
> >The .get_stats64 callback runs in atomic context, but on
> >MDIO-connected switches every register read acquires the MDIO bus
> >mutex, which can sleep:
> >[ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609
> >[ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep
> >[ 12.663377] preempt_count: 0, expected: 0
> >[ 12.667410] RCU nest depth: 1, expected: 0
> >[ 12.671511] INFO: lockdep is turned off.
> >[ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT
> >[ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
> >[ 12.675456] Hardware name: Bananapi BPI-R64 (DT)
> >[ 12.675459] Call trace:
> >[ 12.675462] show_stack+0x14/0x1c (C)
> >[ 12.675477] dump_stack_lvl+0x68/0x8c
> >[ 12.675487] dump_stack+0x14/0x1c
> >[ 12.675495] __might_resched+0x14c/0x220
> >[ 12.675504] __might_sleep+0x44/0x80
> >[ 12.675511] __mutex_lock+0x50/0xb10
> >[ 12.675523] mutex_lock_nested+0x20/0x30
> >[ 12.675532] mt7530_get_stats64+0x40/0x2ac
> >[ 12.675542] dsa_user_get_stats64+0x2c/0x40
> >[ 12.675553] dev_get_stats+0x44/0x1e0
> >[ 12.675564] dev_seq_printf_stats+0x24/0xe0
> >[ 12.675575] dev_seq_show+0x14/0x3c
> >[ 12.675583] seq_read_iter+0x37c/0x480
> >[ 12.675595] seq_read+0xd0/0xec
> >[ 12.675605] proc_reg_read+0x94/0xe4
> >[ 12.675615] vfs_read+0x98/0x29c
> >[ 12.675625] ksys_read+0x54/0xdc
> >[ 12.675633] __arm64_sys_read+0x18/0x20
> >[ 12.675642] invoke_syscall.constprop.0+0x54/0xec
> >[ 12.675653] do_el0_svc+0x3c/0xb4
> >[ 12.675662] el0_svc+0x38/0x200
> >[ 12.675670] el0t_64_sync_handler+0x98/0xdc
> >[ 12.675679] el0t_64_sync+0x158/0x15c
> >
> >For MDIO-connected switches, poll MIB counters asynchronously using a
> >delayed workqueue every second and let .get_stats64 return the cached
> >values under a per-port spinlock. A mod_delayed_work() call on each
^^^^^^^^^^^^^^^^^^^
Just noticed I forgot to update the commit message when changing the
implementation to use a single shared spinlock for all ports...
I'll send v2 tomorrow fixing that, and what ever else comes up, if
anything.
> >read triggers an immediate refresh so counters stay responsive when
> >queried more frequently.
> >
> >MMIO-connected switches (MT7988, EN7581, AN7583) are not affected
> >because their regmap does not sleep, so they continue to read MIB
> >counters directly in .get_stats64.
> >
> >Fixes: 88c810f35ed5 ("net: dsa: mt7530: implement .get_stats64")
> >Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> >---
> >This bug highlights a bigger problem and the actual cause:
> >Locking in the mt7530 driver deserves a cleanup, and refactoring
> >towards cleanly and directly using the regmap API.
> >I've prepared this already and am going to submit a series doing
> >most of that using Coccinelle semantic patches once net-next opens
> >again.
>
> Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
>
> Chester A.
^ permalink raw reply
* Re: [PATCH net] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Andrew Lunn @ 2026-04-17 12:06 UTC (permalink / raw)
To: Daniel Golle
Cc: Chester A. Unal, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, Christian Marangi,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek,
Frank Wunderlich, John Crispin
In-Reply-To: <79dc0ec5b6be698b14cb66339d6f63033ca2934a.1776397542.git.daniel@makrotopia.org>
On Fri, Apr 17, 2026 at 04:55:57AM +0100, Daniel Golle wrote:
> The .get_stats64 callback runs in atomic context, but on
> MDIO-connected switches every register read acquires the MDIO bus
> mutex, which can sleep:
> [ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609
> [ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep
> [ 12.663377] preempt_count: 0, expected: 0
> [ 12.667410] RCU nest depth: 1, expected: 0
> [ 12.671511] INFO: lockdep is turned off.
> [ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT
> [ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
> [ 12.675456] Hardware name: Bananapi BPI-R64 (DT)
> [ 12.675459] Call trace:
> [ 12.675462] show_stack+0x14/0x1c (C)
> [ 12.675477] dump_stack_lvl+0x68/0x8c
> [ 12.675487] dump_stack+0x14/0x1c
> [ 12.675495] __might_resched+0x14c/0x220
> [ 12.675504] __might_sleep+0x44/0x80
> [ 12.675511] __mutex_lock+0x50/0xb10
> [ 12.675523] mutex_lock_nested+0x20/0x30
> [ 12.675532] mt7530_get_stats64+0x40/0x2ac
> [ 12.675542] dsa_user_get_stats64+0x2c/0x40
> [ 12.675553] dev_get_stats+0x44/0x1e0
> [ 12.675564] dev_seq_printf_stats+0x24/0xe0
> [ 12.675575] dev_seq_show+0x14/0x3c
> [ 12.675583] seq_read_iter+0x37c/0x480
> [ 12.675595] seq_read+0xd0/0xec
> [ 12.675605] proc_reg_read+0x94/0xe4
> [ 12.675615] vfs_read+0x98/0x29c
> [ 12.675625] ksys_read+0x54/0xdc
> [ 12.675633] __arm64_sys_read+0x18/0x20
> [ 12.675642] invoke_syscall.constprop.0+0x54/0xec
> [ 12.675653] do_el0_svc+0x3c/0xb4
> [ 12.675662] el0_svc+0x38/0x200
> [ 12.675670] el0t_64_sync_handler+0x98/0xdc
> [ 12.675679] el0t_64_sync+0x158/0x15c
>
> For MDIO-connected switches, poll MIB counters asynchronously using a
> delayed workqueue every second and let .get_stats64 return the cached
> values under a per-port spinlock. A mod_delayed_work() call on each
> read triggers an immediate refresh so counters stay responsive when
> queried more frequently.
>
> MMIO-connected switches (MT7988, EN7581, AN7583) are not affected
> because their regmap does not sleep, so they continue to read MIB
> counters directly in .get_stats64.
>
> Fixes: 88c810f35ed5 ("net: dsa: mt7530: implement .get_stats64")
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] drm/mediatek: hdmi: Convert DRM_ERROR() to drm_err()
From: Jani Nikula @ 2026-04-17 12:03 UTC (permalink / raw)
To: sai madhu, Chun-Kuang Hu
Cc: Philipp Zabel, dri-devel, linux-mediatek, linux-kernel,
linux-arm-kernel, sai madhu
In-Reply-To: <20260417113310.2903091-1-suryasaimadhu369@gmail.com>
On Fri, 17 Apr 2026, sai madhu <suryasaimadhu369@gmail.com> wrote:
> The DRM_ERROR() macro is deprecated in favor of drm_err() which
> provides device-specific logging.
>
> Replace DRM_ERROR() with drm_err() in the Mediatek HDMI bridge
> driver and pass the drm_device pointer via bridge->dev.
>
> No functional change intended.
>
> Signed-off-by: sai madhu <suryasaimadhu369@gmail.com>
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 1ea259854780..f431fc9adca5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -981,8 +981,9 @@ static int mtk_hdmi_bridge_attach(struct drm_bridge *bridge,
> int ret;
>
> if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> - DRM_ERROR("%s: The flag DRM_BRIDGE_ATTACH_NO_CONNECTOR must be supplied\n",
> - __func__);
> + drm_err(bridge->dev,
> + "%s: The flag DRM_BRIDGE_ATTACH_NO_CONNECTOR must be supplied\n",
> + __func__);
We really shouldn't be logging __func__ either. Errors should be
unambigious anyway, and drm_dbg* logging uses
__builtin_return_address(0) to achieve the same with a much smaller
footprint.
BR,
Jani.
> return -EINVAL;
> }
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH v6 01/30] mm: Introduce kpkeys
From: David Hildenbrand (Arm) @ 2026-04-17 12:00 UTC (permalink / raw)
To: Kevin Brodsky, linux-hardening
Cc: linux-kernel, Andrew Morton, Andy Lutomirski, Catalin Marinas,
Dave Hansen, Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Lorenzo Stoakes, Marc Zyngier, Mark Brown,
Matthew Wilcox, Maxwell Bland, Mike Rapoport (IBM),
Peter Zijlstra, Pierre Langlois, Quentin Perret, Rick Edgecombe,
Ryan Roberts, Thomas Gleixner, Vlastimil Babka, Will Deacon,
Yang Shi, Yeoreum Yun, linux-arm-kernel, linux-mm, x86
In-Reply-To: <fea9c939-f955-4020-bed6-427e592f0024@arm.com>
On 4/15/26 17:50, Kevin Brodsky wrote:
> On 15/04/2026 15:00, David Hildenbrand (Arm) wrote:
>> On 2/27/26 18:54, Kevin Brodsky wrote:
>>> kpkeys is a simple framework to enable the use of protection keys
>>> (pkeys) to harden the kernel itself. This patch introduces the basic
>>> API in <linux/kpkeys.h>: a couple of functions to set and restore
>>> the pkey register and macros to define guard objects.
>>>
>>> kpkeys introduces a new concept on top of pkeys: the kpkeys level.
>>> Each level is associated to a set of permissions for the pkeys
>>> managed by the kpkeys framework. kpkeys_set_level(lvl) sets those
>>> permissions according to lvl, and returns the original pkey
>>> register, to be later restored by kpkeys_restore_pkey_reg(). To
>>> start with, only KPKEYS_LVL_DEFAULT is available, which is meant
>>> to grant RW access to KPKEYS_PKEY_DEFAULT (i.e. all memory since
>>> this is the only available pkey for now).
>>>
>>> Because each architecture implementing pkeys uses a different
>>> representation for the pkey register, and may reserve certain pkeys
>>> for specific uses, support for kpkeys must be explicitly indicated
>>> by selecting ARCH_HAS_KPKEYS and defining the following functions in
>>> <asm/kpkeys.h>, in addition to the macros provided in
>>> <asm-generic/kpkeys.h>:
>> I don't quite understand the reason for using levels. Levels sounds like
>> it would all be in some ordered fashion, where higher levels have access
>> to lower levels.
>
> That was originally the idea indeed, but in practice I don't expect
> levels to have a strict ordering, as it's not practical for composing
> features.
>
>> Think of that as a key that can unlock all "lower" locks, not just a
>> single lock.
>>
>> Then, the question is about the ordering once we introduce new
>> keys/locks. With two, it obviously doesn't matter :)
>>
>> So naturally I wonder whether levels is really the right abstraction
>> here, and why we are not simply using "distinct" keys, like
>>
>> KPKEY_DEFAULT
>> KPKEY_PGTABLE
>> KPKEY_SUPER_SECRET1
>> KPKEY_SUPER_SECRET2
>>
>> Is it because you want KPKEY_PGTABLE also be able to write to KPKEY_DEFAULT?
>
> Right, and in general a given level may be able to write to any number
> of pkeys. That's why I don't want to conflate pkeys and levels. Agreed
> that "level" might not be the clearest term though, since there's no
> strict ordering.
As discussed offline, maybe the right terminology to use here would be
something like a "context".
You'd be activating/setting a context.
KPKEY_CTX_DEFAULT
KPKEY_CTX_PGTABLE
KPKEY_CTX_SUPER_SECRET1
What is accessible (and how) is defined for each context. For example, I
would assume that all context allow for read/write access to everything
that KPKEY_CTX_DEFAULT has access to.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] perf/arm_pmu: Skip PMCCNTR_EL0 on NVIDIA Olympus
From: kernel test robot @ 2026-04-17 11:59 UTC (permalink / raw)
To: Besar Wicaksono, will, mark.rutland, james.clark
Cc: oe-kbuild-all, linux-arm-kernel, linux-kernel, linux-tegra,
treding, jonathanh, vsethi, rwiley, sdonthineni, mochs, nirmoyd,
skelley, Besar Wicaksono
In-Reply-To: <20260406232034.2566133-1-bwicaksono@nvidia.com>
Hi Besar,
kernel test robot noticed the following build warnings:
[auto build test WARNING on soc/for-next]
[also build test WARNING on linus/master v7.0 next-20260416]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Besar-Wicaksono/perf-arm_pmu-Skip-PMCCNTR_EL0-on-NVIDIA-Olympus/20260417-021859
base: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
patch link: https://lore.kernel.org/r/20260406232034.2566133-1-bwicaksono%40nvidia.com
patch subject: [PATCH] perf/arm_pmu: Skip PMCCNTR_EL0 on NVIDIA Olympus
config: arm-allyesconfig (https://download.01.org/0day-ci/archive/20260417/202604171959.Zy8qD08x-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260417/202604171959.Zy8qD08x-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604171959.Zy8qD08x-lkp@intel.com/
All warnings (new ones prefixed by >>):
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:125:65: warning: initialized field overwritten [-Woverride-init]
125 | #define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR 0x0043
| ^~~~~~
drivers/perf/arm_pmuv3.c:147:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR'
147 | [C(L1D)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:125:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[0][1][1]')
125 | #define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR 0x0043
| ^~~~~~
drivers/perf/arm_pmuv3.c:147:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR'
147 | [C(L1D)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:134:65: warning: initialized field overwritten [-Woverride-init]
134 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD 0x004E
| ^~~~~~
drivers/perf/arm_pmuv3.c:149:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD'
149 | [C(DTLB)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:134:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[3][0][0]')
134 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD 0x004E
| ^~~~~~
drivers/perf/arm_pmuv3.c:149:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD'
149 | [C(DTLB)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:135:65: warning: initialized field overwritten [-Woverride-init]
135 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR 0x004F
| ^~~~~~
drivers/perf/arm_pmuv3.c:150:52: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR'
150 | [C(DTLB)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:135:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[3][1][0]')
135 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR 0x004F
| ^~~~~~
drivers/perf/arm_pmuv3.c:150:52: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR'
150 | [C(DTLB)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:132:65: warning: initialized field overwritten [-Woverride-init]
132 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD 0x004C
| ^~~~~~
drivers/perf/arm_pmuv3.c:151:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD'
151 | [C(DTLB)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:132:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[3][0][1]')
132 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD 0x004C
| ^~~~~~
drivers/perf/arm_pmuv3.c:151:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD'
151 | [C(DTLB)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:133:65: warning: initialized field overwritten [-Woverride-init]
133 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR 0x004D
| ^~~~~~
drivers/perf/arm_pmuv3.c:152:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR'
152 | [C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:133:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[3][1][1]')
133 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR 0x004D
| ^~~~~~
drivers/perf/arm_pmuv3.c:152:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR'
152 | [C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:149:65: warning: initialized field overwritten [-Woverride-init]
149 | #define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD 0x0060
| ^~~~~~
drivers/perf/arm_pmuv3.c:154:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD'
154 | [C(NODE)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:149:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[6][0][0]')
149 | #define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD 0x0060
| ^~~~~~
drivers/perf/arm_pmuv3.c:154:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD'
154 | [C(NODE)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:150:65: warning: initialized field overwritten [-Woverride-init]
150 | #define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR 0x0061
| ^~~~~~
drivers/perf/arm_pmuv3.c:155:52: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR'
155 | [C(NODE)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:150:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[6][1][0]')
150 | #define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR 0x0061
| ^~~~~~
drivers/perf/arm_pmuv3.c:155:52: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR'
155 | [C(NODE)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/perf/arm_pmuv3.c:984:26: error: array type has incomplete element type 'struct midr_range'
984 | static struct midr_range armv8pmu_avoid_pmccntr_cpus[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/perf/arm_pmuv3.c:1000:9: error: implicit declaration of function 'MIDR_ALL_VERSIONS'; did you mean 'MODULE_VERSION'? [-Wimplicit-function-declaration]
1000 | MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
| ^~~~~~~~~~~~~~~~~
| MODULE_VERSION
drivers/perf/arm_pmuv3.c:1000:27: error: 'MIDR_NVIDIA_OLYMPUS' undeclared here (not in a function)
1000 | MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
| ^~~~~~~~~~~~~~~~~~~
drivers/perf/arm_pmuv3.c: In function 'armv8pmu_can_use_pmccntr':
drivers/perf/arm_pmuv3.c:1042:13: error: implicit declaration of function 'is_midr_in_range_list' [-Wimplicit-function-declaration]
1042 | if (is_midr_in_range_list(armv8pmu_avoid_pmccntr_cpus))
| ^~~~~~~~~~~~~~~~~~~~~
drivers/perf/arm_pmuv3.c: At top level:
>> drivers/perf/arm_pmuv3.c:984:26: warning: 'armv8pmu_avoid_pmccntr_cpus' defined but not used [-Wunused-variable]
984 | static struct midr_range armv8pmu_avoid_pmccntr_cpus[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/armv8pmu_avoid_pmccntr_cpus +984 drivers/perf/arm_pmuv3.c
980
981 /*
982 * List of CPUs that should avoid using PMCCNTR_EL0.
983 */
> 984 static struct midr_range armv8pmu_avoid_pmccntr_cpus[] = {
985 /*
986 * The PMCCNTR_EL0 in Olympus CPU may still increment while in WFI/WFE state.
987 * This is an implementation specific behavior and not an erratum.
988 *
989 * From ARM DDI0487 D14.4:
990 * It is IMPLEMENTATION SPECIFIC whether CPU_CYCLES and PMCCNTR count
991 * when the PE is in WFI or WFE state, even if the clocks are not stopped.
992 *
993 * From ARM DDI0487 D24.5.2:
994 * All counters are subject to any changes in clock frequency, including
995 * clock stopping caused by the WFI and WFE instructions.
996 * This means that it is CONSTRAINED UNPREDICTABLE whether or not
997 * PMCCNTR_EL0 continues to increment when clocks are stopped by WFI and
998 * WFE instructions.
999 */
1000 MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
1001 {}
1002 };
1003
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH rc v2 0/5] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Jason Gunthorpe @ 2026-04-17 11:59 UTC (permalink / raw)
To: Tian, Kevin
Cc: Robin Murphy, Nicolin Chen, will@kernel.org, joro@8bytes.org,
praan@google.com, baolu.lu@linux.intel.com,
miko.lenczewski@arm.com, smostafa@google.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
jamien@nvidia.com
In-Reply-To: <BN9PR11MB5276A13A8014C5C6403FB4EC8C202@BN9PR11MB5276.namprd11.prod.outlook.com>
On Fri, Apr 17, 2026 at 07:48:46AM +0000, Tian, Kevin wrote:
> is there any report on such systems? It might be informational to include
> a link to the report so it's clear that this series fixes real issues instead of
> a preparation for coming systems...
Yeah, we have an internal report and this was confirmed to fix it.
> btw the DMA is allowed after the previous kernel is hung til the point
> where smmu driver blocks it. In cases where in-fly DMAs are considered
> dangerous to kdump, this series just make it worse instead of creating
> a new issue. While for majority other failures not related to DMAs,
> unblocking then increases the chance of success...
Right, exactly.
If DMA's are splattering over the kdump carve out memory its is
probably dead no matter what.
Jason
^ permalink raw reply
* Re: [PATCH 00/40] arm64: dts: rockchip: Wire up frl-enable-gpios for RK3576/RK3588 boards
From: Heiko Stuebner @ 2026-04-17 11:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
Hi Cristan,
Am Freitag, 17. April 2026, 11:24:34 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
[...]
> Cristian Ciocaltea (40):
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
I do think one patch per SoC (rk3576, rk3588, rk3588s) would make more
sense, because these patches really are mostly identical :-)
Heiko
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-sige7
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-w3
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-evb
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-genbook
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb1-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb2-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-firefly-itx-3588j
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-friendlyelec-cm3588-nas
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-h96-max-v58
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-jaguar
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-mnt-reform2
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-nanopc-t6
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-max
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-plus
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-ultra
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-roc-rt
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5-itx
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5b-5bp-5t
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-tiger
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-coolpi-4b
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-gameforce-ace
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-indiedroid-nova
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-khadas-edge2
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-nanopi-r6
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-odroid-m2
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-5
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-cm5-base
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-radxa-cm5-io
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-roc-pc
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5a
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5c
>
> .../boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts | 8 ++++++++
> .../boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
> arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts | 9 ++++-----
> arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3588-armsom-sige7.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588-armsom-w3.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts | 17 ++++++++++++++++-
> .../boot/dts/rockchip/rk3588-coolpi-cm5-genbook.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-evb2-v10.dts | 9 +++++++++
> .../boot/dts/rockchip/rk3588-firefly-itx-3588j.dts | 9 +++++++++
> .../dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-h96-max-v58.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-mnt-reform2.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-max.dts | 15 ++++++++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 16 ++++++++++++++++
> .../arm64/boot/dts/rockchip/rk3588-orangepi-5-ultra.dts | 9 ++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-roc-rt.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 9 ++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 16 +++++++++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts | 3 ++-
> arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 9 ++++++++-
> arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-gameforce-ace.dts | 8 +++-----
> .../arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts | 13 +++++++++----
> arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 9 +++++++++
> .../boot/dts/rockchip/rk3588s-orangepi-cm5-base.dts | 3 ++-
> arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts | 15 ++++++++++++---
> arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts | 10 +++++++++-
> 41 files changed, 392 insertions(+), 35 deletions(-)
> ---
> base-commit: 452c3b1ea875276105ac90ba474f72b4cd9b77a2
> change-id: 20260417-dts-rk-frl-enable-gpios-ce9930dbf5ca
>
>
^ permalink raw reply
* [PATCH] drm/mediatek: hdmi: Convert DRM_ERROR() to drm_err()
From: sai madhu @ 2026-04-17 11:33 UTC (permalink / raw)
To: Chun-Kuang Hu
Cc: Philipp Zabel, dri-devel, linux-mediatek, linux-kernel,
linux-arm-kernel, sai madhu
The DRM_ERROR() macro is deprecated in favor of drm_err() which
provides device-specific logging.
Replace DRM_ERROR() with drm_err() in the Mediatek HDMI bridge
driver and pass the drm_device pointer via bridge->dev.
No functional change intended.
Signed-off-by: sai madhu <suryasaimadhu369@gmail.com>
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 1ea259854780..f431fc9adca5 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -981,8 +981,9 @@ static int mtk_hdmi_bridge_attach(struct drm_bridge *bridge,
int ret;
if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
- DRM_ERROR("%s: The flag DRM_BRIDGE_ATTACH_NO_CONNECTOR must be supplied\n",
- __func__);
+ drm_err(bridge->dev,
+ "%s: The flag DRM_BRIDGE_ATTACH_NO_CONNECTOR must be supplied\n",
+ __func__);
return -EINVAL;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Heiko Stuebner @ 2026-04-17 11:32 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-5-a19c0dd8c9f6@collabora.com>
Hi Cristian,
the comments below apply sort of to all patches in that series.
Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> The board exposes the GPIO4_C6 line to control the voltage bias on the
> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
>
> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
> property and drop the line from the vcc_5v0_hdmi regulator to allow
> adjusting the bias when transitioning between TMDS and FRL operating
> modes.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> index 749f0a54b478..93ae37699366 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> @@ -140,10 +140,7 @@ regulator-state-mem {
>
> vcc_5v0_hdmi: regulator-vcc-5v0-hdmi {
> compatible = "regulator-fixed";
> - enable-active-high;
> - gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&hdmi_con_en>;
> + regulator-always-on;
> regulator-min-microvolt = <5000000>;
> regulator-max-microvolt = <5000000>;
> regulator-name = "vcc_5v0_hdmi";
I think this regulator was sort of a complete hack, to set that
gpio to some sort of default state, by declaring it as hdmi-pwr-supply.
Only 2 rk3576 boards seem, to use that hack, so I think as that "regulator"
is completely functionless now, the whole thing could be removed?
> @@ -231,6 +228,8 @@ &gpu {
> };
>
> &hdmi {
> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
this should be sorted the other way around I think.
Also please provide a pinctrl-names property too. If for whatever reason
the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
board DTs are staying in the "old" compatible mode until they are adapted.
> status = "okay";
> };
>
> @@ -655,7 +654,7 @@ &pcie0 {
>
> &pinctrl {
> hdmi {
> - hdmi_con_en: hdmi-con-en {
> + hdmi_frl_en: hdmi-frl-en {
pinctrl names should ideally match the naming in schematics, for example
the "HDMI0_TX_ON_H" for jaguar and tiger. This makes it way easier to
go from DT to schematics and back.
> rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> };
> };
>
>
Heiko
^ permalink raw reply
* Re: [PATCH v2 0/9] driver core / pmdomain: Add support for fined grained sync_state
From: Ulf Hansson @ 2026-04-17 11:27 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman,
Danilo Krummrich, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
+ Danilo (for the driver core changes)
On Fri, 10 Apr 2026 at 12:41, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> Since the introduction [1] of the common sync_state support for pmdomains
> (genpd), we have encountered a lot of various interesting problems. In most
> cases the new behaviour of genpd triggered some weird platform specific bugs.
>
> That said, in LPC in Tokyo me and Saravana hosted a session to walk through the
> remaining limitations that we have found for genpd's sync state support. In
> particular, we discussed the problems we have for the so-called onecell power
> domain providers, where a single provider typically provides multiple
> independent power domains, all with their own set of consumers.
>
> Note that, onecell power domain providers are very common. It's being used by
> many SoCs/platforms/technologies. To name a few:
> SCMI, Qualcomm, NXP, Mediatek, Renesas, TI, etc.
>
> Anyway, in these cases, the generic sync_state mechanism with fw_devlink isn't
> fine grained enough, as we end up waiting for all consumers for all power
> domains before the ->sync_callback gets called for the supplier/provider. In
> other words, we may end up keeping unused power domains powered-on, for no good
> reasons.
>
> The series intends to fix this problem. Please have a look at the commit
> messages for more details and help review/test!
>
> Kind regards
> Ulf Hansson
>
> [1]
> https://lore.kernel.org/all/20250701114733.636510-1-ulf.hansson@linaro.org/
>
> Ulf Hansson (9):
> driver core: Enable suppliers to implement fine grained sync_state
> support
> driver core: Add dev_set_drv_queue_sync_state()
> pmdomain: core: Move genpd_get_from_provider()
> pmdomain: core: Add initial fine grained sync_state support
> pmdomain: core: Extend fine grained sync_state to more onecell
> providers
> pmdomain: core: Export a common function for ->queue_sync_state()
> pmdomain: renesas: rcar-gen4-sysc: Drop GENPD_FLAG_NO_STAY_ON
> pmdomain: renesas: rcar-sysc: Drop GENPD_FLAG_NO_STAY_ON
> pmdomain: renesas: rmobile-sysc: Drop GENPD_FLAG_NO_STAY_ON
>
> drivers/base/core.c | 7 +-
> drivers/pmdomain/core.c | 205 ++++++++++++++++++----
> drivers/pmdomain/renesas/rcar-gen4-sysc.c | 1 -
> drivers/pmdomain/renesas/rcar-sysc.c | 1 -
> drivers/pmdomain/renesas/rmobile-sysc.c | 3 +-
> include/linux/device.h | 12 ++
> include/linux/device/driver.h | 7 +
> include/linux/pm_domain.h | 3 +
> 8 files changed, 197 insertions(+), 42 deletions(-)
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: imx8mq: Correct MIPI CSI clocks
From: Frank Li @ 2026-04-17 11:22 UTC (permalink / raw)
To: Robby Cai
Cc: robh, krzk+dt, conor+dt, s.hauer, festevam, shawnguo,
martin.kepplinger, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260417110200.753678-2-robby.cai@nxp.com>
On Fri, Apr 17, 2026 at 07:01:59PM +0800, Robby Cai wrote:
> CSI capture may intermittently fail due to mismatched clock rates. The
> previous configuration violated the timing requirement stated in the
> i.MX8MQ Reference Manual:
>
> "The frequency of clk must be exactly equal to or greater than the RX
> byte clock coming from the RX DPHY."
>
> Update the clock configuration to ensure that the CSI core clock rate is
> equal to or greater than the incoming DPHY byte clock.
You reduce clock, how to make sure it >= ?
> The updated clock
> ratios are consistent with those used in NXP's downstream BSP.
"downstream BSP" is not solidate reference for clock rate, it'd better
refer to date sheet, dose datasheet require such frequecy
Frank
>
> Fixes: bcadd5f66c2a ("arm64: dts: imx8mq: add mipi csi phy and csi bridge descriptions")
> Cc: stable@vger.kernel.org
> Signed-off-by: Robby Cai <robby.cai@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 6a25e219832c..165716d08e64 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -1377,7 +1377,7 @@ mipi_csi1: csi@30a70000 {
> assigned-clocks = <&clk IMX8MQ_CLK_CSI1_CORE>,
> <&clk IMX8MQ_CLK_CSI1_PHY_REF>,
> <&clk IMX8MQ_CLK_CSI1_ESC>;
> - assigned-clock-rates = <266000000>, <333000000>, <66000000>;
> + assigned-clock-rates = <133000000>, <100000000>, <66000000>;
> assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
> <&clk IMX8MQ_SYS2_PLL_1000M>,
> <&clk IMX8MQ_SYS1_PLL_800M>;
> @@ -1429,7 +1429,7 @@ mipi_csi2: csi@30b60000 {
> assigned-clocks = <&clk IMX8MQ_CLK_CSI2_CORE>,
> <&clk IMX8MQ_CLK_CSI2_PHY_REF>,
> <&clk IMX8MQ_CLK_CSI2_ESC>;
> - assigned-clock-rates = <266000000>, <333000000>, <66000000>;
> + assigned-clock-rates = <133000000>, <100000000>, <66000000>;
> assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
> <&clk IMX8MQ_SYS2_PLL_1000M>,
> <&clk IMX8MQ_SYS1_PLL_800M>;
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH bpf-next] bpf, arm32: Reject BPF_PSEUDO_CALL in the JIT
From: Daniel Borkmann @ 2026-04-17 11:21 UTC (permalink / raw)
To: Puranjay Mohan, bpf, linux-arm-kernel
Cc: Jonas Rebmann, Alexei Starovoitov, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Russell King, kernel
In-Reply-To: <20260417103004.3552500-1-puranjay@kernel.org>
On 4/17/26 12:30 PM, Puranjay Mohan wrote:
> The ARM32 BPF JIT does not support BPF-to-BPF function calls
> (subprogram calls). When insn->src_reg == BPF_PSEUDO_CALL, the
> imm field contains a pc-relative offset to another BPF function,
> not a helper function index.
>
> When a program containing BPF-to-BPF calls is loaded, the verifier
> invokes bpf_jit_subprogs() which calls bpf_int_jit_compile() for each
> subprogram. Since ARM32 does not reject BPF_PSEUDO_CALL, the JIT
> silently emits code for the call using the wrong address computation:
>
> func = __bpf_call_base + imm
>
> where imm is actually a pc-relative subprogram offset, producing
> a bogus function pointer. Because build_body() reports success,
> bpf_jit_binary_alloc() is reached and a JIT image is allocated.
>
> ARM32 also lacks the jit_data/extra_pass mechanism needed for
> the second JIT pass in bpf_jit_subprogs(). On the second pass,
> bpf_int_jit_compile() performs a full fresh compilation,
> allocating a new JIT binary and overwriting prog->bpf_func. The
> first allocation is never freed. bpf_jit_subprogs() then detects
> the function pointer changed and aborts with -ENOTSUPP, but the
> original JIT binary has already been leaked. Each program
> load/unload cycle leaks one JIT binary allocation, as reported
> by kmemleak:
>
> unreferenced object 0xbf0a1000 (size 4096):
> backtrace:
> bpf_jit_binary_alloc+0x64/0xfc
> bpf_int_jit_compile+0x14c/0x348
> bpf_jit_subprogs+0x4fc/0xa60
>
> Fix this by rejecting BPF_PSEUDO_CALL early in build_insn(),
> falling through to the existing 'notyet' path. This causes
> build_body() to fail before any JIT binary is allocated, so
> bpf_int_jit_compile() returns the original program unjitted.
> bpf_jit_subprogs() then sees !prog->jited and cleanly falls
> back to the interpreter.
>
> Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs")
> Reported-by: Jonas Rebmann <jre@pengutronix.de>
> Closes: https://lore.kernel.org/bpf/b63e9174-7a3d-4e22-8294-16df07a4af89@pengutronix.de
> Tested-by: Jonas Rebmann <jre@pengutronix.de>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH bpf-next] bpf, arm32: Reject BPF_PSEUDO_CALL in the JIT
From: bot+bpf-ci @ 2026-04-17 11:17 UTC (permalink / raw)
To: puranjay, bpf, linux-arm-kernel
Cc: puranjay, jre, ast, daniel, andrii, martin.lau, eddyz87, memxor,
song, linux, kernel, ast, andrii, daniel, martin.lau, eddyz87,
yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260417103004.3552500-1-puranjay@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
> Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs")
Is this the correct Fixes tag? That commit only modified x64 JIT code
and BPF core infrastructure for BPF-to-BPF calls - it never touched
arch/arm/net/bpf_jit_32.c.
The actual bug was introduced by commit 39c13c204bb1 ("arm: eBPF JIT
compiler") from August 2017, which added the ARM32 eBPF JIT with
BPF_CALL handling but failed to reject BPF_PSEUDO_CALL. The code has
been incorrectly computing function addresses as 'func = __bpf_call_base
+ imm' for BPF_PSEUDO_CALL since the ARM32 JIT was first introduced.
Suggested: Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
> diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
> index deeb8f292454..91fef10e88bc 100644
> --- a/arch/arm/net/bpf_jit_32.c
> +++ b/arch/arm/net/bpf_jit_32.c
> @@ -2047,6 +2047,8 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
> /* function call */
> case BPF_JMP | BPF_CALL:
> {
> + if (insn->src_reg == BPF_PSEUDO_CALL)
> + goto notyet;
> const s8 *r0 = bpf2a32[BPF_REG_0];
> const s8 *r1 = bpf2a32[BPF_REG_1];
> const s8 *r2 = bpf2a32[BPF_REG_2];
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24561211195
^ permalink raw reply
* Re: [PATCH v2 2/3] ASoC: soc-core: Add core support for ignoring suspend on selected DAPM widgets
From: Frank Li @ 2026-04-17 11:14 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, broonie, perex, tiwai, shengjiu.wang, Xiubo.Lee,
festevam, nicoleotsuka, s.hauer, kernel, shumingf, rander.wang,
pierre-louis.bossart, linux-sound, linux-kernel, linuxppc-dev,
imx, linux-arm-kernel
In-Reply-To: <20260415081942.4183108-3-chancel.liu@nxp.com>
On Wed, Apr 15, 2026 at 05:19:41PM +0900, Chancel Liu wrote:
> Some audio systems require specific DAPM widgets to remain powered
> during system suspend. Introduce a generic and reusable mechanism in
> the ASoC core to mark selected DAPM widgets as ignore_suspend.
>
> The unified mechanism consists of two parts:
> 1. Parse and store the name list of widgets to ignore suspend in
> struct snd_soc_card
>
> The list of widgets can be provided either by the machine driver or
> parsed from Device Tree. Different machines have different routing and
> power requirements. Each machine can specify its own widgets to ignore
> suspend through DT property. It enables flexible policy without hard
> code. A new helper, snd_soc_of_parse_ignore_suspend_widgets() is added
> for this purpose.
>
> 2. Apply ignore_suspend flags during snd_soc_bind_card()
>
> After all components have been probed and all DAPM widgets have been
> registered, snd_soc_bind_card() performs a unified lookup of the
> configured widget names across all DAPM contexts of the card and marks
> the matching widgets with ignore_suspend = 1.
>
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
...
> @@ -3294,6 +3298,45 @@ int snd_soc_of_parse_aux_devs(struct snd_soc_card *card, const char *propname)
> }
> EXPORT_SYMBOL_GPL(snd_soc_of_parse_aux_devs);
>
> +int snd_soc_of_parse_ignore_suspend_widgets(struct snd_soc_card *card,
> + const char *propname)
propname is fixed value "ignore-suspend-widgets"，needn't this agument.
you funciton include "ignore_suspend_widgets", suppose only parse property.
ignore_suspend_widgets
Frank
^ permalink raw reply
* [PATCH] pmdomain: core: Fix detach procedure for virtual devices in genpd
From: Ulf Hansson @ 2026-04-17 11:13 UTC (permalink / raw)
To: Geert Uytterhoeven, Ulf Hansson, linux-pm
Cc: Geert Uytterhoeven, Frank Binns, Matt Coster, Marek Vasut,
Rafael J . Wysocki, linux-arm-kernel, linux-kernel, Ulf Hansson,
stable
If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(),
genpd calls pm_runtime_enable() for the corresponding virtual device that
it registers. While this avoids boilerplate code in drivers, there is no
corresponding call to pm_runtime_disable() in genpd_dev_pm_detach().
This means these virtual devices are typically detached from its genpd,
while runtime PM remains enabled for them, which is not how things are
designed to work. In worst cases it may lead to critical errors, like a
NULL pointer dereference bug in genpd_runtime_suspend(), which was recently
reported. For another case, we may end up keeping an unnecessary vote for a
performance state for the device.
To fix these problems, let's add this missing call to pm_runtime_disable()
in genpd_dev_pm_detach().
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Fixes: 3c095f32a92b ("PM / Domains: Add support for multi PM domains per device to genpd")
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/all/CAMuHMdWapT40hV3c+CSBqFOW05aWcV1a6v_NiJYgoYi0i9_PDQ@mail.gmail.com/
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pmdomain/core.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 4d32fc676aaf..71e930e80178 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -3089,6 +3089,7 @@ static const struct bus_type genpd_bus_type = {
static void genpd_dev_pm_detach(struct device *dev, bool power_off)
{
struct generic_pm_domain *pd;
+ bool is_virt_dev;
unsigned int i;
int ret = 0;
@@ -3098,6 +3099,13 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
dev_dbg(dev, "removing from PM domain %s\n", pd->name);
+ /* Check if the device was created by genpd at attach. */
+ is_virt_dev = dev->bus == &genpd_bus_type;
+
+ /* Disable runtime PM if we enabled it at attach. */
+ if (is_virt_dev)
+ pm_runtime_disable(dev);
+
/* Drop the default performance state */
if (dev_gpd_data(dev)->default_pstate) {
dev_pm_genpd_set_performance_state(dev, 0);
@@ -3123,7 +3131,7 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
genpd_queue_power_off_work(pd);
/* Unregister the device if it was created by genpd. */
- if (dev->bus == &genpd_bus_type)
+ if (is_virt_dev)
device_unregister(dev);
}
--
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