* [PATCH v4 1/2] i2c: imx-lpi2c: properly unwind resources on probe failure
From: carlos.song @ 2026-06-09 9:51 UTC (permalink / raw)
To: aisheng.dong, andi.shyti, Frank.Li, s.hauer, kernel, festevam
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, Carlos Song
In-Reply-To: <20260609095119.924029-1-carlos.song@oss.nxp.com>
From: Carlos Song <carlos.song@nxp.com>
When probe fails after clk_bulk_prepare_enable() succeeds but before
runtime PM is initialized, the enabled clocks are never disabled.
Additionally, calling pm_runtime_put_sync() in the error path can
trigger the runtime suspend callback, which may attempt to disable
clocks that have not been fully set up, leading to potential issues
during error unwinding.
Introduce two new error labels: clk_disable to explicitly invoke
clk_bulk_disable_unprepare(), and free_irq to release the IRQ via
devm_free_irq(). Replace pm_runtime_put_sync() with the sequence of
pm_runtime_disable(), pm_runtime_set_suspended() and
pm_runtime_put_noidle() to bypass the runtime suspend callback during
error recovery. Update all goto targets so that each failure site
releases only the resources acquired up to that point.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index cd4da50c4dd9..fbb9c0b0a99c 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -1520,21 +1520,25 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
ret = clk_bulk_prepare_enable(lpi2c_imx->num_clks, lpi2c_imx->clks);
if (ret)
- return ret;
+ goto free_irq;
/*
* Lock the parent clock rate to avoid getting parent clock upon
* each transfer
*/
ret = devm_clk_rate_exclusive_get(&pdev->dev, lpi2c_imx->clks[0].clk);
- if (ret)
- return dev_err_probe(&pdev->dev, ret,
- "can't lock I2C peripheral clock rate\n");
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret,
+ "can't lock I2C peripheral clock rate\n");
+ goto clk_disable;
+ }
lpi2c_imx->rate_per = clk_get_rate(lpi2c_imx->clks[0].clk);
- if (!lpi2c_imx->rate_per)
- return dev_err_probe(&pdev->dev, -EINVAL,
- "can't get I2C peripheral clock rate\n");
+ if (!lpi2c_imx->rate_per) {
+ ret = dev_err_probe(&pdev->dev, -EINVAL,
+ "can't get I2C peripheral clock rate\n");
+ goto clk_disable;
+ }
if (lpi2c_imx->hwdata->need_prepare_unprepare_clk)
pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_LONG_TIMEOUT_MS);
@@ -1576,8 +1580,13 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
rpm_disable:
pm_runtime_dont_use_autosuspend(&pdev->dev);
- pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
+clk_disable:
+ clk_bulk_disable_unprepare(lpi2c_imx->num_clks, lpi2c_imx->clks);
+free_irq:
+ devm_free_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/2] i2c: imx-lpi2c: fix probe error handling and reset controller
From: carlos.song @ 2026-06-09 9:51 UTC (permalink / raw)
To: aisheng.dong, andi.shyti, Frank.Li, s.hauer, kernel, festevam
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, Carlos Song
From: Carlos Song <carlos.song@nxp.com>
During probe, two issues exist in the LPI2C driver:
1. The error paths do not properly unwind all acquired resources on
failure. Clocks enabled before runtime PM initialization are never
disabled on certain error paths, and pm_runtime_put_sync() may
trigger the runtime suspend callback before resources are fully
set up.
2. The LPI2C controller may retain unexpected state from previous
boot stages, causing the system to hang during probe.
This series addresses both issues. Patch 1 restructures the probe
error paths to ensure correct resource cleanup on failure. Patch 2
resets the Master and Target controller logic before IRQ registration
to clear any leftover state.
Changes for v4:
- Split v3 into two patches per reviewer feedback:
* Patch 1 contains only the error path restructuring.
* Patch 2 contains only the controller reset and the IRQ
relocation that is required by the reset ordering.
Changes for v3:
- Reset the Target logic via LPI2C_SCR in addition to MCR.
- Replace pm_runtime_put_sync() with pm_runtime_disable() +
pm_runtime_set_suspended() + pm_runtime_put_noidle() to avoid
triggering the suspend callback during error recovery.
- Add clk_disable and free_irq labels for complete error unwinding.
- Update commit log to cover the SCR reset rationale.
Changes for v2:
- Jump to rpm_disable instead of returning directly if the IRQ
request fails.
Carlos Song (2):
i2c: imx-lpi2c: properly unwind resources on probe failure
i2c: imx-lpi2c: reset controller in probe stage
drivers/i2c/busses/i2c-imx-lpi2c.c | 52 +++++++++++++++++++++---------
1 file changed, 36 insertions(+), 16 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2] KVM: arm64: Make guest memory fault-in interruptible
From: Jia He @ 2026-06-09 9:48 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm,
linux-kernel, Jia He
arm64 KVM faults guest memory into the host in kvm_s2_fault_pin_pfn(),
kvm_translate_vncr() (for NV's VNCR page) and pkvm_mem_abort() (for
protected guests). Today these requests are made non-interruptible, so
if the host fault-in path blocks for a long time, a vCPU thread that
already has a pending signal cannot leave the fault-in path until GUP
eventually completes.
This is particularly painful during VM teardown, where userspace may
signal vCPU threads while they are blocked faulting in guest memory. In
that case there is no benefit in continuing to wait for the fault to
complete; the vCPU should return to userspace and let the pending signal
be handled.
Ask the generic KVM fault-in helper to use FOLL_INTERRUPTIBLE (and pass
the same flag to pin_user_pages() for the pKVM path). When GUP reports a
pending signal, __kvm_faultin_pfn() returns KVM_PFN_ERR_SIGPENDING and
pin_user_pages() returns -EINTR; handle both by calling
kvm_handle_signal_exit() and returning -EINTR. This mirrors the
signal-exit handling already done by the arm64 run loop, which sets
run->exit_reason = KVM_EXIT_INTR before returning to userspace. It is
also consistent with x86, which already allows the fault-in to be
interrupted by pending signals.
For the VNCR path, kvm_handle_vncr_abort() handles -EINTR before the
translation-failure path. A signal-interrupted host fault-in is not a VNCR
translation failure: kvm_translate_vncr() has already prepared the signal
exit, while the failure path assumes vt->wr.failed is set and would
otherwise trip BUG_ON(!vt->wr.failed).
The interrupted fault does not install a partial stage-2 mapping: the
-EINTR is returned before any mapping is created, so the fault is simply
retried on a subsequent vCPU entry once userspace re-enters KVM_RUN.
Ordinary stage-2 faults continue to complete as before unless the task
already has a pending signal while blocked in the fault-in path.
Signed-off-by: Jia He <justin.he@arm.com>
---
Changelog:
v2:
- Also make the VNCR (kvm_translate_vncr) and pKVM (pkvm_mem_abort)
fault-in paths interruptible, not just kvm_s2_fault_pin_pfn(); retitle
accordingly. (Marc)
v1: https://lkml.org/lkml/2026/6/8/1033
arch/arm64/kvm/mmu.c | 15 +++++++++++++--
arch/arm64/kvm/nested.c | 19 +++++++++++++++++--
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 4da9281312eb..f1dce829fefe 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1675,7 +1675,8 @@ struct kvm_s2_fault_vma_info {
static int pkvm_mem_abort(const struct kvm_s2_fault_desc *s2fd)
{
- unsigned int flags = FOLL_HWPOISON | FOLL_LONGTERM | FOLL_WRITE;
+ unsigned int flags = FOLL_HWPOISON | FOLL_LONGTERM | FOLL_WRITE |
+ FOLL_INTERRUPTIBLE;
struct kvm_vcpu *vcpu = s2fd->vcpu;
struct kvm_pgtable *pgt = vcpu->arch.hw_mmu->pgt;
struct mm_struct *mm = current->mm;
@@ -1701,6 +1702,10 @@ static int pkvm_mem_abort(const struct kvm_s2_fault_desc *s2fd)
kvm_send_hwpoison_signal(s2fd->hva, PAGE_SHIFT);
ret = 0;
goto dec_account;
+ } else if (ret == -EINTR) {
+ /* GUP was interrupted by a pending signal, return to userspace. */
+ kvm_handle_signal_exit(vcpu);
+ goto dec_account;
} else if (ret != 1) {
ret = -EFAULT;
goto dec_account;
@@ -1872,19 +1877,25 @@ static int kvm_s2_fault_pin_pfn(const struct kvm_s2_fault_desc *s2fd,
struct kvm_s2_fault_vma_info *s2vi)
{
int ret;
+ unsigned int flags = FOLL_INTERRUPTIBLE |
+ (kvm_is_write_fault(s2fd->vcpu) ? FOLL_WRITE : 0);
ret = kvm_s2_fault_get_vma_info(s2fd, s2vi);
if (ret)
return ret;
s2vi->pfn = __kvm_faultin_pfn(s2fd->memslot, get_canonical_gfn(s2fd, s2vi),
- kvm_is_write_fault(s2fd->vcpu) ? FOLL_WRITE : 0,
+ flags,
&s2vi->map_writable, &s2vi->page);
if (unlikely(is_error_noslot_pfn(s2vi->pfn))) {
if (s2vi->pfn == KVM_PFN_ERR_HWPOISON) {
kvm_send_hwpoison_signal(s2fd->hva, __ffs(s2vi->vma_pagesize));
return 0;
}
+ if (is_sigpending_pfn(s2vi->pfn)) {
+ kvm_handle_signal_exit(s2fd->vcpu);
+ return -EINTR;
+ }
return -EFAULT;
}
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 883b6c1008fb..6b4161327222 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1312,8 +1312,16 @@ static int kvm_translate_vncr(struct kvm_vcpu *vcpu, bool *is_gmem)
*is_gmem = kvm_slot_has_gmem(memslot);
if (!*is_gmem) {
- pfn = __kvm_faultin_pfn(memslot, gfn, write_fault ? FOLL_WRITE : 0,
- &writable, &page);
+ unsigned int flags = FOLL_INTERRUPTIBLE;
+
+ if (write_fault)
+ flags |= FOLL_WRITE;
+
+ pfn = __kvm_faultin_pfn(memslot, gfn, flags, &writable, &page);
+ if (is_sigpending_pfn(pfn)) {
+ kvm_handle_signal_exit(vcpu);
+ return -EINTR;
+ }
if (is_error_noslot_pfn(pfn) || (write_fault && !writable))
return -EFAULT;
} else {
@@ -1436,6 +1444,13 @@ int kvm_handle_vncr_abort(struct kvm_vcpu *vcpu)
/* Hack to deal with POE until we get kernel support */
inject_vncr_perm(vcpu);
break;
+ case -EINTR:
+ /*
+ * The fault-in was interrupted by a pending signal;
+ * kvm_translate_vncr() has already set up the signal
+ * exit. Return to userspace and retry on re-entry.
+ */
+ return -EINTR;
case 0:
break;
}
--
2.34.1
^ permalink raw reply related
* [PATCH RESEND v2 1/1] crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
From: Lothar Rubusch @ 2026-06-09 9:47 UTC (permalink / raw)
To: thorsten.blum, herbert, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, krzk+dt
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
The nonblocking RNG path allocates a work_data structure to track the
state of an in-flight asynchronous I2C request. This pointer is stored
in rng->priv and later consumed by the read path once the transaction
completes.
If the underlying I2C transfer fails, the completion callback is invoked
with a non-zero status. In this case, the allocated work_data is not
usable for producing RNG output and must not remain associated with the
hwrng state.
Previously, the failure path only logged a warning but left the pointer
state uncleared, which can result in subsequent read attempts observing
stale state and interpreting it as valid completion data.
Fix this by freeing the pending work_data and clearing rng->priv when
the I2C transaction reports an error. This ensures that failed requests
do not leave residual state behind that could be interpreted as valid
RNG data on later reads.
The explicit clearing of rng->priv in the error path is retained as a
defensive measure. While it may overlap with existing state handling in the
read path, the ownership and lifecycle across asynchronous completion,
read, and teardown paths is not fully localised. Clearing the pointer
ensures no stale state remains after a failed transaction.
Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Assisted-by: Gemini:1.5 Pro [google]
Reviewed-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-sha204a.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index 4c9af737b33a..20cd915ea8a3 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -31,10 +31,15 @@ static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
struct atmel_i2c_client_priv *i2c_priv = work_data->ctx;
struct hwrng *rng = areq;
- if (status)
+ if (status) {
dev_warn_ratelimited(&i2c_priv->client->dev,
"i2c transaction failed (%d)\n",
status);
+ kfree(work_data);
+ rng->priv = 0;
+ atomic_dec(&i2c_priv->tfm_count);
+ return;
+ }
rng->priv = (unsigned long)work_data;
atomic_dec(&i2c_priv->tfm_count);
base-commit: 79bbe453e5bfa6e1c6aa2e8329bfc8f152b81c9b
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] fbdev/arm: Export acorndata_8x8 font symbol for bootloader
From: Russell King (Oracle) @ 2026-06-09 9:46 UTC (permalink / raw)
To: Helge Deller
Cc: linux-fbdev, dri-devel, Ethan Nelson-Moore, Thomas Zimmermann,
linux-arm-kernel
In-Reply-To: <20260609091056.265794-1-deller@gmx.de>
On Tue, Jun 09, 2026 at 11:10:56AM +0200, Helge Deller wrote:
> The text display code used in the Risc PC kernel image decompression
> code uses arch/arm/boot/compressed/font.c, which includes
> lib/fonts/font_acorn_8x8.c, which further includes <linux/font.h>.
>
> Since commit 97df8960240a ("lib/fonts: Provide helpers for calculating
> glyph pitch and size") <linux/font.h> contains inline functions that
> require __do_div64, which is not linked into the ARM kernel
> decompressor. This makes Risc PC zImages fail to build.
>
> Resolve this issue by defining the BOOTLOADER symbol and use it to avoid
> a static declaration of the acorndata_8x8 symbol. That way it can be
> referenced by the arm bootloader, and other static math functions and
> symbols (like __do_div64) stay static and don't get unneccesary included
> in the ARM kernel bootloader decompressor object file.
The decompressor font support has actually been broken since:
commit 6735b4632def0640dbdf4eb9f99816aca18c4f16
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date: Thu Sep 24 09:42:22 2020 -0400
Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts
which added extra data to the beginning of the array of font
information:
ENTRY(ll_write_char)
stmfd sp!, {r4 - r7, lr}
...
/*
* calculate offset into character table
*/
mov r1, r1, lsl #3
r1 is the character, this multiplies the character value by 8.
adr ip, LC0
ldmia ip, {r3, r4, r5, r6, lr}
sub ip, ip, r3
add r6, r6, ip
in conjunction with the data table:
LC0: .word LC0
.word bytes_per_char_h
.word video_size_row
.word acorndata_8x8
.word con_charconvtable
results in r6 pointing at acorndata_8x8. We then index this using the
modified character value above:
orr r1, r1, #7
ldrb r7, [r6, r1]
This breaks if extra data is added to the start, and thus has been
broken since the above commit.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 25/37] drm/bridge: shutdown and cleanup on bridge unplug
From: Luca Ceresoli @ 2026-06-09 9:31 UTC (permalink / raw)
To: Maxime Ripard, Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260608-resilient-outgoing-panther-9efc53@houat>
On Mon Jun 8, 2026 at 2:07 PM CEST, Maxime Ripard wrote:
> Hi,
>
> On Tue, May 19, 2026 at 12:37:42PM +0200, Luca Ceresoli wrote:
>> With the upcoming support for DRM bridge hot(un)plugging, bridges can be
>> removed at any time withotu tearing down the entire card. When this
>> happens, shutdown the pipeline and detach from the encoder chain the bridge
>> being removed along with all the following ones.
>>
>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> ---
>> drivers/gpu/drm/drm_bridge.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index 7f2d1a81d730..d45fb74ec8c2 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -462,9 +462,17 @@ EXPORT_SYMBOL(devm_drm_bridge_add);
>> * it won't be found by users via of_drm_find_and_get_bridge(), and add it
>> * to the lingering bridge list, to keep track of it until its allocated
>> * memory is eventually freed.
>> + *
>> + * If the bridge is attached, also disable the active output and detach
>> + * this bridge and the following ones.
>> */
>> void drm_bridge_remove(struct drm_bridge *bridge)
>> {
>> + if (bridge->encoder) {
>> + drm_atomic_shutdown(bridge->dev);
>> + drm_encoder_cleanup_from(bridge->encoder, bridge);
>> + }
>> +
>> mutex_lock(&bridge_lock);
>> list_move_tail(&bridge->list, &bridge_lingering_list);
>> mutex_unlock(&bridge_lock);
>
> I don't think this makes a lot of sense to disable the whole device at
> once. The connector, encoder, and the CRTC might, but the whole device
> doesn't.
Indeed this is wrong. Dmitry pointed it out during the discussion at
Display Next Hackfest (see my report in reply to the cover letter). The
drm_atomic_shutdown() call will be dropped.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 6/6] irqchip/gic-v5: Enable GICv5 IWB ACPI probe ordering detection
From: Lorenzo Pieralisi @ 2026-06-09 9:31 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Len Brown, Sunil V L, Marc Zyngier, Thomas Gleixner, Huacai Chen,
Anup Patel, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, linux-riscv, linux-kernel, linux-acpi,
linux-arm-kernel, loongarch
In-Reply-To: <CAJZ5v0ibZKfzJwGyUb92-K1N9C_ab0QujpAKCrvMdyygquS1Vw@mail.gmail.com>
On Mon, Jun 08, 2026 at 07:18:15PM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 3, 2026 at 10:21 AM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> >
> > Register an ACPI hook in the ACPI interrupt management code for GICv5 to
> > retrieve the ACPI interrupt controller handle (if any) of the controller
> > handling a specific GSI, by updating the acpi_set_irq_model() call with
> > the gic_v5_get_gsi_handle() function pointer parameter.
> >
> > gicv5_get_gsi_handle() allows ACPI core to detect the ACPI handle
> > of the controller that manages a specific GSI interrupt.
> >
> > Update the IWB driver to clear device dependencies in ACPI core once the
> > IWB driver has probed.
> >
> > Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > Cc: Thomas Gleixner <tglx@kernel.org>
> > Cc: Marc Zyngier <maz@kernel.org>
> > ---
> > drivers/irqchip/irq-gic-v5-iwb.c | 5 +++++
> > drivers/irqchip/irq-gic-v5.c | 13 +++++++++++--
> > 2 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-gic-v5-iwb.c b/drivers/irqchip/irq-gic-v5-iwb.c
> > index 9103feb70ce8..a02cb9537b15 100644
> > --- a/drivers/irqchip/irq-gic-v5-iwb.c
> > +++ b/drivers/irqchip/irq-gic-v5-iwb.c
> > @@ -269,6 +269,11 @@ static int gicv5_iwb_device_probe(struct platform_device *pdev)
> > if (IS_ERR(iwb_node))
> > return PTR_ERR(iwb_node);
> >
> > +#ifdef CONFIG_ACPI
> > + if (has_acpi_companion(&pdev->dev))
> > + acpi_dev_clear_dependencies(ACPI_COMPANION(&pdev->dev));
> > +#endif
>
> I would rather add a wrapper for this, along with an empty stub for
> the !CONFIG_ACPI case.
Ok, I will.
> > +
> > return 0;
> > }
> >
> > diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c
> > index 03cc2830b260..26cfaea1af41 100644
> > --- a/drivers/irqchip/irq-gic-v5.c
> > +++ b/drivers/irqchip/irq-gic-v5.c
> > @@ -1217,11 +1217,19 @@ static struct fwnode_handle *gsi_domain_handle;
> > static struct fwnode_handle *gic_v5_get_gsi_domain_id(u32 gsi)
> > {
> > if (FIELD_GET(GICV5_GSI_IC_TYPE, gsi) == GICV5_GSI_IWB_TYPE)
> > - return iort_iwb_handle(FIELD_GET(GICV5_GSI_IWB_FRAME_ID, gsi));
> > + return iort_iwb_handle_fwnode(FIELD_GET(GICV5_GSI_IWB_FRAME_ID, gsi));
>
> Why is this change needed?
This is a mistake, thanks for spotting it, it belongs in the previous patch
(IMO patch 5 and 6 are a single logical entity, I split it to try to keep
irqchip specific changes in one patch).
iort_iwb_handle() was refactored to return an acpi_handle not a fwnode_handle
(in preparation for adding gic_v5_get_gsi_handle() below - the dependency
chain requires acpi_handle retrieval not fwnode_handle), so the change above
belongs in patch 5, I will move this line change to patch 5 in v3.
Thanks,
Lorenzo
> >
> > return gsi_domain_handle;
> > }
> >
> > +static acpi_handle gic_v5_get_gsi_handle(u32 gsi)
> > +{
> > + if (FIELD_GET(GICV5_GSI_IC_TYPE, gsi) == GICV5_GSI_IWB_TYPE)
> > + return iort_iwb_handle(FIELD_GET(GICV5_GSI_IWB_FRAME_ID, gsi));
> > +
> > + return NULL;
> > +}
> > +
> > static int __init gic_acpi_init(union acpi_subtable_headers *header, const unsigned long end)
> > {
> > struct acpi_madt_gicv5_irs *irs = (struct acpi_madt_gicv5_irs *)header;
> > @@ -1242,7 +1250,8 @@ static int __init gic_acpi_init(union acpi_subtable_headers *header, const unsig
> > if (ret)
> > goto out_irs;
> >
> > - acpi_set_irq_model(ACPI_IRQ_MODEL_GIC_V5, gic_v5_get_gsi_domain_id, NULL);
> > + acpi_set_irq_model(ACPI_IRQ_MODEL_GIC_V5, gic_v5_get_gsi_domain_id,
> > + gic_v5_get_gsi_handle);
> >
> > return 0;
> >
> >
> > --
^ permalink raw reply
* Re: [PATCH 26/37] drm: event-notifier: add mechanism to notify about hotplug events
From: Luca Ceresoli @ 2026-06-09 9:30 UTC (permalink / raw)
To: Maxime Ripard, Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260608-maize-rooster-of-youth-c0bbde@houat>
On Mon Jun 8, 2026 at 2:13 PM CEST, Maxime Ripard wrote:
> On Tue, May 19, 2026 at 12:37:43PM +0200, Luca Ceresoli wrote:
>> In preparation for supporting DRM bridge hotplug, add an event notifier to
>> allow interested parties to be notified about events they need to react to.
>>
>> For the initial implementation of bridge hotplug, two events are needed:
>> bridge detach (happening in drm_bridge.c) and MIPI device attach to MIPI
>> host (happening in drm_mipi_dsi.c).
>>
>> For this reason implement the event notifier in a new common file that
>> event producers can easily use to send events.
>>
>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> So, you claim in the commit message that it's about a hotplug event, but
> the only events are the bridge being attached and detached, so not a
> hotplug event?
>
> And why a bridge would want to be notified that itself (or another?)
> bridge is being attached or detached?
>
> You need documentation, and a more descriptive commit message.
Yes.
But before that I need a decision about the scope we want to give to this
notifier. It is a very generic module, with basically no dependencies, so
people will try to add more unrelated events and we'd need to set a
boundary.
Options:
* Should it be for hotplug-related events only?
* Should it be for any DRM event that needs notifications?
* Something else?
I'm happy to write that in the docs and commit message once it's agreed, so
any comments would be welcome right now.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [RFC PATCH v6 1/1] crypto: atmel-ecc - fix multi-device use-after-free and registration races
From: Lothar Rubusch @ 2026-06-09 9:29 UTC (permalink / raw)
To: thorsten.blum, herbert, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, tudor.ambarus, krzk+dt
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
During parallel driver initialization or driver teardown sequences
in setups with multiple atmel-ecc instances, a race condition exists
between atmel_ecc_i2c_client_alloc() and the probe/remove paths.
A concurrent transformation request can fetch an i2c_client instance
from the global i2c_client_list before the kpp is fully registered, or
while it is actively being unbound, resulting in a use-after-free (UAF)
risk.
1. The initialization problem in probe(): Adding first an i2c client to the
i2c_client_list, and then registering the kpp algorim may result in a race,
when this happens for a second (or further) probed device. In this case the
algorithm is already registered, so a TFM may arrive, while the latest
probing device is added to the list, but not kpp registered. In case this
fails and this last device is going to be removed again from the list, this
leaves a window where the TFM might obtain a pointer to the - now deleted -
i2c client, which opens a UAF risk. Furthermore, there will happen atempts
to multiple registering the same driver to the same type of algorithm.
Note, a simple reverting of the order: first register kpp, second add the
i2c client to the i2c_client_list - is not possible here, since the kpp
registration immediately triggers the self tests, which then will allocate
and require an i2c client.
2. The critical race condition problem: It exists when an Atmel device
instance is rapidly removed and immediately re-probed, before the global
resources are fully cleaned up. In this scenario, the asynchronous
unregistration sequence in the remove() lags behind the incoming probe()
function. Because of the global algorithm structure being not yet
completely cleaned up, the newly re-probed device incorrectly intercepts
the static, partially-dismantled global context. It then overwrites active
pointers and re-acquires the global instance prematurely. In this way, when
the deregistration sequence finally completes its execution, under the
newly initialized device, it may lose the tracking references, leaking the
older driver memory blocks, and introducing an immediate UAF risk.
3. The removal race problem, when a call to remove() starts removing the
device, but another thread executing a TFM, a severe Time-of-Check to
Time-of-Use (TOCTOU) race condition exists in the teardown path between the
asynchronous remove() sequence and completing TFMs. When the device is
unbound, the remove() function evaluates the active tfm_count and decides
whether to wait or proceed with resource deallocation. However, if the
final active TFM finishes its crypto operation and invokes the client free
function immediately after remove() performs its reference check but before
it can sleep, the completion signal is fired into a clearing state. The
unbind thread then misinterprets the zeroed counter, skips the
synchronization barrier entirely, and instantly deallocates the per-device
private structures. This leaves the final TFM worker thread executing code
inside a completely freed memory area, triggering an immediate UAF kernel
panic. Note, simply calling the kpp unregister here won't clean up the
situation in the context of having a setup with external hardware on a slow
bus.
Address this by implementing an independent subsystem reference counter
kpp refcnt protected by a dedicated mutex to ensure the static global kpp
algorithm structure is registered exactly once by the first probing device
instance. In multi-device scenarios, or when extending the resource
management support of the i2c_client_list to all atmel-i2c based device
drivers, such scenarios can become realistic. The particular algorithm is
registered only once. Each i2c client (i.e. each probing device driver) is
added as client to the i2c_client_list. This guarantee that only the first
probe will register the algorithm. The list is populated for further calls
to probe, and subsequent calls to the client alloc function.
Concurrently, decouple list mutations from registration by moving the
global list eviction to the absolute top of the remove lifecycle. This
keeps the quick execution of the list allocation loop intact, ensures that
unbinding hardware is instantly blind to the rest of the system, and
completely bypasses the recursive deadlock condition previously triggered
by synchronous crypto API self-tests.
Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver")
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Assisted-by: Gemini:1.5-Pro [google]
---
RFC: feedback and probably architectural decision needed
The current atmel-ecc driver contains instabilities which should be fixed.
At least the situation with the i2c_client_list and the kpp registration.
Ideally we should have one algorithm registration, but one or multiple
device instances on the i2c list and ensure this to happen as originally
also designed by providing this i2c_client_list approach, which I highly
appreciate. The problematic remove() situation is another known topic here.
Probably more theoretically, but it was commented already before. As also
teardown synchronization might affect probe(), this is a round-trip to open
issues at the i2c list and kpp registration.
While my patch adresses and attempts to fix the above mentioned problems.
The following dilemma is popping up, getting flagged in both cases by
sashiko.
A) Applying unbound wait
Using wait_for_completion() assures waiting for all active TFMs to clear.
Nevertheless, it carries the risk of waiting infinitely.
B) Timed wait
Using wait_for_completion_timeout() avoids infinite waits. Nevertheless, it
introduces the risk of a UAF. In case of an aborting probe() or remove(),
any TFM in progress being cut off devres memory.
Questions:
1. First, please review the current state of the fixes elaborated with
sashiko feedbacks. Do you agree to the approach taken? Do you disagree and
why? Please, let me know what you think.
2. Initially I tried to separately only present a (kind of) fix to problem
1 (v1). Since everything seems to be somehow intertwined, I've put them
together, which increases complexity leading to a huge commit message.
Shall I split or shall I leave it together?
3. Do you see an alternative? If you agree, then which direction you would
like me to take here, A or B? The alternative, I can see here is, we also
could move away from `devm_` memory resources to active
allocation/deallocation in probe here to avoid the UAF.
v5 -> v6:
- RFC
- going back to using timeouts as in v4
- removing redundant code
v4 -> v5:
- sashiko warning: revert wait_for_completion_timeout() by
wait_for_completion() when former instance still active at probe()
- change return type of atmel_ecc_wait_for_tfms() to void
v3 -> v4:
- sashiko warning: replace wait_for_completion() by
wait_for_completion_timeout() in remove; decision is a kind of dilemma
- move redundant code of this fix out into a separate function
- make also use of the wait_for_completion_timeout() function at probe for
convenience
v2 -> v3:
- sashiko warning: fix missing init_completion() for remove_done
- add comment naming all three related main problem situations
v1 -> v2:
- remove the initial approach with "ready" state bool, replace it by
this be a more comprehensive approach
drivers/crypto/atmel-ecc.c | 134 +++++++++++++++++++++++++++++--------
drivers/crypto/atmel-i2c.h | 3 +
2 files changed, 108 insertions(+), 29 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index 0ca02995a1de..702d988a6547 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -23,6 +23,11 @@
#include <crypto/kpp.h>
#include "atmel-i2c.h"
+static DEFINE_MUTEX(atmel_ecc_kpp_lock);
+static int atmel_ecc_kpp_refcnt;
+DECLARE_COMPLETION(atmel_ecc_unreg_done);
+static bool atmel_ecc_unreg_active;
+
static struct atmel_ecc_driver_data driver_data;
/**
@@ -241,7 +246,10 @@ static void atmel_ecc_i2c_client_free(struct i2c_client *client)
{
struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
- atomic_dec(&i2c_priv->tfm_count);
+ spin_lock(&driver_data.i2c_list_lock);
+ if (atomic_dec_and_test(&i2c_priv->tfm_count) && i2c_priv->unbinding)
+ complete(&i2c_priv->remove_done);
+ spin_unlock(&driver_data.i2c_list_lock);
}
static int atmel_ecdh_init_tfm(struct crypto_kpp *tfm)
@@ -276,7 +284,8 @@ static void atmel_ecdh_exit_tfm(struct crypto_kpp *tfm)
struct atmel_ecdh_ctx *ctx = kpp_tfm_ctx(tfm);
kfree(ctx->public_key);
- crypto_free_kpp(ctx->fallback);
+ if (ctx->fallback)
+ crypto_free_kpp(ctx->fallback);
atmel_ecc_i2c_client_free(ctx->client);
}
@@ -295,6 +304,26 @@ static unsigned int atmel_ecdh_max_size(struct crypto_kpp *tfm)
return ATMEL_ECC_PUBKEY_SIZE;
}
+static int atmel_ecc_wait_for_tfms(struct atmel_i2c_client_priv *i2c_priv,
+ unsigned long timeout)
+{
+ spin_lock(&driver_data.i2c_list_lock);
+ list_del(&i2c_priv->i2c_client_list_node);
+ i2c_priv->unbinding = true;
+ reinit_completion(&i2c_priv->remove_done);
+ if (!atomic_read(&i2c_priv->tfm_count)) {
+ spin_unlock(&driver_data.i2c_list_lock);
+ return 0;
+ }
+ spin_unlock(&driver_data.i2c_list_lock);
+
+ if (!wait_for_completion_timeout(&i2c_priv->remove_done,
+ msecs_to_jiffies(timeout)))
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
static struct kpp_alg atmel_ecdh_nist_p256 = {
.set_secret = atmel_ecdh_set_secret,
.generate_public_key = atmel_ecdh_generate_public_key,
@@ -315,6 +344,7 @@ static struct kpp_alg atmel_ecdh_nist_p256 = {
static int atmel_ecc_probe(struct i2c_client *client)
{
struct atmel_i2c_client_priv *i2c_priv;
+ unsigned long timeout;
int ret;
ret = atmel_i2c_probe(client);
@@ -323,49 +353,95 @@ static int atmel_ecc_probe(struct i2c_client *client)
i2c_priv = i2c_get_clientdata(client);
+ init_completion(&i2c_priv->remove_done);
+ i2c_priv->unbinding = false;
+
spin_lock(&driver_data.i2c_list_lock);
list_add_tail(&i2c_priv->i2c_client_list_node,
&driver_data.i2c_client_list);
spin_unlock(&driver_data.i2c_list_lock);
- ret = crypto_register_kpp(&atmel_ecdh_nist_p256);
- if (ret) {
- spin_lock(&driver_data.i2c_list_lock);
- list_del(&i2c_priv->i2c_client_list_node);
- spin_unlock(&driver_data.i2c_list_lock);
+ mutex_lock(&atmel_ecc_kpp_lock);
+ /*
+ * For cases where the same/last such device is still in unregistering,
+ * and now re-registering (refcnt is 0, but completion still exists).
+ * Safely capture the pointer, drop the lock and sleep until it
+ * terminates upon completion or retry limit reached.
+ */
+ while (atmel_ecc_unreg_active) {
+ mutex_unlock(&atmel_ecc_kpp_lock);
+ timeout = wait_for_completion_timeout(&atmel_ecc_unreg_done,
+ msecs_to_jiffies(2000));
+ mutex_lock(&atmel_ecc_kpp_lock);
+ if (timeout == 0) {
+ mutex_unlock(&atmel_ecc_kpp_lock);
+ /*
+ * FIXME / RFC: If we time out here, returning -ETIMEDOUT
+ * triggers devres cleanup, causing a UAF for any lagging TFMs.
+ * Should this be changed to an unbounded wait_for_completion()
+ * to prioritize memory safety over thread liveness?
+ */
+ if (atmel_ecc_wait_for_tfms(i2c_priv, 2000))
+ dev_emerg(&client->dev,
+ "Probe abort timed out! Active TFMs leaked, memory corruption imminent.\n");
+ else
+ dev_err(&client->dev,
+ "Probe timed out waiting for former instance unregistration\n");
+
+ return -ETIMEDOUT;
+ }
+ }
+ if (atmel_ecc_kpp_refcnt == 0) {
+ ret = crypto_register_kpp(&atmel_ecdh_nist_p256);
+ if (ret) {
+ mutex_unlock(&atmel_ecc_kpp_lock);
+
+ atmel_ecc_wait_for_tfms(i2c_priv, 2000);
+ dev_err(&client->dev,
+ "%s alg registration failed\n",
+ atmel_ecdh_nist_p256.base.cra_driver_name);
- dev_err(&client->dev, "%s alg registration failed\n",
- atmel_ecdh_nist_p256.base.cra_driver_name);
- } else {
- dev_info(&client->dev, "atmel ecc algorithms registered in /proc/crypto\n");
+ return ret;
+ }
}
+ atmel_ecc_kpp_refcnt++;
+ mutex_unlock(&atmel_ecc_kpp_lock);
+ dev_info(&client->dev, "atmel ecc algorithms registered in /proc/crypto\n");
return ret;
}
static void atmel_ecc_remove(struct i2c_client *client)
{
struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
+ bool trigger_unreg = false;
- /* Return EBUSY if i2c client already allocated. */
- if (atomic_read(&i2c_priv->tfm_count)) {
- /*
- * After we return here, the memory backing the device is freed.
- * That happens no matter what the return value of this function
- * is because in the Linux device model there is no error
- * handling for unbinding a driver.
- * If there is still some action pending, it probably involves
- * accessing the freed memory.
- */
- dev_emerg(&client->dev, "Device is busy, expect memory corruption.\n");
- return;
+ /*
+ * FIXME / RFC: The timeout prevents a permanent hang,
+ * but since remove() returns void, devres will instantly
+ * free i2c_priv anyway. Memory corruption is imminent
+ * when the active TFM eventually closes.
+ */
+ if (atmel_ecc_wait_for_tfms(i2c_priv, 5000))
+ dev_emerg(&client->dev,
+ "Teardown timed out! Active TFMs leak, memory corruption imminent.\n");
+
+ mutex_lock(&atmel_ecc_kpp_lock);
+ atmel_ecc_kpp_refcnt--;
+ if (atmel_ecc_kpp_refcnt == 0) {
+ trigger_unreg = true;
+ atmel_ecc_unreg_active = true;
+ reinit_completion(&atmel_ecc_unreg_done);
+ }
+ mutex_unlock(&atmel_ecc_kpp_lock);
+
+ if (trigger_unreg) {
+ crypto_unregister_kpp(&atmel_ecdh_nist_p256);
+ mutex_lock(&atmel_ecc_kpp_lock);
+ atmel_ecc_unreg_active = false;
+ complete_all(&atmel_ecc_unreg_done);
+ mutex_unlock(&atmel_ecc_kpp_lock);
}
-
- crypto_unregister_kpp(&atmel_ecdh_nist_p256);
-
- spin_lock(&driver_data.i2c_list_lock);
- list_del(&i2c_priv->i2c_client_list_node);
- spin_unlock(&driver_data.i2c_list_lock);
}
static const struct of_device_id atmel_ecc_dt_ids[] = {
diff --git a/drivers/crypto/atmel-i2c.h b/drivers/crypto/atmel-i2c.h
index 72f04c15682f..8e6617422191 100644
--- a/drivers/crypto/atmel-i2c.h
+++ b/drivers/crypto/atmel-i2c.h
@@ -129,6 +129,7 @@ struct atmel_ecc_driver_data {
* @wake_token_sz : size in bytes of the wake_token
* @tfm_count : number of active crypto transformations on i2c client
* @hwrng : hold the hardware generated rng
+ * @unbinding : unbinding handshake
*
* Reads and writes from/to the i2c client are sequential. The first byte
* transmitted to the device is treated as the byte size. Any attempt to send
@@ -145,6 +146,8 @@ struct atmel_i2c_client_priv {
size_t wake_token_sz;
atomic_t tfm_count ____cacheline_aligned;
struct hwrng hwrng;
+ struct completion remove_done;
+ bool unbinding;
};
/**
base-commit: 79bbe453e5bfa6e1c6aa2e8329bfc8f152b81c9b
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RESEND v4 3/8] can: flexcan: split rx/tx masks per mailbox IRQ line
From: Vincent Mailhol @ 2026-06-09 9:24 UTC (permalink / raw)
To: Ciprian Costea, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet
In-Reply-To: <20260603071342.641874-4-ciprianmarian.costea@oss.nxp.com>
On 03/06/2026 at 09:13, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
> On S32G2, which has two mailbox IRQ lines (mb-0 for MBs 0-7, mb-1
> for MBs 8-127), both handlers currently process the full rx_mask/tx_mask
> range,
>
> Introduce struct flexcan_mb_irq to hold per-IRQ-line rx and tx masks.
>
> In flexcan_irq_mb(), the irq argument selects the correct mask set: the
> primary MB IRQ uses mb_irq[0] and the secondary uses mb_irq[1].
>
> For single-IRQ platforms, mb_irq[0] holds the full combined masks with no
> functional change.
>
> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> ---
> drivers/net/can/flexcan/flexcan-core.c | 61 +++++++++++++++++++-------
> drivers/net/can/flexcan/flexcan.h | 10 ++++-
> 2 files changed, 52 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
> index 7dde2e623def..32e4d4da00a1 100644
> --- a/drivers/net/can/flexcan/flexcan-core.c
> +++ b/drivers/net/can/flexcan/flexcan-core.c
> @@ -957,14 +957,16 @@ static inline void flexcan_write64(struct flexcan_priv *priv, u64 val, void __io
> priv->write(lower_32_bits(val), addr);
> }
>
> -static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv)
> +static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv,
> + u64 rx_mask)
> {
> - return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->rx_mask);
> + return flexcan_read64_mask(priv, &priv->regs->iflag1, rx_mask);
> }
>
> -static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv)
> +static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv,
> + u64 tx_mask)
> {
> - return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->tx_mask);
> + return flexcan_read64_mask(priv, &priv->regs->iflag1, tx_mask);
> }
>
> static inline struct flexcan_priv *rx_offload_to_priv(struct can_rx_offload *offload)
> @@ -1071,7 +1073,8 @@ static struct sk_buff *flexcan_mailbox_read(struct can_rx_offload *offload,
> }
>
> /* Process mailbox (RX + TX) events */
> -static irqreturn_t flexcan_do_mb(struct net_device *dev)
> +static irqreturn_t flexcan_do_mb(struct net_device *dev,
> + const struct flexcan_mb_irq *mb_irq)
> {
> struct net_device_stats *stats = &dev->stats;
> struct flexcan_priv *priv = netdev_priv(dev);
> @@ -1084,7 +1087,8 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
> u64 reg_iflag_rx;
> int ret;
>
> - while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv))) {
> + while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv,
> + mb_irq->rx_mask))) {
> handled = IRQ_HANDLED;
> ret = can_rx_offload_irq_offload_timestamp(&priv->offload,
> reg_iflag_rx);
> @@ -1110,10 +1114,10 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
> }
> }
>
> - reg_iflag_tx = flexcan_read_reg_iflag_tx(priv);
> + reg_iflag_tx = flexcan_read_reg_iflag_tx(priv, mb_irq->tx_mask);
>
> /* transmission complete interrupt */
> - if (reg_iflag_tx & priv->tx_mask) {
> + if (reg_iflag_tx & mb_irq->tx_mask) {
> u32 reg_ctrl = priv->read(&priv->tx_mb->can_ctrl);
>
> handled = IRQ_HANDLED;
> @@ -1125,7 +1129,7 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
> /* after sending a RTR frame MB is in RX mode */
> priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
> &priv->tx_mb->can_ctrl);
> - flexcan_write64(priv, priv->tx_mask, ®s->iflag1);
> + flexcan_write64(priv, mb_irq->tx_mask, ®s->iflag1);
> netif_wake_queue(dev);
> }
>
> @@ -1228,7 +1232,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
> struct flexcan_priv *priv = netdev_priv(dev);
> irqreturn_t handled;
>
> - handled = flexcan_do_mb(dev);
> + handled = flexcan_do_mb(dev, &priv->mb_irq[0]);
> handled |= flexcan_do_state(dev);
> handled |= flexcan_do_berr(dev);
>
> @@ -1243,9 +1247,15 @@ static irqreturn_t flexcan_irq_mb(int irq, void *dev_id)
> {
> struct net_device *dev = dev_id;
> struct flexcan_priv *priv = netdev_priv(dev);
> + const struct flexcan_mb_irq *mb_irq;
> irqreturn_t handled;
> + int idx;
>
> - handled = flexcan_do_mb(dev);
> + idx = (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ &&
> + irq == priv->irq_secondary_mb) ? 1 : 0;
> + mb_irq = &priv->mb_irq[idx];
> +
> + handled = flexcan_do_mb(dev, mb_irq);
>
> if (handled)
> can_rx_offload_irq_finish(&priv->offload);
> @@ -1473,6 +1483,7 @@ static void flexcan_ram_init(struct net_device *dev)
> static int flexcan_rx_offload_setup(struct net_device *dev)
> {
> struct flexcan_priv *priv = netdev_priv(dev);
> + u64 rx_mask, tx_mask;
> int err;
>
> if (priv->can.ctrlmode & CAN_CTRLMODE_FD)
> @@ -1494,20 +1505,35 @@ static int flexcan_rx_offload_setup(struct net_device *dev)
> flexcan_get_mb(priv, FLEXCAN_TX_MB_RESERVED_RX_FIFO);
> priv->tx_mb_idx = priv->mb_count - 1;
> priv->tx_mb = flexcan_get_mb(priv, priv->tx_mb_idx);
> - priv->tx_mask = FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
> -
> priv->offload.mailbox_read = flexcan_mailbox_read;
>
> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_USE_RX_MAILBOX) {
> priv->offload.mb_first = FLEXCAN_RX_MB_RX_MAILBOX_FIRST;
> priv->offload.mb_last = priv->mb_count - 2;
>
> - priv->rx_mask = GENMASK_ULL(priv->offload.mb_last,
> - priv->offload.mb_first);
> + rx_mask = GENMASK_ULL(priv->offload.mb_last,
> + priv->offload.mb_first);
> + tx_mask = FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
> +
> + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ) {
> + /* S32G2 has two MB IRQ lines with the split at MB 8:
> + * mb-0 IRQ handles MBs 0-7,
> + * mb-1 IRQ handles MBs 8-127.
^^^
Your comment says 8-127 but the code uses GENMASK_ULL(63, 8). Is this
intentional?
> + */
> + priv->mb_irq[0].rx_mask = rx_mask & GENMASK_ULL(7, 0);
> + priv->mb_irq[0].tx_mask = tx_mask & GENMASK_ULL(7, 0);
> + priv->mb_irq[1].rx_mask = rx_mask & GENMASK_ULL(63, 8);
> + priv->mb_irq[1].tx_mask = tx_mask & GENMASK_ULL(63, 8);
> + } else {
> + priv->mb_irq[0].rx_mask = rx_mask;
> + priv->mb_irq[0].tx_mask = tx_mask;
> + }
> +
The introduction of the struct flexcan_mb_irq seems a bit overkill.
Can't you just define two new masks and keep the existing struct
flexcan_stop_mode untouched:
#define FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK GENMASK_U64(7, 0)
#define FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK GENMASK_U64(63, 8)
and when you need to access the MB, just select the correct mask. For
example, flexcan_irq_mb() becomes something like this:
u64 mb_mask;
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ
&& irq == priv->irq_secondary_mb)
mb_mask = FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK;
else
mb_mask = FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK;
handled = flexcan_do_mb(dev, mb_mask);
> err = can_rx_offload_add_timestamp(dev, &priv->offload);
> } else {
> - priv->rx_mask = FLEXCAN_IFLAG_RX_FIFO_OVERFLOW |
> + priv->mb_irq[0].rx_mask = FLEXCAN_IFLAG_RX_FIFO_OVERFLOW |
> FLEXCAN_IFLAG_RX_FIFO_AVAILABLE;
> + priv->mb_irq[0].tx_mask = FLEXCAN_IFLAG_MB(priv->tx_mb_idx);
> err = can_rx_offload_add_fifo(dev, &priv->offload,
> FLEXCAN_NAPI_WEIGHT);
> }
> @@ -1531,7 +1557,8 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
> disable_irq(priv->irq_secondary_mb);
>
> priv->write(priv->reg_ctrl_default, ®s->ctrl);
> - reg_imask = priv->rx_mask | priv->tx_mask;
> + reg_imask = priv->mb_irq[0].rx_mask | priv->mb_irq[0].tx_mask |
> + priv->mb_irq[1].rx_mask | priv->mb_irq[1].tx_mask;
> priv->write(upper_32_bits(reg_imask), ®s->imask2);
> priv->write(lower_32_bits(reg_imask), ®s->imask1);
> enable_irq(dev->irq);
> diff --git a/drivers/net/can/flexcan/flexcan.h b/drivers/net/can/flexcan/flexcan.h
> index 16692a2502eb..22aa097ec3c0 100644
> --- a/drivers/net/can/flexcan/flexcan.h
> +++ b/drivers/net/can/flexcan/flexcan.h
> @@ -75,10 +75,17 @@
> */
> #define FLEXCAN_QUIRK_SECONDARY_MB_IRQ BIT(18)
>
> +#define FLEXCAN_NR_MB_IRQS 2
> +
> struct flexcan_devtype_data {
> u32 quirks; /* quirks needed for different IP cores */
> };
>
> +struct flexcan_mb_irq {
> + u64 rx_mask;
> + u64 tx_mask;
> +};
> +
> struct flexcan_stop_mode {
> struct regmap *gpr;
> u8 req_gpr;
> @@ -99,8 +106,7 @@ struct flexcan_priv {
> u8 clk_src; /* clock source of CAN Protocol Engine */
> u8 scu_idx;
>
> - u64 rx_mask;
> - u64 tx_mask;
> + struct flexcan_mb_irq mb_irq[FLEXCAN_NR_MB_IRQS];
> u32 reg_ctrl_default;
>
> struct clk *clk_ipg;
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: display: msm: qcm2290: Add Shikra MDSS
From: Loic Poulain @ 2026-06-09 9:19 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Bjorn Andersson, Konrad Dybcio, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260608-shikra-display-v4-1-88a846afdd5d@oss.qualcomm.com>
On Mon, Jun 8, 2026 at 9:02 AM Nabige Aala <nabige.aala@oss.qualcomm.com> wrote:
>
> Shikra reuses the same MDSS/DPU 6.5 hardware as QCM2290. Extend
> the existing qcm2290 bindings to cover Shikra by adding fallback
> compatible chains for MDSS, DPU and DSI controller nodes rather
> than introducing a separate binding file.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 1/6] ACPI: RISC-V: Fix riscv_acpi_irq_get_dep() loop termination
From: Lorenzo Pieralisi @ 2026-06-09 9:19 UTC (permalink / raw)
To: Sunil V L
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <CAB19ukFFwm3ehzkBFr+oXRjA7VK_4_=XHFSuqdEpbVqUz8Do4Q@mail.gmail.com>
On Mon, Jun 08, 2026 at 09:54:28PM +0530, Sunil V L wrote:
> Hi Lorenzo,
>
> On Wed, Jun 3, 2026 at 1:51 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> >
> > In riscv_acpi_add_irq_dep() the main loop condition would currently stop
> > the loop if an interrupt descriptor contains an interrupt for which the
> > respective GSI handle is NULL, which is not correct because subsequent
> > interrupts in the interrupt descriptor might still have a GSI dependency
> > that must not be skipped.
> >
> > Rework riscv_acpi_add_irq_dep() and the riscv_acpi_irq_get_dep() call chain
> > to fix it - by not forcing the loop to stop in order to guarantee
> > dependency detection for all the interrupt entries in the CRS descriptor.
> >
> > Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > Cc: Sunil V L <sunilvl@ventanamicro.com>
> > ---
> > drivers/acpi/riscv/irq.c | 10 ++++++----
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
> > index 9b88d0993e88..cd83c3035cf6 100644
> > --- a/drivers/acpi/riscv/irq.c
> > +++ b/drivers/acpi/riscv/irq.c
> > @@ -299,6 +299,7 @@ static acpi_status riscv_acpi_irq_get_parent(struct acpi_resource *ares, void *c
> > return AE_OK;
> >
> > ctx->handle = riscv_acpi_get_gsi_handle(eirq->interrupts[ctx->index]);
> > + ctx->rc = 0;
> > return AE_CTRL_TERMINATE;
> > }
> >
> > @@ -314,10 +315,8 @@ static int riscv_acpi_irq_get_dep(acpi_handle handle, unsigned int index, acpi_h
> >
> > acpi_walk_resources(handle, METHOD_NAME__CRS, riscv_acpi_irq_get_parent, &ctx);
> > *gsi_handle = ctx.handle;
> > - if (*gsi_handle)
> > - return 1;
> >
> > - return 0;
> > + return ctx.rc;
> > }
> >
> > static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> > @@ -381,8 +380,11 @@ static u32 riscv_acpi_add_irq_dep(acpi_handle handle)
> > int i;
> >
> > for (i = 0;
> > - riscv_acpi_irq_get_dep(handle, i, &gsi_handle);
> > + !riscv_acpi_irq_get_dep(handle, i, &gsi_handle);
> > i++) {
> > + if (!gsi_handle)
> > + continue;
> > +
> > dep_devices.count = 1;
> > dep_devices.handles = kzalloc_objs(*dep_devices.handles, 1);
> > if (!dep_devices.handles) {
> >
> Do these fixes need the Fixes tag?
I can add a Fixes: tag but I wanted first some help testing them, it
is code perusal that got me there.
> Otherwise, LGTM.
> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com>
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: i2c: qcom-cci: Document Shikra compatible
From: Loic Poulain @ 2026-06-09 9:16 UTC (permalink / raw)
To: Nihal Kumar Gupta
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Robert Foss,
Andi Shyti, Bryan O'Donoghue, Bjorn Andersson, Konrad Dybcio,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma,
Wolfram Sang
In-Reply-To: <20260608-shikra-camss-review-v2-2-ca1936bf1219@oss.qualcomm.com>
On Mon, Jun 8, 2026 at 4:07 PM Nihal Kumar Gupta
<nihal.gupta@oss.qualcomm.com> wrote:
>
> Add Shikra compatible consistent with CAMSS CCI interfaces.
> It requires only two clocks.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
> index 7c497a358e1dc8cec8b31c17bfedf315e4e00606..c94069afd8d06dbb08ddd6b49e2de7dc7acdc29a 100644
> --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
> @@ -35,6 +35,7 @@ properties:
> - qcom,sc8280xp-cci
> - qcom,sdm670-cci
> - qcom,sdm845-cci
> + - qcom,shikra-cci
> - qcom,sm6150-cci
> - qcom,sm6350-cci
> - qcom,sm8250-cci
> @@ -137,6 +138,7 @@ allOf:
> - qcom,kaanapali-cci
> - qcom,qcm2290-cci
> - qcom,qcs8300-cci
> + - qcom,shikra-cci
> - qcom,sm8750-cci
> then:
> properties:
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v3] clk: imx: Add audio PLL debugfs for K-divider control
From: Abel Vesa @ 2026-06-09 9:16 UTC (permalink / raw)
To: Abel Vesa, Peng Fan, Michael Turquette, Stephen Boyd,
Brian Masney, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Jacky Bai
Cc: linux-clk, imx, linux-arm-kernel
In-Reply-To: <20260604-imx8m_pll_debugfs-v3-1-4e331ebc85d7@nxp.com>
On Thu, 04 Jun 2026 21:48:01 +0800, Jacky Bai wrote:
> Add debugfs support for runtime tuning of the audio PLL K divider,
> which enables fine-grained frequency adjustments for audio PLL.
> This is used for:
> - Audio clock calibration and testing
> - Debugging audio synchronization issues
>
> Two debug interfaces are exported to userspace:
> - delta_k: It is used to adjust the K divider in PLL based on small
> steps
> - pll_parameter: It is used for get PLL's current M-divider,
> P-divider, S-divider & K-divider setting in PLL register
>
> [...]
Applied, thanks!
[1/1] clk: imx: Add audio PLL debugfs for K-divider control
commit: b3dcc8c608fbb6352bd94932ba935f2078c9090d
Best regards,
--
Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: nuvoton: Add MA35D1 USB2 OTG PHY binding
From: Joey Lu @ 2026-06-09 9:15 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacky Huang, Shan-Chun Hung, linux-phy, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260608-demonic-horned-honeybee-4f6bb7@quoll>
On 6/8/2026 6:45 PM, Krzysztof Kozlowski wrote:
> On Thu, Jun 04, 2026 at 06:12:19PM +0800, Joey Lu wrote:
>
> A nit, subject: drop second/last, redundant "binding". The
> "dt-bindings" prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
Understood. The trailing "binding" will be dropped from the patch
subject line in the next submission.
>> +properties:
>> + compatible:
>> + const: nuvoton,ma35d1-usb2-phy-otg
>> +
> Where is reg? MMIO is expressed with reg, not via custom phandle.
Understood. The PHY node will be restructured as a child of the syscon
node, with a `reg = <0x60 0x14>` property covering the writable PHY
control registers (USBPMISCR, MISCFCR0) within the parent's address
space. The `nuvoton,sys` custom phandle will be removed; the driver will
obtain the parent's regmap via
`syscon_node_to_regmap(dev->parent->of_node)`, which looks up the global
syscon list by `of_node`. PHY instance selection will be expressed via
`#phy-cells = <1>`, with 0 for the OTG port (USB0) and 1 for the
host-only port (USB1).
>
>> + clocks:
>> + maxItems: 1
>> +
>> + nuvoton,sys:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + - items:
>> + - description: phandle to the system management syscon.
>> + - description: PHY instance index.
>> + enum:
>> + - 0 # USB0, OTG port (shared with DWC2 gadget controller)
>> + - 1 # USB1, host-only port
>> + description:
>> + A phandle to the syscon node covering the SYS register block, with
>> + one argument selecting the PHY instance. Index 0 selects the OTG
>> + port PHY (USB0) and index 1 selects the host-only PHY (USB1).
>> +
>> + "#phy-cells":
>> + const: 0
>> +
>> + nuvoton,rcalcode:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + minimum: 0
>> + maximum: 15
>> + description:
>> + Resistor calibration trim code written to the RCALCODE field in
>> + USBPMISCR. The 4-bit value adjusts the PHY's internal termination
>> + resistance. When absent the hardware reset default is used.
>> +
>> + nuvoton,oc-active-high:
>> + type: boolean
>> + description:
>> + When present, the over-current detect input from the VBUS power
>> + switch is treated as active-high. The default (property absent) is
>> + active-low. This setting is shared by both USB host ports.
>> +
>> +required:
>> + - compatible
>> + - clocks
>> + - nuvoton,sys
>> + - "#phy-cells"
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
>> +
>> + usb_hphy0: usb-host-phy {
> usb-phy
>
> And drop unused label.
Understood. The node name will be changed to `usb-phy` and the unused
label `usb_hphy0:` will be removed.
Thanks for the review!
>> + compatible = "nuvoton,ma35d1-usb2-phy-otg";
>> + clocks = <&clk HUSBH0_GATE>;
>> + nuvoton,sys = <&sys 0>;
>> + #phy-cells = <0>;
>> + };
>> --
>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH] arm_mpam: Fix MPAMCFG_MBW_PBM register setting
From: Ben Horgan @ 2026-06-09 9:12 UTC (permalink / raw)
To: Fenghua Yu, Gavin Shan, James Morse, Reinette Chatre,
Catalin Marinas, Shaopeng Tan, Jesse Chick
Cc: linux-kernel, linux-arm-kernel, Matt Ochs
In-Reply-To: <c994c0a5-9610-49a0-8fda-82f088264ef4@nvidia.com>
Hi Fenghua,
Thanks for the fix!
On 6/9/26 03:06, Fenghua Yu wrote:
> Hi, Gavin,
>
> On 6/7/26 21:46, Gavin Shan wrote:
>> Hi Fenghua,
>>
>> On 6/7/26 3:09 PM, Fenghua Yu wrote:
>>> MPAMCFG_MBW_PBM is written from cfg if cfg has the MBW partition feature.
>>> It is reset when cfg does not have the MBW partition feature.
>>>
>>> But the register handling is reversed. This may cause an incorrect
>>> register setting. For example, during an MPAM reset, reset_cfg is
>>> empty (no MBW partition feature set), and cfg->mbw_pbm is 0. Instead of
>>> resetting MPAMCFG_MBW_PBM to all 1's, the current logic will set it to
>>> cfg->mbw_pbm, which is 0.
>>>
>>> Fix the issue by swapping the if/else branches.
>>>
>>> Fixes: a1cb6577f575 ("arm_mpam: Reset when feature configuration bit unset")
>>> Reported-by: Matt Ochs <mochs@nvidia.com>
>>> Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
>>> ---
>>> drivers/resctrl/mpam_devices.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>
>> The fix itself looks reasonable to me, but two questions below.
>>
>> Reviewed-by: Gavin Shan <gshan@redhat.com>
>
> Thank you for reviewing the patch!
>
>>
>>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/ mpam_devices.c
>>> index 4b93e89c2678..d8b0383cee92 100644
>>> --- a/drivers/resctrl/mpam_devices.c
>>> +++ b/drivers/resctrl/mpam_devices.c
>>> @@ -1570,9 +1570,9 @@ static void mpam_reprogram_ris_partid(struct
>>> mpam_msc_ris *ris, u16 partid,
>>> if (mpam_has_feature(mpam_feat_mbw_part, rprops)) {
>>> if (mpam_has_feature(mpam_feat_mbw_part, cfg))
>>> - mpam_reset_msc_bitmap(msc, MPAMCFG_MBW_PBM, rprops- >mbw_pbm_bits);
>>> - else
>>> mpam_write_partsel_reg(msc, MBW_PBM, cfg->mbw_pbm);
>>> + else
>>> + mpam_reset_msc_bitmap(msc, MPAMCFG_MBW_PBM, rprops- >mbw_pbm_bits);
>>> }
>>> if (mpam_has_feature(mpam_feat_mbw_min, rprops)) {
>>
>> Which machine or system where mpam_feat_mbw_part is set on RIS? As I can
>> remember, this feature isn't available on grace-hopper.
>
> Neither Grace nor Vera supports this feature.
>
>>
>> Besides, I don't think this feature is well handled at present because
>> mpam_config::mbw_pbm is only 32-bits in length, which doesn't match with
>> the maximal length of the bit map (4096) as documented in the spec.
> > Right. The current code only can support up to 32 bits of PBM bitmap. If PBM
> bitmp length is bigger than 32 bits, it's broken. I guess we will need to handle
> this feature properly when hardware supports more than 32 bits of PBM bitmap.
mpam_config::mbw_pbm shouldn't have made it into the driver as nothing ever sets
it. Otherwise, there is no attempt to make use of the MBW_PBM other than to
reset it to an appropriate value, which this patch fixes. I guess this is a
lesson for me on the perils of dead code.
>
> Ditto for CPBM bitmap.
If the CPBM bitmap has more than 32 bits, as checked by
cache_has_usable_cpor(), then we don't attempt to configure it other than to
reset. If there is hardware with more than 32 bits we'd first consider extending
this to 64bits.
>
> This patch currently only fixes the regression issue introduced in commit
> a1cb6577f575 regardless size of PBM bitmap.
Looks good to me.
Reviewed-by: Ben Horgan <ben.horgan@arm.com>
Thanks,
Ben
>
> Thanks.
>
> -Fenghua
^ permalink raw reply
* [PATCH] fbdev/arm: Export acorndata_8x8 font symbol for bootloader
From: Helge Deller @ 2026-06-09 9:10 UTC (permalink / raw)
To: linux-fbdev, dri-devel
Cc: Ethan Nelson-Moore, Thomas Zimmermann, linux-arm-kernel,
Russell King
The text display code used in the Risc PC kernel image decompression
code uses arch/arm/boot/compressed/font.c, which includes
lib/fonts/font_acorn_8x8.c, which further includes <linux/font.h>.
Since commit 97df8960240a ("lib/fonts: Provide helpers for calculating
glyph pitch and size") <linux/font.h> contains inline functions that
require __do_div64, which is not linked into the ARM kernel
decompressor. This makes Risc PC zImages fail to build.
Resolve this issue by defining the BOOTLOADER symbol and use it to avoid
a static declaration of the acorndata_8x8 symbol. That way it can be
referenced by the arm bootloader, and other static math functions and
symbols (like __do_div64) stay static and don't get unneccesary included
in the ARM kernel bootloader decompressor object file.
Fixes: 97df8960240a ("lib/fonts: Provide helpers for calculating glyph pitch and size")
Reported-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Helge Deller <deller@gmx.de>
---
arch/arm/boot/compressed/Makefile | 2 +-
lib/fonts/font_acorn_8x8.c | 5 +++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index a159120d1e42..e3f550d62857 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -157,4 +157,4 @@ $(obj)/piggy_data: $(obj)/../Image FORCE
$(obj)/piggy.o: $(obj)/piggy_data
-CFLAGS_font.o := -Dstatic=
+CFLAGS_font.o := -DBOOTLOADER
diff --git a/lib/fonts/font_acorn_8x8.c b/lib/fonts/font_acorn_8x8.c
index 36c51016769d..4ff52c79f8c4 100644
--- a/lib/fonts/font_acorn_8x8.c
+++ b/lib/fonts/font_acorn_8x8.c
@@ -5,7 +5,12 @@
#define FONTDATAMAX 2048
+#ifdef BOOTLOADER
+/* The acorndata_8x8 symbol is needed by the ARM bootloader too. */
+const struct font_data acorndata_8x8 = {
+#else
static const struct font_data acorndata_8x8 = {
+#endif
{ 0, 0, FONTDATAMAX, 0 }, {
/* 00 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* ^@ */
/* 01 */ 0x7e, 0x81, 0xa5, 0x81, 0xbd, 0x99, 0x81, 0x7e, /* ^A */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: rockchip: fix emmc reset polarity on px30-cobra
From: Quentin Schulz @ 2026-06-09 9:10 UTC (permalink / raw)
To: Jakob Unterwurzacher, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Jakob Unterwurzacher
Cc: stable, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260609081728.30616-2-jakobunt@gmail.com>
Hi Jakob,
On 6/9/26 10:17 AM, Jakob Unterwurzacher wrote:
> From: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
>
> Technically, the reset signal is active low - it's called RST_n after all.
>
> But it is ignored completely unless RST_n_FUNCTION=1 (byte 162 in extcsd)
> is set in the emmc. It is 0 per default.
>
> For emmcs that have RST_n_FUNCTION=1 we failed like this:
>
> [ 3.074480] mmc1: Failed to initialize a non-removable card
>
> With this change they work normally.
>
> Cc: stable@vger.kernel.org
> Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
> Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
Please try to not forget to add tags (Reviewed-by, Acked-by, Tested-by,
...) given in earlier versions of a newer version of the patch (except
if substantial changes were made, which isn't the case here).
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Can Guo @ 2026-06-09 9:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: bvanassche, beanhuo, peter.wang, martin.petersen, mani,
linux-scsi, Alim Akhtar, Avri Altman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Zhaoming Luo, Ram Kumar Dwivedi,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list,
moderated list:ARM/Mediatek SoC support:Keyword:mediatek,
moderated list:ARM/Mediatek SoC support:Keyword:mediatek
In-Reply-To: <87c9f8cf-1300-4dae-82cd-fe6427649cea@kernel.org>
On 6/9/2026 3:08 PM, Krzysztof Kozlowski wrote:
> On 31/05/2026 06:48, Can Guo wrote:
>>>>> is the minimal encoding that covers both.
>>>> Again, why do you need to encode '0'?
>>> The tuple is still needed because Precoding is configured per
>>> transmitter-receiver pair,
>>> so each lane has two independent states:
>>> - Host_TX -> Device_RX
>>> - Device_TX -> Host_RX
>>> A lane-only enabled list cannot represent directional combinations
>>> like lane0 =
>>> (on, off) vs (off, on).
>> How about we split into two properties, something like below?
>> tx-precode-enable-g6-host-lanes = <0 1>
>> tx-precode-enable-g6-device-lanes = <1>
>>
>> Only listed lanes are enabled; unlisted lanes are disabled by default.
>>
>> Are you OK with this approach?
> Yes, I do prefer this, because we don't have empty entries (<0, 0>, <0,
> 1> ....).
Thank you for coming back. Sure, I will use this format in next version.
Best Regards,
Can Guo.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v5 0/4] Enable sysfs module symlink for more built-in drivers
From: Suzuki K Poulose @ 2026-06-09 9:08 UTC (permalink / raw)
To: Danilo Krummrich, Shashank Balaji
Cc: James Clark, Alexander Shishkin, Greg Kroah-Hartman,
Rafael J . Wysocki, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Jonathan Corbet, Shuah Khan, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Mike Leach,
Leo Yan, Thierry Reding, Jonathan Hunter, Rahul Bukte,
linux-kernel, coresight, linux-arm-kernel, driver-core,
rust-for-linux, linux-doc, Daniel Palmer, Tim Bird, linux-modules,
linux-tegra, Sumit Gupta
In-Reply-To: <20260608222448.1353773-1-dakr@kernel.org>
On 08/06/2026 23:24, Danilo Krummrich wrote:
> On Mon, 18 May 2026 19:19:56 +0900, Shashank Balaji wrote:
>> [PATCH v5 0/4] Enable sysfs module symlink for more built-in drivers
>
> Applied, thanks!
>
> Branch: driver-core-testing
> Tree: git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
>
> [1/4] soc/tegra: cbb: Move driver registration from pure_initcall to core_initcall
> commit: cd6e95e7ab29
> [2/4] kernel: param: initialize module_kset in a pure_initcall
> commit: c82dfce47833
> [3/4] coresight: pass THIS_MODULE implicitly through a macro
> commit: efc22b3f89a3
> [4/4] driver core: platform: set mod_name in driver registration
> commit: a7a7dc5c46a0
>
> The patches will appear in the next linux-next integration (typically within 24
> hours on weekdays).
>
> The patches are in the driver-core-testing branch and will be promoted to
> driver-core-next after validation.
Apologies, I missed your emails. I am fine with those, happy to fixup
anything if the linux-next screams.
Cheers
Suzuki
^ permalink raw reply
* Re: [PATCH 2/3] iio: adc: add Axiado SARADC driver
From: Petar Stepanovic @ 2026-06-09 9:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <aiMU2bOFgKT9NrNQ@ashevche-desk.local>
On 6/5/2026 8:26 PM, Andy Shevchenko wrote:
>> +config AXIADO_SARADC
>> + tristate "Axiado SARADC driver"
>> + depends on ARCH_AXIADO || COMPILE_TEST
>> + depends on OF
> No, in IIO we want a good justification on non-agnostic requirements.
> Why can't this device driver be agnostic?
>
Hi Andy,
Thanks for the review. I will address the comments in v2.
You are right. The driver does not have a hard dependency on OF.
It only uses the OF match table for Device Tree based probing, but the
driver itself can use generic device APIs and does not need to be limited
to OF-only systems.
I will drop the `depends on OF` dependency and use generic match-data
handling where applicable.
...
>> + iowrite32(AX_SARADC_MANUAL_CTRL_EN(chan->channel),
>> + info->regs + AX_SARADC_MANUAL_CTRL);
> Why not writel()?
There is no special reason to use iowrite32() here. This is a normal
MMIO resource, so I will switch the driver to readl()/writel().
...
>> +static int axiado_saradc_probe(struct platform_device *pdev)
>> +{
>> + struct axiado_saradc *info;
>> + const struct axiado_saradc_soc_data *soc_data;
>> + struct iio_dev *indio_dev;
>> + int ret;
>> + u32 reg;
>> +
>> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
>> + if (!indio_dev)
>> + return -ENOMEM;
>> +
>> + info = iio_priv(indio_dev);
>> +
>> + info->regs = devm_platform_ioremap_resource(pdev, 0);
>> + if (IS_ERR(info->regs))
>> + return PTR_ERR(info->regs);
>> +
>> + info->clk = devm_clk_get_enabled(&pdev->dev, NULL);
> Why no name? It will make harder for the next generations of HW in case they
> want more than one clock to be used.
This IP block currently has only one clock input, so I used the unnamed clock.
Since there is no ambiguity for the current hardware, I would prefer to keep
the binding simple unless a named clock is required.
...
>> + reg = FIELD_PREP(AX_SARADC_CH_EN_MASK,
>> + GENMASK(soc_data->num_channels - 1, 0)) |
>> + AX_SARADC_SAMPLE_16 | AX_SARADC_MODE | AX_SARADC_ENABLE;
> FIELD_PREP_CONST() ?
FIELD_PREP_CONST() cannot be used here because the channel-enable value is
derived from soc_data->num_channels, which is runtime match data.
Best regards,
Petar
^ permalink raw reply
* [PATCH v4 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-PLUS
From: Stefano Radaelli @ 2026-06-09 9:04 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Dario Binacchi,
Josua Mayer, Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <cover.1780995737.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite DART-MX8MP system on module.
This SOM is designed to be used with various carrier boards.
The module includes:
- NXP i.MX8M Plus MPU processor
- Up to 8GB of LPDDR4 memory
- Up to 128GB of eMMC storage memory
- Integrated 10/100/1000 Mbps Ethernet Transceiver
- Codec audio WM8904
- WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth
Only SOM-specific peripherals are enabled by default. Carrier board
specific interfaces are left disabled to be enabled in the respective
carrier board device trees.
Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-plus/dart-mx8m-plus/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v3->v4:
-
v2->v3:
- Fixed wrong som eth phy address
v1->v2:
- Fixed wrong sai peripheral reference
- Fixed wrong eqos pinctrl gpio
.../boot/dts/freescale/imx8mp-var-dart.dtsi | 476 ++++++++++++++++++
1 file changed, 476 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-var-dart.dtsi
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-dart.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-var-dart.dtsi
new file mode 100644
index 000000000000..a647a2e0ab94
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-dart.dtsi
@@ -0,0 +1,476 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Common dtsi for Variscite DART-MX8M-PLUS
+ *
+ * Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-plus/dart-mx8m-plus/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include "imx8mp.dtsi"
+
+/ {
+ model = "Variscite DART-MX8M-PLUS Module";
+ compatible = "variscite,var-dart-mx8mp", "fsl,imx8mp";
+
+ reg_audio_supply: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "wm8904-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_phy_vddio: regulator-phy-vddio {
+ compatible = "regulator-fixed";
+ regulator-name = "vddio-1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ sound-wm8904 {
+ compatible = "simple-audio-card";
+ simple-audio-card,bitclock-master = <&codec_dai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&codec_dai>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "wm8904-audio";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "IN1L", "Microphone Jack",
+ "IN1R", "Microphone Jack";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Line", "Line In Jack";
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&wm8904>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai3>;
+ };
+ };
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <10000>;
+ reset-gpios = <&gpio2 7 GPIO_ACTIVE_LOW>, /* WIFI_RESET */
+ <&gpio2 8 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */
+ };
+};
+
+&A53_0 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_1 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_2 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_3 {
+ cpu-supply = <&buck2>;
+};
+
+&eqos {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&gpio2 11 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <100000>;
+ vddio-supply = <®_phy_vddio>;
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ pinctrl-1 = <&pinctrl_i2c1_gpio>;
+ scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ wm8904: audio-codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ #sound-dai-cells = <0>;
+ clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>;
+ clock-names = "mclk";
+ AVDD-supply = <®_audio_supply>;
+ CPVDD-supply = <®_audio_supply>;
+ DBVDD-supply = <®_audio_supply>;
+ DCVDD-supply = <®_audio_supply>;
+ MICVDD-supply = <®_audio_supply>;
+ wlf,drc-cfg-names = "default", "peaklimiter", "tradition",
+ "soft", "music";
+ /*
+ * Config registers per name, respectively:
+ * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1
+ * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1
+ * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1
+ * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1
+ * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>,
+ /bits/ 16 <0x04af 0x324b 0x0028 0x0704>,
+ /bits/ 16 <0x04af 0x324b 0x0018 0x078c>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x050e>;
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+ };
+
+ pca9450: pmic@25 {
+ compatible = "nxp,pca9450c";
+ reg = <0x25>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ nxp,dvs-run-voltage = <950000>;
+ nxp,dvs-standby-voltage = <850000>;
+ };
+
+ buck4: BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5: BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2: LDO2 {
+ regulator-name = "LDO2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3: LDO3 {
+ regulator-name = "LDO3";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ ldo5: LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+ };
+};
+
+&mu2 {
+ status = "okay";
+};
+
+&sai3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai3>;
+ assigned-clocks = <&clk IMX8MP_CLK_SAI3>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <11536000>;
+ clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_IPG>,
+ <&clk IMX8MP_CLK_DUMMY>,
+ <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>,
+ <&clk IMX8MP_CLK_DUMMY>,
+ <&clk IMX8MP_CLK_DUMMY>;
+ clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
+ #sound-dai-cells = <0>;
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
+/* BT module */
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>, <&pinctrl_bt>;
+ assigned-clocks = <&clk IMX8MP_CLK_UART4>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth_iw61x: bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
+/* WIFI */
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_wifi>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>, <&pinctrl_wifi>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>, <&pinctrl_wifi>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ keep-power-in-suspend;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_bt: btgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD1_DATA4__GPIO2_IO06 0xc0
+ MX8MP_IOMUXC_SD1_DATA7__GPIO2_IO09 0xc0
+ >;
+ };
+
+ 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
+ MX8MP_IOMUXC_SD2_WP__GPIO2_IO20 0x10
+ MX8MP_IOMUXC_SD1_STROBE__GPIO2_IO11 0x150
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x400001c2
+ MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001c2
+ >;
+ };
+
+ pinctrl_i2c1_gpio: i2c1gpiogrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C1_SCL__GPIO5_IO14 0x1c2
+ MX8MP_IOMUXC_I2C1_SDA__GPIO5_IO15 0x1c2
+ >;
+ };
+
+ pinctrl_pmic: pmicgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
+ >;
+ };
+
+ pinctrl_sai3: sai3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI3_TXFS__AUDIOMIX_SAI3_TX_SYNC 0xd6
+ MX8MP_IOMUXC_SAI3_TXC__AUDIOMIX_SAI3_TX_BCLK 0xd6
+ MX8MP_IOMUXC_SAI3_RXD__AUDIOMIX_SAI3_RX_DATA00 0xd6
+ MX8MP_IOMUXC_SAI3_TXD__AUDIOMIX_SAI3_TX_DATA00 0xd6
+ MX8MP_IOMUXC_SAI3_MCLK__AUDIOMIX_SAI3_MCLK 0xd6
+ MX8MP_IOMUXC_SAI3_RXFS__AUDIOMIX_SAI3_RX_SYNC 0xd6
+ MX8MP_IOMUXC_SAI3_RXC__AUDIOMIX_SAI3_RX_BCLK 0xd6
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_ECSPI2_SCLK__UART4_DCE_RX 0x140
+ MX8MP_IOMUXC_ECSPI2_MOSI__UART4_DCE_TX 0x140
+ MX8MP_IOMUXC_ECSPI2_MISO__UART4_DCE_CTS 0x140
+ MX8MP_IOMUXC_ECSPI2_SS0__UART4_DCE_RTS 0x140
+ >;
+ };
+
+ 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_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x190
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d0
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d0
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d0
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d0
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d0
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d0
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d0
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d0
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d0
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x190
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x194
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x196
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d6
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d6
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d6
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d6
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d6
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d6
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d6
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d6
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d6
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x196
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO02__WDOG1_WDOG_B 0xc6
+ >;
+ };
+
+ pinctrl_wifi: wifigrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD1_DATA5__GPIO2_IO07 0xc0
+ MX8MP_IOMUXC_SD1_DATA6__GPIO2_IO08 0xc0
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v4 3/3] arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board
From: Stefano Radaelli @ 2026-06-09 9:04 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Dario Binacchi,
Josua Mayer, Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <cover.1780995737.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite Sonata carrier board with the
DART-MX8M-PLUS system on module.
The Sonata board includes
- uSD Card support
- USB ports and OTG
- Additional Gigabit Ethernet interface
- Uart, SPI and I2C interfaces
- HDMI support
- GPIO Expanders
- RTC module
- TPM module
- CAN peripherals
Link: https://variscite.com/carrier-boards/sonata-board/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v3->v4:
- Add snvs nodes
v2->v3:
-
v1->v2:
- Fixed model name
- Added new usdhc2 regulator pinctrl
- Adjusted irq edges
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8mp-var-dart-sonata.dts | 731 ++++++++++++++++++
2 files changed, 732 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-var-dart-sonata.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 03988f0eae30..818e57f54475 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -448,6 +448,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tx8p-ml81-moduline-display-106-av123z7m-n17.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-ultra-mach-sbc.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-var-dart-sonata.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-var-som-symphony.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-venice-gw71xx-2x.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-venice-gw72xx-2x.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-dart-sonata.dts
new file mode 100644
index 000000000000..12a2272c73b2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-dart-sonata.dts
@@ -0,0 +1,731 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Variscite Sonata carrier board for DART-MX8M-PLUS
+ *
+ * Link: https://variscite.com/carrier-boards/sonata-board/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>
+#include "imx8mp-var-dart.dtsi"
+
+/ {
+ model = "Variscite DART-MX8M-PLUS on Sonata-Board";
+ compatible = "variscite,var-dart-mx8mp-sonata",
+ "variscite,var-dart-mx8mp",
+ "fsl,imx8mp";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-home {
+ label = "Home";
+ linux,code = <KEY_HOME>;
+ gpios = <&pca6408_1 4 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-up {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ gpios = <&pca6408_1 5 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-down {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ gpios = <&pca6408_1 6 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-back {
+ label = "Back";
+ linux,code = <KEY_BACK>;
+ gpios = <&pca6408_1 7 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_leds>;
+
+ led-emmc {
+ gpios = <&gpio4 18 GPIO_ACTIVE_HIGH>;
+ label = "eMMC";
+ linux,default-trigger = "mmc2";
+ };
+ };
+
+ native-hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "HDMI OUT";
+ type = "a";
+
+ port {
+ hdmi_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
+ clk40m: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <40000000>;
+ clock-output-names = "can_osc";
+ };
+
+ pcie0_refclk: pcie0-refclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ };
+
+ reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_vmmc_usdhc2>;
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ startup-delay-us = <100>;
+ off-on-delay-us = <12000>;
+ };
+
+ sound-hdmi {
+ compatible = "fsl,imx-audio-hdmi";
+ model = "audio-hdmi";
+ audio-cpu = <&aud2htx>;
+ hdmi-out;
+ };
+
+ sound-xcvr {
+ compatible = "fsl,imx-audio-card";
+ model = "imx-audio-xcvr";
+
+ pri-dai-link {
+ link-name = "XCVR PCM";
+
+ cpu {
+ sound-dai = <&xcvr>;
+ };
+ };
+ };
+};
+
+&aud2htx {
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>,
+ <&gpio1 12 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ ads7846: touchscreen@0 {
+ compatible = "ti,ads7846";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_restouch>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ spi-max-frequency = <1500000>;
+ pendown-gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
+ ti,x-min = /bits/ 16 <125>;
+ ti,x-max = /bits/ 16 <4008>;
+ ti,y-min = /bits/ 16 <282>;
+ ti,y-max = /bits/ 16 <3864>;
+ ti,x-plate-ohms = /bits/ 16 <180>;
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,debounce-max = /bits/ 16 <10>;
+ ti,debounce-tol = /bits/ 16 <3>;
+ ti,debounce-rep = /bits/ 16 <1>;
+ ti,settle-delay-usec = /bits/ 16 <150>;
+ ti,keep-vref-on;
+ wakeup-source;
+ };
+
+ can0: can@1 {
+ compatible = "microchip,mcp251xfd";
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+ microchip,rx-int-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
+ clocks = <&clk40m>;
+ spi-max-frequency = <20000000>;
+ };
+};
+
+&eqos {
+ mdio {
+ ethphy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ reset-gpios = <&pca6408_2 0 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <20000>;
+ vddio-supply = <®_phy_vddio>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+ };
+ };
+};
+
+ðphy0 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy1>;
+ status = "okay";
+};
+
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ status = "okay";
+};
+
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ status = "okay";
+};
+
+&hdmi_pai {
+ status = "okay";
+};
+
+&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";
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ pinctrl-1 = <&pinctrl_i2c2_gpio>;
+ scl-gpios = <&gpio5 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca9534: gpio@22 {
+ compatible = "nxp,pca9534";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ eth10g-en-hog {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "eth10g_sel";
+ };
+
+ pcie2-en-hog {
+ gpio-hog;
+ gpios = <6 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "pcie2_sel";
+ };
+
+ /* RGB_SEL */
+ lvds-brg-enable-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "rgb_sel";
+ };
+ };
+
+ /* Capacitive touch controller */
+ ft5x06_ts: touchscreen@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_captouch>;
+ reset-gpios = <&pca6408_2 4 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ wakeup-source;
+ };
+
+ typec@3d {
+ compatible = "nxp,ptn5150";
+ reg = <0x3d>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_extcon>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+
+ port {
+ typec_dr_sw: endpoint {
+ remote-endpoint = <&usb3_drd_sw>;
+ };
+ };
+ };
+
+ rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rtc>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
+ wakeup-source;
+ };
+};
+
+&i2c3 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ pinctrl-1 = <&pinctrl_i2c3_gpio>;
+ scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ pinctrl-1 = <&pinctrl_i2c4_gpio>;
+ scl-gpios = <&gpio5 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 21 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca6408_1: gpio@20 {
+ compatible = "nxp,pcal6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pca6408>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ pca6408_2: gpio@21 {
+ compatible = "nxp,pcal6408";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ st33ktpm2xi2c: tpm@2e {
+ compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
+ reg = <0x2e>;
+ label = "tpm";
+ reset-gpios = <&pca9534 0 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&lcdif3 {
+ status = "okay";
+};
+
+&pcie {
+ reset-gpios = <&pca6408_2 3 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&pcie_phy {
+ fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+ clocks = <&pcie0_refclk>;
+ clock-names = "ref";
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "okay";
+};
+
+&snvs_rtc {
+ status = "disabled";
+};
+
+/* Console */
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+/* Header */
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+/* Header */
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ status = "okay";
+};
+
+&usb3_0 {
+ status = "okay";
+};
+
+&usb3_1 {
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
+ status = "okay";
+
+ port {
+ usb3_drd_sw: endpoint {
+ remote-endpoint = <&typec_dr_sw>;
+ };
+ };
+};
+
+&usb_dwc3_1 {
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usb3_phy0 {
+ fsl,phy-tx-vref-tune-percent = <122>;
+ fsl,phy-tx-preemp-amp-tune-microamp = <1800>;
+ fsl,phy-tx-vboost-level-microvolt = <1156>;
+ fsl,phy-comp-dis-tune-percent = <115>;
+ fsl,phy-pcs-tx-deemph-3p5db-attenuation-db = <33>;
+ fsl,phy-pcs-tx-swing-full-percent = <100>;
+ status = "okay";
+};
+
+&usb3_phy1 {
+ fsl,phy-tx-preemp-amp-tune-microamp = <1800>;
+ fsl,phy-tx-vref-tune-percent = <116>;
+ status = "okay";
+};
+
+&usdhc2 {
+ 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";
+};
+
+&xcvr {
+ #sound-dai-cells = <0>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_can: cangrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO06__GPIO1_IO06 0x1c6
+ MX8MP_IOMUXC_SPDIF_RX__GPIO5_IO04 0x16
+ >;
+ };
+
+ pinctrl_captouch: captouchgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO14__GPIO1_IO14 0x16
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x12
+ MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x12
+ MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x12
+ MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09 0x12
+ MX8MP_IOMUXC_GPIO1_IO12__GPIO1_IO12 0x12
+ >;
+ };
+
+ pinctrl_extcon: extcongrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO10__GPIO1_IO10 0x10
+ >;
+ };
+
+ pinctrl_fec: fecgrp {
+ fsl,pins = <
+ 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 0x1d0
+ MX8MP_IOMUXC_SAI1_TXC__ENET1_RGMII_RXC 0x90
+ MX8MP_IOMUXC_SAI1_TXFS__ENET1_RGMII_RX_CTL 0x90
+ MX8MP_IOMUXC_SAI1_TXD0__ENET1_RGMII_TD0 0x00
+ MX8MP_IOMUXC_SAI1_TXD1__ENET1_RGMII_TD1 0x00
+ MX8MP_IOMUXC_SAI1_TXD2__ENET1_RGMII_TD2 0x00
+ MX8MP_IOMUXC_SAI1_TXD3__ENET1_RGMII_TD3 0x00
+ MX8MP_IOMUXC_SAI1_TXD4__ENET1_RGMII_TX_CTL 0x00
+ MX8MP_IOMUXC_SAI1_TXD5__ENET1_RGMII_TXC 0x00
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI2_RXC__CAN1_TX 0x154
+ MX8MP_IOMUXC_SAI2_TXC__CAN1_RX 0x154
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI2_MCLK__CAN2_RX 0x154
+ MX8MP_IOMUXC_SAI2_TXD0__CAN2_TX 0x154
+ >;
+ };
+
+ pinctrl_gpio_leds: ledgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI1_TXD6__GPIO4_IO18 0xc6
+ >;
+ };
+
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c2
+ MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x1c2
+ MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0x10
+ MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0x10
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c2
+ MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA 0x400001c2
+ >;
+ };
+
+ pinctrl_i2c2_gpio: i2c2gpiogrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C2_SCL__GPIO5_IO16 0x1c2
+ MX8MP_IOMUXC_I2C2_SDA__GPIO5_IO17 0x1c2
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL 0x400001c2
+ MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA 0x400001c2
+ >;
+ };
+
+ pinctrl_i2c3_gpio: i2c3gpiogrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C3_SCL__GPIO5_IO18 0x1c2
+ MX8MP_IOMUXC_I2C3_SDA__GPIO5_IO19 0x1c2
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C4_SCL__I2C4_SCL 0x400001c2
+ MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c2
+ >;
+ };
+
+ pinctrl_i2c4_gpio: i2c4gpiogrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C4_SCL__GPIO5_IO20 0x1c2
+ MX8MP_IOMUXC_I2C4_SDA__GPIO5_IO21 0x1c2
+ >;
+ };
+
+ pinctrl_pca6408: pca6408grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO05__GPIO1_IO05 0x1c6
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO01__PWM1_OUT 0x116
+ >;
+ };
+
+ pinctrl_restouch: restouchgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO07__GPIO1_IO07 0xc0
+ >;
+ };
+
+ pinctrl_rtc: rtcgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO15 0x1c0
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x40
+ MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x40
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x40
+ MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x40
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART3_RXD__UART3_DCE_RX 0x40
+ MX8MP_IOMUXC_UART3_TXD__UART3_DCE_TX 0x40
+ >;
+ };
+
+ 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_vmmc_usdhc2: regvmmc-usdhc2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x40
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CD_B__GPIO2_IO12 0x1c4
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v4 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
From: Stefano Radaelli @ 2026-06-09 9:04 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Dario Binacchi,
Josua Mayer, Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve, Conor Dooley
In-Reply-To: <cover.1780995737.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add DT compatible strings for Variscite DART-MX8MP SoM and Variscite
development carrier Board.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v3->v4:
-
v2->v3:
-
v1->v2:
-
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 86876311ec59..11629b9eafc5 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1310,6 +1310,12 @@ properties:
- const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
- const: fsl,imx8mp
+ - description: Variscite DART-MX8M Plus based boards
+ items:
+ - const: variscite,var-dart-mx8mp-sonata # Variscite DART-MX8MP on Sonata Development Board
+ - const: variscite,var-dart-mx8mp # Variscite DART-MX8MP SOM
+ - const: fsl,imx8mp
+
- description: Variscite VAR-SOM-MX8M Plus based boards
items:
- const: variscite,var-som-mx8mp-symphony
--
2.47.3
^ permalink raw reply related
* [PATCH v4 0/3] Add support for Variscite DART-MX8M-PLUS and Sonata board
From: Stefano Radaelli @ 2026-06-09 9:04 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Dario Binacchi,
Josua Mayer, Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve
This patch series adds support for the Variscite DART-MX8M-PLUS
system on module and the Sonata carrier board.
The series includes:
- 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.
v3->v4:
- Add snvs nodes
v2->v3:
- Fixed wrong som eth phy address
v1->v2:
- Fixed wrong sai peripheral reference
- Fixed wrong eqos pinctrl gpio
- Fixed model name
- Added new usdhc2 regulator pinctrl
- Adjusted irq edges
Stefano Radaelli (3):
dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
arm64: dts: freescale: Add support for Variscite DART-MX8M-PLUS
arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8mp-var-dart-sonata.dts | 731 ++++++++++++++++++
.../boot/dts/freescale/imx8mp-var-dart.dtsi | 476 ++++++++++++
4 files changed, 1214 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-var-dart-sonata.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-var-dart.dtsi
base-commit: be580423d3f84b84a2f549df91e66bc4f54eda02
--
2.47.3
^ 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