* [PATCH 1/1] clk: scmi: Add error message if SCMI protocol handler could not be found
From: Alexander Stein @ 2026-03-25 16:35 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Michael Turquette, Stephen Boyd
Cc: Alexander Stein, arm-scmi, linux-arm-kernel, linux-clk,
linux-kernel
In case the protocol could not be found an error message is better than
probe just failing with error code -22.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
drivers/clk/clk-scmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
index 7c562559ad8bb..c32b15b272ccd 100644
--- a/drivers/clk/clk-scmi.c
+++ b/drivers/clk/clk-scmi.c
@@ -384,7 +384,8 @@ static int scmi_clocks_probe(struct scmi_device *sdev)
scmi_proto_clk_ops =
handle->devm_protocol_get(sdev, SCMI_PROTOCOL_CLOCK, &ph);
if (IS_ERR(scmi_proto_clk_ops))
- return PTR_ERR(scmi_proto_clk_ops);
+ return dev_err_probe(dev, PTR_ERR(scmi_proto_clk_ops),
+ "No SCMI protocol handler found\n");
count = scmi_proto_clk_ops->count_get(ph);
if (count < 0) {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] arm64: panic if IRQ shadow call stack allocation fails
From: Will Deacon @ 2026-03-25 16:35 UTC (permalink / raw)
To: Osama Abdelkader
Cc: Catalin Marinas, Mark Rutland, Ard Biesheuvel, Breno Leitao,
Ryo Takakura, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324161545.5441-1-osama.abdelkader@gmail.com>
On Tue, Mar 24, 2026 at 05:15:41PM +0100, Osama Abdelkader wrote:
> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
> index 15dedb385b9e..b32ed7ef8e00 100644
> --- a/arch/arm64/kernel/irq.c
> +++ b/arch/arm64/kernel/irq.c
> @@ -14,6 +14,7 @@
> #include <linux/init.h>
> #include <linux/irq.h>
> #include <linux/irqchip.h>
> +#include <linux/kernel.h>
> #include <linux/kprobes.h>
> #include <linux/memory.h>
> #include <linux/scs.h>
> @@ -32,23 +33,26 @@ DEFINE_PER_CPU(struct nmi_ctx, nmi_contexts);
>
> DEFINE_PER_CPU(unsigned long *, irq_stack_ptr);
>
> -
> DECLARE_PER_CPU(unsigned long *, irq_shadow_call_stack_ptr);
>
> #ifdef CONFIG_SHADOW_CALL_STACK
> DEFINE_PER_CPU(unsigned long *, irq_shadow_call_stack_ptr);
> #endif
>
> -static void init_irq_scs(void)
> +static void __init init_irq_scs(void)
> {
> int cpu;
> + void *s;
>
> if (!scs_is_enabled())
> return;
>
> - for_each_possible_cpu(cpu)
> - per_cpu(irq_shadow_call_stack_ptr, cpu) =
> - scs_alloc(early_cpu_to_node(cpu));
> + for_each_possible_cpu(cpu) {
> + s = scs_alloc(early_cpu_to_node(cpu));
> + if (!s)
> + panic("irq: Failed to allocate shadow call stack\n");
> + per_cpu(irq_shadow_call_stack_ptr, cpu) = s;
> + }
I don't especially see the point in these panic() messages given that
presumably all sorts of other things will go wrong if we fail simple
allocations this early during boot.
If you really want to check this, then we should at least do the same
for the IRQ stack itself, otherwise it's all a bit academic. So maybe
have init_irq_scs() and init_irq_stacks() return -ENOMEM so that
init_IRQ() can panic?
Will
^ permalink raw reply
* Re: [PATCH v2 2/3] KVM: arm64: Disable SPE Profiling Buffer when running in guest context
From: Alexandru Elisei @ 2026-03-25 16:34 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, mark.rutland, linux-arm-kernel, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose, Fuad Tabba,
Yabin Cui
In-Reply-To: <20260227212136.7660-3-will@kernel.org>
Hi Will,
The patch looks good to me:
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Also tested the series for about 24h on an Orion O6 board with SPE enabled by
profiling two host processes spread across all CPUs with SPE, and at the same
time profiling a virtual machine with the VCPUs simiarly spread across the CPUs
with SPE:
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Thanks,
Alex
On Fri, Feb 27, 2026 at 09:21:34PM +0000, Will Deacon 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>
> ---
> 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 v10 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: Catalin Marinas @ 2026-03-25 16:32 UTC (permalink / raw)
To: David Laight
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: <20260325154210.79a621df@pumpkin>
On Wed, Mar 25, 2026 at 03:42:10PM +0000, David Laight wrote:
> On Wed, 25 Mar 2026 13:53:50 +0000
> Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> > On Tue, Mar 17, 2026 at 09:17:05AM +0000, David Laight wrote:
> > > On Mon, 16 Mar 2026 23:53:22 -0700
> > > Ankur Arora <ankur.a.arora@oracle.com> wrote:
> > > > David Laight <david.laight.linux@gmail.com> writes:
> > > > > On arm64 I think you could use explicit sev and wfe - but that will wake all
> > > > > 'sleeping' cpu; and you may not want the 'thundering herd'.
> > > >
> > > > Wouldn't we still have the same narrow window where the CPU disregards the IPI?
> > >
> > > You need a 'sevl' in the interrupt exit path.
> >
> > No need to, see the rule below in
> > https://developer.arm.com/documentation/ddi0487/maa/2983-beijhbbd:
> >
> > R_XRZRK
> > The Event Register for a PE is set by any of the following:
> > [...]
> > - An exception return.
> >
>
> It is a shame the pages for the SEV and WFE instructions don't mention that.
> And the copy I found doesn't have working hyperlinks to any other sections.
> (Not even references to related instructions...)
The latest architecture spec (M.a.a) has working hyperlinks.
> You do need to at least comment that the "msr s0_3_c1_c0_0, %[ecycles]" is
> actually WFET.
> Is that using an absolute cycle count?
Yes, compared to CNTVCT.
> If so does it work if the time has already passed?
Yes, it exits immediately. These counters are not going to wrap in our
(or device's) lifetime.
> If it is absolute do you need to recalculate it every time around the loop?
No but you do need to read CNTVCT, that's what __delay_cycles() does (it
does not wait).
> __delay_cycles() contains guard(preempt_notrace()). I haven't looked what
> that does but is it needed here since preemption is disabled?
The guard was added recently by commit e5cb94ba5f96 ("arm64: Fix
sampling the "stable" virtual counter in preemptible section"). It's
needed for the udelay() case but probably not for Ankur's series. Maybe
we can move the guard in the caller?
> Looking at the code I think the "sevl; wfe" pair should be higher up.
Yes, I replied to your other message. We could move it higher indeed,
before the condition check, but I can't get my head around the ordering.
Can need_resched() check be speculated before the WFE? I need to think
some more.
> I also wonder how long it takes the cpu to leave any low power state.
> We definitely found that was an issue on some x86 cpu and had to both
> disable the lowest low power state and completely rework some wakeup
> code that really wanted a 'thundering herd' rather than the very gentle
> 'bring each cpu out of low power one at a time' that cv_broadcast()
> gave it.
WFE is a very shallow power state where all hardware state is retained.
We have an even stream broadcast to all CPUs regularly already (10KHz)
and I haven't heard people complaining about power degradation. If a CPU
is a WFI state or even deeper into firmware (following a PSCI call), an
exclusive monitor event won't wake it up. It's only for those cores
waiting in WFE.
--
Catalin
^ permalink raw reply
* Re: [PATCH 02/17] raid6: remove __KERNEL__ ifdefs
From: H. Peter Anvin @ 2026-03-25 16:13 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Morton
Cc: 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: <59d1d178-c141-4229-81e9-a6c23fa81f2f@zytor.com>
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.
-hpa
^ 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 16:28 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: <20260325092300.9008e605ed5550ce4935638f@linux-foundation.org>
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.
^ permalink raw reply
* Re: (subset) [PATCH v3 0/6] arm64: dts: freescale: add Verdin iMX95
From: Frank Li @ 2026-03-25 16:27 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ernest Van Hoecke
Cc: Ernest Van Hoecke, Emanuele Ghidoli, Francesco Dolcini,
devicetree, linux-kernel, imx, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260325-verdin-imx95-upstream-frank-li-base-v3-0-b2b5221a8077@toradex.com>
On Wed, 25 Mar 2026 15:46:01 +0100, Ernest Van Hoecke wrote:
> This patch series adds support for the Toradex Verdin i.MX95 SoM and its
> currently available carrier boards: the Verdin Development Board, and
> the Dahlia, Ivy, Mallow and Yavia carrier boards.
>
> The module consists of an NXP i.MX95 family SoC, up to 16GB LPDDR4x RAM,
> up to 128GB of storage, a USB 3.2 OTG and USB 2.0 Host, a Gigabit
> Ethernet PHY, an I2C EEPROM and Temperature Sensor, an RX8130 RTC, an
> I3C bus, one Quad lane CSI interface, one Quad lane DSI or CSI
> interface, one LVDS interface (one or two channels), and some optional
> addons: TPM 2.0, and a WiFi/BT module.
>
> [...]
Applied, thanks!
[2/6] arm64: dts: freescale: Add Verdin iMX95 support
commit: d77901ff827c6583563d4b24b34efb795b63bdcf
[3/6] arm64: dts: freescale: imx95-verdin: Add Dahlia carrier board
commit: e69a8fd8827699f9de5ec0e092f04462656d40bd
[4/6] arm64: dts: freescale: imx95-verdin: Add Ivy carrier board
commit: ad37ed93a2b564cb7026faf9a0c9dd01ce566479
[5/6] arm64: dts: freescale: imx95-verdin: Add Mallow carrier board
commit: 7d84f7fa8293739d71f92270f46079d4d7c5f0a2
[6/6] arm64: dts: freescale: imx95-verdin: Add Yavia carrier board
commit: fd589d6e8b38eb2783980ba38cef9dd5cfc68386
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [RFC PATCH 00/14] KVM: ITS hardening for pKVM
From: Sebastian Ene @ 2026-03-25 16:26 UTC (permalink / raw)
To: Mostafa Saleh
Cc: alexandru.elisei, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, catalin.marinas, dbrazdil, joey.gouly, kees,
mark.rutland, maz, oupton, perlarsen, qperret, rananta,
suzuki.poulose, tabba, tglx, vdonnefort, bgrzesik, will,
yuzenghui
In-Reply-To: <abQqqTYvmrtGp9l7@google.com>
On Fri, Mar 13, 2026 at 03:18:01PM +0000, Mostafa Saleh wrote:
Hi Mostafa,
> Hi Seb,
>
> On Tue, Mar 10, 2026 at 12:49:19PM +0000, Sebastian Ene wrote:
> > This series introduces the necessary machinery to perform trap & emulate
> > on device access in pKVM. Furthermore, it hardens the GIC/ITS controller to
> > prevent an attacker from tampering with the hypervisor protected memory
> > through this device.
> >
> > In pKVM, the host kernel is initially trusted to manage the boot process but
> > its permissions are revoked once KVM initializes. The GIC/ITS device is
> > configured before the kernel deprivileges itself. Once the hypervisor
> > becomes available, sanitize the accesses to the ITS controller by
> > trapping and emulating certain registers and by shadowing some memory
> > structures used by the ITS.
> >
> > This is required because the ITS can issue transactions on the memory
> > bus *directly*, without having an SMMU in front of it, which makes it
> > an interesting target for crossing the hypervisor-established privilege
> > boundary.
> >
> >
> > Patch overview
> > ==============
> >
> > The first patch is re-used from Mostafa's series[1] which brings SMMU-v3
> > support to pKVM.
> >
> > [1] https://lore.kernel.org/linux-iommu/20251117184815.1027271-1-smostafa@google.com/#r
> >
> > Some of the infrastructure built in that series might intersect and we
> > agreed to converge on some changes. The patches [1 - 3] allow unmapping
> > devices from the host address space and installing a handler to trap
> > accesses from the host. While executing in the handler, enough context
> > has to be given from mem-abort to perform the emulation of the device
> > such as: the offset, the access size, direction of the write and private
> > related data specific to the device.
> > The unmapping of the device from the host address space is performed
> > after the host deprivilege (during _kvm_host_prot_finalize call).
> >
> > The 4th patch looks up the ITS node from the device tree and adds it to
> > an array of unmapped devices. It install a handler that forwards all the
> > MMIO request to mediate the host access inside the emulation layer and
> > to prevent breaking ITS functionality.
> >
> > The 5th patch changes the GIC/ITS driver to exposes two new methods
> > which will be called from the KVM layer to setup the shadow state and
> > to take the appropriate locks. This one is the most intrusive as it
> > changes the current GIC/ITS driver. I tried to avoid creating a
> > dependency with KVM to keep the GIC driver agnostic of the virtualization
> > layer but I am happy to explore other options as well.
> > To avoid re-programming the ITS device with new shadow structures after
> > pKVM is ready, I exposed two functions to change the
> > pointers inside the driver for the following structures:
> > - the command queue points to a newly allocated queue
> > - the GITS_BASER<n> tables configured with an indirect layout have the
> > first layer shadowed and they point to a new memory region
> >
> > Patch 6 adds the entry point into the emulation setup and sets up the
> > shadow command queue. It adds some helper macros to define the offset
> > register and the associate action that we want to execute in the
> > emulation. It also unmaps the state passed from the host kernel
> > to prevent it from playing nasty games later on. The patch
> > traps accesses to CWRITER register and copies the commands from the
> > host command queue to the shadow command queue.
> >
> > Patch 7 prevents the host from directly accessing the first layer of the
> > indirect tables held in GITS_BASER<n>. It also prevents the host from
> > directly accesssing the last layer of the Device Table (since the entries
> > in this table hold the address of the ITT table) and of the vPE Table
> > (since the vPE table entries hold the address of the virtual LPI pending
> > table.
> >
> > Patches [8-10] sanitize the commands sent to the ITS and their
> > arguments.
> >
> > Patches [11-13] restrict the access of the host to certain registers
> > and prevent undefined behaviour. Prevent the host from re-programming
> > the tables held in the GITS_BASER register.
> >
> > The last patch introduces an hvc to setup the ITS emulation and calls
> > into the ITS driver to setup the shadow state.
> >
> >
> > Design
> > ======
> >
> >
> > 1. Command queue shadowing
> >
> > The ITS hardware supports a command queue which is programmed by the driver
> > in the GITS_CBASER register. To inform the hardware that a new command
> > has been added, the driver updates an index into the GITS_CWRITER
> > register. The driver then reads the GITS_CREADR register to see if the
> > command was processed or if the queue is stalled.
> >
> > To create a new command, the emulation layer mirrors the behavior
> > as following:
> > (i) The host ITS driver creates a command in the shadow queue:
> > its_allocate_entry() -> builder()
> > (ii) Notifies the hardware that a new command is available:
> > its_post_commands()
> > (iii) Hypervisor traps the write to GITS_CWRITER:
> > handle_host_mem_abort() -> handle_host_mmio_trap() ->
> > pkvm_handle_gic_emulation()
> > (iv) Hypervisor copies the command from the host command queue
> > to the original queue which is not accessible to the host.
> > It parses the command and updates the hardware write.
> >
> > The driver allocates space for the original command queue and programs
> > the hardware (GITS_CWRITER). When pKVM becomes available, the driver
> > allocates a new (shadow) queue and replaces its original pointer to
> > the queue with this new one. This is to prevent a malicious host from
> > tampering with the commands sent to the ITS hardware.
> >
> > The entry point of our emulation shares the memory of the newly
> > allocated queue with the hypervisor and donates the memory of the
> > original queue to make it inaccesible to the host.
> >
> >
> > 2. Indirect tables first level shadowing
> >
> > The ITS hardware supports indirection to minimize the space required to
> > accommodate large tables (eg. deviceId space used to index the Device Table
> > is quite sparse). This is a 2-level indirection, with entries from the
> > first table pointing to a second table.
> >
> > An attacker in control of the host can insert an address that points to
> > the hypervisor protected memory in the first level table and then use
> > subsequent ITS commands to write to this memory (MAPD).
> >
> > To shadow this tables, we rely on the driver to allocate space for it
> > and we copy the original content from the table into the copy. When
> > pKVM becomes available we switch the pointers that hold the orginal
> > tables to point to the copy.
> > To keep the tables from the hypervisor in sync with what the host
> > has, we update the tables when commands are sent to the ITS.
> >
> >
> > 3. Hiding the last layer of the Device Table and vPE Table from the host
> >
> > An attacker in control of the host kernel can alter the content of these
> > tables directly (the Arm IHI 0069H.b spec says that is undefined behavior
> > if entries are created by software). Normally these entries are created in
> > response of commands sent to the ITS.
> >
> > A Device Table entry that has the following structure:
> >
> > type DeviceTableEntry is (
> > boolean Valid,
> > Address ITT_base,
> > bits(5) ITT_size
> > )
> >
> > This can be maliciously created by an attacker and the ITT_base can be
> > pointed to hypervisor protected memory. The MAPTI command can then be
> > used to write over the ITT_base with an ITE entry.
> >
> > Similarly a vCPU Table entry has the following structure:
> >
> > type VCPUTableEntry is (
> > boolean Valid,
> > bits(32) RDbase,
> > Address VPT_base,
> > bits(5) VPT_size
> > )
> >
> > VPT_base can be pointed to hypervisor protected memory and then a
> > command can be used to raise interrupts and set the corresponding
> > bit. This would give a 1-bit write primitive so is not "as generous"
> > as the others.
> >
> >
> > Notes
> > =====
> >
> >
> > Performance impact is expected with this as the emulation dance is not
> > cost free.
> > I haven't implemented any ITS quirks in the emulation and I don't know
> > whether we will need it ? (some hardware needs explicit dcache flushing
> > ITS_FLAGS_CMDQ_NEEDS_FLUSHING).
> >
> > Please note that Redistributors trapping hasn't been addressed at all in
> > this series and the solution is not sufficient but this can be extended
> > afterwards.
> > The current series has been tested with Qemu (-machine
> > virt,virtualization=true,gic-version=4) and with Pixel 10.
> >
> >
> > Thanks,
> > Sebastian E.
> >
> > Mostafa Saleh (1):
> > KVM: arm64: Donate MMIO to the hypervisor
> >
> > Sebastian Ene (13):
> > KVM: arm64: Track host-unmapped MMIO regions in a static array
> > KVM: arm64: Support host MMIO trap handlers for unmapped devices
> > KVM: arm64: Mediate host access to GIC/ITS MMIO via unmapping
> > irqchip/gic-v3-its: Prepare shadow structures for KVM host deprivilege
> > KVM: arm64: Add infrastructure for ITS emulation setup
> > KVM: arm64: Restrict host access to the ITS tables
> > KVM: arm64: Trap & emulate the ITS MAPD command
> > KVM: arm64: Trap & emulate the ITS VMAPP command
> > KVM: arm64: Trap & emulate the ITS MAPC command
> > KVM: arm64: Restrict host updates to GITS_CTLR
> > KVM: arm64: Restrict host updates to GITS_CBASER
> > KVM: arm64 Restrict host updates to GITS_BASER
> > KVM: arm64: Implement HVC interface for ITS emulation setup
>
> I tested the patches on Lenovo ideacenter Mini X Gen 10 Snapdragon,
> and the kernel hangs at boot for me with messags the following log:
>
> [ 2.735838] ITS queue timeout (1056 1024)
> [ 2.739969] ITS cmd its_build_mapd_cmd failed
> [ 4.776344] ITS queue timeout (1120 1024)
> [ 4.780472] ITS cmd its_build_mapti_cmd failed
> [ 6.816677] ITS queue timeout (1184 1024)
> [ 6.820806] ITS cmd its_build_mapti_cmd failed
> [ 8.857009] ITS queue timeout (1248 1024)
> [ 8.861129] ITS cmd its_build_mapti_cmd failed
>
> I am happy to do more debugging, let me know if I can try anything.
I managed to reproduce it on this Lenovo machine. I will have to dig a bit more
because I am not seeing this under Qemu. As a quick try I used
gic_flush_dcache_to_poc after adding commands to the ITS queue but it
didn't make any difference.
>
> Thanks,
> Mostafa
>
Thanks for trying it,
Sebastian
> >
> > arch/arm64/include/asm/kvm_arm.h | 3 +
> > arch/arm64/include/asm/kvm_asm.h | 1 +
> > arch/arm64/include/asm/kvm_pkvm.h | 20 +
> > arch/arm64/kvm/hyp/include/nvhe/its_emulate.h | 17 +
> > arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 2 +
> > arch/arm64/kvm/hyp/nvhe/Makefile | 3 +-
> > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 14 +
> > arch/arm64/kvm/hyp/nvhe/its_emulate.c | 653 ++++++++++++++++++
> > arch/arm64/kvm/hyp/nvhe/mem_protect.c | 134 ++++
> > arch/arm64/kvm/hyp/nvhe/setup.c | 28 +
> > arch/arm64/kvm/hyp/pgtable.c | 9 +-
> > arch/arm64/kvm/pkvm.c | 60 ++
> > drivers/irqchip/irq-gic-v3-its.c | 177 ++++-
> > include/linux/irqchip/arm-gic-v3.h | 36 +
> > 14 files changed, 1126 insertions(+), 31 deletions(-)
> > create mode 100644 arch/arm64/kvm/hyp/include/nvhe/its_emulate.h
> > create mode 100644 arch/arm64/kvm/hyp/nvhe/its_emulate.c
> >
> > --
> > 2.53.0.473.g4a7958ca14-goog
> >
^ 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 16:23 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: <af9d8a6a-074c-412c-ac5e-3f0dadde3e7d@lucifer.local>
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.
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: imx8mp-tqma8mpql-mba8mp-ras314: add vcc supply for BT device
From: Frank Li @ 2026-03-25 16:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Alexander Stein
Cc: linux, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260323125951.611042-1-alexander.stein@ew.tq-group.com>
On Mon, 23 Mar 2026 13:59:50 +0100, Alexander Stein wrote:
> Add the vcc power supply for the BT device. Fixes the warning:
> btnxpuart serial0-0: supply vcc not found, using dummy regulator
>
>
Applied, thanks!
[1/1] arm64: dts: imx8mp-tqma8mpql-mba8mp-ras314: add vcc supply for BT device
commit: fb205d7e0181c924d62cfd437caed1278990a8c7
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/3] TQMa93xx on MBa93xxLA-Mini support
From: Frank Li @ 2026-03-25 16:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Alexander Stein
Cc: Frank Li, devicetree, linux-kernel, imx, linux-arm-kernel, linux
In-Reply-To: <20260319125013.2421621-1-alexander.stein@ew.tq-group.com>
On Thu, 19 Mar 2026 13:50:07 +0100, Alexander Stein wrote:
> this series adds support for TQMa93xxLA on MBa93xxLA-Mini [1],
> a single board computer board in small form factor.
> It has a reduced feature set compared to MBa93xxLA, with WiFi/Bluetooth and
> WWAN applicaitons in mind.
> An overlay for Ezurio WiFi module is added as well.
>
> Changes in v2:
> * Collected tags
> * Fixes commit message style
> * Remove unused display related DT nodes
> * Fix Ethernet PHY IRQ types
>
> [...]
Applied, thanks!
[2/3] arm64: dts: freescale: add initial device tree for TQMa93xx/MBa93xxLA-MINI
commit: 740c700a11e50ba67f7f5cd6df26affe842c68cc
[3/3] arm64: dts: freescale: imx93-tqma9352-mba93xxla-mini: Add WLAN/BT overlay
commit: c0d0f688b73b42621f1a86c4ad3c418fc06ae2c8
Update Makefile to keep alphabet order.
Update commit message to add extra empty line between paragraph.
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Prevent the host from using an smc with imm16 != 0
From: Sebastian Ene @ 2026-03-25 16:02 UTC (permalink / raw)
To: Mark Rutland
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, maz, oupton, suzuki.poulose, tabba,
vdonnefort, will, yuzenghui
In-Reply-To: <acPi5V0DgGcgHNGO@J2N7QTR9R3>
On Wed, Mar 25, 2026 at 01:28:05PM +0000, Mark Rutland wrote:
> On Wed, Mar 25, 2026 at 11:31:38AM +0000, Sebastian Ene wrote:
> > The ARM Service Calling Convention (SMCCC) specifies that the function
> > identifier and parameters should be passed in registers, leaving the
> > 16-bit immediate field of the SMC instruction un-handled.
>
> That's not quite right; the SMCCC spec says callers must use immediate
> 0.
I'll update the commit message. it is the pKVM that doesn't handle it
(the imm16).
>
> See https://developer.arm.com/documentation/den0028/h/ section 2.10
> ("SME and HVC immediate value"), which says:
>
> | • For all compliant calls, an SMC or HVC immediate value of zero must be
> | used.
> | • Nonzero immediate values in SMC instructions are reserved.
> | • Nonzero immediate values in HVC instructions are designated for use by
> | hypervisor vendors.
>
> > Currently, our pKVM handler ignores the immediate value, which could lead
> > to non-compliant software relying on implementation-defined behavior.
> > Enforce the host kernel running under pKVM to use an immediate value
> > of 0 by decoding the ISS from the ESR_EL2 and return a not supported
> > error code back to the caller.
>
> From my PoV, it'd be fine to turn a non-zero immediate into an UNDEF:
>
> * For HVC, we can say any non-zero immediate represents a request to KVM to
> inject an UNDEF.
>
> * For SMC, the dbehaviour is not defined.
>
> I am also ok with returning a value in x0, BUT that's stronger than SMCCC
> actually requires.
>
> Mark.
Thanks,
Sebastian
>
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > v1 -> v2:
> >
> > - Dropped injecting an UNDEF and return an error instead
> > (SMCCC_RET_NOT_SUPPORTED)
> > - Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX
> > - Updated the title of the commit message from:
> > "[PATCH] KVM: arm64: Inject UNDEF when host is executing an
> > smc with imm16 != 0"
> > ---
> > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index e7790097db93..4ffe30fd8707 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -762,6 +762,12 @@ void handle_trap(struct kvm_cpu_context *host_ctxt)
> > handle_host_hcall(host_ctxt);
> > break;
> > case ESR_ELx_EC_SMC64:
> > + if (ESR_ELx_xVC_IMM_MASK & esr) {
> > + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> > + kvm_skip_host_instr();
> > + break;
> > + }
> > +
> > handle_host_smc(host_ctxt);
> > break;
> > case ESR_ELx_EC_IABT_LOW:
> > --
> > 2.53.0.1018.g2bb0e51243-goog
> >
^ permalink raw reply
* [PATCH v3] arm64: dts: imx8mp-frdm: add sd, ethernet, wifi, usb and hdmi support
From: Fabian Pfitzner @ 2026-03-25 16:01 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Fabian Pfitzner
Add support for the following new features:
- SD Card
- Ethernet (FEC + EQOS)
- Wifi
- USB
- HDMI
The imx8mp-evk dt and the NXP downstream imx8mp-frdm dts were
taken as a reference.
Signed-off-by: Fabian Pfitzner <f.pfitzner@pengutronix.de>
---
Changes in v3:
- Rebased onto for-next branch:
https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git/log/?h=for-next
- Link to v2: https://lore.kernel.org/r/20260316-fpf-imx8mp-frdm-v2-1-e2e8aadecb2f@pengutronix.de
Changes in v2:
- Reorder nodes by name
- Remove unused "realtek,clkout-disable" property
- Link to v1: https://lore.kernel.org/r/20260224-fpf-imx8mp-frdm-v1-1-d7f3b57c18e0@pengutronix.de
---
arch/arm64/boot/dts/freescale/imx8mp-frdm.dts | 407 ++++++++++++++++++++++++++
1 file changed, 407 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts b/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
index d69d78fed4e1b151be3948bb8ef0888eb016c667..b301cf3d425b1b748e2be8f223bb703e7a4355f6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
@@ -42,6 +42,67 @@ memory@40000000 {
reg = <0x0 0x40000000 0 0xc0000000>,
<0x1 0x00000000 0 0x40000000>;
};
+
+ native-hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "HDMI OUT";
+ type = "a";
+
+ port {
+ hdmi_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
+ reg_usdhc2_vmmc: regulator-sd {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usb_vbus: regulator-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "USB_VBUS";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&pcal6416_1 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usdhc1_vmmc: regulator-wifi-vmmc {
+ compatible = "regulator-fixed";
+ regulator-name = "WLAN_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&pcal6416_1 10 GPIO_ACTIVE_HIGH>;
+ /*
+ * IW612 wifi chip needs more delay than other wifi chips to complete
+ * the host interface initialization after power up, otherwise the
+ * internal state of IW612 may be unstable, resulting in the failure of
+ * the SDIO3.0 switch voltage.
+ */
+ enable-active-high;
+ startup-delay-us = <20000>;
+ };
+
+ reg_usdhc1_vqmmc: regulator-wifi-vqmmc {
+ compatible = "regulator-fixed";
+ regulator-name = "regulator-wifi-vqmmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ enable-active-high;
+ };
+
+ sdio_pwrseq: usdhc1-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
+ };
};
&A53_0 {
@@ -60,6 +121,147 @@ &A53_3 {
cpu-supply = <®_arm>;
};
+&eqos {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ snps,force_thresh_dma_mode;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@2 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos_phy>;
+ reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <5>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ };
+
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x4>;
+ };
+
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x8>;
+ };
+
+ queue4 {
+ snps,dcb-algorithm;
+ snps,priority = <0xf0>;
+ };
+ };
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <5>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ snps,map-to-dma-channel = <0>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ snps,map-to-dma-channel = <1>;
+ };
+
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x4>;
+ snps,map-to-dma-channel = <2>;
+ };
+
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x8>;
+ snps,map-to-dma-channel = <3>;
+ };
+
+ queue4 {
+ snps,dcb-algorithm;
+ snps,priority = <0xf0>;
+ snps,map-to-dma-channel = <4>;
+ };
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy1>;
+ fsl,magic-packet;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec_phy>;
+ eee-broken-1000t;
+ reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ realtek,aldps-enable;
+ realtek,clkout-disable;
+ };
+ };
+};
+
+
+&hdmi_pvi {
+ status = "okay";
+};
+
+&hdmi_tx {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+ status = "okay";
+
+ ports {
+ port@1 {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+ };
+};
+
+&hdmi_tx_phy {
+ status = "okay";
+};
+
&i2c1 {
clock-frequency = <400000>;
pinctrl-names = "default";
@@ -218,6 +420,32 @@ &i2c3 {
status = "okay";
};
+&lcdif3 {
+ status = "okay";
+};
+
+&usb3_0 {
+ status = "okay";
+};
+
+&usb3_1 {
+ status = "okay";
+};
+
+&usb3_phy0 {
+ status = "okay";
+};
+
+&usb3_phy1 {
+ vbus-supply = <®_usb_vbus>;
+ status = "okay";
+};
+
+&usb_dwc3_1 {
+ dr_mode = "host";
+ status = "okay";
+};
+
&snvs_pwrkey {
status = "okay";
};
@@ -237,6 +465,36 @@ &uart3 {
status = "okay";
};
+&usdhc1 {
+ assigned-clocks = <&clk IMX8MP_CLK_USDHC1>;
+ assigned-clock-rates = <200000000>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ vmmc-supply = <®_usdhc1_vmmc>;
+ vqmmc-supply = <®_usdhc1_vqmmc>;
+ bus-width = <4>;
+ non-removable;
+ no-sd;
+ no-mmc;
+ status = "okay";
+};
+
+&usdhc2 {
+ assigned-clocks = <&clk IMX8MP_CLK_USDHC2>;
+ assigned-clock-rates = <400000000>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ bus-width = <4>;
+ status = "okay";
+};
+
&usdhc3 {
assigned-clocks = <&clk IMX8MP_CLK_USDHC3>;
assigned-clock-rates = <400000000>;
@@ -250,6 +508,74 @@ &usdhc3 {
};
&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC 0x2
+ MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO 0x2
+ MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0 0x90
+ MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1 0x90
+ MX8MP_IOMUXC_ENET_RD2__ENET_QOS_RGMII_RD2 0x90
+ MX8MP_IOMUXC_ENET_RD3__ENET_QOS_RGMII_RD3 0x90
+ MX8MP_IOMUXC_ENET_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x90
+ MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x90
+ MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0 0x16
+ MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1 0x16
+ MX8MP_IOMUXC_ENET_TD2__ENET_QOS_RGMII_TD2 0x16
+ MX8MP_IOMUXC_ENET_TD3__ENET_QOS_RGMII_TD3 0x16
+ MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x16
+ MX8MP_IOMUXC_ENET_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x16
+ >;
+ };
+
+ pinctrl_eqos_phy: eqosphygrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI2_RXC__GPIO4_IO22 0x10
+ >;
+ };
+
+ pinctrl_fec: fecgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI1_RXD2__ENET1_MDC 0x2
+ MX8MP_IOMUXC_SAI1_RXD3__ENET1_MDIO 0x2
+ MX8MP_IOMUXC_SAI1_RXD4__ENET1_RGMII_RD0 0x90
+ MX8MP_IOMUXC_SAI1_RXD5__ENET1_RGMII_RD1 0x90
+ MX8MP_IOMUXC_SAI1_RXD6__ENET1_RGMII_RD2 0x90
+ MX8MP_IOMUXC_SAI1_RXD7__ENET1_RGMII_RD3 0x90
+ MX8MP_IOMUXC_SAI1_TXC__ENET1_RGMII_RXC 0x90
+ MX8MP_IOMUXC_SAI1_TXFS__ENET1_RGMII_RX_CTL 0x90
+ MX8MP_IOMUXC_SAI1_TXD0__ENET1_RGMII_TD0 0x16
+ MX8MP_IOMUXC_SAI1_TXD1__ENET1_RGMII_TD1 0x16
+ MX8MP_IOMUXC_SAI1_TXD2__ENET1_RGMII_TD2 0x16
+ MX8MP_IOMUXC_SAI1_TXD3__ENET1_RGMII_TD3 0x16
+ MX8MP_IOMUXC_SAI1_TXD4__ENET1_RGMII_TX_CTL 0x16
+ MX8MP_IOMUXC_SAI1_TXD5__ENET1_RGMII_TXC 0x16
+ >;
+ };
+
+ pinctrl_fec_phy: fecphygrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI1_RXD0__GPIO4_IO02 0x10
+ >;
+ };
+
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0x10
+ >;
+ };
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* Pin might be required by multiple drivers
+ * (e. g. HDMI Audio and HDMI TX)
+ */
+ MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0x40000010
+ >;
+ };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL (MX8MP_DSE_X4 | MX8MP_I2C_DEFAULT)
@@ -293,6 +619,12 @@ MX8MP_IOMUXC_SD1_STROBE__GPIO2_IO11
>;
};
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x40
+ >;
+ };
+
pinctrl_uart2: uart2grp {
fsl,pins = <
MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX (MX8MP_PULL_UP | MX8MP_PULL_ENABLE)
@@ -310,6 +642,81 @@ MX8MP_IOMUXC_ECSPI1_MISO__UART3_DCE_CTS (MX8MP_PULL_UP | MX8MP_PULL_ENABLE)
>;
};
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD1_CLK__USDHC1_CLK 0x190
+ MX8MP_IOMUXC_SD1_CMD__USDHC1_CMD 0x1d0
+ MX8MP_IOMUXC_SD1_DATA0__USDHC1_DATA0 0x1d0
+ MX8MP_IOMUXC_SD1_DATA1__USDHC1_DATA1 0x1d0
+ MX8MP_IOMUXC_SD1_DATA2__USDHC1_DATA2 0x1d0
+ MX8MP_IOMUXC_SD1_DATA3__USDHC1_DATA3 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD1_CLK__USDHC1_CLK 0x194
+ MX8MP_IOMUXC_SD1_CMD__USDHC1_CMD 0x1d4
+ MX8MP_IOMUXC_SD1_DATA0__USDHC1_DATA0 0x1d4
+ MX8MP_IOMUXC_SD1_DATA1__USDHC1_DATA1 0x1d4
+ MX8MP_IOMUXC_SD1_DATA2__USDHC1_DATA2 0x1d4
+ MX8MP_IOMUXC_SD1_DATA3__USDHC1_DATA3 0x1d4
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD1_CLK__USDHC1_CLK 0x196
+ MX8MP_IOMUXC_SD1_CMD__USDHC1_CMD 0x1d6
+ MX8MP_IOMUXC_SD1_DATA0__USDHC1_DATA0 0x1d6
+ MX8MP_IOMUXC_SD1_DATA1__USDHC1_DATA1 0x1d6
+ MX8MP_IOMUXC_SD1_DATA2__USDHC1_DATA2 0x1d6
+ MX8MP_IOMUXC_SD1_DATA3__USDHC1_DATA3 0x1d6
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x190
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d0
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d0
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d0
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d0
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d0
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc0
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x194
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d4
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc0
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x196
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d6
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d6
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d6
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d6
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d6
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc0
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CD_B__GPIO2_IO12 0x1c4
+ >;
+ };
+
pinctrl_usdhc3: usdhc3grp {
fsl,pins = <
MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK
---
base-commit: 6c4b48012d57f205c94f25da0c68a4027ea6daf6
change-id: 20260224-fpf-imx8mp-frdm-402c4df06302
Best regards,
--
Fabian Pfitzner <f.pfitzner@pengutronix.de>
^ permalink raw reply related
* Re: [PATCH 03/10] i2c: sun6i-p2wi: Replace dev_err() with dev_err_probe() in probe function
From: Chen-Yu Tsai @ 2026-03-25 16:01 UTC (permalink / raw)
To: Atharv Dubey
Cc: Till Harbaum, Andi Shyti, Laxman Dewangan, Dmitry Osipenko,
Thierry Reding, Jonathan Hunter, Jernej Skrabec, Samuel Holland,
Pierre-Yves MORDRET, Alain Volmat, Maxime Coquelin,
Alexandre Torgue, Patrice Chotard, Orson Zhai, Baolin Wang,
Chunyan Zhang, Jean Delvare, linux-i2c, linux-kernel, linux-tegra,
linux-arm-kernel, linux-sunxi, linux-stm32, Enrico Zanda
In-Reply-To: <20260324-deverr-v1-3-7e591cce33a3@gmail.com>
On Wed, Mar 25, 2026 at 2:27 AM Atharv Dubey <atharvd440@gmail.com> wrote:
>
> From: Enrico Zanda <e.zanda1@gmail.com>
>
> This simplifies the code while improving log.
>
> Signed-off-by: Enrico Zanda <e.zanda1@gmail.com>
> Signed-off-by: Atharv Dubey <atharvd440@gmail.com>
> ---
> drivers/i2c/busses/i2c-sun6i-p2wi.c | 55 ++++++++++++++-----------------------
> 1 file changed, 20 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-sun6i-p2wi.c b/drivers/i2c/busses/i2c-sun6i-p2wi.c
> index fb5280b8cf7f..dffbe776a195 100644
> --- a/drivers/i2c/busses/i2c-sun6i-p2wi.c
> +++ b/drivers/i2c/busses/i2c-sun6i-p2wi.c
> @@ -194,22 +194,16 @@ static int p2wi_probe(struct platform_device *pdev)
> int ret;
>
> of_property_read_u32(np, "clock-frequency", &clk_freq);
> - if (clk_freq > P2WI_MAX_FREQ) {
> - dev_err(dev,
> - "required clock-frequency (%u Hz) is too high (max = 6MHz)",
> - clk_freq);
> - return -EINVAL;
> - }
> + if (clk_freq > P2WI_MAX_FREQ)
> + return dev_err_probe(dev, -EINVAL,
> + "required clock-frequency (%u Hz) is too high (max = 6MHz)",
> + clk_freq);
>
> - if (clk_freq == 0) {
> - dev_err(dev, "clock-frequency is set to 0 in DT\n");
> - return -EINVAL;
> - }
> + if (clk_freq == 0)
> + return dev_err_probe(dev, -EINVAL, "clock-frequency is set to 0 in DT\n");
>
> - if (of_get_child_count(np) > 1) {
> - dev_err(dev, "P2WI only supports one target device\n");
> - return -EINVAL;
> - }
> + if (of_get_child_count(np) > 1)
> + return dev_err_probe(dev, -EINVAL, "P2WI only supports one target device\n");
>
> p2wi = devm_kzalloc(dev, sizeof(struct p2wi), GFP_KERNEL);
> if (!p2wi)
> @@ -226,11 +220,9 @@ static int p2wi_probe(struct platform_device *pdev)
> childnp = of_get_next_available_child(np, NULL);
> if (childnp) {
> ret = of_property_read_u32(childnp, "reg", &target_addr);
> - if (ret) {
> - dev_err(dev, "invalid target address on node %pOF\n",
> - childnp);
> - return -EINVAL;
> - }
> + if (ret)
> + return dev_err_probe(dev, -EINVAL,
> + "invalid target address on node %pOF\n", childnp);
>
> p2wi->target_addr = target_addr;
> }
> @@ -245,26 +237,20 @@ static int p2wi_probe(struct platform_device *pdev)
> return irq;
>
> p2wi->clk = devm_clk_get_enabled(dev, NULL);
> - if (IS_ERR(p2wi->clk)) {
> - ret = PTR_ERR(p2wi->clk);
> - dev_err(dev, "failed to enable clk: %d\n", ret);
> - return ret;
> - }
> + if (IS_ERR(p2wi->clk))
> + return dev_err_probe(dev, PTR_ERR(p2wi->clk),
> + "failed to enable clk\n");
>
> parent_clk_freq = clk_get_rate(p2wi->clk);
>
> p2wi->rstc = devm_reset_control_get_exclusive(dev, NULL);
> - if (IS_ERR(p2wi->rstc)) {
> - dev_err(dev, "failed to retrieve reset controller: %pe\n",
> - p2wi->rstc);
> - return PTR_ERR(p2wi->rstc);
> - }
> + if (IS_ERR(p2wi->rstc))
> + return dev_err_probe(dev, PTR_ERR(p2wi->rstc),
> + "failed to retrieve reset controller\n");
>
> ret = reset_control_deassert(p2wi->rstc);
> - if (ret) {
> - dev_err(dev, "failed to deassert reset line: %d\n", ret);
> - return ret;
> - }
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to deassert reset line\n");
You could also simplify this whole block with
devm_reset_control_get_exclusive_deasserted().
Either way,
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
> init_completion(&p2wi->complete);
> p2wi->adapter.dev.parent = dev;
> @@ -276,8 +262,7 @@ static int p2wi_probe(struct platform_device *pdev)
>
> ret = devm_request_irq(dev, irq, p2wi_interrupt, 0, pdev->name, p2wi);
> if (ret) {
> - dev_err(dev, "can't register interrupt handler irq%d: %d\n",
> - irq, ret);
> + dev_err_probe(dev, ret, "can't register interrupt handler irq%d\n", irq);
> goto err_reset_assert;
> }
>
>
> --
> 2.43.0
>
^ permalink raw reply
* [GIT PULL] firmware: arm_scmi: Updates for v7.1
From: Sudeep Holla @ 2026-03-25 16:00 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, arm-scmi, ALKML
Cc: Sudeep Holla, Arnd Bergmann, Cristian Marussi
Hi ARM SoC Team,
Please pull !
Regards,
Sudeep
-->8
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-updates-7.1
for you to fetch changes up to 0a7ec808abecaf0d5c3ecc0d1b87d58f29c85604:
firmware: arm_scmi: Support loop control in quirk code snippets (2026-03-17 07:30:22 +0000)
----------------------------------------------------------------
Arm SCMI updates for v7.1
This batch mainly improves SCMI robustness on systems where the SCP does
not generate completion interrupts, and includes two small follow-up
cleanups in the SCMI core.
The main functional change adds support for the new DT property
'arm,no-completion-irq'. When present for mailbox/shared-memory based
SCMI implementations, the driver forces SCMI operations into polling
mode so affected platforms can continue to operate even with broken
firmware interrupt behavior.
In addition, it
- replaces open-coded size rounding in the base protocol path with
round_up() for clarity, with no functional change
- updates the SCMI quirk snippet macro implementation so quirk handlers
can use break and continue directly when invoked inside loop contexts
----------------------------------------------------------------
Geert Uytterhoeven (1):
firmware: arm_scmi: Support loop control in quirk code snippets
Marek Vasut (2):
dt-bindings: firmware: arm,scmi: Document arm,no-completion-irq property
firmware: arm_scmi: Implement arm,no-completion-irq property
Peng Fan (1):
firmware: arm_scmi: Use round_up() for base protocol list size calculation
Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 10 ++++++++++
drivers/firmware/arm_scmi/base.c | 4 ++--
drivers/firmware/arm_scmi/common.h | 4 ++++
drivers/firmware/arm_scmi/driver.c | 4 ++++
drivers/firmware/arm_scmi/quirks.h | 8 ++++----
5 files changed, 24 insertions(+), 6 deletions(-)
^ permalink raw reply
* [GIT PULL] arm64: dts: juno/fvp: Updates for v7.1
From: Sudeep Holla @ 2026-03-25 16:00 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML
Cc: Sudeep Holla, Arnd Bergmann, Lorenzo Pieralisi, Liviu Dudau
Hi ARM SoC Team,
Please pull !
Regards,
Sudeep
-->8
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-updates-7.1
for you to fetch changes up to 87599f1843d3baa4083dc9dd01c95826b536de24:
arm64: dts: arm/corstone1000: Add corstone-1000-a320 (2026-03-23 10:03:28 +0000)
----------------------------------------------------------------
Armv8 Juno/FVP/Vexpress updates for v7.1
1. The primary addition is initial support for Zena CSS that includes:
a new binding compatibility, a shared `zena-css.dtsi` description, and
an FVP device tree.
2. Extension of Corstone-1000 FVP platform support with binding updates
to add the new `arm,corstone1000-a320-fvp` platform, and the
`arm,corstone1000-ethos-u85` NPU integration.
Overall, this combines new platform enablement with some DTS layout
cleanup for Arm reference FVP based systems.
----------------------------------------------------------------
Debbie Horsfall (3):
dt-bindings: arm: Add Zena CSS compatibility
arm64: dts: zena: Add support for Zena CSS
arm64: dts: zena: Move SRAM into SoC and memory node out of SoC
Rob Herring (Arm) (5):
dt-bindings: arm,corstone1000: Add "arm,corstone1000-a320-fvp"
dt-bindings: npu: arm,ethos: Add "arm,corstone1000-ethos-u85"
arm64: dts: arm/corstone1000: Move cpu nodes
arm64: dts: arm/corstone1000: Move FVP peripherals to separate .dtsi
arm64: dts: arm/corstone1000: Add corstone-1000-a320
.../devicetree/bindings/arm/arm,corstone1000.yaml | 15 +-
.../devicetree/bindings/arm/arm,vexpress-juno.yaml | 10 +
.../devicetree/bindings/npu/arm,ethos.yaml | 2 +-
arch/arm64/boot/dts/arm/Makefile | 2 +
arch/arm64/boot/dts/arm/corstone1000-a320-fvp.dts | 15 +
arch/arm64/boot/dts/arm/corstone1000-a320.dtsi | 91 +++
arch/arm64/boot/dts/arm/corstone1000-fvp.dts | 96 +--
arch/arm64/boot/dts/arm/corstone1000-fvp.dtsi | 44 ++
arch/arm64/boot/dts/arm/corstone1000-mps3.dts | 13 +
arch/arm64/boot/dts/arm/corstone1000.dtsi | 13 -
arch/arm64/boot/dts/arm/zena-css-fvp.dts | 63 ++
arch/arm64/boot/dts/arm/zena-css.dtsi | 769 +++++++++++++++++++++
12 files changed, 1054 insertions(+), 79 deletions(-)
create mode 100644 arch/arm64/boot/dts/arm/corstone1000-a320-fvp.dts
create mode 100644 arch/arm64/boot/dts/arm/corstone1000-a320.dtsi
create mode 100644 arch/arm64/boot/dts/arm/corstone1000-fvp.dtsi
create mode 100644 arch/arm64/boot/dts/arm/zena-css-fvp.dts
create mode 100644 arch/arm64/boot/dts/arm/zena-css.dtsi
^ permalink raw reply
* Re: [PATCH 02/17] raid6: remove __KERNEL__ ifdefs
From: H. Peter Anvin @ 2026-03-25 15:13 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Morton
Cc: 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: <20260324064115.3217136-3-hch@lst.de>
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.
-hpa
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8dxl-evk: Use audio-graph-card2 for wm8960-2 and wm8960-3
From: Frank Li @ 2026-03-25 15:55 UTC (permalink / raw)
To: Shengjiu Wang
Cc: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260317053738.578187-1-shengjiu.wang@nxp.com>
On Tue, Mar 17, 2026 at 01:37:38PM +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
>
> so switch to use audio-graph-card2 which supports 'capture_only'
> property for wm8960-2 and wm8960-3 cards.
Do we perfer use audio-graph-card2 for all wm8960 later? look like
audio-graph-card2 is more general.
Frank
>
^ permalink raw reply
* Re: [PATCH v10 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: Catalin Marinas @ 2026-03-25 15:55 UTC (permalink / raw)
To: David Laight
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: <20260316233712.7cbfac27@pumpkin>
On Mon, Mar 16, 2026 at 11:37:12PM +0000, David Laight wrote:
> On Mon, 16 Mar 2026 15:08:07 -0700
> Ankur Arora <ankur.a.arora@oracle.com> wrote:
> > However, as David Laight pointed out in this thread
> > (https://lore.kernel.org/lkml/20260214113122.70627a8b@pumpkin/)
> > that this would be fine so long as the polling is on memory, but would
> > need some work to handle MMIO.
>
> I'm not sure the current code works with MMIO on arm64.
It won't but also passing an MMIO pointer to smp_cond_load() is wrong in
general. You'd need a new API that takes an __iomem pointer.
> I was looking at the osq_lock() code, it uses smp_cond_load() with 'expr'
> being 'VAL || need_resched()' expecting to get woken by the IPI associated
> with the preemption being requested.
> But the arm64 code relies on 'wfe' being woken when the memory write
> 'breaks' the 'ldx' for the monitored location.
> That will only work for cached addresses.
Even worse, depending on the hardware, you may even get a data abort
when attempting LDXR on Device memory.
> 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.
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")).
Using SEV instead of IPI would have the same problem.
--
Catalin
^ permalink raw reply
* Re: [PATCH 07/12] rpmsg: use generic driver_override infrastructure
From: Mathieu Poirier @ 2026-03-25 15:49 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
Armin Wolf, Bjorn Andersson, Vineeth Vijayan, Peter Oberparleiter,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Harald Freudenberger,
Holger Dengler, Mark Brown, Michael S. Tsirkin, Jason Wang,
Xuan Zhuo, Eugenio Pérez, Alex Williamson, Juergen Gross,
Stefano Stabellini, Oleksandr Tyshchenko,
Christophe Leroy (CS GROUP), linux-kernel, driver-core,
linuxppc-dev, linux-hyperv, linux-pci, platform-driver-x86,
linux-arm-msm, linux-remoteproc, linux-s390, linux-spi,
virtualization, kvm, xen-devel, linux-arm-kernel, Gui-Dong Han
In-Reply-To: <20260324005919.2408620-8-dakr@kernel.org>
On Mon, 23 Mar 2026 at 19:00, Danilo Krummrich <dakr@kernel.org> wrote:
>
> When a driver is probed through __driver_attach(), the bus' match()
> callback is called without the device lock held, thus accessing the
> driver_override field without a lock, which can cause a UAF.
>
> Fix this by using the driver-core driver_override infrastructure taking
> care of proper locking internally.
>
> Note that calling match() from __driver_attach() without the device lock
> held is intentional. [1]
>
> Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1]
> Reported-by: Gui-Dong Han <hanguidong02@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
> Fixes: e95060478244 ("rpmsg: Introduce a driver override mechanism")
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> ---
> drivers/rpmsg/qcom_glink_native.c | 2 --
For the below files:
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> drivers/rpmsg/rpmsg_core.c | 43 +++++--------------------------
> drivers/rpmsg/virtio_rpmsg_bus.c | 1 -
> include/linux/rpmsg.h | 4 ---
> 4 files changed, 7 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
> index 9ef17c2e45b0..e9d1b2082477 100644
> --- a/drivers/rpmsg/qcom_glink_native.c
> +++ b/drivers/rpmsg/qcom_glink_native.c
> @@ -1623,7 +1623,6 @@ static void qcom_glink_rpdev_release(struct device *dev)
> {
> struct rpmsg_device *rpdev = to_rpmsg_device(dev);
>
> - kfree(rpdev->driver_override);
> kfree(rpdev);
> }
>
> @@ -1859,7 +1858,6 @@ static void qcom_glink_device_release(struct device *dev)
>
> /* Release qcom_glink_alloc_channel() reference */
> kref_put(&channel->refcount, qcom_glink_channel_release);
> - kfree(rpdev->driver_override);
> kfree(rpdev);
> }
>
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index 96964745065b..2b9f6d5a9a4f 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -358,33 +358,6 @@ rpmsg_show_attr(src, src, "0x%x\n");
> rpmsg_show_attr(dst, dst, "0x%x\n");
> rpmsg_show_attr(announce, announce ? "true" : "false", "%s\n");
>
> -static ssize_t driver_override_store(struct device *dev,
> - struct device_attribute *attr,
> - const char *buf, size_t count)
> -{
> - struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> - int ret;
> -
> - ret = driver_set_override(dev, &rpdev->driver_override, buf, count);
> - if (ret)
> - return ret;
> -
> - return count;
> -}
> -
> -static ssize_t driver_override_show(struct device *dev,
> - struct device_attribute *attr, char *buf)
> -{
> - struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> - ssize_t len;
> -
> - device_lock(dev);
> - len = sysfs_emit(buf, "%s\n", rpdev->driver_override);
> - device_unlock(dev);
> - return len;
> -}
> -static DEVICE_ATTR_RW(driver_override);
> -
> static ssize_t modalias_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> @@ -405,7 +378,6 @@ static struct attribute *rpmsg_dev_attrs[] = {
> &dev_attr_dst.attr,
> &dev_attr_src.attr,
> &dev_attr_announce.attr,
> - &dev_attr_driver_override.attr,
> NULL,
> };
> ATTRIBUTE_GROUPS(rpmsg_dev);
> @@ -424,9 +396,11 @@ static int rpmsg_dev_match(struct device *dev, const struct device_driver *drv)
> const struct rpmsg_driver *rpdrv = to_rpmsg_driver(drv);
> const struct rpmsg_device_id *ids = rpdrv->id_table;
> unsigned int i;
> + int ret;
>
> - if (rpdev->driver_override)
> - return !strcmp(rpdev->driver_override, drv->name);
> + ret = device_match_driver_override(dev, drv);
> + if (ret >= 0)
> + return ret;
>
> if (ids)
> for (i = 0; ids[i].name[0]; i++)
> @@ -535,6 +509,7 @@ static const struct bus_type rpmsg_bus = {
> .name = "rpmsg",
> .match = rpmsg_dev_match,
> .dev_groups = rpmsg_dev_groups,
> + .driver_override = true,
> .uevent = rpmsg_uevent,
> .probe = rpmsg_dev_probe,
> .remove = rpmsg_dev_remove,
> @@ -560,11 +535,9 @@ int rpmsg_register_device_override(struct rpmsg_device *rpdev,
>
> device_initialize(dev);
> if (driver_override) {
> - ret = driver_set_override(dev, &rpdev->driver_override,
> - driver_override,
> - strlen(driver_override));
> + ret = device_set_driver_override(dev, driver_override);
> if (ret) {
> - dev_err(dev, "device_set_override failed: %d\n", ret);
> + dev_err(dev, "device_set_driver_override() failed: %d\n", ret);
> put_device(dev);
> return ret;
> }
> @@ -573,8 +546,6 @@ int rpmsg_register_device_override(struct rpmsg_device *rpdev,
> ret = device_add(dev);
> if (ret) {
> dev_err(dev, "device_add failed: %d\n", ret);
> - kfree(rpdev->driver_override);
> - rpdev->driver_override = NULL;
> put_device(dev);
> }
>
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 8d9e2b4dc7c1..e0dacb736ef9 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -373,7 +373,6 @@ static void virtio_rpmsg_release_device(struct device *dev)
> struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
>
> - kfree(rpdev->driver_override);
> kfree(vch);
> }
>
> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
> index fb7ab9165645..c2e3ef8480d5 100644
> --- a/include/linux/rpmsg.h
> +++ b/include/linux/rpmsg.h
> @@ -41,9 +41,6 @@ struct rpmsg_channel_info {
> * rpmsg_device - device that belong to the rpmsg bus
> * @dev: the device struct
> * @id: device id (used to match between rpmsg drivers and devices)
> - * @driver_override: driver name to force a match; do not set directly,
> - * because core frees it; use driver_set_override() to
> - * set or clear it.
> * @src: local address
> * @dst: destination address
> * @ept: the rpmsg endpoint of this channel
> @@ -53,7 +50,6 @@ struct rpmsg_channel_info {
> struct rpmsg_device {
> struct device dev;
> struct rpmsg_device_id id;
> - const char *driver_override;
> u32 src;
> u32 dst;
> struct rpmsg_endpoint *ept;
> --
> 2.53.0
>
^ permalink raw reply
* Re: (subset) [PATCH 1/3] dt: bindings: arm: add bindings for TQMa95xxLA
From: Frank Li @ 2026-03-25 15:49 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Shawn Guo, Alexander Stein
Cc: Markus Niebel, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260316150535.786122-1-alexander.stein@ew.tq-group.com>
On Mon, 16 Mar 2026 16:04:51 +0100, Alexander Stein wrote:
> TQMa95xxLA is a SOM using NXP i.MX95 CPU. MBa95xxCA is a carrier
> reference design / starter kit board.
>
> [1] https://www.tq-group.com/en/products/tq-embedded/arm-architecture/tqma95xxla/
>
>
Applied, thanks!
[1/3] dt: bindings: arm: add bindings for TQMa95xxLA
commit: 98e6e022858ee5845ee00f44b4805ca6b36e0388
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH v5 2/2] hwmon: emc2305: Support configurable fan PWM at shutdown
From: florin.leotescu @ 2026-03-25 16:04 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel
Cc: daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
In-Reply-To: <20260325160444.1736866-1-florin.leotescu@oss.nxp.com>
From: Florin Leotescu <florin.leotescu@nxp.com>
Some systems require fans to enter in a defined safe state during system
shutdown or reboot handoff.
Add support for the optional Device Tree property "fan-shutdown-percent"
to configure the shutdown PWM duty cycle per fan output.
If the property is present for a fan channel, the driver converts the
configured percentage value to the corresponding PWM duty cycle and
applies it during driver shutdown.
If the property is not present, the fan state remains unchanged.
Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com>
---
drivers/hwmon/emc2305.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/drivers/hwmon/emc2305.c b/drivers/hwmon/emc2305.c
index 64b213e1451e..722ec1d054f8 100644
--- a/drivers/hwmon/emc2305.c
+++ b/drivers/hwmon/emc2305.c
@@ -32,6 +32,7 @@
#define EMC2305_REG_DRIVE_PWM_OUT 0x2b
#define EMC2305_OPEN_DRAIN 0x0
#define EMC2305_PUSH_PULL 0x1
+#define EMC2305_PWM_SHUTDOWN_UNSET -1
#define EMC2305_PWM_DUTY2STATE(duty, max_state, pwm_max) \
DIV_ROUND_CLOSEST((duty) * (max_state), (pwm_max))
@@ -104,6 +105,7 @@ struct emc2305_cdev_data {
* @pwm_output_mask: PWM output mask
* @pwm_polarity_mask: PWM polarity mask
* @pwm_separate: separate PWM settings for every channel
+ * @pwm_shutdown: Set shutdown PWM.
* @pwm_min: array of minimum PWM per channel
* @pwm_freq: array of PWM frequency per channel
* @cdev_data: array of cooling devices data
@@ -116,6 +118,7 @@ struct emc2305_data {
u8 pwm_output_mask;
u8 pwm_polarity_mask;
bool pwm_separate;
+ s16 pwm_shutdown[EMC2305_PWM_MAX];
u8 pwm_min[EMC2305_PWM_MAX];
u16 pwm_freq[EMC2305_PWM_MAX];
struct emc2305_cdev_data cdev_data[EMC2305_PWM_MAX];
@@ -539,6 +542,7 @@ static int emc2305_of_parse_pwm_child(struct device *dev,
struct device_node *child,
struct emc2305_data *data)
{ u32 ch;
+ u32 pwm_shutdown_percent;
int ret;
struct of_phandle_args args;
@@ -548,6 +552,12 @@ static int emc2305_of_parse_pwm_child(struct device *dev,
return ret;
}
+ if (ch >= EMC2305_PWM_MAX) {
+ dev_err(dev, "invalid reg %u of node %pOF (valid range 0-%u)\n", ch, child,
+ EMC2305_PWM_MAX - 1);
+ return -EINVAL;
+ }
+
ret = of_parse_phandle_with_args(child, "pwms", "#pwm-cells", 0, &args);
if (ret)
@@ -579,6 +589,16 @@ static int emc2305_of_parse_pwm_child(struct device *dev,
}
of_node_put(args.np);
+
+ ret = of_property_read_u32(child, "fan-shutdown-percent",
+ &pwm_shutdown_percent);
+
+ if (!ret) {
+ pwm_shutdown_percent = clamp(pwm_shutdown_percent, 0, 100);
+ data->pwm_shutdown[ch] =
+ DIV_ROUND_CLOSEST(pwm_shutdown_percent * EMC2305_FAN_MAX, 100);
+ }
+
return 0;
}
@@ -631,6 +651,9 @@ static int emc2305_probe(struct i2c_client *client)
if (ret)
return ret;
+ for (i = 0; i < EMC2305_PWM_MAX; i++)
+ data->pwm_shutdown[i] = EMC2305_PWM_SHUTDOWN_UNSET;
+
pwm_childs = emc2305_probe_childs_from_dt(dev);
pdata = dev_get_platdata(&client->dev);
@@ -714,6 +737,23 @@ static int emc2305_probe(struct i2c_client *client)
return 0;
}
+static void emc2305_shutdown(struct i2c_client *client)
+{
+ int i;
+ int ret;
+ struct emc2305_data *data = i2c_get_clientdata(client);
+
+ for (i = 0; i < data->pwm_num; i++) {
+ if (data->pwm_shutdown[i] != EMC2305_PWM_SHUTDOWN_UNSET) {
+ ret = i2c_smbus_write_byte_data(client, EMC2305_REG_FAN_DRIVE(i),
+ data->pwm_shutdown[i]);
+ if (ret < 0)
+ dev_warn(&client->dev,
+ "Failed to set shutdown PWM for ch %d\n", i);
+ }
+ }
+}
+
static const struct of_device_id of_emc2305_match_table[] = {
{ .compatible = "microchip,emc2305", },
{},
@@ -726,6 +766,7 @@ static struct i2c_driver emc2305_driver = {
.of_match_table = of_emc2305_match_table,
},
.probe = emc2305_probe,
+ .shutdown = emc2305_shutdown,
.id_table = emc2305_ids,
};
--
2.34.1
^ permalink raw reply related
* [PATCH v5 1/2] dt-bindings: hwmon: emc2305: Add fan-shutdown-percent property
From: florin.leotescu @ 2026-03-25 16:04 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel
Cc: daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
In-Reply-To: <20260325160444.1736866-1-florin.leotescu@oss.nxp.com>
From: Florin Leotescu <florin.leotescu@nxp.com>
The EMC2305 fan controller supports multiple independent PWM fan
outputs. Some systems require fans to enter a defined safe state
during system shutdown or reboot handoff, until firmware or the next
boot stage reconfigures the controller.
Add an optional "fan-shutdown-percent" property to fan child nodes
allowing the shutdown fan speed to be configured per fan output.
Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com>
---
.../devicetree/bindings/hwmon/microchip,emc2305.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
index d3f06ebc19fa..8c2548539d7f 100644
--- a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
+++ b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
@@ -54,6 +54,12 @@ patternProperties:
The fan number used to determine the associated PWM channel.
maxItems: 1
+ fan-shutdown-percent:
+ description:
+ PWM duty cycle in percent applied to the fan during shutdown.
+ minimum: 0
+ maximum: 100
+
required:
- reg
@@ -80,12 +86,14 @@ examples:
fan@0 {
reg = <0x0>;
pwms = <&fan_controller 26000 PWM_POLARITY_INVERTED 1>;
+ fan-shutdown-percent = <100>;
#cooling-cells = <2>;
};
fan@1 {
reg = <0x1>;
pwms = <&fan_controller 26000 0 1>;
+ fan-shutdown-percent = <50>;
#cooling-cells = <2>;
};
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/2] hwmon: emc2305: Support configurable fan PWM at shutdown
From: florin.leotescu @ 2026-03-25 16:04 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel
Cc: daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
From: Florin Leotescu <florin.leotescu@nxp.com>
This series adds support for configuring the fan PWM duty cycle applied
during system shutdown for the EMC2305 fan controller.
Some platforms require fans to transition to a predefined safe state
during shutdown or reboot handoff until firmware or the next boot stage
reconfigures the controller.
The new optional Device Tree property "fan-shutdown-percent" allows the
shutdown PWM duty cycle to be configured per fan output.
Changes in v5:
- Add fan channel index bound check after reg property read
to prevent out-of-bounds access.
- Refine fan-shutdown-percent description.
Changes in v4:
- Initialize pwm_shudown array to EMC2305_PWM_SHUTDOWN_UNSET in probe,
to avoid treating unconfigured channels as valid and written 0
during shutdown
Changes in v3:
- Rebased on current upstream
- Dropped already upstreamed of_node_put(child) fix
Changes in v2:
- Address feedback from Guenter Roeck
- Make shutdown behavior configurable via Device Tree
- Add optional fan-shutdown-percent property
- Apply shutdown PWM only for channels defining the property
Florin Leotescu (2):
dt-bindings: hwmon: emc2305: Add fan-shutdown-percent property
hwmon: emc2305: Support configurable fan PWM at shutdown
.../bindings/hwmon/microchip,emc2305.yaml | 8 ++++
drivers/hwmon/emc2305.c | 41 +++++++++++++++++++
2 files changed, 49 insertions(+)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: mba8mx: Add DSI->LVDS bridge IRQ
From: Frank Li @ 2026-03-25 15:47 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, linux
In-Reply-To: <20260316135820.760073-1-alexander.stein@ew.tq-group.com>
On Mon, 16 Mar 2026 14:58:18 +0100, Alexander Stein wrote:
> Now that the bindings supports IRQ, add the IRQ line. Add a GPIO label
> as well.
>
>
Applied, thanks!
[1/2] arm64: dts: mba8mx: Add DSI->LVDS bridge IRQ
commit: cca9457d5461202a08470a6c778e195ac7c7c775
[2/2] arm64: dts: freescale: tqma8mqml/tqma8mxnl-mba8mx: Add dual-channel LVDS overlay
commit: e186e92cc785949b180710af8d9da826e45d57a2
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox