* [PATCH v3 4/6] KVM: arm64: pmu: Kill the PMU interrupt level cache
From: Marc Zyngier @ 2026-05-20 10:01 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Deepanshu Kartikey, Steffen Eiden, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu
In-Reply-To: <20260520100200.543845-1-maz@kernel.org>
Just like the timer, the PMU has an interrupt cache that serves little
purpose. Drop it.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/pmu-emul.c | 13 +++----------
include/kvm/arm_pmu.h | 1 -
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index 31a472a2c4881..edb21239478a9 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -396,19 +396,12 @@ static bool kvm_pmu_overflow_status(struct kvm_vcpu *vcpu)
static void kvm_pmu_update_state(struct kvm_vcpu *vcpu)
{
struct kvm_pmu *pmu = &vcpu->arch.pmu;
- bool overflow;
- overflow = kvm_pmu_overflow_status(vcpu);
- if (pmu->irq_level == overflow)
+ if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
return;
- pmu->irq_level = overflow;
-
- if (likely(irqchip_in_kernel(vcpu->kvm))) {
- int ret = kvm_vgic_inject_irq(vcpu->kvm, vcpu,
- pmu->irq_num, overflow, pmu);
- WARN_ON(ret);
- }
+ WARN_ON(kvm_vgic_inject_irq(vcpu->kvm, vcpu, pmu->irq_num,
+ kvm_pmu_overflow_status(vcpu), pmu));
}
bool kvm_pmu_should_notify_user(struct kvm_vcpu *vcpu)
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 3e844c5ee9174..b5e5942204fc6 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -32,7 +32,6 @@ struct kvm_pmu {
struct kvm_pmc pmc[KVM_ARMV8_PMU_MAX_COUNTERS];
int irq_num;
bool created;
- bool irq_level;
};
struct arm_pmu_entry {
--
2.47.3
^ permalink raw reply related
* [PATCH v3 0/6] KVM: arm64: Don't perform vgic-v2 lazy init on timer injection
From: Marc Zyngier @ 2026-05-20 10:01 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Deepanshu Kartikey, Steffen Eiden, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu
This is the third version of this series aiming at fixing issues with
vgic-v2 being initialised from non-preemptible context.
* From v2 [2]:
- Remove the PMU's irq level cache which was hidding in plain sight
- Simplify the userspace notification of interrupt level update
- Additional comment clarification in patch #1
- Collected RB, with thanks
* From v1 [1]:
- Repaint kvm_timer_irq_can_fire() to kvm_timer_enabled()
- Drop duplicate kvm_timer_update_status() call
- Force lazy init on the irqfd slow-path for SPIs
[1] https://lore.kernel.org/r/20260417124612.2770268-1-maz@kernel.org
[2] https://lore.kernel.org/r/20260422100210.3008156-1-maz@kernel.org
Marc Zyngier (6):
KVM: arm64: timer: Repaint kvm_timer_{should,irq_can}_fire() to
kvm_timer_{pending,enabled}()
KVM: arm64: Simplify userspace notification of interrupt state
KVM: arm64: timer: Kill the per-timer irq level cache
KVM: arm64: pmu: Kill the PMU interrupt level cache
KVM: arm64: vgic-v2: Force vgic init on injection outside the run loop
KVM: arm64: vgic-v2: Don't init the vgic on in-kernel interrupt
injection
arch/arm64/kvm/arch_timer.c | 106 ++++++++++++++-----------------
arch/arm64/kvm/arm.c | 39 ++++++++----
arch/arm64/kvm/pmu-emul.c | 31 +++------
arch/arm64/kvm/vgic/vgic-irqfd.c | 6 ++
arch/arm64/kvm/vgic/vgic.c | 6 +-
include/kvm/arm_arch_timer.h | 7 +-
include/kvm/arm_pmu.h | 5 +-
7 files changed, 94 insertions(+), 106 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH v3 2/6] KVM: arm64: Simplify userspace notification of interrupt state
From: Marc Zyngier @ 2026-05-20 10:01 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Deepanshu Kartikey, Steffen Eiden, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu
In-Reply-To: <20260520100200.543845-1-maz@kernel.org>
The userspace notification of interrupts is has a few problems:
- it is utterly pointless
- it is annoyingly split between detecting the need for notification
and the population of the interrupts in the run structure
We can't do anything about the former (yet), but the latter can be
addressed. If we detect that we must notify userspace, we know that
we are going to exit, as we populate the exit status. Which means
we can also populate the interrupt state at this stage and be done
with it.
This simplifies the structure of the code.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/arch_timer.c | 49 +++++++++++++++---------------------
arch/arm64/kvm/arm.c | 24 ++++++++++--------
arch/arm64/kvm/pmu-emul.c | 18 +++++--------
include/kvm/arm_arch_timer.h | 2 +-
include/kvm/arm_pmu.h | 4 +--
5 files changed, 43 insertions(+), 54 deletions(-)
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index d8add34717f07..7236dd6a99e67 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -404,22 +404,30 @@ int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
return vcpu_has_wfit_active(vcpu) && wfit_delay_ns(vcpu) == 0;
}
+static u64 kvm_timer_needs_notify(struct kvm_vcpu *vcpu)
+{
+ u64 v = vcpu->run->s.regs.device_irq_level;
+
+ v ^= kvm_timer_pending(vcpu_vtimer(vcpu)) ? KVM_ARM_DEV_EL1_VTIMER : 0;
+ v ^= kvm_timer_pending(vcpu_ptimer(vcpu)) ? KVM_ARM_DEV_EL1_PTIMER : 0;
+
+ return v & (KVM_ARM_DEV_EL1_VTIMER | KVM_ARM_DEV_EL1_PTIMER);
+}
+
+bool kvm_timer_should_notify_user(struct kvm_vcpu *vcpu)
+{
+ return !!kvm_timer_needs_notify(vcpu);
+}
+
/*
* Reflect the timer output level into the kvm_run structure
*/
-void kvm_timer_update_run(struct kvm_vcpu *vcpu)
+bool kvm_timer_update_run(struct kvm_vcpu *vcpu)
{
- struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
- struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
- struct kvm_sync_regs *regs = &vcpu->run->s.regs;
-
- /* 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_pending(vtimer))
- regs->device_irq_level |= KVM_ARM_DEV_EL1_VTIMER;
- if (kvm_timer_pending(ptimer))
- regs->device_irq_level |= KVM_ARM_DEV_EL1_PTIMER;
+ u64 mask = kvm_timer_needs_notify(vcpu);
+ if (mask)
+ vcpu->run->s.regs.device_irq_level ^= mask;
+ return !!mask;
}
static void kvm_timer_update_status(struct arch_timer_context *ctx, bool level)
@@ -903,23 +911,6 @@ void kvm_timer_vcpu_load(struct kvm_vcpu *vcpu)
timer_set_traps(vcpu, &map);
}
-bool kvm_timer_should_notify_user(struct kvm_vcpu *vcpu)
-{
- struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
- struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
- struct kvm_sync_regs *sregs = &vcpu->run->s.regs;
- bool vlevel, plevel;
-
- if (likely(irqchip_in_kernel(vcpu->kvm)))
- return false;
-
- vlevel = sregs->device_irq_level & KVM_ARM_DEV_EL1_VTIMER;
- plevel = sregs->device_irq_level & KVM_ARM_DEV_EL1_PTIMER;
-
- return kvm_timer_pending(vtimer) != vlevel ||
- kvm_timer_pending(ptimer) != plevel;
-}
-
void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu)
{
struct arch_timer_cpu *timer = vcpu_timer(vcpu);
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 8bb2c7422cc8b..6e6dc17f8b606 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1163,6 +1163,15 @@ static bool vcpu_mode_is_bad_32bit(struct kvm_vcpu *vcpu)
return !kvm_supports_32bit_el0();
}
+static bool kvm_irq_update_run(struct kvm_vcpu *vcpu)
+{
+ bool r;
+
+ r = kvm_timer_update_run(vcpu);
+ r |= kvm_pmu_update_run(vcpu);
+ return r;
+}
+
/**
* kvm_vcpu_exit_request - returns true if the VCPU should *not* enter the guest
* @vcpu: The VCPU pointer
@@ -1184,13 +1193,11 @@ static bool kvm_vcpu_exit_request(struct kvm_vcpu *vcpu, int *ret)
/*
* If we're using a userspace irqchip, then check if we need
* to tell a userspace irqchip about timer or PMU level
- * changes and if so, exit to userspace (the actual level
- * state gets updated in kvm_timer_update_run and
- * kvm_pmu_update_run below).
+ * changes and if so, exit to userspace while updating the run
+ * state.
*/
if (unlikely(!irqchip_in_kernel(vcpu->kvm))) {
- if (kvm_timer_should_notify_user(vcpu) ||
- kvm_pmu_should_notify_user(vcpu)) {
+ if (unlikely(kvm_irq_update_run(vcpu))) {
*ret = -EINTR;
run->exit_reason = KVM_EXIT_INTR;
return true;
@@ -1405,11 +1412,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
ret = handle_exit(vcpu, ret);
}
- /* Tell userspace about in-kernel device output levels */
- if (unlikely(!irqchip_in_kernel(vcpu->kvm))) {
- kvm_timer_update_run(vcpu);
- kvm_pmu_update_run(vcpu);
- }
+ if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
+ kvm_irq_update_run(vcpu);
kvm_sigset_deactivate(vcpu);
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index e1860acae641f..31a472a2c4881 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -413,27 +413,21 @@ static void kvm_pmu_update_state(struct kvm_vcpu *vcpu)
bool kvm_pmu_should_notify_user(struct kvm_vcpu *vcpu)
{
- struct kvm_pmu *pmu = &vcpu->arch.pmu;
struct kvm_sync_regs *sregs = &vcpu->run->s.regs;
bool run_level = sregs->device_irq_level & KVM_ARM_DEV_PMU;
- if (likely(irqchip_in_kernel(vcpu->kvm)))
- return false;
-
- return pmu->irq_level != run_level;
+ return kvm_pmu_overflow_status(vcpu) != run_level;
}
/*
* Reflect the PMU overflow interrupt output level into the kvm_run structure
*/
-void kvm_pmu_update_run(struct kvm_vcpu *vcpu)
+bool kvm_pmu_update_run(struct kvm_vcpu *vcpu)
{
- struct kvm_sync_regs *regs = &vcpu->run->s.regs;
-
- /* Populate the timer bitmap for user space */
- regs->device_irq_level &= ~KVM_ARM_DEV_PMU;
- if (vcpu->arch.pmu.irq_level)
- regs->device_irq_level |= KVM_ARM_DEV_PMU;
+ bool update = kvm_pmu_should_notify_user(vcpu);
+ if (update)
+ vcpu->run->s.regs.device_irq_level ^= KVM_ARM_DEV_PMU;
+ return update;
}
/**
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index bf8cc9589bd09..9e4076eebd29f 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -104,7 +104,7 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
void kvm_timer_sync_nested(struct kvm_vcpu *vcpu);
void kvm_timer_sync_user(struct kvm_vcpu *vcpu);
bool kvm_timer_should_notify_user(struct kvm_vcpu *vcpu);
-void kvm_timer_update_run(struct kvm_vcpu *vcpu);
+bool kvm_timer_update_run(struct kvm_vcpu *vcpu);
void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu);
void kvm_timer_init_vm(struct kvm *kvm);
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 0a36a3d5c8944..3e844c5ee9174 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -54,7 +54,7 @@ void kvm_pmu_reprogram_counter_mask(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
void kvm_pmu_sync_hwstate(struct kvm_vcpu *vcpu);
bool kvm_pmu_should_notify_user(struct kvm_vcpu *vcpu);
-void kvm_pmu_update_run(struct kvm_vcpu *vcpu);
+bool kvm_pmu_update_run(struct kvm_vcpu *vcpu);
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
@@ -131,7 +131,7 @@ static inline bool kvm_pmu_should_notify_user(struct kvm_vcpu *vcpu)
{
return false;
}
-static inline void kvm_pmu_update_run(struct kvm_vcpu *vcpu) {}
+static inline bool kvm_pmu_update_run(struct kvm_vcpu *vcpu) { return false; }
static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-20 10:07 UTC (permalink / raw)
To: Barry Song
Cc: Suren Baghdasaryan, Matthew Wilcox, akpm, linux-mm, david, liam,
vbabka, rppt, mhocko, jack, pfalcato, wanglian, chentao,
lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng,
nphamcs, bhe, youngjun.park, linux-arm-kernel, linux-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAGsJ_4zN5ezh9vvvQDQdMF2KuuDGvkhNjTZWc0y0Lsa-P4Aahw@mail.gmail.com>
On Wed, May 20, 2026 at 05:07:16PM +0800, Barry Song wrote:
> On Wed, May 20, 2026 at 3:50 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > On Wed, May 20, 2026 at 05:18:52AM +0800, Barry Song wrote:
> > > On Tue, May 19, 2026 at 8:53 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> > > >
> > > > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
> > > >
> > > > > >
> > > > > > I think we either need to fix `fork()`, or keep the current
> > > > > > behavior of dropping the VMA lock before performing I/O.
> > > > >
> > > > > I see. So, this problem arises from the fact that we are changing the
> > > > > pagefaults requiring I/O operation to hold VMA lock...
> > > > > And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> > > > > is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> > > > > anonymous and COW VMAs only while holding mmap_write_lock, preventing
> > > > > any VMA modification. On the surface, that looks ok to me but I might
> > > > > be missing some corner cases. If nobody sees any obvious issues, I
> > > > > think it's worth a try.
> > > >
> > > > Not sure if you noticed but I did raise concerns ;)
> > > >
> > > > I wonder if you've confused the fault path and fork here, as I think Barry has
> > > > been a little unclear on that.
> > >
> > > I think I’ve been absolutely clear :-)
> >
> > On this point sure, I would argue less so around the fork stuff but I responded
> > on that specifically elsewhere so let's keep things moving :>)
> >
> > > We should either stick to the current behavior - drop
> > > the VMA lock before doing I/O, or change fork() so that it
> > > does not wait on vma_start_write().
> >
> > Again, as I said elsewhere, I think there might be a 3rd way possibly. It's a
> > big mistake to assume that there are only specific solutions to problems in the
> > kernel then to present a false dichotomy.
>
> I recalled that when we discussed this part in my slides:
>
> ‘For simplicity, rather than using a whitelist mechanism for
> per-VMA retry, we could use a blacklist instead: default to
> always retry via the VMA lock, and only allow mmap_lock-based
> page-fault retry for specific cases such as
> __vmf_anon_prepare().’
Yeah that's an itneresting approach actually, sorry if I missed that.
>
> Suren mentioned introducing a FALLBACK flag. With the
> FALLBACK flag, we would retry via mmap_lock; with the RETRY
> flag, we would retry via the VMA lock.
Yeah, and honestly I'm beginning to wonder if we don't just have to pay the
complexity tax anyway and eat the fact we have to deal with that.
But as per Josef's comment re: this whole mechanism, simply not waiting for
file-backed I think is another option (but I don't recall where we left that
conversation actually?)
Anyway I want to make sure any complexity we add is necessary so will take a
look through patches and have a think (and obviously others will have their own
opinions!)
>
> Not sure whether this could really be called a ‘third way,’
> but it seems more like a shift from a whitelist model to a
> blacklist model, without changing the fundamental design, but
> it does change where we would need to touch the source code.
Right yeah, good to have more options.
>
> >
> > We absolutely hear you on this being a problem and it WILL be addressed one way
> > or another.
>
> Thanks. This is a bit of light in what has felt like a fairly
> dark situation. I really appreciate your thoughtful and
> responsible approach.
Yes, sorry, I maybe was a bit too harsh in my tone here, I didn't really intend
to be negative as to addresisng the problem as a whole.
Moreso I've been concerned about the fork approach, and that is what's led to me
being shall we say 'emphatic' about it :)
But of course I sometimes make mistakes in quite how my tone comes across, so
apologies if it came across overly negatively - I am negative (on a technical
level) about the fork approach, but not the fact we should address this.
To be clear - I'm very glad you've brought this up, it's important, as much as
it's painful that we have this issue in the first place! :)
>
> >
> > Of the two approaches, as I said elsewhere, I prefer what you've done in this
> > series to anything touching fork.
> >
> > But give me time to look through the series please (I'd also suggest RFC'ing
> > when it's something kinda fundamental that might generate converastion, makes
> > life a bit easier on the review side :)
>
> Thanks! Sure, I’m happy to wait and there’s no urgency.
>
> Last year you made quite a significant contribution to the work
> when I tried to remove mmap_lock in madvise. I really
> appreciated it. Now we’re back to the same lock again, just in
> different places.
Yeah :) one day maybe we can get rid of it altogether (maybe I'm dreaming :)
>
> Best Regards
> Barry
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] spi: aspeed: Replace VLA parameter with flat pointer in calibration helper
From: Mark Brown @ 2026-05-20 10:10 UTC (permalink / raw)
To: David Laight
Cc: Chin-Ting Kuo, clg, joel, andrew, linux-aspeed, openbmc,
linux-spi, linux-arm-kernel, linux-kernel, BMC-SW,
kernel test robot
In-Reply-To: <20260519181348.777f7dc5@pumpkin>
[-- Attachment #1: Type: text/plain, Size: 758 bytes --]
On Tue, May 19, 2026 at 06:13:48PM +0100, David Laight wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > On Mon, May 18, 2026 at 05:57:08PM +0800, Chin-Ting Kuo wrote:
> > > - while (k < cols && buf[i][k])
> > > + while (k < cols && buf[i * cols + k])
> > This really needs () to make it clear what's going on; the precedence is
> > well defined but not everyone is going to know that off the top of their
> > head.
> Come on, it's multiply and add - everyone is going to get that right.
No, I have to stop and think. It's not just "what is the rule" it's
also "is that the same rule whoever wrote the code thought there was" -
implicit precedence is the sort of thing that flags up as an alarm bell
when scanning through code.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: Consistently define pci_device_ids using named initializers
From: Helge Deller @ 2026-05-20 10:11 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Benjamin Herrenschmidt, Russell King, Andres Salomon,
Antonino Daplas, linux-fbdev, dri-devel, linux-kernel,
linux-arm-kernel, linux-geode, Markus Schneider-Pargmann
In-Reply-To: <ag1xQVCCzXkc_Ucu@monoceros>
On 5/20/26 10:46, Uwe Kleine-König (The Capable Hub) wrote:
> Hello,
>
> On Thu, Apr 30, 2026 at 01:16:36PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
>> diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c b/drivers/video/fbdev/matrox/matroxfb_base.c
>> index e1a4bc7c2318..22774eb1b14c 100644
>> --- a/drivers/video/fbdev/matrox/matroxfb_base.c
>> +++ b/drivers/video/fbdev/matrox/matroxfb_base.c
>> @@ -1642,7 +1642,7 @@ static int initMatrox2(struct matrox_fb_info *minfo, struct board *b)
>> int err;
>>
>> static const struct pci_device_id intel_82437[] = {
>> - { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82437) },
>> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_82437) },
>> { },
>> };
>>
>
> after further sharpening my tooling there is an additional change that
> IMHO should be done here:
>
> - { },
> + { }
>
> and ...
>
>> diff --git a/drivers/video/fbdev/pvr2fb.c b/drivers/video/fbdev/pvr2fb.c
>> index 3f6384e631b1..06aefad75f46 100644
>> --- a/drivers/video/fbdev/pvr2fb.c
>> +++ b/drivers/video/fbdev/pvr2fb.c
>> @@ -993,9 +993,8 @@ static void pvr2fb_pci_remove(struct pci_dev *pdev)
>> }
>>
>> static const struct pci_device_id pvr2fb_pci_tbl[] = {
>> - { PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_NEON250,
>> - PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
>> - { 0, },
>> + { PCI_VDEVICE(NEC, PCI_DEVICE_ID_NEC_NEON250), },
>> + { },
>> };
>>
>> MODULE_DEVICE_TABLE(pci, pvr2fb_pci_tbl);
>
> ... here:
>
> - { PCI_VDEVICE(NEC, PCI_DEVICE_ID_NEC_NEON250), },
> + { PCI_VDEVICE(NEC, PCI_DEVICE_ID_NEC_NEON250) },
> - { },
> + { }
>
> Would you mind squashing that into the patch you already applied, maybe
> adding:
>
> While touching all these arrays, unify usage of whitespace and
> comma in a few drivers.
>
> to the commit log? I can also send a v2 of the patch with these changes
> included if that's easier for you.
>
> Otherwise I will put sending these modifications separately on my todo
> list.
No need to resend anything. I'll clean it up manually during the next few hours....
Helge
^ permalink raw reply
* [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Carlos Song (OSS) @ 2026-05-20 10:15 UTC (permalink / raw)
To: o.rempel, kernel, andi.shyti, Frank.Li, s.hauer, festevam,
carlos.song, haibo.chen
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
From: Carlos Song <carlos.song@nxp.com>
Mark the I2C adapter as suspended during system suspend to block further
transfers, and resume it on system resume. This prevents potential hangs
when the hardware is powered down but clients still attempt I2C transfers.
Fixes: 358025ac091e ("i2c: imx: make controller available until system suspend_noirq() and from resume_noirq()")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
Change for v3:
- Add hrtimer_cancel in i2c_imx_suspend_noirq to cancel slave_timer for
safe suspend in i2c slave mode.
Change for v2:
- Call i2c_mark_adapter_suspended() before pm_runtime_force_suspend()
to prevent potential deadlock if a transfer is active during suspend.
- Roll back with i2c_mark_adapter_resumed() if pm_runtime_force_suspend()
fails.
---
drivers/i2c/busses/i2c-imx.c | 41 ++++++++++++++++++++++++++++++++++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index a208fefd3c3b..d651ade86267 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1913,6 +1913,43 @@ static int i2c_imx_runtime_resume(struct device *dev)
return ret;
}
+static int __maybe_unused i2c_imx_suspend_noirq(struct device *dev)
+{
+ struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
+ int ret;
+
+ i2c_mark_adapter_suspended(&i2c_imx->adapter);
+
+ /*
+ * Cancel the slave timer before powering down to prevent
+ * i2c_imx_slave_timeout() from accessing hardware registers
+ * while the clock is disabled.
+ */
+ hrtimer_cancel(&i2c_imx->slave_timer);
+
+ ret = pm_runtime_force_suspend(dev);
+ if (ret) {
+ i2c_mark_adapter_resumed(&i2c_imx->adapter);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __maybe_unused i2c_imx_resume_noirq(struct device *dev)
+{
+ struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_force_resume(dev);
+ if (ret)
+ return ret;
+
+ i2c_mark_adapter_resumed(&i2c_imx->adapter);
+
+ return 0;
+}
+
static int i2c_imx_suspend(struct device *dev)
{
/*
@@ -1946,8 +1983,8 @@ static int i2c_imx_resume(struct device *dev)
}
static const struct dev_pm_ops i2c_imx_pm_ops = {
- NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
- pm_runtime_force_resume)
+ NOIRQ_SYSTEM_SLEEP_PM_OPS(i2c_imx_suspend_noirq,
+ i2c_imx_resume_noirq)
SYSTEM_SLEEP_PM_OPS(i2c_imx_suspend, i2c_imx_resume)
RUNTIME_PM_OPS(i2c_imx_runtime_suspend, i2c_imx_runtime_resume, NULL)
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] coresight: fix resource leaks on path build failure
From: Jie Gan @ 2026-05-20 10:13 UTC (permalink / raw)
To: Mike Leach, James Clark
Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Suzuki Poulose, Leo Yan,
Alexander Shishkin, Mathieu Poirier, Tingwei Zhang,
Greg Kroah-Hartman, nd
In-Reply-To: <PAVPR08MB9674C4C58210122F3A6E07AB8C012@PAVPR08MB9674.eurprd08.prod.outlook.com>
On 5/20/2026 5:27 PM, Mike Leach wrote:
>
>
>> -----Original Message-----
>> From: James Clark <james.clark@linaro.org>
>> Sent: Wednesday, May 20, 2026 9:38 AM
>> To: Jie Gan <jie.gan@oss.qualcomm.com>
>> Cc: coresight@lists.linaro.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>; Mike
>> Leach <Mike.Leach@arm.com>; Leo Yan <Leo.Yan@arm.com>; Alexander
>> Shishkin <alexander.shishkin@linux.intel.com>; Mathieu Poirier
>> <mathieu.poirier@linaro.org>; Tingwei Zhang
>> <tingwei.zhang@oss.qualcomm.com>; Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org>
>> Subject: Re: [PATCH] coresight: fix resource leaks on path build failure
>>
>>
>>
>> On 20/05/2026 2:55 am, Jie Gan wrote:
>>>
>>>
>>> On 5/19/2026 9:57 PM, James Clark wrote:
>>>>
>>>>
>>>> On 13/05/2026 2:32 am, Jie Gan wrote:
>>>>> Two related leaks when _coresight_build_path() encounters an error after
>>>>> coresight_grab_device() has already incremented the pm_runtime,
>> module,
>>>>> and device references for a node:
>>>>>
>>>>> 1. In _coresight_build_path(), if kzalloc_obj() for the path node fails
>>>>> after coresight_grab_device() succeeds, coresight_drop_device() was
>>>>> never called, permanently leaking all three references.
>>>>>
>>>>> 2. In coresight_build_path(), on failure the partial path was freed with
>>>>> kfree(path) instead of coresight_release_path(path). kfree() only
>>>>> frees the coresight_path struct itself; it does not iterate
>>>>> path_list
>>>>> to call coresight_drop_device() and kfree() for each coresight_node
>>>>> already added by deeper recursive calls, leaking both the
>>>>> pm_runtime,
>>>>> module, and device references and the node memory for every element
>>>>> on the partial path.
>>>>>
>>>>> Fix both by adding coresight_drop_device() in the OOM unwind of
>>>>> _coresight_build_path(), and replacing kfree(path) with
>>>>> coresight_release_path(path) in coresight_build_path().
>>>>>
>>>>> Fixes: 32b0707a4182 ("coresight: Add try_get_module() in
>>>>> coresight_grab_device()")
>>>>> Fixes: b3e94405941e ("coresight: associating path with session rather
>>>>> than tracer")
>>>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>>>> ---
>>>>> drivers/hwtracing/coresight/coresight-core.c | 6 ++++--
>>>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/
>>>>> hwtracing/coresight/coresight-core.c
>>>>> index 46f247f73cf6..c1354ea8e11d 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-core.c
>>>>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>>>>> @@ -825,8 +825,10 @@ static int _coresight_build_path(struct
>>>>> coresight_device *csdev,
>>>>> return ret;
>>>>> node = kzalloc_obj(struct coresight_node);
>>>>> - if (!node)
>>>>> + if (!node) {
>>>>> + coresight_drop_device(csdev);
>>>>> return -ENOMEM;
>>>>> + }
>>>>> node->csdev = csdev;
>>>>> list_add(&node->link, &path->path_list);
>>>>> @@ -851,7 +853,7 @@ struct coresight_path
>>>>> *coresight_build_path(struct coresight_device *source,
>>>>> rc = _coresight_build_path(source, source, sink, path);
>>>>> if (rc) {
>>>>> - kfree(path);
>>>>> + coresight_release_path(path);
>>>>> return ERR_PTR(rc);
>>>>> }
>>>>>
>>>>> ---
>>>>> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
>>>>> change-id: 20260513-fix-memory-leak-issue-034b4a45265e
>>>>>
>>>>> Best regards,
>>>>
>>>> Looks good to me, but sashiko is complaining: https://sashiko.dev/#/
>>>> patchset/20260513-fix-memory-leak-issue-
>>>> v1-1-49822d7bc7d4%40oss.qualcomm.com
>>>>
>>>> I'm trying to understand why it's saying that, but I think the
>>>> scenario is that if there are multiple correct paths to a sink, when
>>>> one path partially fails and a second path succeeds you could get a
>>>> path_list with some garbage entries in it.
>>>
>>> I think the coresight_release_path is added to address this situation.
>>> We suffered the path partially failure, and we need release all nodes
>>> already added to the path.
>>>
>>
>> It wouldn't call coresight_release_path() in this case though. If one
>> path ends up building to success but a parallel path partially failed
>> then _coresight_build_path() still returns success. During the search it
>> would have still added the nodes from the partially failed path to the
>> path_list. This is only an issue if there are multiple correct paths.
>>
The point here is there are multiple routes from the same source device
to the same sink device, am right?
I have no experience on this scenario. So with the scenario, the
build_path may succeeded in one route and failed in another route, but
finally, the _coresight_build_path still returns success, is that correct?
>>>>
>>>> That's kind of a different and existing issue to the one you've fixed,
>>>> and assumes that multiple paths to one sink are possible, which I'm
>>>> not sure is supported?
>>>
>>> Each path is unique. We only deal with the issue path for balancing the
>>> reference count.
>>>
>>> Thanks,
>>> Jie
>>>
>>
>> I'm not exactly sure what you mean by unique, but the same source and
>> sink could potentially be connected through two different sets of links.
>>
>
> Multiple paths between a source and sink are not permitted under the CoreSight spec.
>
As Mike mentioned, my understanding is that a source device is only
allowed to be added to one valid path—this is what I mean by “unique.”
Thanks,
Jie
> If such a system was to be built - then a fix would need to be in the declaration of connections - e.g. miss one path out in the device tree for example. Not up to the Coresight drivers to handle out of specification hardware.
>
> Mike
>
>
>>>>
>>>> It might be as easy as breaking the loop early for any return value
>>>> other than -ENODEV, but I'll leave it to you to decide whether to do
>>>> that here or not.
>>>>
>>>> Reviewed-by: James Clark <james.clark@linaro.org>
>>>>
>>>
>
^ permalink raw reply
* Re: [PATCH v3] arm64: Kconfig: drop unneeded dependency on OF_GPIO for ARCH_MVEBU
From: Arnd Bergmann @ 2026-05-20 10:18 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bartosz Golaszewski, Catalin Marinas, Will Deacon,
linux-arm-kernel, linux-kernel, Linus Walleij
In-Reply-To: <CAMRc=Md5wDV+w7awoiiBoFVG24VEfH8hKvH2VP7dtcRX3m-Wnw@mail.gmail.com>
On Wed, May 20, 2026, at 10:32, Bartosz Golaszewski wrote:
> On Tue, May 5, 2026 at 12:42 PM Linus Walleij <linusw@kernel.org> wrote:
>>
>> On Thu, Apr 30, 2026 at 4:32 PM Bartosz Golaszewski
>> <bartosz.golaszewski@oss.qualcomm.com> wrote:
>>
>> > OF_GPIO is selected automatically on all OF systems. Any symbols it
>> > controls also provide stubs so there's really no reason to select it
>> > explicitly. ARCH_MVEBU already selects GPIOLIB, drop the redundant
>> > OF_GPIO dependency.
>> >
>> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>
>> Reviewed-by: Linus Walleij <linusw@kernel.org>
>>
>
> Arnd, can you please queue this directly for v7.2?
Done, thanks for the patch!
Arnd
^ permalink raw reply
* [PATCH] phy: rockchip: inno-usb2: Add missing clkout_ctl_phy kerneldoc
From: Heiko Stuebner @ 2026-05-20 10:28 UTC (permalink / raw)
To: vkoul
Cc: neil.armstrong, heiko, jonas, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, kernel test robot
Add the missing documentation for the newly added clkout_ctl_phy field.
Fixes: 2775541de058 ("phy: rockchip: inno-usb2: Add clkout_ctl_phy support")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605150315.MyBNQOPB-lkp@intel.com/
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 133cfd6624e8..7d8a533f24ae 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -170,7 +170,8 @@ struct rockchip_usb2phy_port_cfg {
* @reg: the address offset of grf for usb-phy config.
* @num_ports: specify how many ports that the phy has.
* @phy_tuning: phy default parameters tuning.
- * @clkout_ctl: keep on/turn off output clk of phy.
+ * @clkout_ctl: register to enable output clk of phy, when set in GRF
+ * @clkout_ctl_phy: register to enable output clk of phy, when set inside phy
* @port_cfgs: usb-phy port configurations.
* @chg_det: charger detection registers.
*/
--
2.47.3
^ permalink raw reply related
* Re: [PATCH V2 00/11] soc: ti: keystone/k3 navigator queue/dma/ringacc cleanups
From: Sai Sree Kartheek Adivi @ 2026-05-20 10:29 UTC (permalink / raw)
To: Nishanth Menon
Cc: Justin Stitt, Bill Wendling, Nick Desaulniers, Nathan Chancellor,
Santosh Shilimkar, afd, llvm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260512170623.3174416-1-nm@ti.com>
On 12:06-20260512, Nishanth Menon wrote:
> Fix W=2 (clang/gcc), sparse, smatch and coccinelle warnings.
> No functional changes.
>
> Tested: NFS boot (via nav subsystem) on k2l-evm, k2hk-evm and k2g-evm
> based on next-20260507:
> https://gist.github.com/nmenon/cff02a5f2a72fde5fcb49664fcc834d2
>
> Changes since V1:
> - update for review comments.
> - Picked up Randy's and Andrew's tags in appropriate patches.
>
> V1: https://lore.kernel.org/all/20260508153211.3688277-1-nm@ti.com/
>
For the entire series,
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Regards,
Kartheek
> Nishanth Menon (11):
> soc: ti: knav_qmss: Remove remaining redundant ENOMEM printks
> soc: ti: knav_qmss: Rename global kdev to knav_qdev to fix -Wshadow
> soc: ti: knav_qmss: Inline lockdep condition in for_each_handle_rcu
> soc: ti: knav_qmss: Fix kernel-doc Return: tags
> soc: ti: knav_qmss: Use %pe to print PTR_ERR()
> soc: ti: knav_qmss: Fix __iomem annotations and __be32 type
> soc: ti: knav_qmss_acc: Fix kernel-doc Return: tag
> soc: ti: knav_dma: Remove unused DMA_PRIO_MASK macro
> soc: ti: knav_dma: Remove dead check on unsigned args.args[0]
> soc: ti: knav_dma: Use IOMEM_ERR_PTR() in pktdma_get_regs()
> soc: ti: k3-ringacc: Use str_enabled_disabled() helper
>
> drivers/soc/ti/k3-ringacc.c | 3 +-
> drivers/soc/ti/knav_dma.c | 8 +-
> drivers/soc/ti/knav_qmss.h | 2 +-
> drivers/soc/ti/knav_qmss_acc.c | 2 +-
> drivers/soc/ti/knav_qmss_queue.c | 148 +++++++++++++++----------------
> 5 files changed, 75 insertions(+), 88 deletions(-)
>
> --
> 2.47.0
>
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: David Hildenbrand (Arm) @ 2026-05-20 10:33 UTC (permalink / raw)
To: Lorenzo Stoakes, Suren Baghdasaryan
Cc: Barry Song, Matthew Wilcox, akpm, linux-mm, liam, vbabka, rppt,
mhocko, jack, pfalcato, wanglian, chentao, lianux.mm, kunwu.chan,
liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <agxbq1TxJdniMQT3@lucifer>
On 5/19/26 14:53, Lorenzo Stoakes wrote:
> On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
>
>>>
>>> I think we either need to fix `fork()`, or keep the current
>>> behavior of dropping the VMA lock before performing I/O.
>>
>> I see. So, this problem arises from the fact that we are changing the
>> pagefaults requiring I/O operation to hold VMA lock...
>> And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
>> is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
>> anonymous and COW VMAs only while holding mmap_write_lock, preventing
>> any VMA modification. On the surface, that looks ok to me but I might
>> be missing some corner cases. If nobody sees any obvious issues, I
>> think it's worth a try.
>
> Not sure if you noticed but I did raise concerns ;)
>
> I wonder if you've confused the fault path and fork here, as I think Barry has
> been a little unclear on that.
>
> What's being suggested in this thread is to fundamentally change fork behaviour
> so it's different from the entire history of the kernel (or - presumably - at
> least recent history :)
I don't want fork() to become different in that regard.
There is already a slight difference with vs. without per-VMA locks, because
there is a window in-between us taking the write mmap_lock and all the per-VMA
locks. I raised that previously [1] and assumed that it is probably fine.
I also raised in the past why I think we must not allow concurrent page faults,
at least as soon as anonymous memory is involved [2].
... and I raised that this is pretty much slower by design right now: "Well, the
design decision that CONFIG_PER_VMA_LOCK made for now to make page faults fast
and to make blocking any page faults from happening to be slower ..." [3]
[1] https://lore.kernel.org/all/970295ab-e85d-7af3-76e6-df53a5c52f8b@redhat.com/
[2] https://lore.kernel.org/all/7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com/
[3] https://lore.kernel.org/all/2efa2c89-3765-721d-2c3c-00590054aa5b@redhat.com/
--
Cheers,
David
^ permalink raw reply
* Re: [RFC V2 01/14] mm: Abstract printing of pxd_val()
From: David Hildenbrand (Arm) @ 2026-05-20 10:41 UTC (permalink / raw)
To: Dave Hansen, Anshuman Khandual, linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
Usama Arif, linux-kernel, linux-mm
In-Reply-To: <74f66e30-ab3d-4352-89ef-1bccc7e9daeb@intel.com>
On 5/19/26 16:28, Dave Hansen wrote:
> On 5/12/26 21:45, Anshuman Khandual wrote:
>> if (!p4d_present(p4d) || p4d_leaf(p4d)) {
>> - pr_alert("pgd:%08llx p4d:%08llx\n", pgdv, p4dv);
>> + pr_alert("pgd:%" __PRIpxx " p4d:%" __PRIpxx "\n",
>> + __PRIpxx_args(pgdv), __PRIpxx_args(p4dv));
>> return;
>> }
>
> That's not the most readable result. Could a printk() format specifier
> make this nicer? Maybe use "%pT"?
>
> pr_alert("pgd:%pT p4d:%pT\n", &pgd, &p4d);
>
> I _think_ it could even get rid of the p??v variables.
That would be nicer indeed, if that works.
--
Cheers,
David
^ permalink raw reply
* [PATCH] i2c: imx: fix clock and pinctrl state inconsistency in runtime PM
From: Carlos Song (OSS) @ 2026-05-20 10:49 UTC (permalink / raw)
To: o.rempel, kernel, andi.shyti, Frank.Li, s.hauer, festevam,
carlos.song
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
From: Carlos Song <carlos.song@nxp.com>
In i2c_imx_runtime_suspend(), the clock is disabled before switching
the pinctrl state to sleep. If pinctrl_pm_select_sleep_state() fails,
the runtime suspend is aborted but the clock remains disabled, causing
a system crash when the hardware is subsequently accessed.
Fix this by switching the pinctrl state before disabling the clock so
that a pinctrl failure leaves the clock enabled and the hardware
accessible.
In i2c_imx_runtime_resume(), restore the pinctrl state back to sleep
if clk_enable() fails to keep the two consistent.
Fixes: 576eba03c994 ("i2c: imx: switch different pinctrl state in different system power status")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
drivers/i2c/busses/i2c-imx.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index d651ade86267..54fd5d0e4056 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1892,9 +1892,15 @@ static void i2c_imx_remove(struct platform_device *pdev)
static int i2c_imx_runtime_suspend(struct device *dev)
{
struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pinctrl_pm_select_sleep_state(dev);
+ if (ret)
+ return ret;
clk_disable(i2c_imx->clk);
- return pinctrl_pm_select_sleep_state(dev);
+
+ return 0;
}
static int i2c_imx_runtime_resume(struct device *dev)
@@ -1907,10 +1913,13 @@ static int i2c_imx_runtime_resume(struct device *dev)
return ret;
ret = clk_enable(i2c_imx->clk);
- if (ret)
+ if (ret) {
dev_err(dev, "can't enable I2C clock, ret=%d\n", ret);
+ pinctrl_pm_select_sleep_state(dev);
+ return ret;
+ }
- return ret;
+ return 0;
}
static int __maybe_unused i2c_imx_suspend_noirq(struct device *dev)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 7/7] mm/vmalloc: Stop scanning for compound pages after encountering small pages in vmap
From: Wen Jiang @ 2026-05-20 10:56 UTC (permalink / raw)
To: Uladzislau Rezki
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel
In-Reply-To: <ag2CeHWDLLglCF7t@milan>
Sure, will do.
Thanks,
Wen Jiang
On Wed, 20 May 2026 at 17:44, Uladzislau Rezki <urezki@gmail.com> wrote:
>
> On Thu, May 14, 2026 at 05:41:08PM +0800, Wen Jiang wrote:
> > From: "Barry Song (Xiaomi)" <baohua@kernel.org>
> >
> > Users typically allocate memory in descending orders, e.g.
> > 8 → 4 → 0. Once an order-0 page is encountered, subsequent
> > pages are likely to also be order-0, so we stop scanning
> > for compound pages at that point.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> > Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > ---
> > mm/vmalloc.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index b3389c8f1..60579bfbf 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3576,6 +3576,12 @@ static int __vmap_huge(unsigned long addr, unsigned long end,
> > map_addr = addr;
> > idx = i;
> > }
> > + /*
> > + * Once small pages are encountered, the remaining pages
> > + * are likely small as well
> > + */
> > + if (shift == PAGE_SHIFT)
> > + break;
> >
> > addr += 1UL << shift;
> > i += 1U << (shift - PAGE_SHIFT);
> > --
> > 2.34.1
> >
> Can we squash this patch with
> "mm/vmalloc: map contiguous pages in batches for vmap() if possible"?
>
> --
> Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm-smmu: qcom: Constrain clocks for Hawi SoC
From: Krzysztof Kozlowski @ 2026-05-20 10:57 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robin Murphy, linux-arm-kernel, iommu, devicetree,
linux-kernel
In-Reply-To: <20260520073447.2138384-1-mukesh.ojha@oss.qualcomm.com>
On Wed, May 20, 2026 at 01:04:47PM +0530, Mukesh Ojha wrote:
> The Hawi SoC has two SMMU instances with different clock requirements.
> The Adreno GPU SMMU uses the qcom,adreno-smmu fallback and requires a
> single HLOS vote clock, matching the pattern already established for
> Glymur and SM8750. The Application Processor SMMU (APSS) uses the
> qcom,smmu-500 fallback and has no controllable clocks.
>
> Add qcom,hawi-smmu-500 to the single-clock constraint block for the
> Adreno GPU SMMU and to the no-clocks constraint block for the APSS SMMU,
> following the pattern how it is done for other SoCs.
If you decided to make a competitive simultaneous work, you could at
least tell me that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] KVM: arm64: nv: Don't save/restore FP register during a nested ERET or exception
From: Joey Gouly @ 2026-05-20 11:02 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, kvm, Steffen Eiden, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Mark Rutland, Will Deacon, Fuad Tabba
In-Reply-To: <20260520085036.541666-3-maz@kernel.org>
Hi Marc,
On Wed, May 20, 2026 at 09:50:36AM +0100, Marc Zyngier wrote:
> When switching between L1 and L2, we save the old state using
> kvm_arch_vcpu_put(), mutate the state in memory, then load the new
> state using kvm_arch_vcpu_load(). Any live FPSIMD/SVE state is saved
> and unbound, such that it can be lazily restored on a subsequent trap.
>
> The FPSIMD/SVE state is shared by exception levels, and only a handful
> of related control registers need to be changed when transitioning
> between L1 and L2. The save/restore of the common state is needless
> overhead, especially as trapping becomes exponentially more expensive
> with nesting.
>
> Avoid this overhead by leaving the common FPSIMD/SVE state live on the
> CPU, and only switching the state that is distinct for L1 and L2:
To make sure I understand this part:
L1 sets up L2's FP state live on the CPU
L1 erets
eret traps to L0/host
preemption disabled
kvm_arch_vcpu_put()
kvm_arch_vcpu_put_fp() <-- actually saves the state of the live registers
.. set elr etc ..
kvm_arch_vcpu_load()
kvm_arch_vcpu_load_fp() <-- doesn't actually restore state, but ensures
the CPTR trap will be set
.. returns to L2 (traps on first use of FP and state will be restored)
So this patch is (effectively) removing the put_fp()/load_fp(), because the FP
state is common/shared between L1 and L2, so whatever L1 put into that state
before the eret, L2 was going to see.
If my understanding is correct:
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Thanks,
Joey
>
> - the trap controls: the effective values are recomputed on each entry
> into the guest to take the EL into account and merge the L0 and L1
> configuration if in a nested context, or directly use the L0 configuration
> in non-nested context (see __activate_traps()).
>
> - the VL settings: the effective values are are also recomputed on each
> entry into the guest (see fpsimd_lazy_switch_to_guest()).
>
> Since we appear to cover all bases, use the vcpu flags indicating the
> handling of a nested ERET or exception delivery to avoid the whole FP
> save/restore shenanigans. SME will have to be similarly dealt with when
> it eventually gets supported.
>
> For an EL1 L3 guest where L1 and L2 have this optimisation, this
> results in at least a 10% wall clock reduction when running an I/O
> heavy workload, generating a high rate of nested exceptions.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/fpsimd.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 15e17aca1dec0..aca98752a6e42 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -28,6 +28,20 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> if (!system_supports_fpsimd())
> return;
>
> + /*
> + * Avoid needless save/restore of the guest's common
> + * FPSIMD/SVE/SME regs during transitions between L1/L2.
> + *
> + * These transitions only happens in a non-preemptible context
> + * where the host regs have already been saved and unbound. The
> + * live registers are either free or owned by the guest.
> + */
> + if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
> + vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION)) {
> + WARN_ON_ONCE(host_owns_fp_regs());
> + return;
> + }
> +
> /*
> * Ensure that any host FPSIMD/SVE/SME state is saved and unbound such
> * that the host kernel is responsible for restoring this state upon
> @@ -102,6 +116,15 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> {
> unsigned long flags;
>
> + /*
> + * See comment in kvm_arch_vcpu_load_fp().
> + */
> + if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
> + vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION)) {
> + WARN_ON_ONCE(host_owns_fp_regs());
> + return;
> + }
> +
> local_irq_save(flags);
>
> if (guest_owns_fp_regs()) {
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v15 0/9] Add Type-C DP support for RK3399 EVB IND board
From: Heiko Stuebner @ 2026-05-20 11:03 UTC (permalink / raw)
To: Heikki Krogerus, Chaoyi Chen, Dmitry Baryshkov, Luca Ceresoli,
Neil Armstrong
Cc: Chaoyi Chen, Greg Kroah-Hartman, Peter Chen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Kishon Vijay Abraham I, Sandy Huang, Andy Yan, Yubing Zhang,
Frank Wang, Andrzej Hajda, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Amit Sunil Dhamne,
Dragan Simic, Johan Jonker, Diederik de Haas, Peter Robinson,
Hugh Cole-Baker, linux-usb, devicetree, linux-kernel, linux-phy,
linux-arm-kernel, linux-rockchip, dri-devel
In-Reply-To: <c0bc4796-afe5-40ff-8816-9605a6114d23@rock-chips.com>
Hi,
Am Mittwoch, 20. Mai 2026, 03:13:25 Mitteleuropäische Sommerzeit schrieb Chaoyi Chen:
> Hello Heikki,
>
> On 5/19/2026 9:43 PM, Heikki Krogerus wrote:
> > Hi,
> >
> > On Wed, Mar 04, 2026 at 05:41:43PM +0800, Chaoyi Chen wrote:
> >> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> >>
> >> This series focuses on adding Type-C DP support for USBDP PHY and DP
> >> driver. The USBDP PHY and DP will perceive the changes in cable status
> >> based on the USB PD and Type-C state machines provided by TCPM. Before
> >> this, the USBDP PHY and DP controller of RK3399 sensed cable state
> >> changes through extcon, and devices such as the RK3399 Gru-Chromebook
> >> rely on them. This series should not break them.
> >
> > What's the status with this series?
> > Are these inteded to go via the DRM tree?
> >
> > thanks,
> >
>
> Thank you very much for your continued attention to this series.
> The maintainers seem quite busy... Despite there being no further review
> comments, this series have yet to be merged into the DRM tree.
>
> And some of my other patches are in the same situation.
> Do you happen to know what the next steps should be? Thank you.
For this series, I would think it'd be best to split it a bit.
- Make patches 1, 2, 5-7 its own series
* patch 5 _should_ be included here, needs an Ack from the phy-maintainer
to go through the drm-tree. It does look independent from the other
phy changes (code changes themself), but needs the function from patch 2.
- Make patches 3+4 its own series, so that phy maintainers notice
The code-changes themself seem independent of the rest
* Reference the drm-series and explicity note that the phy-patch in it
needs an Ack from the phy maintainer to through the drm-tree
Hopefully helps to get that
* patch 1 has a Reviewed-by from the type-c side, but needs someone
knowing drm-bridge internals to agree
- Makes patches 8+9 its own series, reference both series from above
as dependencies.
That would be my take here, to have the right maintainers notice they
should do something.
Heiko
^ permalink raw reply
* Re: [PATCH v15 9/9] arm64: dts: rockchip: rk3399-evb-ind: Add support for DisplayPort
From: Heiko Stuebner @ 2026-05-20 11:06 UTC (permalink / raw)
To: Heikki Krogerus, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Sandy Huang, Andy Yan,
Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, Chaoyi Chen
Cc: linux-usb, devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel, Chaoyi Chen
In-Reply-To: <20260304094152.92-10-kernel@airkyi.com>
Am Mittwoch, 4. März 2026, 10:41:52 Mitteleuropäische Sommerzeit schrieb Chaoyi Chen:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> The RK3399 EVB IND board has a Type-C interface DisplayPort.
> It use fusb302 chip as Type-C controller.
>
> fusb302 chip ---> USB/DP PHY0 <----> CDN-DP controller
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Apart from what I replied to the cover-letter, it might be
nice to split this into
- patch adding the fusb and general type-c parts
- patch adding the dp altmode
To make each part a bit shorter.
Heiko
^ permalink raw reply
* [PATCH] dt-bindings: arm-smmu: Correct and add constraints for Hawi, Shikra and Kaanapali
From: Krzysztof Kozlowski @ 2026-05-20 11:09 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, iommu,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Previous commit 75949eb02653 ("dt-bindings: arm-smmu: Constrain clocks
for newer Qualcomm variants") duplicated constraints for
qcom,sm6350-smmu-500 and qcom,sm6375-smmu-500 - these are already part
of previous "if:" block.
It also missed enforcing one clock for qcom,kaanapali-smmu-500 in GPU
case and missed simultaneously added Shikra and Hawi.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index ed0d10157bd6..5103adeee6d4 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -568,6 +568,8 @@ allOf:
items:
- enum:
- qcom,glymur-smmu-500
+ - qcom,hawi-smmu-500
+ - qcom,kaanapali-smmu-500
- qcom,sm8750-smmu-500
- const: qcom,adreno-smmu
- const: qcom,smmu-500
@@ -614,15 +616,15 @@ allOf:
- enum:
- qcom,eliza-smmu-500
- qcom,glymur-smmu-500
+ - qcom,hawi-smmu-500
- qcom,kaanapali-smmu-500
- qcom,milos-smmu-500
- qcom,qcs615-smmu-500
- qcom,qcs8300-smmu-500
- qcom,sa8775p-smmu-500
+ - qcom,shikra-smmu-500
- qcom,sm6115-smmu-500
- qcom,sm6125-smmu-500
- - qcom,sm6350-smmu-500
- - qcom,sm6375-smmu-500
- qcom,sm8150-smmu-500
- qcom,sm8250-smmu-500
- qcom,sm8350-smmu-500
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v15 6/9] drm/rockchip: cdn-dp: Support handle lane info without extcon
From: Heiko Stuebner @ 2026-05-20 11:10 UTC (permalink / raw)
To: Heikki Krogerus, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Sandy Huang, Andy Yan,
Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, Chaoyi Chen
Cc: linux-usb, devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel, Chaoyi Chen
In-Reply-To: <20260304094152.92-7-kernel@airkyi.com>
Am Mittwoch, 4. März 2026, 10:41:49 Mitteleuropäische Sommerzeit schrieb Chaoyi Chen:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> This patch add support for get PHY lane info without help of extcon.
>
> There is no extcon needed if the Type-C controller is present. In this
> case, the lane info can be get from PHY instead of extcon.
>
> The extcon device should still be supported if Type-C controller is
> not present.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v4 4/6] media: synopsys: Add PHY stopstate wait for i.MX93
From: Alexander Stein @ 2026-05-20 11:12 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil, Guoniu Zhou
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260519-csi2_imx95-v4-4-84ea4bb78a88@oss.nxp.com>
Hi,
Am Dienstag, 19. Mai 2026, 04:07:41 CEST schrieb Guoniu Zhou:
> Implement waiting for D-PHY lanes to enter stop state on i.MX93. This
> ensures proper PHY initialization by verifying that the clock lane and
> all active data lanes have entered the stop state before proceeding with
> further operations.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> Changes in v2:
> - Removes redundant register availability check
> - Uses read_poll_timeout() with dw_mipi_csi2rx_read() instead of
> readl_poll_timeout() with direct register address
> - Fixes stopstate condition logic
> - Check PHY stopstate after sensor enable instead of before to ensure
> correct timing.
> - Optimize PHY stopstate polling parameters (1000us->10us, 2s->1ms) to
> balance performance and responsiveness.
> ---
> drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 36 ++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> index 92178a3dec5d..8a34aec550ad 100644
> --- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> +++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> @@ -11,6 +11,7 @@
> #include <linux/clk.h>
> #include <linux/delay.h>
> #include <linux/io.h>
> +#include <linux/iopoll.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/phy/phy.h>
> @@ -35,6 +36,8 @@
> #define DW_REG_EXIST BIT(31)
> #define DW_REG(x) (DW_REG_EXIST | (x))
>
> +#define DPHY_STOPSTATE_CLK_LANE BIT(16)
> +
> #define DPHY_TEST_CTRL0_TEST_CLR BIT(0)
>
> #define IPI_VCID_VC(x) FIELD_PREP(GENMASK(1, 0), (x))
> @@ -65,6 +68,7 @@ enum dw_mipi_csi2rx_regs_index {
> DW_MIPI_CSI2RX_PHY_TST_CTRL0,
> DW_MIPI_CSI2RX_PHY_TST_CTRL1,
> DW_MIPI_CSI2RX_PHY_SHUTDOWNZ,
> + DW_MIPI_CSI2RX_PHY_STOPSTATE,
> DW_MIPI_CSI2RX_IPI_DATATYPE,
> DW_MIPI_CSI2RX_IPI_MEM_FLUSH,
> DW_MIPI_CSI2RX_IPI_MODE,
> @@ -87,6 +91,7 @@ struct dw_mipi_csi2rx_drvdata {
> void (*dphy_assert_reset)(struct dw_mipi_csi2rx_device *csi2);
> void (*dphy_deassert_reset)(struct dw_mipi_csi2rx_device *csi2);
> void (*ipi_enable)(struct dw_mipi_csi2rx_device *csi2);
> + int (*wait_for_phy_stopstate)(struct dw_mipi_csi2rx_device *csi2);
> };
>
> struct dw_mipi_csi2rx_format {
> @@ -139,6 +144,7 @@ static const u32 imx93_regs[DW_MIPI_CSI2RX_MAX] = {
> [DW_MIPI_CSI2RX_PHY_SHUTDOWNZ] = DW_REG(0x40),
> [DW_MIPI_CSI2RX_DPHY_RSTZ] = DW_REG(0x44),
> [DW_MIPI_CSI2RX_PHY_STATE] = DW_REG(0x48),
> + [DW_MIPI_CSI2RX_PHY_STOPSTATE] = DW_REG(0x4c),
> [DW_MIPI_CSI2RX_PHY_TST_CTRL0] = DW_REG(0x50),
> [DW_MIPI_CSI2RX_PHY_TST_CTRL1] = DW_REG(0x54),
> [DW_MIPI_CSI2RX_IPI_MODE] = DW_REG(0x80),
> @@ -556,10 +562,19 @@ static int dw_mipi_csi2rx_enable_streams(struct v4l2_subdev *sd,
> if (ret)
> goto err_csi_stop;
>
> + if (!csi2->enabled_streams &&
> + csi2->drvdata->wait_for_phy_stopstate) {
> + ret = csi2->drvdata->wait_for_phy_stopstate(csi2);
> + if (ret)
> + goto err_disable_streams;
> + }
> +
> csi2->enabled_streams |= streams_mask;
>
> return 0;
>
> +err_disable_streams:
> + v4l2_subdev_disable_streams(remote_sd, remote_pad->index, mask);
> err_csi_stop:
> /* Stop CSI hardware if no streams are enabled */
> if (!csi2->enabled_streams)
> @@ -871,11 +886,32 @@ static void imx93_csi2rx_dphy_ipi_enable(struct dw_mipi_csi2rx_device *csi2)
> dw_mipi_csi2rx_write(csi2, DW_MIPI_CSI2RX_IPI_MODE, val);
> }
>
> +static int imx93_csi2rx_wait_for_phy_stopstate(struct dw_mipi_csi2rx_device *csi2)
> +{
> + struct device *dev = csi2->dev;
> + u32 stopstate_mask;
> + u32 val;
> + int ret;
> +
> + stopstate_mask = DPHY_STOPSTATE_CLK_LANE | GENMASK(csi2->lanes_num - 1, 0);
> +
> + ret = read_poll_timeout(dw_mipi_csi2rx_read, val,
> + (val & stopstate_mask) == stopstate_mask,
> + 10, 1000, true,
> + csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE);
> + if (ret)
> + dev_err(dev, "lanes are not in stop state: %#x, expected %#x\n",
> + val, stopstate_mask);
Did you actually test this on imx93? I'm trying to get my imx327 sensor to
run, but only run into this error message:
dw-mipi-csi2rx 4ae00000.mipi-csi: lanes are not in stop state: 0x0, expected 0x10003
Currently I'm using this DT node:
--8<--
mipi_csi: mipi-csi@4ae00000 {
compatible = "fsl,imx93-mipi-csi2";
reg = <0x4ae00000 0x10000>;
interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX93_CLK_MIPI_CSI_GATE>,
<&clk IMX93_CLK_CAM_PIX>;
clock-names = "per", "pixel";
assigned-clocks = <&clk IMX93_CLK_CAM_PIX>;
assigned-clock-parents = <&clk IMX93_CLK_VIDEO_PLL>;
assigned-clock-rates = <140000000>;
power-domains = <&media_blk_ctrl IMX93_MEDIABLK_PD_MIPI_CSI>;
phys = <&dphy_rx>;
phy-names = "dphy-rx";
status = "disabled";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
mipi_from_sensor: endpoint {
data-lanes = <1 2>;
bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
};
};
port@1 {
reg = <1>;
mipi_to_isi: endpoint {
remote-endpoint = <&isi_in>;
};
};
};
};
--8<--
Am I'm missing something?
best regards,
Alexander
> +
> + return ret;
> +}
> +
> static const struct dw_mipi_csi2rx_drvdata imx93_drvdata = {
> .regs = imx93_regs,
> .dphy_assert_reset = imx93_csi2rx_dphy_assert_reset,
> .dphy_deassert_reset = imx93_csi2rx_dphy_deassert_reset,
> .ipi_enable = imx93_csi2rx_dphy_ipi_enable,
> + .wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
> };
>
> static const struct of_device_id dw_mipi_csi2rx_of_match[] = {
>
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH v15 7/9] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection
From: Heiko Stuebner @ 2026-05-20 11:12 UTC (permalink / raw)
To: Heikki Krogerus, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Sandy Huang, Andy Yan,
Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, Chaoyi Chen
Cc: linux-usb, devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel, Chaoyi Chen
In-Reply-To: <20260304094152.92-8-kernel@airkyi.com>
Am Mittwoch, 4. März 2026, 10:41:50 Mitteleuropäische Sommerzeit schrieb Chaoyi Chen:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> The RK3399 has two USB/DP combo PHY and one CDN-DP controller. And
> the CDN-DP can be switched to output to one of the PHYs. If both ports
> are plugged into DP, DP will select the first port for output.
>
> This patch adds support for multiple bridges, enabling users to flexibly
> select the output port. For each PHY port, a separate encoder and bridge
> are registered.
>
> The change is based on the DRM AUX HPD bridge, rather than the
> extcon approach. This requires the DT to correctly describe the
> connections between the first bridge in bridge chain and DP
> controller. For example, the bridge chain may be like this:
>
> PHY aux birdge -> fsa4480 analog audio switch bridge ->
> onnn,nb7vpq904m USB reminder bridge -> USB-C controller AUX HPD bridge
>
> In this case, the connection relationships among the PHY aux bridge
> and the DP contorller need to be described in DT.
>
> In addition, the cdn_dp_parse_next_bridge_dt() will parses it and
> determines whether to register one or two bridges.
>
> Since there is only one DP controller, only one of the PHY ports can
> output at a time. The key is how to switch between different PHYs,
> which is handled by cdn_dp_switch_port() and cdn_dp_enable().
>
> There are two cases:
>
> 1. Neither bridge is enabled. In this case, both bridges can
> independently read the EDID, and the PHY port may switch before
> reading the EDID.
>
> 2. One bridge is already enabled. In this case, other bridges are not
> allowed to read the EDID. So we will try to return the cached EDID.
>
> Since the scenario of two ports plug in at the same time is rare,
> I don't have a board which support two TypeC connector to test this.
> Therefore, I tested forced switching on a single PHY port, as well as
> output using a fake PHY port alongside a real PHY port.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH AUTOSEL 7.0-6.12] KVM: arm64: nv: Consider the DS bit when translating TCR_EL2
From: Sasha Levin @ 2026-05-20 11:18 UTC (permalink / raw)
To: patches, stable
Cc: Wei-Lin Chang, Marc Zyngier, Sasha Levin, oupton, catalin.marinas,
will, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Wei-Lin Chang <weilin.chang@arm.com>
[ Upstream commit 8d9b9d985ad3a81c751a6b97edaf1d3c0780af7c ]
When running an nVHE L1, TCR_EL2 is mapped to TCR_EL1. Writes to the
register are trapped and written to TCR_EL1 after a translation.
Booting an nVHE L1 with 52-bit VA isn't working because the translation
was ignoring the DS bit set by the guest, hence causing repeating level
0 faults. Add it in the translation function.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
Link: https://patch.msgid.link/20260505144735.1496530-1-weilin.chang@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Stable Backport Analysis
### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `KVM: arm64: nv`; action verb is
“Consider”; intent is to preserve the `DS` bit when translating
`TCR_EL2` into `TCR_EL1` for nested virtualization.
Step 1.2 Record: Tags present are:
- `Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>`
- `Link: https://patch.msgid.link/20260505144735.1496530-1-
weilin.chang@arm.com`
- `Signed-off-by: Marc Zyngier <maz@kernel.org>`
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
or `Cc: stable@vger.kernel.org` tags are present.
Step 1.3 Record: The bug is that an nVHE L1 guest using 52-bit VA cannot
boot because trapped writes to `TCR_EL2` are translated to `TCR_EL1`
without carrying over the guest’s `DS` bit. The recorded failure mode is
repeated level 0 faults. No affected kernel version is stated in the
message. Root cause is an incomplete EL2-to-EL1 TCR translation.
Step 1.4 Record: This is not hidden as cleanup; it is a direct
correctness fix for guest boot failure.
### Phase 2: Diff Analysis
Step 2.1 Record: One file changed:
`arch/arm64/include/asm/kvm_nested.h`, 1 insertion, 0 deletions.
Function modified: `translate_tcr_el2_to_tcr_el1()`. Scope is a single-
file surgical fix.
Step 2.2 Record: Before, `translate_tcr_el2_to_tcr_el1()` preserved
`TBI`, physical size, granule, cacheability, shareability, and `T0SZ`,
but ignored `TCR_EL2_DS`. After, it adds `TCR_DS` to the EL1 value when
`TCR_EL2_DS` is set. This affects the normal path where KVM programs the
physical EL1 `TCR` while running an nVHE L1.
Step 2.3 Record: Bug category is logic/correctness. The specific
mechanism is a missing architectural bit translation: `TCR_EL2_DS` is
bit 32, while `TCR_EL1.DS` is bit 59, so it cannot be preserved by the
existing mask-copy operations and must be explicitly mapped.
Step 2.4 Record: The fix is obviously correct and minimal. Regression
risk is very low: it only sets `TCR_EL1.DS` when the guest already set
the corresponding `TCR_EL2.DS` bit.
### Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows `translate_tcr_el2_to_tcr_el1()` was
introduced by `3606e0b2e46216` (“KVM: arm64: nv: Add non-VHE-EL2->EL1
translation helpers”), first contained in `v6.8-rc1`. The buggy omission
is long-lived relative to current stable trees.
Step 3.2 Record: No `Fixes:` tag is present, so there is no tagged
introducer to follow. The blame commit above is the practical introducer
of the incomplete translation.
Step 3.3 Record: Recent history of `arch/arm64/include/asm/kvm_nested.h`
shows active nested-virt development, including 52-bit PA/LPA2 related
work. No prerequisite patch for this one-line change was identified
beyond the existing definitions already present in stable tags checked.
Step 3.4 Record: Wei-Lin Chang has multiple recent `KVM: arm64`/nested-
virt commits. Marc Zyngier, listed in `MAINTAINERS` as a KVM/arm64
maintainer, committed the patch.
Step 3.5 Record: `git log --grep=translate_tcr_el2_to_tcr_el1` found no
other commits mentioning the helper. The patch applies cleanly to the
current checked-out stable tree with `git apply --check`.
### Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 8d9b9d985ad3a81c751a6b97edaf1d3c0780af7c`
found the original submission at the provided patch link. `b4 dig -a`
found only v1. The thread includes Marc Zyngier’s “Applied to fixes”
reply and no objections.
Step 4.2 Record: `b4 dig -w` shows the patch was sent to `linux-arm-
kernel`, `kvmarm`, `linux-kernel`, and KVM/arm64 maintainers/reviewers
including Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, and Will Deacon.
Step 4.3 Record: No separate bug report or syzbot report was found in
the commit tags or b4 thread. The commit message itself gives the
observed boot failure.
Step 4.4 Record: The patch is standalone, single-patch v1; no multi-
patch series dependency was found.
Step 4.5 Record: No stable-specific discussion was found. WebFetch to
lore was blocked by Anubis, but b4 successfully retrieved the thread.
### Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `translate_tcr_el2_to_tcr_el1()`.
Step 5.2 Record: Callers found:
- `locate_register()` maps `TCR_EL2` to `TCR_EL1` with this translation
for loaded nVHE hyp context.
- `__sysreg_restore_vel2_state()` restores nVHE virtual EL2 state by
translating guest `TCR_EL2` before writing physical `SYS_TCR`.
Step 5.3 Record: Key callees are `tcr_el2_ps_to_tcr_el1_ips()` and the
bit definitions/macros for `TCR_EL2_*` and `TCR_*`. The function has no
allocation, locking, or complex side effects; it returns a composed
register value.
Step 5.4 Record: Reachability is verified through guest sysreg traps:
`ESR_ELx_EC_SYS64` goes to `kvm_handle_sys_reg()`, then
`perform_access()`, then the `TCR_EL2` descriptor with `access_rw()`,
then `vcpu_write_sys_reg()`, which applies `loc.xlate()` when the mapped
register is loaded. This is reachable by an L1 guest using EL2.
Step 5.5 Record: Similar translation helpers exist for `SCTLR_EL2`,
`CPTR_EL2`, and `TTBR0_EL2`; this patch fixes the missing special-case
bit in the TCR helper. `TCR_EL1.DS` and `TCR_EL2.DS` are at different
bit positions, so the existing mask copying cannot handle it.
### Phase 6: Stable Tree Analysis
Step 6.1 Record: The helper commit is present in checked tags `v6.12`,
`v6.18`, `v6.19`, and `v7.0`. The LPA2 DS field definitions are also
present in those tags. The 52-bit PA helper commit checked is present in
`v6.18`, `v6.19`, and `v7.0`, but not `v6.12`.
Step 6.2 Record: Expected backport difficulty is low for trees with this
helper. `b4 am` reported “Base: applies clean to current tree”, and `git
apply --check` succeeded on the current `v7.0.9` checkout.
Step 6.3 Record: No related fix for “Consider the DS bit” is in `v7.0`
or `v7.0.9`; `git merge-base --is-ancestor` returned absent for the
candidate in those tags.
### Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is KVM/arm64 nested virtualization.
Criticality is IMPORTANT: it affects ARM64 KVM users running nested
virtualization with nVHE L1 guests and 52-bit VA.
Step 7.2 Record: Subsystem is actively maintained; recent
`arch/arm64/kvm` history contains multiple KVM/arm64 fixes, and
`MAINTAINERS` marks KVM/arm64 as maintained by Marc Zyngier and Oliver
Upton.
### Phase 8: Impact And Risk Assessment
Step 8.1 Record: Affected population is platform/config-specific: ARM64
KVM users with nested virtualization and an nVHE L1 using 52-bit VA.
Step 8.2 Record: Trigger is booting or running such an nVHE L1 with
`TCR_EL2.DS` set. The path is guest-triggerable through EL2 sysreg
writes, but only for VMs configured with nested virtualization support.
Step 8.3 Record: Failure mode is repeated level 0 faults and failed L1
boot. Severity is HIGH for affected users because the guest hypervisor
cannot boot correctly.
Step 8.4 Record: Benefit is high for affected nested virtualization
users. Risk is very low: one line, no API change, no locking, no data
structure change, and only changes behavior when the guest sets
`TCR_EL2_DS`.
### Phase 9: Final Synthesis
Step 9.1 Record:
Evidence for backporting:
- Fixes a real boot failure for nVHE L1 guests with 52-bit VA.
- One-line, contained architectural bit translation.
- Existing definitions verify this is a required bit-position mapping,
not a feature addition.
- Maintainer applied it to the KVM/arm64 fixes branch.
- Applies cleanly to the current stable checkout.
- Buggy helper exists in active stable-era tags checked.
Evidence against backporting:
- No `Fixes:`, `Reported-by:`, `Tested-by:`, or explicit stable tag.
- Affected population is narrower than core KVM users.
- Exact user-visible 52-bit VA nested scenario was not fully proven for
every older stable branch, especially `v6.12`.
Unresolved:
- I did not build-test or boot-test.
- I did not verify clean application to every stable branch
individually.
- WebFetch could not read lore directly due Anubis, though b4 retrieved
the thread.
Step 9.2 Stable rules:
1. Obviously correct and tested? Obviously correct by code inspection;
no explicit Tested-by found.
2. Fixes a real bug? Yes, commit message and code path verify a missing
required register bit translation causing L1 boot failure.
3. Important issue? Yes, boot failure/repeated translation faults for
affected nested virtualization guests.
4. Small and contained? Yes, 1 line in one helper.
5. No new features/APIs? Yes.
6. Can apply to stable trees? Yes for current checked stable tree;
likely straightforward for trees containing this helper.
Step 9.3 Exception category: None. This is not a device ID, quirk, DT,
build, or documentation exception; it is a direct bug fix.
Step 9.4 Decision: Backport. The fix is small, technically clear, and
corrects an architectural register translation bug that prevents a
supported nested-virtualization configuration from booting.
## Verification
- Phase 1: Parsed `git show` for candidate
`8d9b9d985ad3a81c751a6b97edaf1d3c0780af7c`; confirmed subject, body,
and tags.
- Phase 2: Inspected exact diff; confirmed 1 insertion in
`translate_tcr_el2_to_tcr_el1()`.
- Phase 2: Verified `TCR_EL2_DS` is bit 32 in
`arch/arm64/include/asm/kvm_arm.h`.
- Phase 2: Verified `TCR_EL1.DS` is bit 59 in `arch/arm64/tools/sysreg`
and `TCR_DS` aliases it in `arch/arm64/include/asm/pgtable-hwdef.h`.
- Phase 3: `git blame` identified `3606e0b2e46216` as introducer of the
helper.
- Phase 3: `git describe --contains 3606e0b2e46216` reported first
containment at `v6.8-rc1`.
- Phase 3: `git log` on affected files found related nested-virt/LPA2
activity and no required adjacent patch.
- Phase 4: `b4 dig -c` found the original patch by patch-id.
- Phase 4: `b4 dig -a` found only v1.
- Phase 4: `b4 dig -w` confirmed KVM/arm64 maintainers and lists were
included.
- Phase 4: `b4 mbox -c -o -` retrieved Marc Zyngier’s applied-to-fixes
reply.
- Phase 5: `rg` found callers in `sys_regs.c` and `hyp/vhe/sysreg-sr.c`.
- Phase 5: Read trap path from `handle_exit.c`, `sys_regs.c`, and
`arm.c`; verified guest sysreg traps can reach the translation.
- Phase 6: `git merge-base --is-ancestor` confirmed the helper and DS
definitions are present in `v6.12`, `v6.18`, `v6.19`, and `v7.0`.
- Phase 6: `git apply --check` succeeded on the current stable checkout.
- Phase 7: Read `MAINTAINERS`; confirmed Marc Zyngier and Oliver Upton
maintain KVM/arm64.
- Phase 8: Failure mode verified from commit message and code path;
exact boot reproduction was not run.
- UNVERIFIED: No build or boot test was performed.
- UNVERIFIED: Clean application to every individual stable branch was
not tested.
- UNVERIFIED: Exact impact on older stable trees lacking later 52-bit PA
helper work was not fully established.
**YES**
arch/arm64/include/asm/kvm_nested.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h
index 091544e6af442..dc2957662ff20 100644
--- a/arch/arm64/include/asm/kvm_nested.h
+++ b/arch/arm64/include/asm/kvm_nested.h
@@ -23,6 +23,7 @@ static inline u64 tcr_el2_ps_to_tcr_el1_ips(u64 tcr_el2)
static inline u64 translate_tcr_el2_to_tcr_el1(u64 tcr)
{
return TCR_EPD1_MASK | /* disable TTBR1_EL1 */
+ ((tcr & TCR_EL2_DS) ? TCR_DS : 0) |
((tcr & TCR_EL2_TBI) ? TCR_TBI0 : 0) |
tcr_el2_ps_to_tcr_el1_ips(tcr) |
(tcr & TCR_EL2_TG0_MASK) |
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] fbdev: ipu-v3: clean up kernel-doc warnings
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Randy Dunlap, Philipp Zabel, Helge Deller, Sasha Levin, Frank.Li,
linux-fbdev, dri-devel, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit f1fb23a0a0fcbdb66672da51d7d63a259f6396ca ]
Correct all kernel-doc warnings:
- fix a typedef kernel-doc comment
- mark a list_head as private
- use Returns: for function return values
Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
described in 'ipu_image_convert_run'
Warning: include/video/imx-ipu-image-convert.h:40 function parameter
'ipu_image_convert_cb_t' not described in 'void'
Warning: include/video/imx-ipu-image-convert.h:40 expecting prototype for
ipu_image_convert_cb_t(). Prototype was for void() instead
Warning: include/video/imx-ipu-image-convert.h:66 No description found for
return value of 'ipu_image_convert_verify'
Warning: include/video/imx-ipu-image-convert.h:90 No description found for
return value of 'ipu_image_convert_prepare'
Warning: include/video/imx-ipu-image-convert.h:125 No description found for
return value of 'ipu_image_convert_queue'
Warning: include/video/imx-ipu-image-convert.h:163 No description found for
return value of 'ipu_image_convert'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `fbdev: ipu-v3`; action verb `clean up`;
intent is to correct kernel-doc warnings in `include/video/imx-ipu-
image-convert.h`.
Step 1.2 Record: tags in committed message are `Signed-off-by: Randy
Dunlap <rdunlap@infradead.org>`, `Reviewed-by: Philipp Zabel
<p.zabel@pengutronix.de>`, and `Signed-off-by: Helge Deller
<deller@gmx.de>`. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Acked-
by:`, `Link:`, or `Cc: stable@vger.kernel.org` tag is present in the
committed message.
Step 1.3 Record: the described problem is seven kernel-doc warnings: one
undocumented/private list member, malformed typedef documentation, and
missing `Returns:` sections. The visible symptom is documentation
tooling warnings, not a runtime crash, hang, data corruption, or
security issue. No affected kernel version is stated. Root cause is
incorrect kernel-doc comment syntax.
Step 1.4 Record: this is not a hidden runtime bug fix. The body and diff
both show a documentation/comment-only cleanup.
## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `include/video/imx-ipu-image-
convert.h`, 11 insertions and 5 deletions. Modified documentation covers
`struct ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`. Scope is single-
file, header-only, surgical.
Step 2.2 Record: hunk behavior:
- `struct ipu_image_convert_run`: before, `list` was documented neither
as a member nor private; after, `/* private: */` tells kernel-doc to
ignore it as an API member.
- `ipu_image_convert_cb_t`: before, kernel-doc treated the typedef
comment as a function prototype mismatch; after, it is marked as a
typedef comment.
- Return docs: before, several returns were plain prose or missing;
after, they use kernel-doc `Returns:` syntax.
- `ipu_image_convert_prepare()`: before, the V4L2 usage note followed
the return prose; after, the return section is last and formatted for
kernel-doc.
Step 2.3 Record: bug category is documentation/kernel-doc warning
cleanup. No error-path, synchronization, refcount, memory-safety,
initialization, type, logic, or hardware workaround change exists.
Step 2.4 Record: fix quality is high for the stated documentation issue:
small, obviously correct kernel-doc syntax changes. Runtime regression
risk is effectively zero because no C declarations, types, function
bodies, data layout, or APIs are changed. Documentation rendering risk
is very low.
## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the affected header comments and
declarations came from `cd98e85a6b786d` by Steve Longerbeam, dated
2016-09-17. `git describe --contains cd98e85a6b786d` reports it as
present by `v4.9-rc1~41^2~24^2`.
Step 3.2 Record: no `Fixes:` tag is present, so there is no tagged
introducing commit to follow. Blame identifies `cd98e85a6b786d` as the
source of the documented preimage; `git show` confirms that commit added
queued IPU image conversion support and the API documentation.
Step 3.3 Record: recent local history for the file shows `96e9d754b35e8`
removing unused `ipu_image_convert_*` functions, `c942fddf8793b` adding
SPDX boilerplate conversion, and `cd98e85a6b786d` adding the header/API.
No prerequisite commit is needed for this documentation-only patch.
Step 3.4 Record: `git log --author='Randy Dunlap'` under fbdev/include
areas shows Randy has related cleanup/documentation work such as `fbdev:
hgafb: fix kernel-doc comments` and `fbdev: fbmon: fix function name in
kernel-doc`. The patch was reviewed by Philipp Zabel and committed by
Helge Deller, verified from the commit and lore thread.
Step 3.5 Record: no dependencies found. The diff changes only comments
and applies locally with `git apply --check`.
## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`
failed to find a lore match by patch-id, author/subject, or in-body
From. External fetch found the v3 discussion at
`https://yhbt.net/lore/dri-
devel/20260427183236.656902-1-rdunlap@infradead.org/T/`. The v3 thread
has Helge Deller replying “applied to fbdev git tree.” Web search/fetch
also found v2 and a v2 ping. No NAKs or objections were found.
Step 4.2 Record: `b4 dig -w` also failed for the same reason. The v3
lore mirror shows recipients included `dri-devel`, Philipp Zabel, DRM
maintainers, `imx`, `linux-arm-kernel`, Helge Deller, and `linux-fbdev`.
Step 4.3 Record: no `Reported-by:` or bug-report `Link:` tags exist. No
external crash/security bug report applies.
Step 4.4 Record: this is a standalone one-patch documentation cleanup.
v2 added the reviewed-by and updated Cc list; v3 rebased and resent.
Step 4.5 Record: direct `lore.kernel.org/stable` fetch was blocked by
Anubis. Web search for the exact subject plus `stable` found patch-
thread results but no stable-specific discussion or stable nomination.
## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified documented symbols are
`ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`.
Step 5.2 Record: `rg` found callers in `drivers/staging/media/imx/imx-
media-csc-scaler.c` for `ipu_image_convert_abort()`,
`ipu_image_convert_queue()`, `ipu_image_convert_adjust()`,
`ipu_image_convert_unprepare()`, and `ipu_image_convert_prepare()`.
Runtime callers are unaffected because only comments changed.
Step 5.3 Record: reading `drivers/gpu/ipu-v3/ipu-image-convert.c`
confirms the documented functions perform image format
adjustment/verification, context allocation, queueing, abort/unprepare,
and single conversion setup. None of those function bodies are touched.
Step 5.4 Record: runtime path is reachable through IPU image conversion
users, but the patch changes no runtime path. The affected path for the
fix is kernel-doc/documentation generation.
Step 5.5 Record: no related same-header kernel-doc fix was found by `git
log --grep='kernel-doc' -- include/video/imx-ipu-image-convert.h`.
## Phase 6: Stable Tree Analysis
Step 6.1 Record: version tags `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.15`, `v6.16`, and `v6.17` all contain `include/video/imx-ipu-image-
convert.h` with the old kernel-doc text. The API was introduced before
`v4.9-rc1`, so active stable trees checked contain the documentation
issue.
Step 6.2 Record: expected backport difficulty is clean or minor. `git
apply --check` succeeds against the current local tree, and the checked
stable tags contain representative preimage lines. Full per-stable
worktree application was not run.
Step 6.3 Record: no related stable fix for this header was found in
local `git log --grep` searches.
## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is fbdev/gpu IPU-v3 image conversion
documentation in an include header. Runtime criticality is
peripheral/driver-specific; documentation-build criticality is low.
Step 7.2 Record: local subsystem history shows ongoing cleanup/removal
activity in `drivers/gpu/ipu-v3` and the header, including unused-
function removals and treewide cleanup. This patch is not part of a
required functional series.
## Phase 8: Impact And Risk
Step 8.1 Record: affected population is kernel documentation builders,
maintainers, and users consuming generated kernel-doc. Runtime users of
IPU-v3 are not affected by behavior.
Step 8.2 Record: trigger is running kernel-doc/documentation tooling
over this header. It is not triggered by boot, device probe, syscalls,
or ordinary runtime use. Unprivileged runtime trigger does not apply.
Step 8.3 Record: failure mode is documentation warnings only. Severity
is LOW. I did not verify any configuration where these warnings are
fatal, so that does not drive the decision.
Step 8.4 Record: benefit is low but real under the documentation-fix
exception: it makes stable documentation builds cleaner. Risk is
extremely low because only comments change. Risk/benefit is favorable if
stable accepts documentation corrections.
## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: pure documentation
correction, explicitly fixes listed kernel-doc warnings, tiny single-
file patch, reviewed by Philipp Zabel, applied by Helge Deller, old text
exists in active stable tags checked, and documentation/comment fixes
are an allowed stable exception. Evidence against: no runtime bug, no
crash/security/data-corruption impact, no stable nomination found, and
b4 could not match the thread. Unresolved: direct stable-lore search was
blocked; full apply checks on every stable branch were not run.
Step 9.2 Record:
1. Obviously correct and tested? Mostly yes for documentation syntax;
reviewed and applied, but no `Tested-by`.
2. Fixes a real bug that affects users? Yes, a real kernel-doc warning
issue; not a runtime bug.
3. Important issue? No runtime severity; LOW documentation-build
severity.
4. Small and contained? Yes, 11 additions and 5 deletions in one header.
5. No new features or APIs? Yes, comments only.
6. Can apply to stable trees? Likely yes; local apply check passed and
stable tags checked contain the preimage.
Step 9.3 Record: exception category applies: documentation/comment fix.
This is the main reason to accept despite lack of runtime impact.
Step 9.4 Decision: backporting is appropriate under the stable
documentation-fix exception. It is not a stability/security fix, but it
is a correct, reviewed, zero-runtime-risk cleanup of real kernel-doc
warnings in code present across active stable trees.
## Verification
- Phase 1: fetched and inspected committed metadata for
`f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`; confirmed tags and
message.
- Phase 2: `git show --stat --patch` confirmed one header, 11
insertions, 5 deletions, comments only.
- Phase 3: `git blame` confirmed changed comment preimage from
`cd98e85a6b786d`; `git describe --contains` placed it before
`v4.9-rc1`; `git show cd98e85a6b786d` confirmed original API addition.
- Phase 3: `git log` on the header/subsystem found no prerequisite
functional series.
- Phase 4: `b4 dig`, `b4 dig -a`, and `b4 dig -w` all failed to match;
recorded as a tool limitation/failure.
- Phase 4: WebFetch of the v3 lore mirror confirmed the patch thread and
Helge Deller’s applied reply; Spinics fetch confirmed v2 and a later
ping.
- Phase 5: `rg` found runtime users; `ReadFile` of implementation
confirmed function bodies exist but are not changed.
- Phase 6: tag checks confirmed the header and old doc text in `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.15`, `v6.16`, and `v6.17`; `git
apply --check` succeeded locally.
- Phase 8: severity/risk assessment is derived from the verified
comments-only diff.
- UNVERIFIED: direct `lore.kernel.org/stable` search content was blocked
by Anubis; no actual `make htmldocs` run was performed; full patch
application against every individual stable branch was not performed.
**YES**
include/video/imx-ipu-image-convert.h | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/video/imx-ipu-image-convert.h b/include/video/imx-ipu-image-convert.h
index 003b3927ede5c..6b77968a6a150 100644
--- a/include/video/imx-ipu-image-convert.h
+++ b/include/video/imx-ipu-image-convert.h
@@ -27,12 +27,13 @@ struct ipu_image_convert_run {
int status;
+ /* private: */
/* internal to image converter, callers don't touch */
struct list_head list;
};
/**
- * ipu_image_convert_cb_t - conversion callback function prototype
+ * typedef ipu_image_convert_cb_t - conversion callback function prototype
*
* @run: the completed conversion run pointer
* @ctx: a private context pointer for the callback
@@ -60,7 +61,7 @@ void ipu_image_convert_adjust(struct ipu_image *in, struct ipu_image *out,
* @out: output image format
* @rot_mode: rotation mode
*
- * Returns 0 if the formats and rotation mode meet IPU restrictions,
+ * Returns: 0 if the formats and rotation mode meet IPU restrictions,
* -EINVAL otherwise.
*/
int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
@@ -77,11 +78,11 @@ int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
* @complete: run completion callback
* @complete_context: a context pointer for the completion callback
*
- * Returns an opaque conversion context pointer on success, error pointer
+ * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
+ *
+ * Returns: an opaque conversion context pointer on success, error pointer
* on failure. The input/output formats and rotation mode must already meet
* IPU retrictions.
- *
- * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
*/
struct ipu_image_convert_ctx *
ipu_image_convert_prepare(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
@@ -122,6 +123,8 @@ void ipu_image_convert_unprepare(struct ipu_image_convert_ctx *ctx);
* In V4L2, drivers should call ipu_image_convert_queue() while
* streaming to queue the conversion of a received input buffer.
* For example mem2mem devices this would be called in .device_run.
+ *
+ * Returns: 0 on success or -errno on error.
*/
int ipu_image_convert_queue(struct ipu_image_convert_run *run);
@@ -155,6 +158,9 @@ void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx);
* On successful return the caller can queue more run requests if needed, using
* the prepared context in run->ctx. The caller is responsible for unpreparing
* the context when no more conversion requests are needed.
+ *
+ * Returns: pointer to the created &struct ipu_image_convert_run that has
+ * been queued on success; an ERR_PTR(errno) on error.
*/
struct ipu_image_convert_run *
ipu_image_convert(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
--
2.53.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