* Re: [PATCH 02/17] raid6: remove __KERNEL__ ifdefs
From: Eric Biggers @ 2026-03-25 19:58 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Christoph Hellwig, Andrew Morton, Catalin Marinas, Will Deacon,
Ard Biesheuvel, Huacai Chen, WANG Xuerui, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, Herbert Xu,
Dan Williams, Chris Mason, David Sterba, Arnd Bergmann, Song Liu,
Yu Kuai, Li Nan, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, linux-crypto, linux-btrfs,
linux-arch, linux-raid
In-Reply-To: <fa11e4d3-1c70-4fa7-9f03-8772c002be6a@zytor.com>
On Wed, Mar 25, 2026 at 09:13:16AM -0700, H. Peter Anvin wrote:
> On 2026-03-25 08:13, H. Peter Anvin wrote:
> > On 2026-03-23 23:40, Christoph Hellwig wrote:
> >> With the test code ported to kernel space, none of this is required.
> >
> > I really *really* don't like this.
> >
> > The ability of running in user space is really useful when it comes to
> > developing new code for new platforms, which happens often enough for this code.
> >
>
> That being said -- and I do say this as the original author of this code --
> this should be reduced to the maximum extent possible to a (minimal) set of
> #ifndef __KERNEL__, which should be localized as much as possible. The actual
> user space components, even such a thing as a simple #include, should be moved
> to a separate user space header.
>
> But pretty please do leave the ability to debug the algorithms in user space.
> This is hard code to write and debug; it is not just about regression testing.
While I do like developing code in userspace as well, I've been doing it
less over time as the kernel's tests and benchmarks have been improved.
Running the KUnit tests is pretty straightforward and fast.
The issues with providing userspace build support in the tree are that:
- It has to be maintained.
- It's fundamentally a bit of a hack that is used only by developers
(who always have the option of doing something locally that is
tailored to the specific function they're working on)
- It diverts effort from the kernel's actual test and benchmark.
So while the faster iteration speed that userspace development enables
is definitely nice, I do think we should be cautious with committing to
maintain it in the kernel tree. If it's causing problems for the
ongoing refactoring, dropping it for now seems reasonable to me.
I would suggest adding a benchmark to the KUnit test similar to the
crypto and CRC ones, though.
- Eric
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Andrew Lunn @ 2026-03-25 19:45 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
AngeloGioacchino Del Regno, Heiner Kallweit, Russell King,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <199e674cfdbccad104db761964611b1d6352f9f3.camel@collabora.com>
> > You configure the PHY to support downshift. If it has performed a
> > downshift, does it report the actual speed in the usual registers
> > read
> > by genphy_read_status(), or is it necessary to read a vendor
> > register?
> >From the tests I've done, I got the actual speed read correctly by
> genphy_read_status function.
> I did a test by adding in this function the vendor register reading at
> the same time and comparing it and did not get a discrepancy too when
> switching with ethtool between different speed configurations.
>
> Would it be more reliable to use the vendor register instead?
It is unusual to report the actually speed in BMSR etc, which is why i
asked. But if it works, this is fine.
Andrew
^ permalink raw reply
* Re: [PATCH v10 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: David Laight @ 2026-03-25 19:36 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ankur Arora, Andrew Morton, linux-kernel, linux-arch,
linux-arm-kernel, linux-pm, bpf, arnd, will, peterz, mark.rutland,
harisokn, cl, ast, rafael, daniel.lezcano, memxor, zhenglifeng1,
xueshuai, rdunlap, joao.m.martins, boris.ostrovsky, konrad.wilk
In-Reply-To: <acQFaVR_bGZU2JmJ@arm.com>
On Wed, 25 Mar 2026 15:55:21 +0000
Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Mon, Mar 16, 2026 at 11:37:12PM +0000, David Laight wrote:
...
> > For osq_lock(), while an IPI will wake it up, there is also a small timing
> > window where the IPI can happen before the ldx and so not actually wake up it.
> > This is true whenever 'expr' is non-trivial.
>
> Hmm, I thought this is fine because of the implicit SEVL on exception
> return but the arm64 __cmpwait_relaxed() does a SEVL+WFE which clears
> any prior event, it can wait in theory forever when the event stream is
> disabled.
Not forever, there will be a timer interrupt in the end.
> Expanding smp_cond_load_relaxed() into asm, we have something like:
>
> LDR X0, [PTR]
> condition check for VAL || need_resched() with branch out
> SEVL
> WFE
> LDXR X1, [PTR]
> EOR X1, X1, X0
> CBNZ out
> WFE
> out:
>
> If the condition is updated to become true (need_resched()) after the
> condition check but before the first WFE while *PTR remains unchanged,
> the IPI won't do anything. Maybe we should revert 1cfc63b5ae60 ("arm64:
> cmpwait: Clear event register before arming exclusive monitor"). Not
> great but probably better than reverting f5bfdc8e3947 ("locking/osq: Use
> optimized spinning loop for arm64")).
Could you change the order to:
LDR X0, [PTR]
SEVL
WFE
condition check for VAL || need_resched() with branch out
LDXR X1, [PTR]
EOR X1, X1, X0
CBNZ out
WFE
out:
that closes the timing window for the interrupt provided the condition
check doesn't change the event register.
I must get back to the osq_lock code again.
I'm happy with the code - the per-cpu data is down to two cpu numbers.
(Apart from the acquire/release semantics in a few places.)
But the comments have got out of hand.
Writing succinct and accurate comments is hard - too verbose and they
hide too much code.
David
^ permalink raw reply
* Re: [PATCH v2 3/3] KVM: arm64: Don't pass host_debug_state to BRBE world-switch routines
From: Fuad Tabba @ 2026-03-25 19:28 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, mark.rutland, linux-arm-kernel, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose,
Alexandru Elisei, Yabin Cui
In-Reply-To: <20260227212136.7660-4-will@kernel.org>
On Fri, 27 Feb 2026 at 21:22, Will Deacon <will@kernel.org> wrote:
>
> Now that the SPE and BRBE nVHE world-switch routines operate on the
> host_debug_state directly, tweak the BRBE code to do the same for
> consistency.
>
> This is purely cosmetic.
>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: James Clark <james.clark@linaro.org>
> Cc: Leo Yan <leo.yan@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Fuad Tabba <tabba@google.com>
> Cc: Alexandru Elisei <alexandru.elisei@arm.com>
> Signed-off-by: Will Deacon <will@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> arch/arm64/kvm/hyp/nvhe/debug-sr.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> index 75158a9cd06a..06ae122a7761 100644
> --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> @@ -158,9 +158,9 @@ static void __trace_switch_to_host(void)
> *host_data_ptr(host_debug_state.trfcr_el1));
> }
>
> -static void __debug_save_brbe(u64 *brbcr_el1)
> +static void __debug_save_brbe(void)
> {
> - *brbcr_el1 = 0;
> + u64 *brbcr_el1 = host_data_ptr(host_debug_state.brbcr_el1);
>
> /* Check if the BRBE is enabled */
> if (!(read_sysreg_el1(SYS_BRBCR) & (BRBCR_ELx_E0BRE | BRBCR_ELx_ExBRE)))
> @@ -175,8 +175,10 @@ static void __debug_save_brbe(u64 *brbcr_el1)
> write_sysreg_el1(0, SYS_BRBCR);
> }
>
> -static void __debug_restore_brbe(u64 brbcr_el1)
> +static void __debug_restore_brbe(void)
> {
> + u64 brbcr_el1 = *host_data_ptr(host_debug_state.brbcr_el1);
> +
> if (!brbcr_el1)
> return;
>
> @@ -192,7 +194,7 @@ void __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu)
>
> /* Disable BRBE branch records */
> if (host_data_test_flag(HAS_BRBE))
> - __debug_save_brbe(host_data_ptr(host_debug_state.brbcr_el1));
> + __debug_save_brbe();
>
> if (__trace_needs_switch())
> __trace_switch_to_guest();
> @@ -208,7 +210,7 @@ void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu)
> if (host_data_test_flag(HAS_SPE))
> __debug_restore_spe();
> if (host_data_test_flag(HAS_BRBE))
> - __debug_restore_brbe(*host_data_ptr(host_debug_state.brbcr_el1));
> + __debug_restore_brbe();
> if (__trace_needs_switch())
> __trace_switch_to_host();
> }
> --
> 2.53.0.473.g4a7958ca14-goog
>
^ permalink raw reply
* Re: [PATCH v2 2/3] KVM: arm64: Disable SPE Profiling Buffer when running in guest context
From: Fuad Tabba @ 2026-03-25 19:28 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, mark.rutland, linux-arm-kernel, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose,
Alexandru Elisei, Yabin Cui
In-Reply-To: <20260227212136.7660-3-will@kernel.org>
On Fri, 27 Feb 2026 at 21:22, Will Deacon <will@kernel.org> wrote:
>
> The nVHE world-switch code relies on zeroing PMSCR_EL1 to disable
> profiling data generation in guest context when SPE is in use by the
> host.
>
> Unfortunately, this may leave PMBLIMITR_EL1.E set and consequently we
> can end up running in guest/hypervisor context with the Profiling Buffer
> enabled. The current "known issues" document for Rev M.a of the Arm ARM
> states that this can lead to speculative, out-of-context translations:
>
> | 2.18 D23136:
> |
> | When the Profiling Buffer is enabled, profiling is not stopped, and
> | Discard mode is not enabled, the Statistical Profiling Unit might
> | cause speculative translations for the owning translation regime,
> | including when the owning translation regime is out-of-context.
>
> In a similar fashion to TRBE, ensure that the Profiling Buffer is
> disabled during the nVHE world switch before we start messing with the
> stage-2 MMU and trap configuration.
>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: James Clark <james.clark@linaro.org>
> Cc: Leo Yan <leo.yan@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Fuad Tabba <tabba@google.com>
> Cc: Alexandru Elisei <alexandru.elisei@arm.com>
> Fixes: f85279b4bd48 ("arm64: KVM: Save/restore the host SPE state when entering/leaving a VM")
> Signed-off-by: Will Deacon <will@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> arch/arm64/include/asm/kvm_host.h | 1 +
> arch/arm64/kvm/hyp/nvhe/debug-sr.c | 33 ++++++++++++++++++++----------
> arch/arm64/kvm/hyp/nvhe/switch.c | 2 +-
> 3 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 1532ad2b2ec2..d527c77977dd 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -768,6 +768,7 @@ struct kvm_host_data {
> struct kvm_guest_debug_arch regs;
> /* Statistical profiling extension */
> u64 pmscr_el1;
> + u64 pmblimitr_el1;
> /* Self-hosted trace */
> u64 trfcr_el1;
> u64 trblimitr_el1;
> diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> index 3dbdee1148d3..75158a9cd06a 100644
> --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> @@ -14,20 +14,20 @@
> #include <asm/kvm_hyp.h>
> #include <asm/kvm_mmu.h>
>
> -static void __debug_save_spe(u64 *pmscr_el1)
> +static void __debug_save_spe(void)
> {
> - u64 reg;
> + u64 *pmscr_el1, *pmblimitr_el1;
>
> - /* Clear pmscr in case of early return */
> - *pmscr_el1 = 0;
> + pmscr_el1 = host_data_ptr(host_debug_state.pmscr_el1);
> + pmblimitr_el1 = host_data_ptr(host_debug_state.pmblimitr_el1);
>
> /*
> * At this point, we know that this CPU implements
> * SPE and is available to the host.
> * Check if the host is actually using it ?
> */
> - reg = read_sysreg_s(SYS_PMBLIMITR_EL1);
> - if (!(reg & BIT(PMBLIMITR_EL1_E_SHIFT)))
> + *pmblimitr_el1 = read_sysreg_s(SYS_PMBLIMITR_EL1);
> + if (!(*pmblimitr_el1 & BIT(PMBLIMITR_EL1_E_SHIFT)))
> return;
>
> /* Yes; save the control register and disable data generation */
> @@ -37,18 +37,29 @@ static void __debug_save_spe(u64 *pmscr_el1)
>
> /* Now drain all buffered data to memory */
> psb_csync();
> + dsb(nsh);
> +
> + /* And disable the profiling buffer */
> + write_sysreg_s(0, SYS_PMBLIMITR_EL1);
> + isb();
> }
>
> -static void __debug_restore_spe(u64 pmscr_el1)
> +static void __debug_restore_spe(void)
> {
> - if (!pmscr_el1)
> + u64 pmblimitr_el1 = *host_data_ptr(host_debug_state.pmblimitr_el1);
> +
> + if (!(pmblimitr_el1 & BIT(PMBLIMITR_EL1_E_SHIFT)))
> return;
>
> /* The host page table is installed, but not yet synchronised */
> isb();
>
> + /* Re-enable the profiling buffer. */
> + write_sysreg_s(pmblimitr_el1, SYS_PMBLIMITR_EL1);
> + isb();
> +
> /* Re-enable data generation */
> - write_sysreg_el1(pmscr_el1, SYS_PMSCR);
> + write_sysreg_el1(*host_data_ptr(host_debug_state.pmscr_el1), SYS_PMSCR);
> }
>
> static void __trace_do_switch(u64 *saved_trfcr, u64 new_trfcr)
> @@ -177,7 +188,7 @@ void __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu)
> {
> /* Disable and flush SPE data generation */
> if (host_data_test_flag(HAS_SPE))
> - __debug_save_spe(host_data_ptr(host_debug_state.pmscr_el1));
> + __debug_save_spe();
>
> /* Disable BRBE branch records */
> if (host_data_test_flag(HAS_BRBE))
> @@ -195,7 +206,7 @@ void __debug_switch_to_guest(struct kvm_vcpu *vcpu)
> void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu)
> {
> if (host_data_test_flag(HAS_SPE))
> - __debug_restore_spe(*host_data_ptr(host_debug_state.pmscr_el1));
> + __debug_restore_spe();
> if (host_data_test_flag(HAS_BRBE))
> __debug_restore_brbe(*host_data_ptr(host_debug_state.brbcr_el1));
> if (__trace_needs_switch())
> diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
> index f00688e69d88..9b6e87dac3b9 100644
> --- a/arch/arm64/kvm/hyp/nvhe/switch.c
> +++ b/arch/arm64/kvm/hyp/nvhe/switch.c
> @@ -278,7 +278,7 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
> * We're about to restore some new MMU state. Make sure
> * ongoing page-table walks that have started before we
> * trapped to EL2 have completed. This also synchronises the
> - * above disabling of BRBE and SPE.
> + * above disabling of BRBE.
> *
> * See DDI0487I.a D8.1.5 "Out-of-context translation regimes",
> * rule R_LFHQG and subsequent information statements.
> --
> 2.53.0.473.g4a7958ca14-goog
>
^ permalink raw reply
* Re: [PATCH v2 1/3] KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest context
From: Fuad Tabba @ 2026-03-25 19:27 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, mark.rutland, linux-arm-kernel, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose,
Alexandru Elisei, Yabin Cui
In-Reply-To: <20260227212136.7660-2-will@kernel.org>
Hi Will,
Now that I have backported this to various Android versions....
On Fri, 27 Feb 2026 at 21:22, Will Deacon <will@kernel.org> wrote:
>
> The nVHE world-switch code relies on zeroing TRFCR_EL1 to disable trace
> generation in guest context when self-hosted TRBE is in use by the host.
>
> Per D3.2.1 ("Controls to prohibit trace at Exception levels"), clearing
> TRFCR_EL1 means that trace generation is prohibited at EL1 and EL0 but
> per R_YCHKJ the Trace Buffer Unit will still be enabled if
> TRBLIMITR_EL1.E is set. R_SJFRQ goes on to state that, when enabled, the
> Trace Buffer Unit can perform address translation for the "owning
> exception level" even when it is out of context.
>
> Consequently, we can end up in a state where TRBE performs speculative
> page-table walks for a host VA/IPA in guest/hypervisor context depending
> on the value of MDCR_EL2.E2TB, which changes over world-switch. The
> potential result appears to be a heady mixture of SErrors, data
> corruption and hardware lockups.
>
> Extend the TRBE world-switch code to clear TRBLIMITR_EL1.E after
> draining the buffer, restoring the register on return to the host. This
> unfortunately means we need to tackle CPU errata #2064142 and #2038923
> which add additional synchronisation requirements around manipulations
> of the limit register. Hopefully this doesn't need to be fast.
>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: James Clark <james.clark@linaro.org>
> Cc: Leo Yan <leo.yan@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Fuad Tabba <tabba@google.com>
> Cc: Alexandru Elisei <alexandru.elisei@arm.com>
> Fixes: a1319260bf62 ("arm64: KVM: Enable access to TRBE support for host")
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> arch/arm64/include/asm/kvm_host.h | 1 +
> arch/arm64/kvm/hyp/nvhe/debug-sr.c | 73 ++++++++++++++++++++++++++----
> arch/arm64/kvm/hyp/nvhe/switch.c | 2 +-
> 3 files changed, 66 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 5d5a3bbdb95e..1532ad2b2ec2 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -770,6 +770,7 @@ struct kvm_host_data {
> u64 pmscr_el1;
> /* Self-hosted trace */
> u64 trfcr_el1;
> + u64 trblimitr_el1;
> /* Values of trap registers for the host before guest entry. */
> u64 mdcr_el2;
> u64 brbcr_el1;
> diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> index 2a1c0f49792b..3dbdee1148d3 100644
> --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> @@ -57,12 +57,56 @@ static void __trace_do_switch(u64 *saved_trfcr, u64 new_trfcr)
> write_sysreg_el1(new_trfcr, SYS_TRFCR);
> }
>
> -static bool __trace_needs_drain(void)
> +static void __trace_drain_and_disable(void)
> {
> - if (is_protected_kvm_enabled() && host_data_test_flag(HAS_TRBE))
> - return read_sysreg_s(SYS_TRBLIMITR_EL1) & TRBLIMITR_EL1_E;
> + u64 *trblimitr_el1 = host_data_ptr(host_debug_state.trblimitr_el1);
>
> - return host_data_test_flag(TRBE_ENABLED);
> + *trblimitr_el1 = 0;
> +
> + if (is_protected_kvm_enabled()) {
> + if (!host_data_test_flag(HAS_TRBE))
> + return;
> + } else {
> + if (!host_data_test_flag(TRBE_ENABLED))
> + return;
> + }
Can we simplify this? e.g.,
+ bool needs_drain = is_protected_kvm_enabled() ?
host_data_test_flag(HAS_TRBE) : host_data_test_flag(TRBE_ENABLED);
....
That said:
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> +
> + *trblimitr_el1 = read_sysreg_s(SYS_TRBLIMITR_EL1);
> + if (*trblimitr_el1 & TRBLIMITR_EL1_E) {
> + /*
> + * The host has enabled the Trace Buffer Unit so we have
> + * to beat the CPU with a stick until it stops accessing
> + * memory.
> + */
> +
> + /* First, ensure that our prior write to TRFCR has stuck. */
> + isb();
> +
> + /* Now synchronise with the trace and drain the buffer. */
> + tsb_csync();
> + dsb(nsh);
> +
> + /*
> + * With no more trace being generated, we can disable the
> + * Trace Buffer Unit.
> + */
> + write_sysreg_s(0, SYS_TRBLIMITR_EL1);
> + if (cpus_have_final_cap(ARM64_WORKAROUND_2064142)) {
> + /*
> + * Some CPUs are so good, we have to drain 'em
> + * twice.
> + */
> + tsb_csync();
> + dsb(nsh);
> + }
> +
> + /*
> + * Ensure that the Trace Buffer Unit is disabled before
> + * we start mucking with the stage-2 and trap
> + * configuration.
> + */
> + isb();
> + }
> }
>
> static bool __trace_needs_switch(void)
> @@ -79,15 +123,26 @@ static void __trace_switch_to_guest(void)
>
> __trace_do_switch(host_data_ptr(host_debug_state.trfcr_el1),
> *host_data_ptr(trfcr_while_in_guest));
> -
> - if (__trace_needs_drain()) {
> - isb();
> - tsb_csync();
> - }
> + __trace_drain_and_disable();
> }
>
> static void __trace_switch_to_host(void)
> {
> + u64 trblimitr_el1 = *host_data_ptr(host_debug_state.trblimitr_el1);
> +
> + if (trblimitr_el1 & TRBLIMITR_EL1_E) {
> + /* Re-enable the Trace Buffer Unit for the host. */
> + write_sysreg_s(trblimitr_el1, SYS_TRBLIMITR_EL1);
> + isb();
> + if (cpus_have_final_cap(ARM64_WORKAROUND_2038923)) {
> + /*
> + * Make sure the unit is re-enabled before we
> + * poke TRFCR.
> + */
> + isb();
> + }
> + }
> +
> __trace_do_switch(host_data_ptr(trfcr_while_in_guest),
> *host_data_ptr(host_debug_state.trfcr_el1));
> }
> diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
> index 779089e42681..f00688e69d88 100644
> --- a/arch/arm64/kvm/hyp/nvhe/switch.c
> +++ b/arch/arm64/kvm/hyp/nvhe/switch.c
> @@ -278,7 +278,7 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
> * We're about to restore some new MMU state. Make sure
> * ongoing page-table walks that have started before we
> * trapped to EL2 have completed. This also synchronises the
> - * above disabling of BRBE, SPE and TRBE.
> + * above disabling of BRBE and SPE.
> *
> * See DDI0487I.a D8.1.5 "Out-of-context translation regimes",
> * rule R_LFHQG and subsequent information statements.
> --
> 2.53.0.473.g4a7958ca14-goog
>
^ permalink raw reply
* Re: [PATCH v3] nvme: Add nvme_setup_cmd to host_path_error
From: Keith Busch @ 2026-03-25 19:03 UTC (permalink / raw)
To: Justin Tee
Cc: hmi.jeon, axboe@kernel.dk, sven@kernel.org, j@jannau.net,
neal@gompa.dev, hch@lst.de, sagi@grimberg.me,
justin.tee@broadcom.com, nareshgottumukkala83@gmail.com,
paul.ely@broadcom.com, James Smart, kch@nvidia.com,
linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, asahi@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <CABPRKS8-x6Tfr90inpz1fR0=8a5HD=mkujtfLJ1h9ikEUjTvxg@mail.gmail.com>
On Wed, Mar 25, 2026 at 11:37:44AM -0700, Justin Tee wrote:
> > - After
> > nvme_setup_cmd: \
> > nvme0: qid=0, cmdid=32777, nsid=0, flags=0x0, meta=0x0, \
> > cmd=(nvme_admin_identify cns=1, ctrlid=0)
> > nvme_complete_rq: \
> > nvme0: qid=0, cmdid=32777, res=0x0, retries=0, flags=0x2, status=0x370
>
> > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > index 766e9cc4ffca..378d28b2c971 100644
> > --- a/drivers/nvme/host/core.c
> > +++ b/drivers/nvme/host/core.c
> > @@ -512,6 +512,7 @@ EXPORT_SYMBOL_GPL(nvme_complete_batch_req);
> > blk_status_t nvme_host_path_error(struct request *req)
> > {
> > nvme_req(req)->status = NVME_SC_HOST_PATH_ERROR;
> > + nvme_setup_cmd(req->q->queuedata, req);
> > blk_mq_set_request_complete(req);
> > nvme_complete_rq(req);
> > return BLK_STS_OK;
>
> Since trace_nvme_complete_rq is printing only cmdid to help identify
> the command, why not define a new TRACE_EVENT(nvme_host_path_error,
> ...) in trace.h instead?
Why are we even tracing the completion? I agree the completion without a
submission is confusing, but why don't we just skip tracing the
completion in this condition? The idea for these trace events was to
match up commands dispatched to hardware with the hardware's
posted response, so I'm not sure what value we get by synthesizing both
sides of the events.
^ permalink raw reply
* Re: [PATCH v7 0/2] Add support for Variscite DART-MX95 and Sonata board
From: Frank Li @ 2026-03-25 19:02 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Stefano Radaelli, devicetree, linux-kernel, pierluigi.p,
Stefano Radaelli, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel
In-Reply-To: <20260325180604.GA2972@francesco-nb>
On Wed, Mar 25, 2026 at 07:06:04PM +0100, Francesco Dolcini wrote:
> On Wed, Mar 25, 2026 at 10:50:57AM -0400, Frank Li wrote:
> > On Wed, Mar 25, 2026 at 01:21:04PM +0100, Francesco Dolcini wrote:
> > > On Tue, Mar 24, 2026 at 03:48:29PM -0400, Frank Li wrote:
> > > > On Fri, Mar 13, 2026 at 02:56:03PM -0400, Frank Li wrote:
> > > > > On Fri, Mar 13, 2026 at 06:47:01PM +0100, Stefano Radaelli wrote:
> > > > > > This patch series adds support for the Variscite DART-MX95 system on
> > > > > > module and the Sonata carrier board.
> > > > > >
> > > > > > The series includes:
> > > > > > - Device tree bindings documentation for both SOM and carrier board
> > > > > > - SOM device tree with on-module peripherals
> > > > > > - Sonata carrier board device tree with board-specific features
> > > > > >
> > > > > > The implementation follows the standard SOM + carrier board pattern
> > > > > > where the SOM dtsi contains only peripherals mounted on the module,
> > > > > > while carrier-specific interfaces are enabled in the board dts.
> > > > > >
> > > > > > v7:
> > > > > > - Order nodes in symphony dts
> > > > >
> > > > > Can you run https://github.com/lznuaa/dt-format for new file to easy
> > > > > track and check by script later.
> > > >
> > > > I applied with below change
> > > > - update copywrite to 2026
> > >
> > > How do you know that the correct copyright year is 2026?
> > > The copyright years does not change to today just because it is the year
> > > it was submitted.
> >
> > At least it should include 2026 because it is new files in kernel
> > tree.
>
> The copyright year is not changing nor being updated just because you
> are adding the file to the linux kernel tree.
It is impossible zero modify before submit patch. If update copywrite year,
it needs include current years, I omit it when review it and find at apply.
And original owner Stefano Radaelli's agree on update to 2026.
Frank
>
> Francesco
>
>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: freescale: imx95-toradex-smarc: Use gpio-hog for WIFI_UART_EN
From: Frank Li @ 2026-03-25 18:58 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Franz Schnyder, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Franz Schnyder, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260325181057.GB2972@francesco-nb>
On Wed, Mar 25, 2026 at 07:10:57PM +0100, Francesco Dolcini wrote:
> On Wed, Mar 25, 2026 at 10:54:46AM -0400, Frank Li wrote:
> > On Wed, Mar 25, 2026 at 12:55:11PM +0100, Franz Schnyder wrote:
> > > From: Franz Schnyder <franz.schnyder@toradex.com>
> > >
> > > On the Toradex SMARC iMX95, the WiFi UART signals are shared with the
> > > JTAG. The WIFI_UART_EN signal is used to select between these
> > > two functions.
> > >
> > > Configure the signal as gpio-hog and drive it high to select the UART
> > > function by default. Add a label to override the hog in derived
> > > device trees.
> >
> > gpio hog have problem about probe order, are you sure gpio device probe
> > before pcie?
>
> This is not about PCIe, we are talking about UART here. Specifically the
> module is a combo Wi-Fi/BT device, with Wi-Fi over SDIO, and BT over
> UART from NXP.
>
> In any case, this DT is going to be used also by the boot firmware that will
> configure the GPIO hog way before the Linux driver probes.
Commit message need show it is safe.
Frank
>
> The DT files from the Linux kernel are used also by other projects.
>
> > I have not seen any place refer to wifi_uart_en.
>
> There is none (as of now). This is there to make it easier for a user
> that needs access to debug to adjust this node enabling the JTAG
> functionality.
>
> Francesco
>
^ permalink raw reply
* Re: [PATCH v6 1/5] mm: rmap: support batched checks of the references for large folios
From: Lorenzo Stoakes (Oracle) @ 2026-03-25 18:58 UTC (permalink / raw)
To: Andrew Morton
Cc: David Hildenbrand (Arm), Baolin Wang, Barry Song, catalin.marinas,
will, lorenzo.stoakes, ryan.roberts, Liam.Howlett, vbabka, rppt,
surenb, mhocko, riel, harry.yoo, jannh, willy, dev.jain, linux-mm,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260325114305.eb90add580948aa56a88373b@linux-foundation.org>
On Wed, Mar 25, 2026 at 11:43:05AM -0700, Andrew Morton wrote:
> On Wed, 25 Mar 2026 16:28:18 +0000 "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:
>
> > On Wed, Mar 25, 2026 at 09:23:00AM -0700, Andrew Morton wrote:
> > > On Wed, 25 Mar 2026 15:32:50 +0000 "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:
> > >
> > > > Really I guess I'd like to know the timing of when mm-stable is taken so I can
> > > > know the deadline for stuff like this.
> > >
> > > Yeah, as mentioned elsewhere I'll add some words into the series file to
> > > try to describe this.
> > >
> > > But the start of the migration is quite variable (-rc4 through -rc6) so
> > > I'll aim to keep people updated in the weekly "mm.git review status"
> > > emails.
> > >
> >
> > Thanks. Wasn't aware that was a thing actually, but I see
> > https://lore.kernel.org/linux-mm/20260323202941.08ddf2b0411501cae801ab4c@linux-foundation.org/
> > now.
>
> Well now I'm all sad.
>
> Yeah, I started doing this Feb 2, shall attempt to sustain this weekly
> after we've hit -rc4 ish. I expect I'll be adding more waffle to these as
> things occur to me. A general overview of where the tree is at.
>
> I can Bcc: people if asked ;) lmk.
>
Yes please!
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH] media: verisilicon: AV1: Discard none supported profiles
From: Nicolas Dufresne @ 2026-03-25 18:46 UTC (permalink / raw)
To: Benjamin Gaignard, p.zabel, mchehab, heiko
Cc: linux-media, linux-rockchip, linux-kernel, linux-arm-kernel,
kernel
In-Reply-To: <20260325131956.18075-1-benjamin.gaignard@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]
Le mercredi 25 mars 2026 à 14:19 +0100, Benjamin Gaignard a écrit :
> AV1 hardware can only decode YUV420 pixel format. That means
> that only profile 0 is supported. Discard all other profiles
> when receiving AV1 sequence control.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
> ---
> drivers/media/platform/verisilicon/hantro_drv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
> index 2e81877f640f..12f98e7e7994 100644
> --- a/drivers/media/platform/verisilicon/hantro_drv.c
> +++ b/drivers/media/platform/verisilicon/hantro_drv.c
> @@ -283,6 +283,8 @@ static int hantro_try_ctrl(struct v4l2_ctrl *ctrl)
>
> if (sequence->bit_depth != 8 && sequence->bit_depth != 10)
> return -EINVAL;
> + if (sequence->seq_profile != 0)
> + return -EINVAL;
You should also add the missing control to better tell userspace what it can and
cannot do. Check MTK driver for reference, I think the same config can be used:
drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
...
.cfg = {
.id = V4L2_CID_MPEG_VIDEO_AV1_PROFILE,
.min = V4L2_MPEG_VIDEO_AV1_PROFILE_MAIN,
.def = V4L2_MPEG_VIDEO_AV1_PROFILE_MAIN,
.max = V4L2_MPEG_VIDEO_AV1_PROFILE_MAIN,
},
...
Nicolas
> }
>
> return 0;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-25 18:43 UTC (permalink / raw)
To: Maxime Ripard
Cc: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <20260325-magnificent-ultraviolet-oarfish-baefbc@houat>
On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > +enum drm_connector_color_format {
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > + * semantics.
> > > > > > > + *
> > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > + * YCbCr 4:2:0.
> > > > > > > + *
> > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > + * how HDMI does it).
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > + * not subsampled)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > + * with horizontal subsampling)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > >
> > > > > > Seems like this should document what the quantization range
> > > > > > should be for each format.
> > > > > >
> > > > >
> > > > > I don't think so? If you want per-component bit depth values,
> > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > enum is more abstract than that, and is there to communicate
> > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > by other properties.
> > > > >
> > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > be added; no digital display protocol standard supports it to my
> > > > > knowledge, and hopefully none ever will.
> > > >
> > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > >
> > > > The i915 behaviour is that YCbCr is always limited range,
> > > > RGB can either be full or limited range depending on the
> > > > "Broadcast RGB" property and other related factors.
> > >
> > > So far the HDMI state has both the format and quantization range as
> > > different fields. I'm not sure we need to document the range in the
> > > format field, maybe only mention it's not part of the format but has a
> > > field of its own?
> >
> > I think we only have it for RGB (on some drivers only?). For YCbCr
> > I think the assumption is limited range everywhere.
> >
> > But I'm not really concerned about documenting struct members.
> > What I'm talking about is the *uapi* docs. Surely userspace
> > will want to know what the new property actually does so the
> > uapi needs to be documented properly. And down the line some
> > new driver might also implement the wrong behaviour if there
> > is no clear specification.
>
> Ack
>
> > So I'm thinking (or perhaps hoping) the rule might be something like:
> > - YCbCr limited range
> > - RGB full range if "Broadcast RGB" property is not present
>
> Isn't it much more complicated than that for HDMI though? My
> recollection was that any VIC but VIC1 would be limited range, and
> anything else full range?
Do we have some driver that implements the CTA-861 CE vs. IT mode
logic but doesn't expose the "Broadcast RGB" property? I was hoping
those would always go hand in hand now.
>
> > - RGB full or limited range based on the "Broadcast RGB" property
> > if it's present
> >
> > I think the "Broadcast RGB" property itself might also be lacking
> > proper uapi docs, so that may need to be remedied as well.
>
> I took care of documenting it when merging the HDMI helpers:
> https://docs.kernel.org/gpu/drm-kms.html#hdmi-specific-connector-properties
>
> Maxime
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: imx8mp-tqma8mpql: Add DT overlays to explicit list
From: Frank Li @ 2026-03-25 18:43 UTC (permalink / raw)
To: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexander Stein
Cc: imx, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260324075842.815005-1-alexander.stein@ew.tq-group.com>
On Tue, 24 Mar 2026 08:58:41 +0100, Alexander Stein wrote:
> Armbian installs DT overlays using dtbs_install. For it to work all
> the overlays have to be added to dtb-y explicitly.
> Add the overlays for platforms supported by Armbian.
>
>
Applied, thanks!
[1/1] arm64: dts: imx8mp-tqma8mpql: Add DT overlays to explicit list
commit: 6cb68d84bc632865c89a22a4f956814df9b8d609
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v6 1/5] mm: rmap: support batched checks of the references for large folios
From: Andrew Morton @ 2026-03-25 18:43 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle)
Cc: David Hildenbrand (Arm), Baolin Wang, Barry Song, catalin.marinas,
will, lorenzo.stoakes, ryan.roberts, Liam.Howlett, vbabka, rppt,
surenb, mhocko, riel, harry.yoo, jannh, willy, dev.jain, linux-mm,
linux-arm-kernel, linux-kernel
In-Reply-To: <7820cffe-60bf-4ff6-af10-89c774f0fe0c@lucifer.local>
On Wed, 25 Mar 2026 16:28:18 +0000 "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:
> On Wed, Mar 25, 2026 at 09:23:00AM -0700, Andrew Morton wrote:
> > On Wed, 25 Mar 2026 15:32:50 +0000 "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:
> >
> > > Really I guess I'd like to know the timing of when mm-stable is taken so I can
> > > know the deadline for stuff like this.
> >
> > Yeah, as mentioned elsewhere I'll add some words into the series file to
> > try to describe this.
> >
> > But the start of the migration is quite variable (-rc4 through -rc6) so
> > I'll aim to keep people updated in the weekly "mm.git review status"
> > emails.
> >
>
> Thanks. Wasn't aware that was a thing actually, but I see
> https://lore.kernel.org/linux-mm/20260323202941.08ddf2b0411501cae801ab4c@linux-foundation.org/
> now.
Well now I'm all sad.
Yeah, I started doing this Feb 2, shall attempt to sustain this weekly
after we've hit -rc4 ish. I expect I'll be adding more waffle to these as
things occur to me. A general overview of where the tree is at.
I can Bcc: people if asked ;) lmk.
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-evk: Specify ADV7535 register addresses
From: Frank Li @ 2026-03-25 18:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Shawn Guo, Liu Ying
Cc: devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324-imx8mp-evk-adv7535-cec-reg-addr-v1-1-52dbdd63d5a4@nxp.com>
On Tue, 24 Mar 2026 13:52:03 +0800, Liu Ying wrote:
> MIPI DSI to HDMI bridge ADV7535 CEC default register address is 0x3c
> on an I2C bus. And, OV5640 camera uses the same address on the same
> I2C bus. To resolve this conflict, use 0x3b as ADV7535 CEC register
> address by specifying all ADV7535 register addresses.
>
>
Applied, thanks!
[1/1] arm64: dts: imx8mp-evk: Specify ADV7535 register addresses
commit: 9f9dd832661b62091f75b88b8467d8441b546cf7
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v3] nvme: Add nvme_setup_cmd to host_path_error
From: Justin Tee @ 2026-03-25 18:37 UTC (permalink / raw)
To: hmi.jeon
Cc: kbusch@kernel.org, axboe@kernel.dk, sven@kernel.org, j@jannau.net,
neal@gompa.dev, hch@lst.de, sagi@grimberg.me,
justin.tee@broadcom.com, nareshgottumukkala83@gmail.com,
paul.ely@broadcom.com, James Smart, kch@nvidia.com,
linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, asahi@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <20260325063333epcms2p60954532c1b65a1665bad6dcdcfd7d62c@epcms2p6>
Hi Minsik,
> - After
> nvme_setup_cmd: \
> nvme0: qid=0, cmdid=32777, nsid=0, flags=0x0, meta=0x0, \
> cmd=(nvme_admin_identify cns=1, ctrlid=0)
> nvme_complete_rq: \
> nvme0: qid=0, cmdid=32777, res=0x0, retries=0, flags=0x2, status=0x370
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 766e9cc4ffca..378d28b2c971 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -512,6 +512,7 @@ EXPORT_SYMBOL_GPL(nvme_complete_batch_req);
> blk_status_t nvme_host_path_error(struct request *req)
> {
> nvme_req(req)->status = NVME_SC_HOST_PATH_ERROR;
> + nvme_setup_cmd(req->q->queuedata, req);
> blk_mq_set_request_complete(req);
> nvme_complete_rq(req);
> return BLK_STS_OK;
Since trace_nvme_complete_rq is printing only cmdid to help identify
the command, why not define a new TRACE_EVENT(nvme_host_path_error,
...) in trace.h instead?
So, perhaps something like this?
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 5037444687bd..a2e253dbb744 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -511,7 +511,11 @@ EXPORT_SYMBOL_GPL(nvme_complete_batch_req);
*/
blk_status_t nvme_host_path_error(struct request *req)
{
+ struct nvme_command *cmd = nvme_req(req)->cmd;
+
nvme_req(req)->status = NVME_SC_HOST_PATH_ERROR;
+ cmd->common.command_id = nvme_cid(req);
+ trace_nvme_host_path_error(req, cmd);
blk_mq_set_request_complete(req);
nvme_complete_rq(req);
return BLK_STS_OK;
Regards,
Justin
^ permalink raw reply related
* Re: [PATCH] arm64: dts: imx8dxl-evk: Use audio-graph-card2 for wm8960-2 and wm8960-3
From: Frank Li @ 2026-03-25 18:37 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, devicetree,
imx, linux-arm-kernel, linux-kernel, Shengjiu Wang
In-Reply-To: <20260317053738.578187-1-shengjiu.wang@nxp.com>
On Tue, 17 Mar 2026 13:37:38 +0800, Shengjiu Wang wrote:
> The sound card wm8960-2 and wm8960-3 only support capture mode for the
> reason of connection on the EVK board. But fsl-asoc-card don't support
> capture_only setting, the sound card creation will fail.
>
> fsl-sai 59060000.sai: Missing dma channel for stream: 0
> fsl-sai 59060000.sai: ASoC error (-22): at snd_soc_pcm_component_new() on 59060000.sai
> fsl-sai 59070000.sai: Missing dma channel for stream: 0
> fsl-sai 59070000.sai: ASoC error (-22): at snd_soc_pcm_component_new() on 59070000.sai
>
> [...]
Applied, thanks!
[1/1] arm64: dts: imx8dxl-evk: Use audio-graph-card2 for wm8960-2 and wm8960-3
commit: 9055b1100a7758efc817edf80d19724c619f9073
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: imx8mp: Add DT overlays for DH i.MX8M Plus DHCOM SoM and boards
From: Frank Li @ 2026-03-25 18:33 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Christoph Niedermaier, Conor Dooley,
Fabio Estevam, Krzysztof Kozlowski, Pengutronix Kernel Team,
Rob Herring, Sascha Hauer, devicetree, imx, kernel, linux-kernel
In-Reply-To: <20260324190544.74531-1-marex@nabladev.com>
On Tue, Mar 24, 2026 at 08:04:19PM +0100, Marek Vasut wrote:
> Add DT overlays to support DH i.MX8M Plus DHCOM SoM variants and carrier
> board expansion modules. The following DT overlays are implemented:
> - SoM:
> - DH 660-x00 SoM with 1xRMII PHY
> - DH 660-x00 SoM with 2xRMII PHY
> - PDK2:
> - DH 505-200 Display board in edge connector X12 via direct LVDS
> - DH 531-100 SPI/I2C board in header X21
> - DH 531-200 SPI/I2C board in header X22
> - DH 560-200 Display board in edge connector X12
> - PDK3:
> - DH 505-200 Display board in edge connector X36 via direct LVDS
> - DH 531-100 SPI/I2C board in header X40
> - DH 531-200 SPI/I2C board in header X41
> - DH 560-300 Display board in edge connector X36
> - EA muRata 2AE M.2 A/E-Key card in connector X20
> - NXP SPF-29853-C1 MINISASTOCSI with OV5640 sensor in connector X31
> - NXP SPF-29853-C1 MINISASTOCSI with OV5640 sensor in connector X29
> - PicoITX:
> - DH 626-100 Display board in edge connector X2
>
...
> + * Copyright (C) 2022-2026 Marek Vasut
> + */
> +/dts-v1/;
> +/plugin/;
> +
> +#define DH_OVERLAY_PANEL_I2C_BUS i2c5
> +#define DH_OVERLAY_PANEL_I2C_TOUCHSCREEN_PINCTRL &pinctrl_dhcom_b &pinctrl_dhcom_h
This is not straight forward.
you can add label like panel_i2c at dts file.
panel_i2c: &i2c5 {
}
in overlay file use
&panel_i2c {
....
}
So you use the same overlay file for difference dts. The same as others
Frank
> +#define DH_OVERLAY_PANEL_I2C_TOUCHSCREEN_IRQ_PARENT gpio1
> +#define DH_OVERLAY_PANEL_I2C_TOUCHSCREEN_IRQ_PIN 11
> +#define DH_OVERLAY_PANEL_I2C_TOUCHSCREEN_RESET_GPIO gpio1
> +#define DH_OVERLAY_PANEL_I2C_TOUCHSCREEN_RESET_PIN 8
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: rockchip: Convert rockchip-max98090.txt to yaml
From: Mark Brown @ 2026-03-25 16:56 UTC (permalink / raw)
To: Fabio Estevam
Cc: heiko, robh, krzk+dt, conor+dt, linux-sound, devicetree,
linux-rockchip, linux-kernel, linux-arm-kernel
In-Reply-To: <20260324135508.839142-1-festevam@gmail.com>
On Tue, 24 Mar 2026 10:55:08 -0300, Fabio Estevam wrote:
> ASoC: dt-bindings: rockchip: Convert rockchip-max98090.txt to yaml
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.1
Thanks!
[1/1] ASoC: dt-bindings: rockchip: Convert rockchip-max98090.txt to yaml
https://git.kernel.org/broonie/sound/c/c9b48a451ca8
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] spi: pxa2xx: update outdated reference to pump_transfers()
From: Mark Brown @ 2026-03-24 19:55 UTC (permalink / raw)
To: daniel, haojian.zhuang, robert.jarzmik, linux-arm-kernel,
linux-spi, linux-kernel, Kexin Sun
Cc: julia.lawall, xutong.ma, yunbolyu, ratnadiraw
In-Reply-To: <20260321105945.8224-1-kexinsun@smail.nju.edu.cn>
On Sat, 21 Mar 2026 18:59:45 +0800, Kexin Sun wrote:
> spi: pxa2xx: update outdated reference to pump_transfers()
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.1
Thanks!
[1/1] spi: pxa2xx: update outdated reference to pump_transfers()
https://git.kernel.org/broonie/spi/c/762a3847a05c
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3] PCI: dw-rockchip: Enable async probe by default
From: Anand Moon @ 2026-03-25 18:24 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Danilo Krummrich, Robin Murphy, Manivannan Sadhasivam,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Heiko Stuebner, Niklas Cassel, Shawn Lin, Hans Zhang,
Nicolas Frattaroli, Wilfred Mallawa, linux-pci, linux-arm-kernel,
linux-rockchip, linux-kernel, Grimmauld, Greg Kroah-Hartman,
Rafael J. Wysocki, driver-core, Lukas Wunner
In-Reply-To: <acP9-AfUQ7zp3kMS@google.com>
Hi Dmitry/ Robin,
On Wed, 25 Mar 2026 at 20:57, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> On Wed, Mar 25, 2026 at 04:13:03PM +0100, Danilo Krummrich wrote:
> > On Wed Mar 25, 2026 at 5:13 AM CET, Dmitry Torokhov wrote:
> > > That means that you are kicking the majority devices (for now) into
> > > deferral path. I do not think this is optimal.
> >
> > That's not necessary, we'd only need to kick those into the deferral path that
> > have PROBE_FORCE_SYNCHRONOUS, no?
>
> Yes, it may limit the fallout, but as I explained in my other email
> there seem to be a serious disconnect on what synchronous and
> asynchronous probing mean.
>
> I wonder, don't we get issues with phylib in other cases? Don't we ever
> have a module resulting in creating a phy device triggering loading
> another module on the same thread? Won't that result in a warning also?
>
> Thanks.
>
> --
> Dmitry
In comparing the Orange Pi 5 Plus and Radxa Rock 5B schematics,
I noticed a key difference in regulator implementation for pcie2x1l2 node.
While the Orange Pi uses a dedicated GPIO (GPIO3_B4) for ethernet_power_en,
Reference: orangepi‑5‑plus schematics
[1] https://drive.google.com/file/d/1cVT7lSLlgtIvHh4PllijP5E4zz7pxCyh/view
On the Rock 5B ties the LAN_EXT_CORE regulator directly to the VCC_3V3_S3
PMIC rail without a control GPIO.
For LAN_EXT_CORE regulator POW_EXT_SWR/ENSWREG is defined
as enabled by this regulator, but with no GPIO pin linked to toggle.
Reference: Radxa Rock 5B schematics
[2] https://dl.radxa.com/rock5/5b+/docs/hw/radxa_rock5bp_v1.2_schematic.pdf
Because the Rock 5B lacks that GPIO toggle, the existing dummy regulator
definition is redundant.
By stripping out the dummy node and pointing the PCIe supply
directly to the PMIC rail,
If somebody could verify these DTS changes
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
index 668b19c05f7e..cf7d9d516d0e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
@@ -81,15 +81,6 @@ vcc3v3_pcie2x1l0: regulator-vcc3v3-pcie2x1l0 {
status = "disabled";
};
- vcc3v3_pcie2x1l2: regulator-vcc3v3-pcie2x1l2 {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3_pcie2x1l2";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- startup-delay-us = <5000>;
- vin-supply = <&vcc_3v3_s3>;
- };
-
vcc3v3_pcie30: regulator-vcc3v3-pcie30 {
compatible = "regulator-fixed";
enable-active-high;
@@ -480,7 +471,7 @@ &pcie2x1l2 {
pinctrl-0 = <&pcie2_2_rst>, <&pcie20x1m0_clkreqn>;
supports-clkreq;
reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
- vpcie3v3-supply = <&vcc3v3_pcie2x1l2>;
+ vpcie3v3-supply = <&vcc_3v3_s3>;
status = "okay";
};
Thanks
-Anand
^ permalink raw reply related
* Re: [PATCH 3/4] dt-bindings: arm: fsl: add compatible for new Skov I.MX8MP variant
From: Conor Dooley @ 2026-03-25 18:21 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, dri-devel, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-3-10255d236439@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display: simple: Add JuTouch JT070TM041 panel
From: Conor Dooley @ 2026-03-25 18:21 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, dri-devel, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-1-10255d236439@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] arm64/kvm: Enable eager hugepage splitting if HDBSS is available
From: Leonardo Bras @ 2026-03-25 18:20 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
will, yuzenghui, wangzhou1, liuyonglong, Jonathan.Cameron,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose
In-Reply-To: <acQj5grOdZT8LUGp@devkitleo>
FEAT_HDBSS speeds up guest memory dirty tracking by avoiding a page fault
and saving the entry in a tracking structure.
That may be a problem when we have guest memory backed by hugepages or
transparent huge pages, as it's not possible to do on-demand hugepage
splitting, relying only on eager hugepage splitting.
So, at stage2 initialization, enable eager hugepage splitting with
chunk = PAGE_SIZE if the system supports HDBSS.
Signed-off-by: Leonardo Bras <leo.bras@arm.com>
---
arch/arm64/kvm/mmu.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 070a01e53fcb..bdfa72b7c073 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -993,22 +993,26 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
mmu->last_vcpu_ran = alloc_percpu(typeof(*mmu->last_vcpu_ran));
if (!mmu->last_vcpu_ran) {
err = -ENOMEM;
goto out_destroy_pgtable;
}
for_each_possible_cpu(cpu)
*per_cpu_ptr(mmu->last_vcpu_ran, cpu) = -1;
- /* The eager page splitting is disabled by default */
- mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
+ /* The eager page splitting is disabled by default if system has no HDBSS */
+ if (system_supports_hacdbs())
+ mmu->split_page_chunk_size = PAGE_SIZE;
+ else
+ mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
+
mmu->split_page_cache.gfp_zero = __GFP_ZERO;
mmu->pgd_phys = __pa(pgt->pgd);
if (kvm_is_nested_s2_mmu(kvm, mmu))
kvm_init_nested_s2_mmu(mmu);
return 0;
out_destroy_pgtable:
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next 2/2] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Louis-Alexis Eyraud @ 2026-03-25 18:15 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
AngeloGioacchino Del Regno, Heiner Kallweit, Russell King,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <3fbfabf7-b3af-405b-ade4-4f62db2c1c45@lunn.ch>
Hi Andrew,
On Wed, 2026-03-04 at 15:59 +0100, Andrew Lunn wrote:
> > +static int an8801r_did_interrupt(struct phy_device *phydev)
> > +{
> > + u32 irq_en, irq_status;
> > + int ret;
> > +
> > + ret = air_buckpbus_reg_read(phydev,
> > AN8801_BPBUS_REG_WAKE_IRQ_EN,
> > + &irq_en);
> > + if (ret)
> > + return ret;
> > +
> > + ret = air_buckpbus_reg_read(phydev,
> > AN8801_BPBUS_REG_WAKE_IRQ_STS,
> > + &irq_status);
> > + if (ret)
> > + return ret;
> > +
> > + if (irq_status & AN8801_IRQ_WAKE_MAGICPKT)
> > + return 0;
>
> With a name like an8801r_did_interrupt() you would expect the return
> value to be some value of True, if there was an interrupt. I would
> suggest either a different name, or return 1. Maybe also add a
> kerneldoc header indicating the return values, since it is probably
> not going to be standard.
>
The function name was not great and confusing.
While reworking the interrupt handling for WoL support for v2, I merged
the function with the an8801r_handle_interrupt function (to process
differently the Magic Packet and Link Change interrupts) so this
function won't be in v2.
> > +static void an8801r_get_wol(struct phy_device *phydev,
> > + struct ethtool_wolinfo *wol)
> > +{
> > + u32 reg_val;
> > +
> > + air_buckpbus_reg_read(phydev,
> > AN8801_BPBUS_REG_WAKEUP_CTL1, ®_val);
> > +
> > + wol->supported = WAKE_MAGIC;
>
> How does WoL work on this device. Only via interrupts? If so, maybe
> you should only return WAKE_MAGIC as supported if there is a valid
> interrupt?
>
Yes, the WoL works via interrupts and indeed it lacks the interrupt
validity check.
In v2, following the RTL8211F wake-on-lan support example given to me
by Russell in his review, I'll fix this by adding a check using
device_can_wakeup in an8801r_get_wol and an8801r_set_wol functions and
adding a probe function (there was none in v1) to mark the PHY device
as wakeup capable if it has a valid interrupt and if the wakeup-source
property is present in the devicetree for the device node.
> > +static int an8801r_rgmii_delay_config(struct phy_device *phydev)
> > +{
> > + switch (phydev->interface) {
> > + case PHY_INTERFACE_MODE_RGMII_TXID:
> > + return an8801r_rgmii_txdelay(phydev, 4);
> > + case PHY_INTERFACE_MODE_RGMII_RXID:
> > + return an8801r_rgmii_rxdelay(phydev, 0);
> > + case PHY_INTERFACE_MODE_RGMII_ID:
> > + return an8801r_rgmii_txdelay(phydev, 4);
> > + return an8801r_rgmii_rxdelay(phydev, 0);
>
> The parameters look very odd here. 4 means 2ns, but 0 also means 0ns?
> Can this API be improved?
From the info I finally got about these magic values, the differences
between the RX and TX values for the default insert delays can be
explained by the additional RGMII_RXDELAY_ALIGN bit setting when
writing the RX delay register (AN8801_BPBUS_REG_RXDLY_STEP), done by
an8801r_rgmii_rxdelay function because it adds an extra offset.
For TX, the 4 value is the delay step value that is the closest to 2ns
(1.883ns). But For RX, setting the step value to 0 and setting the
RGMII_RXDELAY_ALIGN bit too, inserts a 1.992ns delay. Without align
bit, it would indeed be -0.008ns.
Those delays are also inserted because the an8801r_rgmii_rxdelay and
an8801r_rgmii_txdelay function set the force mode bit
(RGMII_RXDELAY_FORCE_MODE / RGMII_TXDELAY_FORCE_MODE).
If this bit is unset, it prevents inserting a delay.
> Also, PHY_INTERFACE_MODE_RGMII_TXID means 2ns delay for TX, but it
> also means 0ns delay for RX. The code appears to be missing this
> second part.
>
There is indeed a bug with this double return in
PHY_INTERFACE_MODE_RGMII_ID case so the RX delay is not inserted.
> > + case PHY_INTERFACE_MODE_RGMII:
>
> And here you should be disabling all delays. We have seen boards
> where
> the strapping is wrong, the PHY boots in RGMII_ID, but RGMII is
> required, and so the driver must fully implement
> PHY_INTERFACE_MODE_RGMII disabling the delays.
>
You're right it is also missing the delay disabling part.
The an8801r_rgmii_txdelay and an8801r_rgmii_rxdelay function don't
allow to disable them since they always set force mode bit and because
the 0 values does not completely mean no inserted delay.
Their implementations should be modify to be able to do that.
For v2, I've reworked the an8801r_rgmii_delay_config and
an8801r_rgmii_rx/txdelay to handle properly all RGMII configuration
cases and I hope in a simpler manner.
> > +static int an8801r_config_init(struct phy_device *phydev)
> > +{
> > + u8 led_default_function[AN8801R_NUM_LEDS] = { 0 };
> > + int prev_page, ret;
> > +
> > + ret = an8801r_of_init_leds(phydev, led_default_function);
> > + if (ret)
> > + return ret;
> > +
> > + /* Disable Low Power Mode (LPM) */
> > + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2,
> > AN8801_REG_PHY_INTERNAL0,
> > + FIELD_PREP(AN8801_PHY_INTFUNC_MASK,
> > 0x1e));
> > + if (ret)
> > + return ret;
> > +
> > + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2,
> > AN8801_REG_PHY_INTERNAL1,
> > + FIELD_PREP(AN8801_PHY_INTFUNC_MASK,
> > 0x2));
> > + if (ret)
> > + return ret;
> > +
> > + /* Disable EEE by default */
> > + ret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV,
> > 0);
> > + if (ret)
> > + return ret;
>
> Why? If EEE is broken, this is not sufficient to stop a user
> re-enabling it.
>
I've tested by removing these lines and EEE seems working fine.
I'll remove them in v2.
> > +static int an8801r_read_status(struct phy_device *phydev)
> > +{
> > + int prev_speed, ret;
> > + u32 val;
> > +
> > + prev_speed = phydev->speed;
> > +
> > + ret = genphy_read_status(phydev);
> > + if (ret)
> > + return ret;
>
> You configure the PHY to support downshift. If it has performed a
> downshift, does it report the actual speed in the usual registers
> read
> by genphy_read_status(), or is it necessary to read a vendor
> register?
From the tests I've done, I got the actual speed read correctly by
genphy_read_status function.
I did a test by adding in this function the vendor register reading at
the same time and comparing it and did not get a discrepancy too when
switching with ethtool between different speed configurations.
Would it be more reliable to use the vendor register instead?
>
> > +static struct phy_driver airoha_driver[] = {
> > +{
> > + PHY_ID_MATCH_MODEL(AN8801R_PHY_ID),
> > + .name = "Airoha AN8801R",
> > + .features = PHY_GBIT_FEATURES,
>
> Should not be needed, if the PHY enumerates its capabilities
> correctly.
I confirm it is not needed, I'll remove it in v2.
Thanks for the review.
Regards,
Louis-Alexis
>
> Andrew
>
> ---
> pw-bot: cr
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox