* Re: [PATCH 3/5] arm_mpam: add MPAM-Fb MSC firmware access support
From: Andre Przywara @ 2026-05-21 15:54 UTC (permalink / raw)
To: Niyas Sait
Cc: ben.horgan, catalin.marinas, fenghuay, guohanjun, james.morse,
jic23, lenb, linux-acpi, linux-arm-kernel, linux-kernel,
lpieralisi, rafael, reinette.chatre, sudeep.holla, will
In-Reply-To: <20260518085237.3259344-1-niyas.sait@arm.com>
Hi Niyas,
many thanks for replying on the list!
On 5/18/26 10:52, Niyas Sait wrote:
> Hi Andre,
>
> On Wed, Apr 29, 2026 at 04:13:37PM +0200, Andre Przywara wrote:
>
>> +#define SCMI_CHAN_FLAGS_OFS 0x10
>> +#define SCMI_CHAN_FLAGS_IRQ BIT(0)
>> +#define SCMI_MSG_LENGTH_OFS 0x14
>> +#define SCMI_MSG_HEADER_OFS 0x18
>> +#define SCMI_MSG_PAYLOAD_OFS 0x1c
>
> I think this will not work for the ACPI PCC Type 3 MPAM Fb path.
Ah yes, I was confused about the offsets, and since I also provided the
firmware side in my very crude test setup, this matches, courtesy of me
making the same mistake on both sides ;-)
>
> SCMI shared memory transport layout and ACPI Extended PCC subspace
> shared memory layout use different offsets for the flags, length, command,
> and payload fields.
>
> For Extended PCC subspace, the layout is:
>
> Flags @ 0x04
> Length @ 0x08
> Command @ 0x0c
> Payload @ 0x10
>
> SCMI shared memory layout uses:
>
> Flags @ 0x10
> Length @ 0x14
> Command @ 0x18
> Payload @ 0x1c
>
> You will need to use the extended PCC subspace layout for the ACPI path.
Ah yes, I now see that I actually used a PCC subspace type 2 layout,
which explains some parts of my confusion, I guess.
So I changed that now: as you show above, there is just an offset, but
the relevant fields magically match otherwise. Since there is no SCMI
support in the code base at the moment, I can just change the offsets,
and deal with SCMI later.
>
>> +static int mpam_fb_wait_for_channel(struct pcc_mbox_chan *chan,
>> + bool free)
>> +{
>> + u32 status = free ? SCMI_CHAN_STATUS_FREE_BIT : 0;
>> + u32 val;
>> +
>> + /*
>> + * The channel should really be free always at this point, as we take
>> + * a lock for every read or write request. Check the free bit anyway,
>> + * for good measure and to catch corner cases.
>> + */
>> + return readl_poll_timeout(chan->shmem + SCMI_CHAN_STATUS_OFS, val,
>> + (val & SCMI_CHAN_STATUS_FREE_BIT) == status,
>> + 1, 10000);
>> +}
>
> This also assumes SCMI channel status completion semantics in shared memory.
> For PCC Type 3 transport, completion should follow PCC Type 3 completion mechanisms.
Ah, this is a very good point. As mention, I was staring at type 2 in
the ACPI spec. The PCC type 3 semantics is effectively very similar, or
at least can made to be, by just putting the right bits into the PCCT
table. The nice thing is that the Linux PCC code already handles the
channel negotiation, as part of the mailbox abstraction, so by just
populating the right fields in the PCCT table, I get the same semantics
on the device side, and can drop the whole channel ownership negotiation
from the MPAM code.
I now did one trick to simplify this: I kept the shared memory area
using the SCMI layout, so with the payload starting at offset 0x1c. In
the PCCT table I add 0xc to the beginning of the SRAM area, and give
that as the base address. This makes the SCP side always see the same
layout, at least for the relevant bits. Then I tell PCCT that the
command update register is at offset 0x4 of SRAM (so *before* the PCCT
shared mem area), which is exactly the location of the SCMI channel
ownership bit. To me that looks like it should work with SCMI and PCC
alike, maybe with some little tweaks on the SCP side.
With those changes it works for me now using type 3. I will send a v2 in
due time, once I address all the other outstanding issues.
Many thanks for the heads up on this one!
Cheers,
Andre
^ permalink raw reply
* [PATCH] ARM: module.lds: fix unwind metadata for merged .text sections
From: Egg12138 @ 2026-05-21 15:57 UTC (permalink / raw)
To: Russell King
Cc: Josh Poimboeuf, Petr Mladek, linux-arm-kernel, linux-modules,
linux-kernel, Egg12138
Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN,
and related macros") made scripts/module.lds.S merge module input
.text.* sections into the output .text section.
On ARM, the paired unwind input sections keep their original names. A
module can therefore contain .ARM.exidx.text.unlikely with sh_link
pointing at .text, while .text.unlikely no longer exists.
This is a valid ELF relationship, but ARM module_finalize() does not use
sh_link when registering module unwind tables. It derives the target
text section from the exidx section name instead:
.ARM.exidx.text.unlikely -> .text.unlikely
The lookup fails and the unwind table is not registered for the actual
.text range. This can make module stack unwinding fail with:
unwind: Index not found
Keep the ARM module unwind output names in sync with the text sections
that scripts/module.lds.S now produces. Coalesce the .ARM.exidx/.ARM.extab
sections associated with .text.*, into the
stable output names expected by the existing ARM module unwind code.
Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros")
Signed-off-by: Egg12138 <egg12138@foxmail.com>
---
arch/arm/include/asm/module.lds.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/include/asm/module.lds.h b/arch/arm/include/asm/module.lds.h
index 0e7cb4e314b4..dc9adf8fa50e 100644
--- a/arch/arm/include/asm/module.lds.h
+++ b/arch/arm/include/asm/module.lds.h
@@ -1,4 +1,12 @@
/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef CONFIG_ARCH_WANTS_MODULES_TEXT_SECTIONS
+SECTIONS {
+ .ARM.extab 0 : { *(.ARM.extab .ARM.extab.text .ARM.extab.text.[0-9a-zA-Z_]*) }
+ .ARM.exidx 0 : { *(.ARM.exidx .ARM.exidx.text .ARM.exidx.text.[0-9a-zA-Z_]*) }
+}
+#endif
+
#ifdef CONFIG_ARM_MODULE_PLTS
SECTIONS {
.plt : { BYTE(0) }
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 4/5] arm_mpam: prevent MPAM-Fb accesses inside IRQ handler
From: Andre Przywara @ 2026-05-21 15:59 UTC (permalink / raw)
To: Niyas Sait
Cc: ben.horgan, catalin.marinas, fenghuay, guohanjun, james.morse,
jic23, lenb, linux-acpi, linux-arm-kernel, linux-kernel,
lpieralisi, rafael, reinette.chatre, sudeep.holla, will
In-Reply-To: <20260518105708.3268174-1-niyas.sait@arm.com>
Hi Niyas,
thanks for the reply!
On 5/18/26 12:57, Niyas Sait wrote:
> Hi Andre,
>
> On Wed, Apr 29, 2026 at 04:13:38PM +0200, Andre Przywara wrote:
>
>> This error report relies on reading the MSC's error status register
>> (ESR) in the IRQ handler, which is not possible for MPAM-Fb based
>> MSC accesses, since they involve mailbox routines that might sleep.
>
> I think there are a few other places where we may still end up invoking
> the MPAM-Fb path from atomic/IRQ context.
>
> For example, _msmon_read() uses smp_call_function_any(), which runs
> __ris_msmon_read() in callback/atomic context
Ah, good point, I thought that the running CPU always being in the mask
would avoid the IPI - and it does, but it drops the code into atomic
context anyway, courtesy of disabling preemption when calling get_cpu().
So I just avoid that by checking the interface type and just calling
__ris_msmon_read() directly for PCC. Maybe there is a smarter solution
to this, but that seems simple enough.
Will be part of v2.
Many thanks for finding this!
Cheers,
Andre
>
> static int _msmon_read(struct mpam_component *comp, struct mon_read *arg)
> {
> ...
> err = smp_call_function_any(&msc->accessibility,
> __ris_msmon_read, arg,
> true);
> ...
> }
>
> For MPAM-Fb, I think we could potentially avoid the smp_call_function_any() path entirely
> and invoke directly from the current CPU. Since PCC accesses are effectively CPU agnostic,
> I think that should be fine for the MPAM-Fb case.
>
> Thanks,
> Niyas
^ permalink raw reply
* Re: [PATCH v14 09/44] arm64: RMI: Provide functions to delegate/undelegate ranges of memory
From: Suzuki K Poulose @ 2026-05-21 16:01 UTC (permalink / raw)
To: Marc Zyngier, Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <867bowx3qx.wl-maz@kernel.org>
On 21/05/2026 14:59, Marc Zyngier wrote:
> On Wed, 13 May 2026 14:17:17 +0100,
> Steven Price <steven.price@arm.com> wrote:
>>
>> The RMM requires memory is 'delegated' to it so that it can be used
>> either for a realm guest or for various tracking purposes within the RMM
>> (e.g. for metadata or page tables). Memory that has been delegated
>> cannot be accessed by the host (it will result in a Granule Protection
>> Fault).
>>
>> Undelegation may fail if the memory is still in use by the RMM. This
>> shouldn't happen (Linux should ensure it has destroyed the RMM objects
>> before attempting to undelegate). In the event that it does happen this
>> points to a programming bug and the only reasonable approach is for the
>> physical pages to be leaked - it is up to the caller of
>> rmi_undelegate_range() to handle this.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> v14:
>> * Split into separate patch and moved out of KVM
>> ---
>> arch/arm64/include/asm/rmi_cmds.h | 13 +++++++++++
>> arch/arm64/kernel/rmi.c | 36 +++++++++++++++++++++++++++++++
>> 2 files changed, 49 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/rmi_cmds.h b/arch/arm64/include/asm/rmi_cmds.h
>> index 9078a2920a7c..eb213c8e6f26 100644
>> --- a/arch/arm64/include/asm/rmi_cmds.h
>> +++ b/arch/arm64/include/asm/rmi_cmds.h
>> @@ -33,6 +33,19 @@ struct rmi_sro_state {
>> } while (RMI_RETURN_STATUS(res.a0) == RMI_BUSY || \
>> RMI_RETURN_STATUS(res.a0) == RMI_BLOCKED)
>>
>> +int rmi_delegate_range(phys_addr_t phys, unsigned long size);
>> +int rmi_undelegate_range(phys_addr_t phys, unsigned long size);
>> +
>> +static inline int rmi_delegate_page(phys_addr_t phys)
>> +{
>> + return rmi_delegate_range(phys, PAGE_SIZE);
>> +}
>> +
>> +static inline int rmi_undelegate_page(phys_addr_t phys)
>> +{
>> + return rmi_undelegate_range(phys, PAGE_SIZE);
>> +}
>> +
>> bool rmi_is_available(void);
>>
>> unsigned long rmi_sro_execute(struct rmi_sro_state *sro, gfp_t gfp);
>> diff --git a/arch/arm64/kernel/rmi.c b/arch/arm64/kernel/rmi.c
>> index 52a415e99500..08cef54acadb 100644
>> --- a/arch/arm64/kernel/rmi.c
>> +++ b/arch/arm64/kernel/rmi.c
>> @@ -12,6 +12,42 @@ static bool arm64_rmi_is_available;
>> unsigned long rmm_feat_reg0;
>> unsigned long rmm_feat_reg1;
>>
>> +int rmi_delegate_range(phys_addr_t phys, unsigned long size)
>> +{
>> + unsigned long ret = 0;
>> + unsigned long top = phys + size;
>> + unsigned long out_top;
>> +
>> + while (phys < top) {
>> + ret = rmi_granule_range_delegate(phys, top, &out_top);
>> + if (ret == RMI_SUCCESS)
>> + phys = out_top;
>> + else if (ret != RMI_BUSY && ret != RMI_BLOCKED)
>> + return ret;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +int rmi_undelegate_range(phys_addr_t phys, unsigned long size)
>> +{
>> + unsigned long ret = 0;
>> + unsigned long top = phys + size;
>> + unsigned long out_top;
>> +
>> + WARN_ON(size == 0);
>
> I find it odd to warn on size = 0. After all, free(NULL) is not an
> error. But even then, you continue feeding this to the RMM.
>
> You also don't seem to be bothered with that on the delegation side...
>
>> +
>> + while (phys < top) {
>> + ret = rmi_granule_range_undelegate(phys, top, &out_top);
>> + if (ret == RMI_SUCCESS)
>> + phys = out_top;
>
> and size==0 doesn't violate any of the failure conditions listed in
> B4.5.18.2 (beta2). Will you end-up looping around forever?
That is not true ? It triggers, top_bound error condition, for both.
pre: UInt(top) <= UInt(base)
post: result.status == RMI_ERROR_INPUT
Suzuki
>
> Same questions for the delegation, obviously.
>
> M.
>
^ permalink raw reply
* Re: [PATCH v2] perf/arm-cmn: Add workarounds for CMN-S3 on Graviton5
From: Robin Murphy @ 2026-05-21 16:02 UTC (permalink / raw)
To: Aviv Bakal, will, mark.rutland
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, zeev, blakgeof
In-Reply-To: <20260504133923.23373-1-avivb@amazon.com>
On 2026-05-04 2:39 pm, Aviv Bakal wrote:
> Graviton5 uses a customised CMN-S3 implementation where certain
> discovery registers report zeroed fields. Add the following workarounds:
>
> - Introduce a dedicated ACPI HID to identify the Graviton5 CMN variant.
> - Derive the DTC domain from the XP node ID, since the unit info
> register reports it as zero.
> - Set the DTC logical ID from the computed domain ID, since the node
> info register's logical ID field is also zeroed.
>
> Signed-off-by: Aviv Bakal <avivb@amazon.com>
> ---
> v2:
> - Use computed domain ID (xp->dtc) instead of XP logical ID for DTC
> logical ID assignment.
>
> drivers/perf/arm-cmn.c | 32 +++++++++++++++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
> index f5305c8fdca4..8ee3f8638602 100644
> --- a/drivers/perf/arm-cmn.c
> +++ b/drivers/perf/arm-cmn.c
> @@ -31,7 +31,8 @@
> #define CMN_CHILD_NODE_ADDR GENMASK(29, 0)
> #define CMN_CHILD_NODE_EXTERNAL BIT(31)
>
> -#define CMN_MAX_DIMENSION 12
> +/* Some implementations use a mesh larger than the architectural max of 12 */
> +#define CMN_MAX_DIMENSION 14
> #define CMN_MAX_XPS (CMN_MAX_DIMENSION * CMN_MAX_DIMENSION)
> #define CMN_MAX_DTMS (CMN_MAX_XPS + (CMN_MAX_DIMENSION - 1) * 4)
>
> @@ -214,6 +215,8 @@ enum cmn_part {
> PART_CMN700 = 0x43c,
> PART_CI700 = 0x43a,
> PART_CMN_S3 = 0x43e,
> + /* Synthetic part number, overridden to PART_CMN_S3 during discovery */
> + PART_GRAVITON5 = 0xa5,
> };
>
> /* CMN-600 r0px shouldn't exist in silicon, thankfully */
> @@ -2221,6 +2224,18 @@ static unsigned int arm_cmn_dtc_domain(struct arm_cmn *cmn, void __iomem *xp_reg
> return FIELD_GET(CMN_DTM_UNIT_INFO_DTC_DOMAIN, readl_relaxed(xp_region + offset));
> }
>
> +static unsigned int arm_cmn_graviton5_dtc_domain(u16 xp_id)
> +{
> + unsigned int x = (xp_id >> 7) & 0xf;
> + unsigned int y = (xp_id >> 3) & 0xf;
> +
> + /*
> + * The unit info register reads as zero; derive the DTC domain from
> + * the XP's mesh coordinates over the 10x14 mesh.
> + */
> + return (x / 5) + (y / 7) * 2;
> +}
> +
> static void arm_cmn_init_node_info(struct arm_cmn *cmn, u32 offset, struct arm_cmn_node *node)
> {
> int level;
> @@ -2266,6 +2281,7 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset)
> u64 reg;
> int i, j;
> size_t sz;
> + bool graviton5_workaround = false;
>
> arm_cmn_init_node_info(cmn, rgn_offset, &cfg);
> if (cfg.type != CMN_TYPE_CFG)
> @@ -2276,6 +2292,13 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset)
> reg = readq_relaxed(cfg_region + CMN_CFGM_PERIPH_ID_01);
> part = FIELD_GET(CMN_CFGM_PID0_PART_0, reg);
> part |= FIELD_GET(CMN_CFGM_PID1_PART_1, reg) << 8;
> +
> + /* Graviton5 has a customised CMN-S3 which needs some fixups */
> + if (cmn->part == PART_GRAVITON5) {
> + cmn->part = PART_CMN_S3;
> + graviton5_workaround = true;
> + }
> +
> /* 600AE is close enough that it's not really worth more complexity */
> if (part == PART_CMN600AE)
> part = PART_CMN600;
> @@ -2365,6 +2388,8 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset)
>
> if (cmn->part == PART_CMN600)
> xp->dtc = -1;
> + else if (graviton5_workaround)
> + xp->dtc = arm_cmn_graviton5_dtc_domain(xp->id);
> else
> xp->dtc = arm_cmn_dtc_domain(cmn, xp_region);
>
> @@ -2443,6 +2468,10 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset)
>
> switch (dn->type) {
> case CMN_TYPE_DTC:
> + if (graviton5_workaround) {
> + /* Node info logical ID is zeroed; use the domain ID */
> + dn->logid = xp->dtc;
No, this really should be xp->logid - other than DTC0 whose logical ID
is always forced to 0, but if it naturally lines up that way anyway then
all the better - since that is consistent with how the tooling generates
a regular hardware configuration. The cmn->dtc array ends up sorted by
logical ID as that is a guaranteed stable order for all CMN versions (as
the domain numbers themselves aren't always known), and it is the
interrupt order defined by the firmware bindings which we need to match.
If it's not guaranteed that the actual domain numbers are in the same
order then we have an existing bug in general (I'll have to check...)
Otherwise, this looks OK to me - in fact surprisingly pleasant and
unobtrusive given that it's a pretty horrible hardware issue to work
around. I guess we get lucky that it's an easy topology to compute.
Thanks,
Robin.
> + }
> cmn->num_dtcs++;
> dn++;
> break;
> @@ -2658,6 +2687,7 @@ static const struct acpi_device_id arm_cmn_acpi_match[] = {
> { "ARMHC650" },
> { "ARMHC700" },
> { "ARMHC003" },
> + { "AMZN0070", PART_GRAVITON5 },
> {}
> };
> MODULE_DEVICE_TABLE(acpi, arm_cmn_acpi_match);
^ permalink raw reply
* Re: [PATCH 5/5] arm_mpam: detect and enable MPAM-Fb PCC support
From: Andre Przywara @ 2026-05-21 16:04 UTC (permalink / raw)
To: Niyas Sait
Cc: ben.horgan, catalin.marinas, fenghuay, guohanjun, james.morse,
jic23, lenb, linux-acpi, linux-arm-kernel, linux-kernel,
lpieralisi, rafael, reinette.chatre, sudeep.holla, will
In-Reply-To: <20260518111422.3269965-1-niyas.sait@arm.com>
Hi Niyas,
On 5/18/26 13:14, Niyas Sait wrote:
> Hi Andre,
>
> On Wed, Apr 29, 2026 at 04:13:39PM +0200, Andre Przywara wrote:
>
>> + msc->pcc_chan = pcc_mbox_request_channel(&msc->pcc_cl,
>> + pcc_subspace_id);
>> + if (IS_ERR(msc->pcc_chan)) {
>> + pr_err("Failed to request MSC PCC channel\n");
>> + return (void *)msc->pcc_chan;
>> + }
>> +
>> + if (msc->pcc_chan->shmem_size < MPAM_FB_MAX_MSG_SIZE) {
>> + pr_err("MPAM-Fb PCC channel size too small.\n");
>> + pcc_mbox_free_channel(msc->pcc_chan);
>> + return ERR_PTR(-ENOMEM);
>> + }
>
> I think this allocates one PCC channel per MSC instance.
>
> MPAM-Fb spec. allows MPAM manager to support multiple MSCs and does not
Ouch, that's right, the MSC ID parameter in the protocol would be pretty
pointless otherwise ;-)
I guess me testing with just one MSC kind of hides this problem ;-)
> require seperate channels per MSC. Each MSC is targeted via its msc_id
> in the MPAM_MSC_READ/WRITE commands.
>
> So for systems where multiple MSC nodes point to the same PCC subspace,
> should we share one pcc_mbox_chan and serialize requests through it?
I think we serialise already, because we have this pcc_chan_lock. This
makes sure that each access is done in isolation. But on the setup side
we need to indeed make sure to share an already allocated channel, which
required some code changes.
Thanks for pointing this out!
Cheers,
Andre
^ permalink raw reply
* Re: [GIT PULL] soc: fixes for 7.1
From: pr-tracker-bot @ 2026-05-21 16:23 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linus Torvalds, soc, linux-arm-kernel, linux-kernel
In-Reply-To: <fa4afee7-8cb5-4555-b1e0-de376cc901e6@app.fastmail.com>
The pull request you sent on Wed, 20 May 2026 23:13:35 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-fixes-7.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dd3802fc4f6b52201a93330d44981a66bd6ef883
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v2 14/15] dt-bindings: display/lvds-codec: add ti,sn65lvds93
From: Hugo Villeneuve @ 2026-05-21 16:23 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: krzk, robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
rfoss, Laurent.pinchart, jonas, jernej.skrabec, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, Frank.Li, s.hauer, kernel,
festevam, shawnguo, laurent.pinchart+renesas, antonin.godard,
devicetree, linux-kernel, dri-devel, imx, linux-arm-kernel,
Hugo Villeneuve, Krzysztof Kozlowski
In-Reply-To: <20260511114406.24673c770d112b2ca4aba2eb@hugovil.com>
On Mon, 11 May 2026 11:44:06 -0400
Hugo Villeneuve <hugo@hugovil.com> wrote:
> Hi,
>
> On Thu, 5 Mar 2026 13:06:29 -0500
> Hugo Villeneuve <hugo@hugovil.com> wrote:
>
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Add compatible string for TI SN65LVDS93. Similar to
> > SN65LVDS83 but with an industrial temperature range.
> >
> > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Now that this series landed in linux-next/master, except for this
> patch, we now have an error since it is required:
>
> https://lore.kernel.org/oe-kbuild-all/202605071909.lXKPelNA-lkp@intel.com/
Hi DT folks,
wondering if someone could pick/apply this patch to fix the build error?
Hugo.
> > ---
> > Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > index 4f52e35d02537..f2cb74b86cc05 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > @@ -37,6 +37,7 @@ properties:
> > - ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
> > - ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
> > - ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter
> > + - ti,sn75lvds93 # For the TI SN75LVDS93 FlatLink transmitter
> > - const: lvds-encoder # Generic LVDS encoder compatible fallback
> > - items:
> > - enum:
> > --
> > 2.47.3
> >
> >
>
>
> Hugo Villeneuve <hugo@hugovil.com>
--
Hugo Villeneuve
^ permalink raw reply
* Re: (subset) [PATCH 0/4] power: sys-off: fix Pixel C shutdown via MAX77620
From: Lee Jones @ 2026-05-21 16:24 UTC (permalink / raw)
To: Diogo Ivo
Cc: Mark Rutland, Lorenzo Pieralisi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, linux-arm-kernel,
linux-kernel, devicetree, linux-tegra
In-Reply-To: <f98bcd81-29c6-4df2-8040-d17686b28f45@tecnico.ulisboa.pt>
On Thu, 21 May 2026, Diogo Ivo wrote:
>
>
> On 5/21/26 12:41, Lee Jones wrote:
> > On Thu, 21 May 2026, Diogo Ivo wrote:
> >
> > > Hi Lee,
> > >
> > > On 5/20/26 18:25, Lee Jones wrote:
> > > > On Thu, 14 May 2026 16:47:18 +0200, Diogo Ivo wrote:
> > > > > This series migrates PSCI and MAX77620 poweroff handling to the
> > > > > sys-off framework and fixes shutdown on the Pixel C (Smaug).
> > > > >
> > > > > The first two patches replace legacy pm_power_off usage in the PSCI
> > > > > and MAX77620 drivers with sys-off handlers. Besides aligning both
> > > > > drivers with the modern poweroff infrastructure, this removes the
> > > > > global callback dependency and allows multiple handlers to coexist
> > > > > with explicit priorities.
> > > > >
> > > > > [...]
> > > >
> > > > Applied, thanks!
> > >
> > > Thanks for applying the patches! Just a question and an observation:
> > >
> > > - I'm assuming you were ok with merging [2/4] despite the possible
> > > deadlock since this risk is already present in mainline in the same
> > > form so we're not actually making things worse, is that so?
> >
> > Did you see the text below?
>
> Yes, but patch 3 is not addressing the possible deadlock hence my
> question.
>
> > Both patches 2 and 3 are applied.
> >
> > > - The observation is that the comment about overriding PSCI is only
> > > true after (and if) a reworked [1/4] is actually merged.
> > > If it isn't then patch [3/4] is actually working around another handler
> > > in soc/tegra/pmc.c where a handler that only does work for the Nexus
> > > 7 is actually registered at FIRMWARE level for all platforms that
> > > probe that driver (I will send out a patch shortly to only register
> > > the handler on the Nexus 7).
> >
> > I assume the other patches will be applied soon.
> >
> > If this causes some kind of issue - let me know later on in the cycle
> > and I'll remove whatever patches you ask me to.
>
> The PSCI patch [1/4] has a fundamental issue and needs a respin to be
> applied.
>
> In connection with this it might then become easier to quirk the PSCI
> driver rather than the PMIC driver, so for the moment I'll ask you to
> drop [3/4] until I propose the changes to the PSCI maintainers and see
> the feedback and at that point we can either completely drop [3/4] or
> reapply it; sorry for the noise.
Done.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Fix OOB in scmi_power_name_get()
From: Sudeep Holla @ 2026-05-21 16:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Cristian Marussi, arm-scmi, Sudeep Holla, linux-arm-kernel,
linux-kernel
In-Reply-To: <75caae28bdffb55199a0bc6cac5df112a966c608.1778838987.git.geert+renesas@glider.be>
On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote:
> scmi_power_name_get() does not validate the domain number passed by the
> external caller, which may lead to an out-of-bounds access.
>
> Fix this by returning "unknown" for invalid domains, like
> scmi_reset_name_get() does.
>
> Fixes: 76a6550990e296a7 ("firmware: arm_scmi: add initial support for power protocol")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> drivers/firmware/arm_scmi/power.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
> index 3aa84ceb6d2bab68..4a7215e02dec035d 100644
> --- a/drivers/firmware/arm_scmi/power.c
> +++ b/drivers/firmware/arm_scmi/power.c
> @@ -204,8 +204,12 @@ scmi_power_name_get(const struct scmi_protocol_handle *ph,
> u32 domain)
> {
> struct scmi_power_info *pi = ph->get_priv(ph);
> - struct power_dom_info *dom = pi->dom_info + domain;
> + struct power_dom_info *dom;
> +
> + if (domain >= pi->num_domains)
> + return "unknown";
>
The only user of this function must not call it for domain >= pi->num_domains.
However, I am thinking if it is bit inconsistent within SCMI core now. I like
the way pinmux/ctl handles this as I don't like the alternative for this
(i.e. ERRPTR(-EINVAL or something)). Worst case if this ever causes issue
we can change the signature of the scmi_{power,reset}_name_get to follow
something like pinmux and update the users. Thoughts ? Happy to apply this
for now.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Lee Jones @ 2026-05-21 16:27 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Shivendra Pratap, Sebastian Reichel, Mark Rutland,
Lorenzo Pieralisi, Rafael J. Wysocki, Daniel Lezcano,
Christian Loehle, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Arnd Bergmann,
Souvik Chakravarty, Andy Yan, Matthias Brugger, John Stultz,
Moritz Fischer, Sudeep Holla, linux-pm, linux-kernel,
linux-arm-msm, linux-arm-kernel, devicetree, Florian Fainelli,
Krzysztof Kozlowski, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Greg Kroah-Hartman, Kathiravan Thirumoorthy, Srinivas Kandagatla,
Bartosz Golaszewski
In-Reply-To: <CAMRc=Me5QS4xA3PJWXNuRP1N_C+w3sP9ZvqH36GNh2Ebc9hwcw@mail.gmail.com>
On Thu, 21 May 2026, Bartosz Golaszewski wrote:
> On Thu, May 21, 2026 at 3:24 PM Lee Jones <lee@kernel.org> wrote:
> >
> > >
> > > I suggested it because of its flexibility. The alternative I had in
> > > mind is something like a new field in mfd_cell:
> > >
> > > const char *cell_node_name;
> > >
> > > Which - if set - would tell MFD to look up an fwnode that's a child of
> > > the parent device's node by name - as it may not have a compatible.
> >
> > Remind me why the chlid device can't look-up its own fwnode?
> >
>
> Oh sure it can, but should it? I'm not sure it's logically sound to
> have the child device reach into the parent, look up the fwnode and
> then assign it to itself after it's already attached to the driver.
> This should be done at the subsystem level before the device is
> registered.
Leaf drivers reach back into the parent all the time.
--
Lee Jones
^ permalink raw reply
* [PATCH v2] net: stmmac: mmc: Remove duplicate mmc_rx crc
From: Abid Ali via B4 Relay @ 2026-05-21 16:32 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel, Abid Ali
From: Abid Ali <dev.taqnialabs@gmail.com>
MMC_XGMAC_RX_CRC_ERR is clear-on-read, and just a single read would
update the mmc_rx_crc_error counter.
[1] commit b6cdf09 ("net: stmmac: xgmac: Implement MMC counters").
The duplicate read appears to have been unintentionally introduced in
the intial MMC counter implementation. The databook does not mention
MMC_XGMAC_RX_CRC_ERR needing the additional read.
Fixes: b6cdf09 ("net: stmmac: xgmac: Implement MMC counters")
Signed-off-by: Abid Ali <dev.taqnialabs@gmail.com>
---
Changes in v2:
- Updated why the redundant read is removed based on feedback.
- Link to v1: https://lore.kernel.org/r/20260520-xgmac-mmc_rx_crc-cleanup-v1-1-7133f529859f@gmail.com
---
drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
index 1b3b114e7..d81581dfa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
@@ -479,8 +479,6 @@ static void dwxgmac_mmc_read(void __iomem *mmcaddr, struct stmmac_counters *mmc)
&mmc->mmc_rx_multicastframe_g);
dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_CRC_ERR,
&mmc->mmc_rx_crc_error);
- dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_CRC_ERR,
- &mmc->mmc_rx_crc_error);
mmc->mmc_rx_run_error += readl(mmcaddr + MMC_XGMAC_RX_RUNT_ERR);
mmc->mmc_rx_jabber_error += readl(mmcaddr + MMC_XGMAC_RX_JABBER_ERR);
mmc->mmc_rx_undersize_g += readl(mmcaddr + MMC_XGMAC_RX_UNDER);
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260520-xgmac-mmc_rx_crc-cleanup-afcea6faa8ab
Best regards,
--
Abid Ali <dev.taqnialabs@gmail.com>
^ permalink raw reply related
* Re: [RFC PATCH 2/2] arm64: mm: add SMCCC-backed cache invalidate provider
From: Catalin Marinas @ 2026-05-21 16:35 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Srirangan Madhavan, will, mark.rutland, lpieralisi, sudeep.holla,
conor, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams
In-Reply-To: <20260521121812.2e4abd71@jic23-huawei>
On Thu, May 21, 2026 at 12:18:12PM +0100, Jonathan Cameron wrote:
> On Thu, 21 May 2026 07:30:47 +0000
> Srirangan Madhavan <smadhavan@nvidia.com> wrote:
> > MAINTAINERS | 1 +
> > arch/arm64/mm/Makefile | 1 +
> > arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++++++
>
> File location wise, this is a driver for a subsystem, be it one closely
> coupled to arm. Arm maintainers, do you want it in there or in drivers/cache ?
> My personal preference is always to keep drivers with subsystems but I don't
> care that much.
Yes, it makes more sense to keep it under drivers/cache/. We have many
other users of the SMCCC interface under drivers/.
>
> > 3 files changed, 182 insertions(+)
> > create mode 100644 arch/arm64/mm/cache_maint.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 2fb1c75afd16..33c35f8e6e40 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -25383,6 +25383,7 @@ M: Jonathan Cameron <jic23@kernel.org>
> > S: Maintained
> > T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
> > F: Documentation/devicetree/bindings/cache/
> > +F: arch/arm64/mm/cache_maint.c
>
> I wonder if this should just have a separate maintainers entry?
> We did that for the hisi driver.
Not needed if the code is moved to drivers/cache/.
> > +struct arm64_smccc_cache {
> > + /* Must be first member */
> > + struct cache_coherency_ops_inst cci;
> > + struct mutex lock; /* Serializes SMCCC cache maintenance calls. */
> > + u32 latency_us;
> > + u32 rate_limit;
> > + bool global_op;
> > + u64 global_flush_gen;
> > +};
> > +
> > +static struct arm64_smccc_cache *arm64_smccc_cache;
Nit: if these are all static, does it still make sense to use the arm64_
prefix throughout this file?
--
Catalin
^ permalink raw reply
* Re: [PATCH 1/2] gfp_types: Introduce a new GFP_ATOMIC_RT gfp flag
From: Lorenzo Stoakes @ 2026-05-21 16:40 UTC (permalink / raw)
To: Waiman Long
Cc: Marc Zyngier, Thomas Gleixner, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, linux-arm-kernel, linux-kernel,
linux-mm, linux-rt-devel, Matthew Wilcox
In-Reply-To: <20260520204628.933654-1-longman@redhat.com>
+cc Matthew who has fairly strong opinions on GFP flags and such :)
Also, please don't send 2 patch series with 2/2 in-reply-to 1/2, use a
cover letter + have patches reply to that :) [yes it's one of those
subjective things that people differ on a lot but generally how we do in
mm]
On Wed, May 20, 2026 at 04:46:27PM -0400, Waiman Long wrote:
> The GFP_ATOMIC flag is to be used in atomic context where user cannot
> sleep and need the allocation to succeed. However, it does not support
> contexts where preemption or interrupt is disabled under PREEMPT_RT
> like raw_spin_lock_irqsave() or plain preempt_disable().
>
> With the advance of the ALLOC_TRYLOCK allocation flag in the v7.1
> kernel, it is possible to allocate memory under such contexts by using
> spin_trylock to acquire the spinlock in the memory allocation path. This
> does increase the chance that the allocation can fail due to the presence
> of concurrent memory allocation requests. So its users must be able to
> handle such memory allocation failure gracefully.
>
> The ALLOC_TRYLOCK flag will only be enabled if none of the
> ___GFP_DIRECT_RECLAIM and ___GFP_KSWAPD_RECLAIM flags are set.
>
> Introduce a new GFP_ATOMIC_RT gfp flag for those PREEMPT_RT
> atomic contexts. This new flag will fall back to GFP_ATOMIC in
> non-PREEMPT_RT kernel. GFP_ATOMIC can continue to be used in contexts
> where preemption and interrupt are not disabled in PREEMPT_RT kernel
> like spin_lock_irqsave().
This seems like the wrong place for the solution, now we have to remember
to use a specific GFP flag but only in one specific place in some IRQ code,
yet RT is fine with this in any other scenario?
This is really confusing.
Wouldn't we better off with a way of actively detecting this context
somehow in the page allocator?
It just instinctively feels like this is the wrong level of abstraction for
a fix here :)
>
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> include/linux/gfp_types.h | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> index cd4972a7c97c..ac30882b6cd4 100644
> --- a/include/linux/gfp_types.h
> +++ b/include/linux/gfp_types.h
> @@ -316,6 +316,13 @@ enum {
> * preempt_disable() - see "Memory allocation" in
> * Documentation/core-api/real-time/differences.rst for more info.
> *
> + * %GFP_ATOMIC_RT is similar to %GFP_ATOMIC with the addition that it can also
> + * be used in context where preemption and/or interrupt is disabled under
> + * PREEMPT_RT, but not in NMI or hardirq contexts. The allocation is more
I'm not sure 'GFP_ATOMIC_RT' really communicates all of this information.
> + * likely to fail under PREEMPT_RT due to the spin_trylock() nature of lock
> + * acquisition. So the caller must be ready to handle memory allocation failure
> + * gracefully.
> + *
> * %GFP_KERNEL is typical for kernel-internal allocations. The caller requires
> * %ZONE_NORMAL or a lower zone for direct access but can direct reclaim.
> *
> @@ -388,4 +395,10 @@ enum {
> __GFP_NOMEMALLOC | __GFP_NOWARN) & ~__GFP_RECLAIM)
> #define GFP_TRANSHUGE (GFP_TRANSHUGE_LIGHT | __GFP_DIRECT_RECLAIM)
>
> +#ifdef CONFIG_PREEMPT_RT
> +# define GFP_ATOMIC_RT __GFP_HIGH
> +#else
> +# define GFP_ATOMIC_RT GFP_ATOMIC
> +#endif
> +
> #endif /* __LINUX_GFP_TYPES_H */
> --
> 2.54.0
>
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v1 14/15] dt-bindings: display: panel-lvds: Add LG LP156WF1
From: Conor Dooley @ 2026-05-21 16:54 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-31-ivitro@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3611 bytes --]
On Thu, May 21, 2026 at 04:00:50PM +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> Add the compatible string for the LG LP156WF1 15.6" FHD (1920x1080)
> dual-channel TFT LCD LVDS panel.
>
> Assisted-by: Claude:claude-sonnet-4.6
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> ---
> Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> index 45183a1439ce..a6af2b9cc2f9 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> @@ -58,6 +58,8 @@ properties:
> - hydis,hv070wx2-1e0
> # Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
> - jenson,bl-jt60050-01a
> + # LG LP156WF1 15.6" FHD (1920x1080) dual-channel TFT LCD LVDS panel
> + - lg,lp156wf1
> # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod.
> - logictechno,lt170410-2whc
> # Riverdi RVT101HVLNWC00 10.1" WXGA (1280x800) TFT LCD LVDS panel
Copy pasting a reply from me to sashiko-bot, cos the mail from it only
went to the submitter, dt maintainers and dt list:
|On Thu, May 21, 2026 at 03:27:16PM +0000, sashiko-bot@kernel.org wrote:
|> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
|> - [Medium] The dt-binding fails to enforce the dual-channel requirement (the `ports` property) for the newly added `lg,lp156wf1` compatible string.
|> --
|>
|> commit a568203d1851908daadd835b566099e0a123357a
|> Author: Vitor Soares <vitor.soares@toradex.com>
|> dt-bindings: display: panel-lvds: Add LG LP156WF1
|>
|> This commit adds the compatible string for the LG LP156WF1 15.6" FHD
|> dual-channel TFT LCD LVDS panel to the generic panel-lvds schema.
|>
|> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
|> > index 45183a1439ce9..a6af2b9cc2f9a 100644
|> > --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
|> > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
|> > @@ -58,6 +58,8 @@ properties:
|> > - hydis,hv070wx2-1e0
|> > # Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
|> > - jenson,bl-jt60050-01a
|> > + # LG LP156WF1 15.6" FHD (1920x1080) dual-channel TFT LCD LVDS panel
|> > + - lg,lp156wf1
|>
|> [Severity: Medium]
|> Since the commit message indicates this is a dual-channel panel, shouldn't we
|> add an if-then conditional block to require the ports property specifically for
|> this compatible string?
|
|No idea if this is accurate, but if it is accurate, would the
|lvds-dual-ports bindings come into play?
|
|>
|> Currently, the panel-lvds.yaml schema allows panels to be configured with
|> either a single port or multiple ports. Without a specific conditional block
|> enforcing required: [ports] for lg,lp156wf1, a device tree incorrectly
|> configuring this dual-channel hardware with only a single port will silently
|> pass validation.
|>
|> --
|> Sashiko AI review · https://sashiko.dev/#/patchset/20260521150038.103538-17-ivitro@gmail.com?part=14
I don't understand these deviecs enough to know if this is a valid
report.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 04/15] dt-bindings: vendor-prefixes: Add Riverdi
From: Conor Dooley @ 2026-05-21 16:54 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-21-ivitro@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 01/15] dt-bindings: display: panel: Move Logic Technologies LT170410-2WHC to LVDS
From: Conor Dooley @ 2026-05-21 16:56 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-18-ivitro@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]
On Thu, May 21, 2026 at 04:00:37PM +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> The Logic Technologies LT170410-2WHC is an LVDS panel, so move it to
> the correct bindings file.
>
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
Am I missing a driver change in the series for this?
v7.1-rc1 has:
rg logictechno,lt170410-2whc
Documentation/devicetree/bindings/display/panel/panel-simple.yaml
210: - logictechno,lt170410-2whc
drivers/gpu/drm/panel/panel-simple.c
5482: .compatible = "logictechno,lt170410-2whc",
Additionally, please add a fixes tag.
Cheers,
Conor.
pw-bot: changes-requested
> ---
> Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 --
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> index b31c67babaa8..9db96dd724b2 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> @@ -58,6 +58,8 @@ properties:
> - hydis,hv070wx2-1e0
> # Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
> - jenson,bl-jt60050-01a
> + # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod.
> + - logictechno,lt170410-2whc
> # Samsung LTN070NL01 7.0" WSVGA (1024x600) TFT LCD LVDS panel
> - samsung,ltn070nl01
> # Samsung LTN101AL03 10.1" WXGA (800x1280) TFT LCD LVDS panel
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 3e41ed0ef5d5..f7e09f5b1b5e 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -206,8 +206,6 @@ properties:
> - logictechno,lt161010-2nhc
> # Logic Technologies LT161010-2NHR 7" WVGA TFT Resistive Touch Module
> - logictechno,lt161010-2nhr
> - # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod.
> - - logictechno,lt170410-2whc
> # Logic Technologies LTTD800x480 L2RT 7" 800x480 TFT Resistive Touch Module
> - logictechno,lttd800480070-l2rt
> # Logic Technologies LTTD800480070-L6WH-RT 7” 800x480 TFT Resistive Touch Module
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 05/15] dt-bindings: display: panel-lvds: Add Riverdi RVT70HSLNWCA0 and RVT101HVLNWC00
From: Conor Dooley @ 2026-05-21 16:57 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-22-ivitro@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 13/15] dt-bindings: display: panel-lvds: Add dual-channel LVDS support
From: Conor Dooley @ 2026-05-21 16:59 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-30-ivitro@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
On Thu, May 21, 2026 at 04:00:49PM +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> The panel-lvds binding only supports single-channel panels.
> Extend it to support dual-channel LVDS panels by referencing the
> lvds-dual-ports schema when a ports container is present.
>
> Assisted-by: Claude:claude-sonnet-4.6
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
Ah, this is part of what sashiko was talking about I guess.
nvm that email so.
Why can't your new device go into panel-simple-lvds-dual-ports?
> ---
> .../bindings/display/panel/panel-lvds.yaml | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> index 7ed0c486870b..45183a1439ce 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> @@ -82,6 +82,17 @@ required:
> - width-mm
> - height-mm
> - panel-timing
> - - port
> +
> +oneOf:
> + - required:
> + - port
> + - required:
> + - ports
> +
> +if:
> + required:
> + - ports
> +then:
> + $ref: /schemas/display/lvds-dual-ports.yaml#
>
> ...
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Mostafa Saleh @ 2026-05-21 17:06 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Catalin Marinas, Jiri Pirko, Jason Gunthorpe,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <20260512090408.794195-5-aneesh.kumar@kernel.org>
On Tue, May 12, 2026 at 10:05 AM Aneesh Kumar K.V (Arm)
<aneesh.kumar@kernel.org> wrote:
> @@ -1411,6 +1436,16 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev, phys_addr_t orig_addr,
> if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
> pr_warn_once("Memory encryption is active and system is using DMA bounce buffers\n");
>
> + /*
> + * if we are trying to swiotlb map a decrypted paddr or the paddr is encrypted
> + * but the device is forcing decryption, use decrypted io_tlb_mem
> + */
> + if ((attrs & DMA_ATTR_CC_SHARED) || force_dma_unencrypted(dev))
I don't think swiotlb needs to know about force_dma_unencrypted(), the
dma/direct caller should have all the information to pass the
appropriate flags.
Thanks.
Mostafa
> + require_decrypted = true;
> +
> + if (require_decrypted != mem->unencrypted)
> + return (phys_addr_t)DMA_MAPPING_ERROR;
> +
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: ti: icssg: Add HSR and LRE PA statistics
From: Felix Maurer @ 2026-05-21 17:06 UTC (permalink / raw)
To: Jakub Kicinski
Cc: MD Danish Anwar, Luka Gejak, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
Roger Quadros, Andrew Lunn, Meghana Malladi, Jacob Keller,
David Carlier, Vadim Fedorenko, Kevin Hao, netdev, linux-doc,
linux-kernel, linux-arm-kernel, Vladimir Oltean
In-Reply-To: <20260520153303.33692fe3@kernel.org>
On Wed, May 20, 2026 at 03:33:03PM -0700, Jakub Kicinski wrote:
> On Wed, 20 May 2026 15:30:24 +0530 MD Danish Anwar wrote:
> > What should be the next steps here? Is there any existing defined set of
> > stats where I could populate stats from ICSSG firmware for HSR (similar
> > to ndo_get_stats64 callback). Or de we need to implement a new callback
> > that will do this for HSR.
>
> I'd try to plumb this thru ndo_get_offload_stats
> Close enough for my taste, let's see if anyone objects.
I'm not super well versed with the different options for stats we have
at the moment, so I'm definitely not going to object. I'm just going to
note that the stats I listed are applicable to all HSR/PRP interfaces,
not just the ones with hardware offloads. Therefore, it would IMHO be
nice if the two didn't diverge too much in the end and (best case)
userspace can ask for either the one or the other but get the same
structure back (no need to implement it for the software-only interfaces
in this patch series, I can do that afterwards as well).
Thanks,
Felix
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: arm: fsl: add Aquila iMX95
From: Franz Schnyder @ 2026-05-21 17:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, Conor Dooley
In-Reply-To: <20260521-add-aquila-imx95-v4-0-5a7f86c824f5@toradex.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
Add DT compatible strings for the Aquila i.MX95 SoM and its supported
carrier boards: the Aquila Development Board and the Clover carrier
board.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Link: https://www.toradex.com/products/carrier-board/clover
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v4: No changes
v3: No changes
v2: Added Conor's acked-by
v1: https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-1-69c8ee1c5413@toradex.com/
---
Documentation/devicetree/bindings/arm/fsl.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 59f7f168bf7c4..ea4cc98dadebc 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1507,6 +1507,14 @@ properties:
- const: phytec,imx95-phycore-fpsc # phyCORE-i.MX 95 FPSC
- const: fsl,imx95
+ - description: Toradex Boards with Aquila iMX95 Modules
+ items:
+ - enum:
+ - toradex,aquila-imx95-clover # Aquila iMX95 Module on Clover Board
+ - toradex,aquila-imx95-dev # Aquila iMX95 Module on Aquila Development Board
+ - const: toradex,aquila-imx95 # Aquila iMX95 Module
+ - const: fsl,imx95
+
- description: Toradex Boards with SMARC iMX95 Modules
items:
- const: toradex,smarc-imx95-dev # Toradex SMARC iMX95 on Toradex SMARC Development Board
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/3] arm64: dts: freescale: add Toradex Aquila iMX95
From: Franz Schnyder @ 2026-05-21 17:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, Conor Dooley,
João Paulo Gonçalves, Emanuele Ghidoli,
Francesco Dolcini, Antoine Gouby, Ernest Van Hoecke
This patch series adds support for the Toradex Aquila i.MX95 SoM and its
currently available carrier boards: the Aquila Development Board and the
Clover carrier board.
The module consists of an NXP i.MX95 family SoC, up to 16GB LPDDR5 RAM,
up to 128GB of storage, a USB 3.2 OTG and USB 2.0 Host, a Gigabit
Ethernet PHY, a 10 Gigabit Ethernet interface, an I2C EEPROM and
Temperature Sensor, an RX8130 RTC, one Quad lane CSI interface, one Quad
lane DSI or CSI interface, one LVDS interface (one or two channels), and
some optional addons: DisplayPort (through a DSI-DP bridge), TPM 2.0,
and a WiFi/BT module.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Link: https://www.toradex.com/products/carrier-board/clover
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
Changes in v4:
- Removed som_dsi2dp_bridge node from dev and clover board
since SoC's DSI controller is unsupported
- Link to v3: https://patch.msgid.link/20260521-add-aquila-imx95-v3-0-621843807def@toradex.com
Changes in v3:
- Changed QSPI_1 4bit iomux node name to 'flexspi14bitgrp'
- Deleted the cdns,* properties from flexspi1
- Link to v2: https://patch.msgid.link/20260520-add-aquila-imx95-v2-0-06424a51e33a@toradex.com
Changes in v2:
- Add 'acked-by' tag from Conor to the bindings patch
- Reordering iomux by node name
- Changed Francesco's tags to have the Toradex mail address
- Link to v1: https://lore.kernel.org/r/20260506-add-aquila-imx95-v1-0-69c8ee1c5413@toradex.com
---
Antoine Gouby (1):
arm64: dts: freescale: imx95-aquila: Add Clover carrier board
Franz Schnyder (1):
dt-bindings: arm: fsl: add Aquila iMX95
João Paulo Gonçalves (1):
arm64: dts: freescale: add Aquila iMX95 support
Documentation/devicetree/bindings/arm/fsl.yaml | 8 +
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../boot/dts/freescale/imx95-aquila-clover.dts | 285 +++++
arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts | 389 +++++++
arch/arm64/boot/dts/freescale/imx95-aquila.dtsi | 1160 ++++++++++++++++++++
5 files changed, 1844 insertions(+)
---
base-commit: 596d0f9f4fefffbf783ab26cfa90cf50f5dd6bb0
change-id: 20260501-add-aquila-imx95-423256af3d21
Best regards,
--
Franz Schnyder <franz.schnyder@toradex.com>
^ permalink raw reply
* [PATCH v4 2/3] arm64: dts: freescale: add Aquila iMX95 support
From: Franz Schnyder @ 2026-05-21 17:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, João Paulo Gonçalves,
Emanuele Ghidoli, Francesco Dolcini, Antoine Gouby,
Ernest Van Hoecke
In-Reply-To: <20260521-add-aquila-imx95-v4-0-5a7f86c824f5@toradex.com>
From: João Paulo Gonçalves <joao.goncalves@toradex.com>
Add support for the Toradex Aquila iMX95 and its development carrier
board.
The module consists of an NXP i.MX95 family SoC, up to 16GB LPDDR5 RAM,
up to 128GB of storage, a USB 3.2 OTG and USB 2.0 Host, a Gigabit
Ethernet PHY, a 10 Gigabit Ethernet interface, an I2C EEPROM and
Temperature Sensor, an RX8130 RTC, one Quad lane CSI interface, one Quad
lane DSI or CSI interface, one LVDS interface (one or two channels), and
some optional addons: DisplayPort (through a DSI-DP bridge), TPM 2.0,
and a WiFi/BT module.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com>
Co-developed-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Co-developed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Co-developed-by: Antoine Gouby <antoine.gouby@toradex.com>
Signed-off-by: Antoine Gouby <antoine.gouby@toradex.com>
Co-developed-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Co-developed-by: Franz Schnyder <franz.schnyder@toradex.com>
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v4: Removed som_dsi2dp_bridge node from the dev board
since SoC's DSI controller is unsupported
v3: -Changed QSPI_1 4bit iomux node name to 'flexspi14bitgrp'
-Deleted the cdns,* properties from flexspi1
v2: -Reordered iomux alphanumerically by node name
-Changed Francesco's tags to have the Toradex mail address
v1: https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-2-69c8ee1c5413@toradex.com/
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts | 389 +++++++
arch/arm64/boot/dts/freescale/imx95-aquila.dtsi | 1160 ++++++++++++++++++++
3 files changed, 1550 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 513f61eb27b85..c8697b6ae01c5 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -523,6 +523,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-var-dart-sonata.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts b/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts
new file mode 100644
index 0000000000000..3df17700b632f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts
@@ -0,0 +1,389 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
+ * https://www.toradex.com/products/carrier-board/aquila-development-board-kit
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/usb/pd.h>
+#include "imx95-aquila.dtsi"
+
+/ {
+ model = "Aquila iMX95 on Aquila Development Board";
+ compatible = "toradex,aquila-imx95-dev",
+ "toradex,aquila-imx95",
+ "fsl,imx95";
+
+ aliases {
+ eeprom1 = &carrier_eeprom;
+ };
+
+ dp_1_connector: dp0-connector {
+ compatible = "dp-connector";
+ dp-pwr-supply = <®_dp_3p3v>;
+ type = "full-size";
+
+ port {
+ dp_1_connector_in: endpoint {
+ remote-endpoint = <&dsi2dp_out>;
+ };
+ };
+ };
+
+ reg_carrier_1p8v: regulator-carrier-1p8v {
+ compatible = "regulator-fixed";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "On-carrier 1V8";
+ };
+
+ reg_dp_3p3v: regulator-dp-3p3v {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_21_dp>;
+ /* Aquila GPIO_21_DP */
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "DP_3V3";
+ startup-delay-us = <10000>;
+ };
+
+ sound {
+ 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 = "aquila-wm8904";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Microphone Jack", "MICBIAS",
+ "IN1L", "Microphone Jack",
+ "IN1R", "Digital Mic";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Digital Mic",
+ "Headphone", "Headphone Jack",
+ "Line", "Line In Jack";
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&wm8904_1a>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai2>;
+ };
+ };
+};
+
+/* Aquila ADC_[1-4] */
+&adc1 {
+ status = "okay";
+};
+
+/* Aquila CTRL_WAKE1_MICO# */
+&aquila_key_wake {
+ status = "okay";
+};
+
+&dsi2dp_out {
+ remote-endpoint = <&dp_1_connector_in>;
+};
+
+/* Aquila ETH_1 */
+&enetc_port0 {
+ status = "okay";
+};
+
+/* Aquila CAN_1 */
+&flexcan1 {
+ status = "okay";
+};
+
+/* Aquila CAN_2 */
+&flexcan2 {
+ status = "okay";
+};
+
+/* Aquila CAN_3 */
+&flexcan3 {
+ status = "okay";
+};
+
+/* Aquila CAN_4 */
+&flexcan4 {
+ status = "okay";
+};
+
+/* Aquila QSPI_1 */
+&flexspi1 {
+ pinctrl-0 = <&pinctrl_flexspi1_4bit>,
+ <&pinctrl_qspi_cs1>;
+
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+ };
+};
+
+&gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_8>;
+};
+
+&gpio4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_1>,
+ <&pinctrl_gpio_2>,
+ <&pinctrl_gpio_3>,
+ <&pinctrl_gpio_4>,
+ <&pinctrl_gpio_5>,
+ <&pinctrl_gpio_6>,
+ <&pinctrl_gpio_7>;
+};
+
+/* Aquila I2C_1 */
+&lpi2c2 {
+ status = "okay";
+
+ fan_controller: fan@18 {
+ compatible = "ti,amc6821";
+ reg = <0x18>;
+ #pwm-cells = <2>;
+
+ fan {
+ cooling-levels = <255>;
+ pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED>;
+ };
+ };
+
+ wm8904_1a: audio-codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai2_mclk>;
+ clocks = <&scmi_clk IMX95_CLK_SAI2>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ AVDD-supply = <®_carrier_1p8v>;
+ CPVDD-supply = <®_carrier_1p8v>;
+ DBVDD-supply = <®_carrier_1p8v>;
+ DCVDD-supply = <®_carrier_1p8v>;
+ MICVDD-supply = <®_carrier_1p8v>;
+ wlf,drc-cfg-names = "default", "peaklimiter";
+ /*
+ * 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
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>;
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+ wlf,in1r-as-dmicdat2;
+ };
+
+ /* Current measurement into module VCC */
+ hwmon@41 {
+ compatible = "ti,ina226";
+ reg = <0x41>;
+ shunt-resistor = <5000>;
+ };
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp1075";
+ reg = <0x4f>;
+ };
+
+ /* USB-C OTG (TCPC USB PD PHY) */
+ tcpc@52 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x52>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+
+ connector {
+ compatible = "usb-c-connector";
+ data-role = "dual";
+ op-sink-microwatt = <0>;
+ power-role = "dual";
+ self-powered;
+ sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "sink";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec_con_hs: endpoint {
+ remote-endpoint = <&usb1_con_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ typec_con_ss: endpoint {
+ remote-endpoint = <&usb1_con_ss>;
+ };
+ };
+ };
+ };
+ };
+
+ carrier_eeprom: eeprom@57 {
+ compatible = "st,24c02", "atmel,24c02";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+};
+
+/* Aquila I2C_2 */
+&i3c2 {
+ status = "okay";
+};
+
+/* Aquila I2C_4_CSI1 */
+&lpi2c4 {
+ status = "okay";
+};
+
+/* Aquila I2C_6 */
+&lpi2c5 {
+ status = "okay";
+};
+
+/* Aquila I2C_3_DSI1/I2C_5_CSI2 */
+&lpi2c8 {
+ status = "okay";
+
+ i2c-mux@70 {
+ compatible = "nxp,pca9543";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* I2C on DSI Connector Pin #4 and #6 */
+ i2c_dsi_0: i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ /* I2C on DSI Connector Pin #52 and #54 */
+ i2c_dsi_1: i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+/* Aquila SPI_1 */
+&lpspi6 {
+ status = "okay";
+};
+
+/* Aquila UART_3, used as the Linux Console */
+&lpuart1 {
+ status = "okay";
+};
+
+/* Aquila UART_4 */
+&lpuart2 {
+ status = "okay";
+};
+
+/* Aquila UART_1 */
+&lpuart3 {
+ status = "okay";
+};
+
+/* Aquila UART_2 as RS485 */
+&lpuart7 {
+ linux,rs485-enabled-at-boot-time;
+ rs485-rts-active-low;
+ rs485-rx-during-tx;
+
+ status = "okay";
+};
+
+/* Aquila PCIE_1 */
+&pcie0 {
+ status = "okay";
+};
+
+/* Aquila I2S_1 */
+&sai2 {
+ status = "okay";
+};
+
+/* Aquila PWM_1 */
+&tpm3 {
+ status = "okay";
+};
+
+/* Aquila PWM_2 */
+&tpm6 {
+ status = "okay";
+};
+
+/* Aquila PWM_3_DSI and PWM_4_DP */
+&tpm5 {
+ status = "okay";
+};
+
+/* Aquila USB_2, optional Bluetooth USB */
+&usb2 {
+ status = "okay";
+};
+
+/* Aquila USB_1 */
+&usb3 {
+ status = "okay";
+};
+
+&usb3_dwc3 {
+ status = "okay";
+
+ port {
+ usb1_con_hs: endpoint {
+ remote-endpoint = <&typec_con_hs>;
+ };
+ };
+};
+
+&usb3_phy {
+ orientation-switch;
+
+ status = "okay";
+
+ port {
+ usb1_con_ss: endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+};
+
+/* Aquila SD_1 */
+&usdhc2 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx95-aquila.dtsi b/arch/arm64/boot/dts/freescale/imx95-aquila.dtsi
new file mode 100644
index 0000000000000..69dc962a24a1d
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-aquila.dtsi
@@ -0,0 +1,1160 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
+ */
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include "imx95.dtsi"
+
+/ {
+ aliases {
+ can0 = &flexcan1;
+ can1 = &flexcan2;
+ can2 = &flexcan3;
+ can3 = &flexcan4;
+ eeprom0 = &som_eeprom;
+ ethernet0 = &enetc_port0;
+ i2c0 = &lpi2c3;
+ i2c1 = &lpi2c2;
+ i2c2 = &i3c2;
+ i2c3 = &lpi2c8;
+ i2c4 = &lpi2c4;
+ i2c6 = &lpi2c5;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ rtc0 = &rtc_i2c;
+ rtc1 = &scmi_bbm;
+ serial0 = &lpuart3;
+ serial1 = &lpuart7;
+ serial2 = &lpuart1;
+ serial3 = &lpuart2;
+ usb0 = &usb3;
+ usb1 = &usb2;
+ };
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ aquila_key_wake: gpio-key-wakeup {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ctrl_wake1_mico>;
+
+ status = "disabled";
+
+ key-wakeup {
+ /* Aquila CTRL_WAKE1_MICO# */
+ gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
+ label = "Wake Up";
+ wakeup-source;
+ linux,code = <KEY_WAKEUP>;
+ };
+ };
+
+ clk_dsi2dp_refclk: clock-dsi2dp-refclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <27000000>;
+ };
+
+ clk_dsi2dp_refclk_en: clock-dsi2dp-refclk-en {
+ compatible = "gpio-gate-clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ctrl_dp_clk_en>;
+ clocks = <&clk_dsi2dp_refclk>;
+ #clock-cells = <0>;
+ /* CTRL_DP_CLK_EN */
+ enable-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ clk_serdes_eth_ref: clock-serdes-eth-ref {
+ compatible = "gpio-gate-clock";
+ #clock-cells = <0>;
+ /* CTRL_ETH_REF_CLK_STBY */
+ enable-gpios = <&som_gpio_expander_0 6 GPIO_ACTIVE_LOW>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "On-module +V1.8";
+ };
+
+ reg_dp_1p2v: regulator-dp-1p2v {
+ compatible = "regulator-fixed";
+ /* CTRL_DP_BRIDGE_EN */
+ gpios = <&som_gpio_expander_0 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ regulator-max-microvolt = <1200000>;
+ regulator-min-microvolt = <1200000>;
+ regulator-name = "On-module +V1.2_DP";
+ vin-supply = <®_1p8v>;
+ };
+
+ reg_usb1_vbus: regulator-usb1-vbus {
+ compatible = "regulator-fixed";
+ /* Aquila USB_1_EN */
+ gpios = <&som_gpio_expander_0 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-name = "USB_1_EN";
+ };
+
+ reg_usb2_vbus: regulator-usb2-vbus {
+ compatible = "regulator-fixed";
+ /* Aquila USB_2_EN */
+ gpios = <&som_gpio_expander_0 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-name = "USB_2_H_EN";
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sd1_pwr_en>;
+ /* Aquila SD_1_PWR_EN */
+ gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ off-on-delay-us = <100000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "SD_1_PWR_EN";
+ startup-delay-us = <20000>;
+ };
+
+ reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc {
+ compatible = "regulator-gpio";
+ /* PMIC_SD_1_VSEL */
+ gpios = <&som_gpio_expander_1 9 GPIO_ACTIVE_HIGH>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "PMIC_SD_1_VSEL";
+ states = <1800000 0x1>,
+ <3300000 0x0>;
+ };
+
+ remoteproc-cm7 {
+ compatible = "fsl,imx95-cm7";
+ mboxes = <&mu7 0 1 &mu7 1 1 &mu7 3 1>;
+ mbox-names = "tx", "rx", "rxdb";
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>, <&m7_reserved>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ linux_cma: linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0 0x3c000000>;
+ alloc-ranges = <0 0x80000000 0 0x7f000000>;
+ linux,cma-default;
+ };
+
+ m7_reserved: memory@80000000 {
+ reg = <0 0x80000000 0 0x1000000>;
+ no-map;
+ };
+
+ rsc_table: rsc-table@88220000 {
+ reg = <0 0x88220000 0 0x1000>;
+ no-map;
+ };
+
+ vdev0vring0: vdev0vring0@88000000 {
+ reg = <0 0x88000000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: vdev0vring1@88008000 {
+ reg = <0 0x88008000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring0: vdev1vring0@88010000 {
+ reg = <0 0x88010000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring1: vdev1vring1@88018000 {
+ reg = <0 0x88018000 0 0x8000>;
+ no-map;
+ };
+
+ vdevbuffer: vdevbuffer@88020000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x88020000 0 0x100000>;
+ no-map;
+ };
+ };
+};
+
+/* Aquila ADC_[1-4] */
+&adc1 {
+ vref-supply = <®_1p8v>;
+};
+
+/* Aquila ETH_1 */
+&enetc_port0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enetc0>;
+ phy-handle = <ðphy1>;
+ phy-mode = "rgmii-id";
+};
+
+/* Aquila CAN_1 */
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+};
+
+/* Aquila CAN_2 */
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+};
+
+/* Aquila CAN_3 */
+&flexcan3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan3>;
+};
+
+/* Aquila CAN_4 */
+&flexcan4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan4>;
+};
+
+/* Aquila QSPI_1 */
+&flexspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexspi1_8bit>,
+ <&pinctrl_qspi_cs1>;
+};
+
+&gpio1 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_C24", /* 10 */
+ "",
+ "AQUILA_B17",
+ "CTRL_GPIO_EXP_INT#",
+ "AQUILA_B18";
+
+ status = "okay";
+};
+
+&gpio2 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_B42",
+ "",
+ "AQUILA_B43";
+};
+
+&gpio3 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_A11",
+ "", /* 20 */
+ "AQUILA_B57",
+ "AQUILA_B19";
+};
+
+&gpio4 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_C22",
+ "AQUILA_C21",
+ "AQUILA_C20",
+ "", /* 20 */
+ "",
+ "",
+ "AQUILA_C23",
+ "AQUILA_D23",
+ "AQUILA_D24",
+ "",
+ "AQUILA_D25";
+};
+
+&gpio5 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "AQUILA_B44",
+ "AQUILA_B45";
+};
+
+/* Aquila I2C_2 */
+&i3c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i3c2>;
+ i2c-scl-hz = <100000>;
+};
+
+/* Aquila I2C_1 */
+&lpi2c2 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c2>;
+ pinctrl-1 = <&pinctrl_lpi2c2_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio1 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio1 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* On-module I2C - I2C_SOM */
+&lpi2c3 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c3>, <&pinctrl_ctrl_gpio_exp_int>;
+ pinctrl-1 = <&pinctrl_lpi2c3_gpio>, <&pinctrl_ctrl_gpio_exp_int>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <400000>;
+ scl-gpios = <&gpio2 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+
+ status = "okay";
+
+ som_gpio_expander_0: gpio@20 {
+ compatible = "nxp,pcal6408";
+ reg = <0x20>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-line-names =
+ "AQUILA_C38", /* 0 */
+ "PCIE_2_RESET#",
+ "AQUILA_B77",
+ "USB_2_H_EN",
+ "BT_DISABLE#",
+ "WIFI_DISABLE#",
+ "CTRL_ETH_REF_CLK_STBY",
+ "CTRL_DP_BRIDGE_EN";
+ };
+
+ som_gpio_expander_1: gpio@21 {
+ compatible = "nxp,pcal6416";
+ reg = <0x21>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio1>;
+ interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-line-names =
+ "AQUILA_C1", /* 0 */
+ "AQUILA_C2",
+ "AQUILA_C3",
+ "AQUILA_C4",
+ "AQUILA_C36",
+ "AQUILA_B74",
+ "AQUILA_B75",
+ "USB_2_H_OC#",
+ "AQUILA_B81",
+ "PMIC_SD_1_VSEL",
+ "ETH_1_INT#", /* 10 */
+ "CTRL_TPM_INT#",
+ "SPI_2_CS2_TPM",
+ "PCIE_WAKE_WIFI#",
+ "WIFI_WAKE_BT",
+ "WIFI_WAKEUP_HOST";
+ };
+
+ som_dsi2dp_bridge: bridge@2c {
+ compatible = "ti,sn65dsi86";
+ reg = <0x2c>;
+ clocks = <&clk_dsi2dp_refclk_en>;
+ clock-names = "refclk";
+ vcc-supply = <®_dp_1p2v>;
+ vcca-supply = <®_dp_1p2v>;
+ vccio-supply = <®_1p8v>;
+ vpll-supply = <®_1p8v>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi2dp_in: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dsi2dp_out: endpoint {
+ data-lanes = <3 2 1 0>;
+ };
+ };
+ };
+ };
+
+ rtc_i2c: rtc@32 {
+ compatible = "epson,rx8130";
+ reg = <0x32>;
+ };
+
+ temperature-sensor@48 {
+ compatible = "ti,tmp1075";
+ reg = <0x48>;
+ };
+
+ som_eeprom: eeprom@50 {
+ compatible = "st,24c02", "atmel,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
+
+/* Aquila I2C_4_CSI1 */
+&lpi2c4 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c4>;
+ pinctrl-1 = <&pinctrl_lpi2c4_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio2 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 30 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* Aquila I2C_6 */
+&lpi2c5 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c5>;
+ pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio2 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* Aquila I2C_3_DSI1/I2C_5_CSI2 */
+&lpi2c8 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c8>;
+ pinctrl-1 = <&pinctrl_lpi2c8_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio2 13 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 12 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* Aquila SPI_2 */
+&lpspi4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi4>;
+ cs-gpios = <&gpio2 18 GPIO_ACTIVE_LOW>,
+ <&som_gpio_expander_1 12 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+
+ som_tpm: tpm@1 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <0x1>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ /*
+ * Maximum TPM-supported speed is 18.5 MHz, limited to 12 MHz
+ * here as lpspi4's per-clock (2x the max speed) is 24 MHz.
+ */
+ spi-max-frequency = <12000000>;
+ };
+};
+
+/* Aquila SPI_1 */
+&lpspi6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi6>;
+ cs-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+};
+
+/* Aquila UART_3, used as the Linux Console */
+&lpuart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+};
+
+/* Aquila UART_4 */
+&lpuart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+};
+
+/* Aquila UART_1 */
+&lpuart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ uart-has-rtscts;
+};
+
+/* Aquila UART_2 */
+&lpuart7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart7>;
+ uart-has-rtscts;
+};
+
+&mu7 {
+ status = "okay";
+};
+
+/* Aquila ETH_2_XGMII_MDIO, shared between all ethernet ports */
+&netc_emdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_emdio>;
+
+ status = "okay";
+
+ ethphy1: ethernet-phy@1 {
+ reg = <1>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ };
+};
+
+&netcmix_blk_ctrl {
+ status = "okay";
+};
+
+&netc_blk_ctrl {
+ status = "okay";
+};
+
+&netc_timer {
+ status = "okay";
+};
+
+/* Aquila PCIE_1 */
+&pcie0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie0>;
+ reset-gpios = <&som_gpio_expander_0 0 GPIO_ACTIVE_LOW>;
+};
+
+/* On-module Wi-Fi or Aquila PCIE_2 */
+&pcie1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie1>;
+ reset-gpios = <&som_gpio_expander_0 1 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+};
+
+/* Aquila I2S_1 */
+&sai2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai2>;
+ assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX95_CLK_SAI2>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>,
+ <3612672000>, <393216000>,
+ <361267200>, <12288000>;
+ #sound-dai-cells = <0>;
+ fsl,sai-mclk-direction-output;
+};
+
+&scmi_bbm {
+ linux,code = <KEY_POWER>;
+};
+
+&thermal_zones {
+ /* PF09 Main PMIC */
+ pf09-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 2>;
+
+ trips {
+ trip0 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ /* PF53 VDD_ARM PMIC */
+ pf53-arm-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 4>;
+
+ trips {
+ trip0 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ /* PF53 VDD_SOC PMIC */
+ pf53-soc-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 3>;
+
+ trips {
+ trip0 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+};
+
+/* Aquila PWM_1 */
+&tpm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+};
+
+/* Aquila PWM_2 */
+&tpm6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+};
+
+/* Aquila PWM_3_DSI and PWM_4_DP */
+&tpm5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3_dsi>, <&pinctrl_pwm4_dp>;
+};
+
+/* Aquila USB_2, optional Bluetooth USB */
+&usb2 {
+ dr_mode = "host";
+ vbus-supply = <®_usb2_vbus>;
+};
+
+/* Aquila USB_1 */
+&usb3 {
+ fsl,disable-port-power-control;
+};
+
+&usb3_dwc3 {
+ dr_mode = "otg";
+ adp-disable;
+ hnp-disable;
+ srp-disable;
+ usb-role-switch;
+};
+
+&usb3_phy {
+ vbus-supply = <®_usb1_vbus>;
+};
+
+/* On-module eMMC */
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ no-sdio;
+ no-sd;
+
+ status = "okay";
+};
+
+/* Aquila SD_1 */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_sd1_cd_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2>, <&pinctrl_sd1_cd_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>,<&pinctrl_sd1_cd_gpio>;
+ pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_sd1_cd_gpio>;
+ cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ vqmmc-supply = <®_usdhc2_vqmmc>;
+};
+
+&wdog3 {
+ fsl,ext-reset-output;
+
+ status = "okay";
+};
+
+&scmi_iomuxc {
+ /* Aquila CTRL_WAKE1_MICO# */
+ pinctrl_ctrl_wake1_mico: ctrlwake1micogrp {
+ fsl,pins = <IMX95_PAD_XSPI1_SS1_B__GPIO5_IO_BIT11 0x31e>; /* Aquila D6 */
+ };
+
+ pinctrl_ctrl_dp_clk_en: dpclkengrp {
+ fsl,pins = <IMX95_PAD_SAI1_TXFS__AONMIX_TOP_GPIO1_IO_BIT11 0x11e>; /* CTRL_DP_CLK_EN */
+ };
+
+ /* Aquila ETH_2_XGMII_MDIO */
+ pinctrl_emdio: emdiogrp {
+ fsl,pins = <IMX95_PAD_ENET2_MDC__NETCMIX_TOP_NETC_MDC 0x57e>, /* Aquila B90 */
+ <IMX95_PAD_ENET2_MDIO__NETCMIX_TOP_NETC_MDIO 0x97e>; /* Aquila B89 */
+ };
+
+ /* Aquila ETH_1 */
+ pinctrl_enetc0: enetc0grp {
+ fsl,pins = <IMX95_PAD_ENET1_TX_CTL__NETCMIX_TOP_ETH0_RGMII_TX_CTL 0x57e>, /* ENET1_TX_CTL */
+ <IMX95_PAD_ENET1_TXC__NETCMIX_TOP_ETH0_RGMII_TX_CLK 0x58e>, /* ENET1_TXC */
+ <IMX95_PAD_ENET1_TD0__NETCMIX_TOP_ETH0_RGMII_TD0 0x50e>, /* ENET1_TDO */
+ <IMX95_PAD_ENET1_TD1__NETCMIX_TOP_ETH0_RGMII_TD1 0x50e>, /* ENET1_TD1 */
+ <IMX95_PAD_ENET1_TD2__NETCMIX_TOP_ETH0_RGMII_TD2 0x50e>, /* ENET1_TD2 */
+ <IMX95_PAD_ENET1_TD3__NETCMIX_TOP_ETH0_RGMII_TD3 0x50e>, /* ENET1_TD3 */
+ <IMX95_PAD_ENET1_RX_CTL__NETCMIX_TOP_ETH0_RGMII_RX_CTL 0x57e>, /* ENET1_RX_CTL */
+ <IMX95_PAD_ENET1_RXC__NETCMIX_TOP_ETH0_RGMII_RX_CLK 0x58e>, /* ENET1_RXC */
+ <IMX95_PAD_ENET1_RD0__NETCMIX_TOP_ETH0_RGMII_RD0 0x57e>, /* ENET1_RD0 */
+ <IMX95_PAD_ENET1_RD1__NETCMIX_TOP_ETH0_RGMII_RD1 0x57e>, /* ENET1_RD1 */
+ <IMX95_PAD_ENET1_RD2__NETCMIX_TOP_ETH0_RGMII_RD2 0x57e>, /* ENET1_RD2 */
+ <IMX95_PAD_ENET1_RD3__NETCMIX_TOP_ETH0_RGMII_RD3 0x57e>; /* ENET1_RD3 */
+ };
+
+ /* Aquila CAN_1 */
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <IMX95_PAD_PDM_CLK__AONMIX_TOP_CAN1_TX 0x39e>, /* Aquila B48 */
+ <IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_CAN1_RX 0x39e>; /* Aquila B49 */
+ };
+
+ /* Aquila CAN_2 */
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO25__CAN2_TX 0x39e>, /* Aquila B50 */
+ <IMX95_PAD_GPIO_IO27__CAN2_RX 0x39e>; /* Aquila B51 */
+ };
+
+ /* Aquila CAN_3 */
+ pinctrl_flexcan3: flexcan3grp {
+ fsl,pins = <IMX95_PAD_CCM_CLKO3__CAN3_TX 0x39e>, /* Aquila B53 */
+ <IMX95_PAD_CCM_CLKO4__CAN3_RX 0x39e>; /* Aquila B54 */
+ };
+
+ /* Aquila CAN_4 */
+ pinctrl_flexcan4: flexcan4grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO04__CAN4_TX 0x39e>, /* Aquila B55 */
+ <IMX95_PAD_GPIO_IO05__CAN4_RX 0x39e>; /* Aquila B56 */
+ };
+
+ /* Aquila QSPI_1 (4 bit) */
+ pinctrl_flexspi1_4bit: flexspi14bitgrp {
+ fsl,pins = <IMX95_PAD_XSPI1_SCLK__FLEXSPI1_A_SCLK 0x3fe>, /* Aquila B65 */
+ <IMX95_PAD_XSPI1_DATA0__FLEXSPI1_A_DATA_BIT0 0x3fe>, /* Aquila B68 */
+ <IMX95_PAD_XSPI1_DATA1__FLEXSPI1_A_DATA_BIT1 0x3fe>, /* Aquila B67 */
+ <IMX95_PAD_XSPI1_DATA2__FLEXSPI1_A_DATA_BIT2 0x3fe>, /* Aquila B61 */
+ <IMX95_PAD_XSPI1_DATA3__FLEXSPI1_A_DATA_BIT3 0x3fe>, /* Aquila B60 */
+ <IMX95_PAD_XSPI1_DQS__FLEXSPI1_A_DQS 0x3fe>; /* Aquila B63 */
+ };
+
+ /* Aquila QSPI_1 (8 bit) */
+ pinctrl_flexspi1_8bit: flexspi18bitgrp {
+ fsl,pins = <IMX95_PAD_XSPI1_SCLK__FLEXSPI1_A_SCLK 0x3fe>, /* Aquila B65 */
+ <IMX95_PAD_XSPI1_DATA0__FLEXSPI1_A_DATA_BIT0 0x3fe>, /* Aquila B68 */
+ <IMX95_PAD_XSPI1_DATA1__FLEXSPI1_A_DATA_BIT1 0x3fe>, /* Aquila B67 */
+ <IMX95_PAD_XSPI1_DATA2__FLEXSPI1_A_DATA_BIT2 0x3fe>, /* Aquila B61 */
+ <IMX95_PAD_XSPI1_DATA3__FLEXSPI1_A_DATA_BIT3 0x3fe>, /* Aquila B60 */
+ <IMX95_PAD_XSPI1_DATA4__FLEXSPI1_A_DATA_BIT4 0x3fe>, /* Aquila B70 */
+ <IMX95_PAD_XSPI1_DATA5__FLEXSPI1_A_DATA_BIT5 0x3fe>, /* Aquila B71 */
+ <IMX95_PAD_XSPI1_DATA6__FLEXSPI1_A_DATA_BIT6 0x3fe>, /* Aquila B72 */
+ <IMX95_PAD_XSPI1_DATA7__FLEXSPI1_A_DATA_BIT7 0x3fe>, /* Aquila B73 */
+ <IMX95_PAD_XSPI1_DQS__FLEXSPI1_A_DQS 0x3fe>; /* Aquila B63 */
+ };
+
+ /* Aquila GPIO_01 */
+ pinctrl_gpio_1: gpio1grp {
+ fsl,pins = <IMX95_PAD_ENET2_RD0__GPIO4_IO_BIT24 0x31e>; /* Aquila D23 */
+ };
+
+ /* Aquila GPIO_02 */
+ pinctrl_gpio_2: gpio2grp {
+ fsl,pins = <IMX95_PAD_ENET2_RD1__GPIO4_IO_BIT25 0x31e>; /* Aquila D24 */
+ };
+
+ /* Aquila GPIO_03 */
+ pinctrl_gpio_3: gpio3grp {
+ fsl,pins = <IMX95_PAD_ENET2_RD3__GPIO4_IO_BIT27 0x31e>; /* Aquila D25 */
+ };
+
+ /* Aquila GPIO_04 */
+ pinctrl_gpio_4: gpio4grp {
+ fsl,pins = <IMX95_PAD_ENET2_TD0__GPIO4_IO_BIT19 0x31e>; /* Aquila C20 */
+ };
+
+ /* Aquila GPIO_05 */
+ pinctrl_gpio_5: gpio5grp {
+ fsl,pins = <IMX95_PAD_ENET2_TD1__GPIO4_IO_BIT18 0x31e>; /* Aquila C21 */
+ };
+
+ /* Aquila GPIO_06 */
+ pinctrl_gpio_6: gpio6grp {
+ fsl,pins = <IMX95_PAD_ENET2_TD2__GPIO4_IO_BIT17 0x31e>; /* Aquila C22 */
+ };
+
+ /* Aquila GPIO_07 */
+ pinctrl_gpio_7: gpio7grp {
+ fsl,pins = <IMX95_PAD_ENET2_RXC__GPIO4_IO_BIT23 0x31e>; /* Aquila C23 */
+ };
+
+ /* Aquila GPIO_08 */
+ pinctrl_gpio_8: gpio8grp {
+ fsl,pins = <IMX95_PAD_PDM_BIT_STREAM1__AONMIX_TOP_GPIO1_IO_BIT10 0x31e>; /* Aquila C24 */
+ };
+
+ /* Aquila GPIO_09_CSI_1 */
+ pinctrl_gpio_9_csi_1: gpio9csi1grp {
+ fsl,pins = <IMX95_PAD_SAI1_TXC__AONMIX_TOP_GPIO1_IO_BIT12 0x31e>; /* Aquila B17 */
+ };
+
+ /* Aquila GPIO_10_CSI_1 */
+ pinctrl_gpio_10_csi_1: gpio10csi1grp {
+ fsl,pins = <IMX95_PAD_SAI1_RXD0__AONMIX_TOP_GPIO1_IO_BIT14 0x31e>; /* Aquila B18 */
+ };
+
+ /* Aquila GPIO_11_CSI_1 */
+ pinctrl_gpio_11_csi_1: gpio11csi1grp {
+ fsl,pins = <IMX95_PAD_SD2_VSELECT__GPIO3_IO_BIT19 0x31e>; /* Aquila A11*/
+ };
+
+ /* Aquila GPIO_12_CSI_1 */
+ pinctrl_gpio_12_csi_1: gpio12csi1grp {
+ fsl,pins = <IMX95_PAD_SD3_DATA0__GPIO3_IO_BIT22 0x31e>; /* Aquila B19 */
+ };
+
+ /* Aquila GPIO_17_DSI_1 */
+ pinctrl_gpio_17_dsi_1: gpio17dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO07__GPIO2_IO_BIT7 0x31e>; /* Aquila B42 */
+ };
+
+ /* Aquila GPIO_18_DSI_1 */
+ pinctrl_gpio_18_dsi_1: gpio18dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO09__GPIO2_IO_BIT9 0x31e>; /* Aquila B43 */
+ };
+
+ /* Aquila GPIO_19_DSI_1 */
+ pinctrl_gpio_19_dsi_1: gpio19dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO33__GPIO5_IO_BIT13 0x31e>; /* Aquila B44 */
+ };
+
+ /* Aquila GPIO_20_DSI_1 */
+ pinctrl_gpio_20_dsi_1: gpio20dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14 0x31e>; /* Aquila B45 */
+ };
+
+ /* Aquila GPIO_21_DP */
+ pinctrl_gpio_21_dp: gpio21dpgrp {
+ fsl,pins = <IMX95_PAD_SD3_CMD__GPIO3_IO_BIT21 0x31e>; /* Aquila B57 */
+ };
+
+ pinctrl_ctrl_gpio_exp_int: gpioexpintgrp {
+ fsl,pins = <IMX95_PAD_SAI1_TXD0__AONMIX_TOP_GPIO1_IO_BIT13 0x31e>; /* CTRL_GPIO_EXP_INT# */
+ };
+
+ /* Aquila I2C_2 */
+ pinctrl_i3c2: i3c2cgrp {
+ fsl,pins = <IMX95_PAD_ENET1_MDC__I3C2_SCL 0x40001186>, /* Aquila C17 */
+ <IMX95_PAD_ENET1_MDIO__I3C2_SDA 0x40001186>; /* Aquila C16 */
+ };
+
+ /* Aquila I2C_1 as GPIOs */
+ pinctrl_lpi2c2_gpio: lpi2c2gpiogrp {
+ fsl,pins = <IMX95_PAD_I2C2_SCL__AONMIX_TOP_GPIO1_IO_BIT2 0x40001b9e>, /* Aquila D8 */
+ <IMX95_PAD_I2C2_SDA__AONMIX_TOP_GPIO1_IO_BIT3 0x40001b9e>; /* Aquila D7 */
+ };
+
+ /* Aquila I2C_1 */
+ pinctrl_lpi2c2: lpi2c2grp {
+ fsl,pins = <IMX95_PAD_I2C2_SCL__AONMIX_TOP_LPI2C2_SCL 0x40001b9e>, /* Aquila D8 */
+ <IMX95_PAD_I2C2_SDA__AONMIX_TOP_LPI2C2_SDA 0x40001b9e>; /* Aquila D7 */
+ };
+
+ /* On-module I2C as GPIOs */
+ pinctrl_lpi2c3_gpio: lpi2c3gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO28__GPIO2_IO_BIT28 0x40001b9e>, /* I2C_SOM_SDA */
+ <IMX95_PAD_GPIO_IO29__GPIO2_IO_BIT29 0x40001b9e>; /* I2C_SOM_SCL */
+ };
+
+ /* On-module I2C */
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO28__LPI2C3_SDA 0x40001b9e>, /* I2C_SOM_SDA */
+ <IMX95_PAD_GPIO_IO29__LPI2C3_SCL 0x40001b9e>; /* I2C_SOM_SCL */
+ };
+
+ /* Aquila I2C_4_CSI1 as GPIO */
+ pinctrl_lpi2c4_gpio: lpi2c4gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO30__GPIO2_IO_BIT30 0x40001b9e>, /* Aquila A12 */
+ <IMX95_PAD_GPIO_IO31__GPIO2_IO_BIT31 0x40001b9e>; /* Aquila A13 */
+ };
+
+ /* Aquila I2C_4_CSI1 */
+ pinctrl_lpi2c4: lpi2c4grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO30__LPI2C4_SDA 0x40001b9e>, /* Aquila A12 */
+ <IMX95_PAD_GPIO_IO31__LPI2C4_SCL 0x40001b9e>; /* Aquila A13 */
+ };
+
+ /* Aquila I2C_6 as GPIO */
+ pinctrl_lpi2c5_gpio: lpi2c5gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO22__GPIO2_IO_BIT22 0x40001b9e>, /* Aquila C18 */
+ <IMX95_PAD_GPIO_IO23__GPIO2_IO_BIT23 0x40001b9e>; /* Aquila C19 */
+ };
+
+ /* Aquila I2C_6 */
+ pinctrl_lpi2c5: lpi2c5grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO22__LPI2C5_SDA 0x40001b9e>, /* Aquila C18 */
+ <IMX95_PAD_GPIO_IO23__LPI2C5_SCL 0x40001b9e>; /* Aquila C19 */
+ };
+
+ /* Aquila I2C_3_DSI1/I2C_5_CSI2 as GPIO */
+ pinctrl_lpi2c8_gpio: lpi2c8gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO12__GPIO2_IO_BIT12 0x40001b9e>, /* Aquila C5/B40 */
+ <IMX95_PAD_GPIO_IO13__GPIO2_IO_BIT13 0x40001b9e>; /* Aquila C6/B41 */
+ };
+
+ /* Aquila I2C_3_DSI1/I2C_5_CSI2 */
+ pinctrl_lpi2c8: lpi2c8grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO12__LPI2C8_SDA 0x40001b9e>, /* Aquila C5/B40 */
+ <IMX95_PAD_GPIO_IO13__LPI2C8_SCL 0x40001b9e>; /* Aquila C6/B41 */
+ };
+
+ /* Aquila SPI_2 */
+ pinctrl_lpspi4: lpspi4grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO18__GPIO2_IO_BIT18 0x3fe>, /* Aquila D16 */
+ <IMX95_PAD_GPIO_IO19__LPSPI4_SIN 0x3fe>, /* Aquila D15 */
+ <IMX95_PAD_GPIO_IO20__LPSPI4_SOUT 0x3fe>, /* Aquila D17 */
+ <IMX95_PAD_GPIO_IO21__LPSPI4_SCK 0x3fe>; /* Aquila D14 */
+ };
+
+ /* Aquila SPI_1 */
+ pinctrl_lpspi6: lpspi6grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO00__GPIO2_IO_BIT0 0x3fe>, /* Aquila D9 */
+ <IMX95_PAD_GPIO_IO01__LPSPI6_SIN 0x3fe>, /* Aquila D10 */
+ <IMX95_PAD_GPIO_IO02__LPSPI6_SOUT 0x3fe>, /* Aquila D11 */
+ <IMX95_PAD_GPIO_IO03__LPSPI6_SCK 0x3fe>; /* Aquila D12 */
+ };
+
+ /* Aquila PCIE_1 */
+ pinctrl_pcie0: pcie0grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO32__HSIOMIX_TOP_PCIE1_CLKREQ_B 0x40001b1e>; /* Aquila C37 */
+ };
+
+ /* Aquila PCIE_2 */
+ pinctrl_pcie1: pcie1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x40001b1e>; /* Aquila C34 */
+ };
+
+ /* Aquila QSPI_1_CS1# */
+ pinctrl_qspi_cs1: qspics1grp {
+ fsl,pins = <IMX95_PAD_XSPI1_SS0_B__FLEXSPI1_A_SS0_B 0x3fe>; /* Aquila B66 */
+ };
+
+ /* Aquila QSPI_1_CS2# as GPIO */
+ pinctrl_qspi_cs2_gpio: qspics2gpiogrp {
+ fsl,pins = <IMX95_PAD_CCM_CLKO2__GPIO3_IO_BIT27 0x3fe>; /* Aquila B62 */
+ };
+
+ /* Aquila I2S_1 */
+ pinctrl_sai2: sai2grp {
+ fsl,pins = <IMX95_PAD_ENET2_TX_CTL__NETCMIX_TOP_SAI2_TX_SYNC 0x11e>, /* Aquila B21 */
+ <IMX95_PAD_ENET2_TXC__NETCMIX_TOP_SAI2_TX_BCLK 0x11e>, /* Aquila B20 */
+ <IMX95_PAD_ENET2_TD3__NETCMIX_TOP_SAI2_RX_DATA_BIT0 0x11e>, /* Aquila B23 */
+ <IMX95_PAD_ENET2_RX_CTL__NETCMIX_TOP_SAI2_TX_DATA_BIT0 0x11e>; /* Aquila B22 */
+ };
+
+ pinctrl_sai2_mclk: sai2mclkgrp {
+ fsl,pins = <IMX95_PAD_ENET2_RD2__NETCMIX_TOP_SAI2_MCLK 0x31e>; /* Aquila B24 */
+ };
+
+ /* Aquila SD_1_CD# as GPIO */
+ pinctrl_sd1_cd_gpio: sd1cdgpiogrp {
+ fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>; /* Aquila A1 */
+ };
+
+ /* Aquila SD_1_PWR_EN */
+ pinctrl_sd1_pwr_en: sd1pwrengpiogrp {
+ fsl,pins = <IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7 0x11e>; /* Aquila A6 */
+ };
+
+ /* Aquila PWM_1 */
+ pinctrl_pwm1: tpm3ch3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO24__TPM3_CH3 0x11e>; /* Aquila C25 */
+ };
+
+ /* Aquila PWM_3_DSI as GPIO */
+ pinctrl_pwm3_dsi_gpio: tpm5ch0gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO06__GPIO2_IO_BIT6 0x11e>; /* Aquila B46 */
+ };
+
+ /* Aquila PWM_3_DSI */
+ pinctrl_pwm3_dsi: tpm5ch0grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO06__TPM5_CH0 0x11e>; /* Aquila B46 */
+ };
+
+ /* Aquila PWM_4_DP */
+ pinctrl_pwm4_dp: tpm5ch3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO26__TPM5_CH3 0x11e>; /* Aquila B58 */
+ };
+
+ /* Aquila PWM_2 */
+ pinctrl_pwm2: tpm6ch0grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO08__TPM6_CH0 0x11e>; /* Aquila C26 */
+ };
+
+ /* Aquila UART_3 */
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX 0x31e>, /* Aquila D20 */
+ <IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX 0x31e>; /* Aquila D19 */
+ };
+
+ /* Aquila UART_4 */
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <IMX95_PAD_UART2_TXD__AONMIX_TOP_LPUART2_TX 0x31e>, /* Aquila D22 */
+ <IMX95_PAD_UART2_RXD__AONMIX_TOP_LPUART2_RX 0x31e>; /* Aquila D21 */
+ };
+
+ /* Aquila UART_1 */
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO14__LPUART3_TX 0x31e>, /* Aquila B37 */
+ <IMX95_PAD_GPIO_IO15__LPUART3_RX 0x31e>, /* Aquila B35 */
+ <IMX95_PAD_GPIO_IO16__LPUART3_CTS_B 0x31e>, /* Aquila B36 */
+ <IMX95_PAD_GPIO_IO17__LPUART3_RTS_B 0x31e>; /* Aquila B38 */
+ };
+
+ /* Aquila UART_2 */
+ pinctrl_uart7: uart7grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO36__LPUART7_TX 0x31e>, /* Aquila B33 */
+ <IMX95_PAD_GPIO_IO37__LPUART7_RX 0x31e>, /* Aquila B31 */
+ <IMX95_PAD_GPIO_IO10__LPUART7_CTS_B 0x31e>, /* Aquila B32 */
+ <IMX95_PAD_GPIO_IO11__LPUART7_RTS_B 0x31e>; /* Aquila B34 */
+ };
+
+ /* On-module eMMC */
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>, /* eMMC_CLK */
+ <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e>, /* eMMC_CMD */
+ <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e>, /* eMMC_DATA0 */
+ <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e>, /* eMMC_DATA1 */
+ <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e>, /* eMMC_DATA2 */
+ <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e>, /* eMMC_DATA3 */
+ <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e>, /* eMMC_DATA4 */
+ <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e>, /* eMMC_DATA5 */
+ <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e>, /* eMMC_DATA6 */
+ <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e>, /* eMMC_DATA7 */
+ <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e>; /* eMMC_STROBE */
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x15fe>, /* eMMC_CLK */
+ <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x13fe>, /* eMMC_CMD */
+ <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x13fe>, /* eMMC_DATA0 */
+ <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x13fe>, /* eMMC_DATA1 */
+ <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x13fe>, /* eMMC_DATA2 */
+ <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x13fe>, /* eMMC_DATA3 */
+ <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x13fe>, /* eMMC_DATA4 */
+ <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x13fe>, /* eMMC_DATA5 */
+ <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x13fe>, /* eMMC_DATA6 */
+ <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x13fe>, /* eMMC_DATA7 */
+ <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe>; /* eMMC_STROBE */
+ };
+
+ /* Aquila SD_1 */
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x158e>, /* Aquila A5 */
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x138e>, /* Aquila A7 */
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e>, /* Aquila A3 */
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e>, /* Aquila A2 */
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e>, /* Aquila A10 */
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e>; /* Aquila A8 */
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x15fe>, /* Aquila A5 */
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x13fe>, /* Aquila A7 */
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x13fe>, /* Aquila A3 */
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x13fe>, /* Aquila A2 */
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x13fe>, /* Aquila A10 */
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x13fe>; /* Aquila A8 */
+ };
+
+ pinctrl_usdhc2_sleep: usdhc2-sleepgrp {
+ fsl,pins = <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x400>, /* Aquila A5 */
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x400>, /* Aquila A7 */
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x400>, /* Aquila A3 */
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x400>, /* Aquila A2 */
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x400>, /* Aquila A10 */
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x400>; /* Aquila A8 */
+ };
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/3] arm64: dts: freescale: imx95-aquila: Add Clover carrier board
From: Franz Schnyder @ 2026-05-21 17:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, Antoine Gouby
In-Reply-To: <20260521-add-aquila-imx95-v4-0-5a7f86c824f5@toradex.com>
From: Antoine Gouby <antoine.gouby@toradex.com>
Add support for the Aquila i.MX95 SoM mated with the Clover carrier
board. Clover is a low-cost carrier board for the Aquila family
featuring a small form factor (Nano-ITX 120mm x 120mm) and built for
volume production.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/clover
Signed-off-by: Antoine Gouby <antoine.gouby@toradex.com>
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v4: Removed som_dsi2dp_bridge node since SoC's DSI controller is unsupported
v3: Deleted the cdns,* properties from flexspi1
v2: no changes
v1: https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-3-69c8ee1c5413@toradex.com/
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx95-aquila-clover.dts | 285 +++++++++++++++++++++
2 files changed, 286 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index c8697b6ae01c5..3ce082c121036 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -523,6 +523,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-clover.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-aquila-clover.dts b/arch/arm64/boot/dts/freescale/imx95-aquila-clover.dts
new file mode 100644
index 0000000000000..fd93043314466
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-aquila-clover.dts
@@ -0,0 +1,285 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
+ * https://www.toradex.com/products/carrier-board/clover
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/usb/pd.h>
+#include "imx95-aquila.dtsi"
+
+/ {
+ model = "Aquila iMX95 on Aquila Clover Board";
+ compatible = "toradex,aquila-imx95-clover",
+ "toradex,aquila-imx95",
+ "fsl,imx95";
+
+ aliases {
+ eeprom1 = &carrier_eeprom;
+ };
+
+ dp_1_connector: dp0-connector {
+ compatible = "dp-connector";
+ dp-pwr-supply = <®_dp_3p3v>;
+ type = "full-size";
+
+ port {
+ dp_1_connector_in: endpoint {
+ remote-endpoint = <&dsi2dp_out>;
+ };
+ };
+ };
+
+ reg_dp_3p3v: regulator-dp-3p3v {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_21_dp>;
+ /* Aquila GPIO_21_DP */
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "DP_3V3";
+ startup-delay-us = <10000>;
+ };
+};
+
+/* Aquila ADC_[1-4] */
+&adc1 {
+ status = "okay";
+};
+
+/* Aquila CTRL_WAKE1_MICO# */
+&aquila_key_wake {
+ status = "okay";
+};
+
+&dsi2dp_out {
+ remote-endpoint = <&dp_1_connector_in>;
+};
+
+/* Aquila ETH_1 */
+&enetc_port0 {
+ status = "okay";
+};
+
+/* Aquila CAN_1 */
+&flexcan1 {
+ status = "okay";
+};
+
+/* Aquila CAN_2 */
+&flexcan2 {
+ status = "okay";
+};
+
+/* Aquila CAN_3 */
+&flexcan3 {
+ status = "okay";
+};
+
+/* Aquila CAN_4 */
+&flexcan4 {
+ status = "okay";
+};
+
+/* Aquila QSPI_1 */
+&flexspi1 {
+ pinctrl-0 = <&pinctrl_flexspi1_4bit>,
+ <&pinctrl_qspi_cs1>;
+
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+ };
+};
+
+&gpio4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_1>,
+ <&pinctrl_gpio_2>,
+ <&pinctrl_gpio_3>,
+ <&pinctrl_gpio_4>;
+};
+
+/* Aquila I2C_2 */
+&i3c2 {
+ status = "okay";
+};
+
+/* Aquila I2C_1 */
+&lpi2c2 {
+ status = "okay";
+
+ fan_controller: fan@18 {
+ compatible = "ti,amc6821";
+ reg = <0x18>;
+ #pwm-cells = <2>;
+
+ fan {
+ cooling-levels = <255>;
+ pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED>;
+ };
+ };
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp1075";
+ reg = <0x4f>;
+ };
+
+ /* USB-C OTG (TCPC USB PD PHY) */
+ tcpc@52 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x52>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+
+ connector {
+ compatible = "usb-c-connector";
+ data-role = "dual";
+ op-sink-microwatt = <0>;
+ power-role = "dual";
+ self-powered;
+ sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "sink";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec_con_hs: endpoint {
+ remote-endpoint = <&usb1_con_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ typec_con_ss: endpoint {
+ remote-endpoint = <&usb1_con_ss>;
+ };
+ };
+ };
+ };
+ };
+
+ carrier_eeprom: eeprom@57 {
+ compatible = "st,24c02", "atmel,24c02";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+};
+
+/* Aquila I2C_6 */
+&lpi2c5 {
+ status = "okay";
+};
+
+/* Aquila SPI_1 */
+&lpspi6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi6 &pinctrl_gpio_5>;
+ cs-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>, <&gpio4 18 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+
+ tpm@1 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_6>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+ spi-max-frequency = <12000000>;
+ };
+};
+
+/* Aquila UART_3, used as the Linux Console */
+&lpuart1 {
+ status = "okay";
+};
+
+/* Aquila UART_4 */
+&lpuart2 {
+ status = "okay";
+};
+
+/* Aquila UART_1 */
+&lpuart3 {
+ status = "okay";
+};
+
+/* Aquila UART_2 */
+&lpuart7 {
+ status = "okay";
+};
+
+/* Aquila PCIE_1 */
+&pcie0 {
+ status = "okay";
+};
+
+/* Aquila PWM_1 */
+&tpm3 {
+ status = "okay";
+};
+
+/* Aquila PWM_3_DSI and PWM_4_DP */
+&tpm5 {
+ status = "okay";
+};
+
+/* Aquila PWM_2 */
+&tpm6 {
+ status = "okay";
+};
+
+/* Aquila USB_2, optional Bluetooth USB */
+&usb2 {
+ status = "okay";
+};
+
+/* Aquila USB_1 */
+&usb3 {
+ status = "okay";
+};
+
+&usb3_dwc3 {
+ status = "okay";
+
+ port {
+ usb1_con_hs: endpoint {
+ remote-endpoint = <&typec_con_hs>;
+ };
+ };
+};
+
+&usb3_phy {
+ orientation-switch;
+
+ status = "okay";
+
+ port {
+ usb1_con_ss: endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+};
+
+/* Aquila SD_1 */
+&usdhc2 {
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox