* Re: [PATCH v10 16/20] coresight: Add PM callbacks for sink device
From: James Clark @ 2026-04-09 12:54 UTC (permalink / raw)
To: Leo Yan
Cc: coresight, linux-arm-kernel, Yeoreum Yun, Mark Rutland,
Will Deacon, Yabin Cui, Keita Morisaki, Yuanfang Zhang,
Greg Kroah-Hartman, Alexander Shishkin, Tamas Petz,
Thomas Gleixner, Peter Zijlstra, Suzuki K Poulose, Mike Leach
In-Reply-To: <e7c6f497-f8f0-409b-b80a-a064b222c08d@linaro.org>
On 09/04/2026 11:52 am, James Clark wrote:
>
>
> On 05/04/2026 4:02 pm, Leo Yan wrote:
>> Unlike system level sinks, per-CPU sinks may lose power during CPU idle
>> states. Currently, this applies specifically to TRBE. This commit
>> invokes save and restore callbacks for the sink in the CPU PM notifier.
>>
>> If the sink provides PM callbacks but the source does not, this is
>> unsafe because the sink cannot be disabled safely unless the source
>> can also be controlled, so veto low power entry to avoid lockups.
>>
>> Tested-by: James Clark <james.clark@linaro.org>
>> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
>> Reviewed-by: James Clark <james.clark@linaro.org>
>> Signed-off-by: Leo Yan <leo.yan@arm.com>
>> ---
>> drivers/hwtracing/coresight/coresight-core.c | 46 ++++++++++++++++++
>> ++++++++--
>> 1 file changed, 43 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/
>> hwtracing/coresight/coresight-core.c
>> index
>> c1e8debc76aba7eb5ecf7efe2a3b9b8b3e11b10c..a918bf6398a932de30fe9b4947020cc4c1cfb2f7 100644
>> --- a/drivers/hwtracing/coresight/coresight-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>> @@ -1736,14 +1736,15 @@ static void coresight_release_device_list(void)
>> /* Return: 1 if PM is required, 0 if skip, <0 on error */
>> static int coresight_pm_check(struct coresight_path *path)
>> {
>> - struct coresight_device *source;
>> - bool source_has_cb;
>> + struct coresight_device *source, *sink;
>> + bool source_has_cb, sink_has_cb;
>> if (!path)
>> return 0;
>> source = coresight_get_source(path);
>> - if (!source)
>> + sink = coresight_get_sink(path);
>> + if (!source || !sink)
>> return 0;
>> /* Don't save and restore if the source is inactive */
>> @@ -1759,16 +1760,36 @@ static int coresight_pm_check(struct
>> coresight_path *path)
>> if (source_has_cb)
>> return 1;
>> + sink_has_cb = coresight_ops(sink)->pm_save_disable &&
>> + coresight_ops(sink)->pm_restore_enable;
>> + /*
>> + * It is not permitted that the source has no callbacks while the
>> sink
>> + * does, as the sink cannot be disabled without disabling the
>> source,
>> + * which may lead to lockups. Alternatively, the ETM driver should
>> + * enable self-hosted PM mode at probe (see etm4_probe()).
>> + */
>> + if (sink_has_cb) {
>> + pr_warn_once("coresight PM failed: source has no PM callbacks; "
>> + "cannot safely control sink\n");
>
> This prints out on my Orion board on a fresh boot because of how
> pm_save_enable is setup there. Do we really need the configuration of
> pm_save_enable for ETE/TRBE if we know that it always needs saving?
>
> It also stops warning if I rmmod and modprobe the module after booting.
> Seems like pm_save_enable is different depending on how the module is
> loaded which doesn't seem right.
>
>> + return -EINVAL;
>> + }
>> +
>> return 0;
>> }
>> static int coresight_pm_device_save(struct coresight_device *csdev)
>> {
>> + if (!csdev || !coresight_ops(csdev)->pm_save_disable)
>> + return 0;
>> +
>> return coresight_ops(csdev)->pm_save_disable(csdev);
>> }
>> static void coresight_pm_device_restore(struct coresight_device *csdev)
>> {
>> + if (!csdev || !coresight_ops(csdev)->pm_restore_enable)
>> + return;
>> +
>> coresight_ops(csdev)->pm_restore_enable(csdev);
>> }
>> @@ -1787,15 +1808,32 @@ static int coresight_pm_save(struct
>> coresight_path *path)
>> to = list_prev_entry(coresight_path_last_node(path), link);
>> coresight_disable_path_from_to(path, from, to);
>> + ret = coresight_pm_device_save(coresight_get_sink(path));
>> + if (ret)
>> + goto sink_failed;
>> +
>
> The comment directly above this says "Up to the node before sink to
> avoid latency". But then this line goes and saves the sink anyway. So
> I'm not sure what's meant by the comment?
>
>> return 0;
>> +
>> +sink_failed:
>> + if (!coresight_enable_path_from_to(path, coresight_get_mode(source),
>> + from, to))
>> + coresight_pm_device_restore(source);
>> +
>> + pr_err("Failed in coresight PM save on CPU%d: %d\n",
>> + smp_processor_id(), ret);
>> + this_cpu_write(percpu_pm_failed, true);
>
> Why does only a failing sink set percpu_pm_failed when failing to save
> the source exits early. Sashiko has a similar comment that this could
> result in restoring uninitialised source save data later, but a comment
> in this function about why the flow is like this would be helpful.
>
> We have coresight_disable_path_from_to() which always succeeds and
> doesn't return an error. TRBE is the only sink with a pm_save_disable()
> callback, but it always succeeds anyway.
>
> Would it not be much simpler to require that sink save/restore callbacks
> always succeed and don't return anything? Seems like this
> percpu_pm_failed stuff is extra complexity for a scenario that doesn't
> exist? The only thing that can fail is saving the source but it doesn't
> goto sink_failed when that happens.
>
> Ideally etm4_cpu_save() wouldn't have a return value either. It would be
> good if we could find away to skip or ignore the timeouts in there
> somehow because that's the only reason it can fail.
>
etm4_disable_trace_unit() and etm4_enable_hw() also have timeouts but
the timeouts only print warnings, they don't cause early exits or return
error values.
Can we do the same for etm4_cpu_save()? It would be better to read and
restore potentially 'unstable' register values than to early exit and
restore known uninitialised values as it is here.
>> + return ret;
>> }
>> static void coresight_pm_restore(struct coresight_path *path)
>> {
>> struct coresight_device *source = coresight_get_source(path);
>> + struct coresight_device *sink = coresight_get_sink(path);
>> struct coresight_node *from, *to;
>> int ret;
>> + coresight_pm_device_restore(sink);
>> +
>> from = coresight_path_first_node(path);
>> /* Up to the node before sink to avoid latency */
>> to = list_prev_entry(coresight_path_last_node(path), link);
>> @@ -1808,6 +1846,8 @@ static void coresight_pm_restore(struct
>> coresight_path *path)
>> return;
>> path_failed:
>> + coresight_pm_device_save(sink);
>> +
>> pr_err("Failed in coresight PM restore on CPU%d: %d\n",
>> smp_processor_id(), ret);
>>
>
^ permalink raw reply
* Re: [PATCH 1/2] KVM: arm64: Factor out TG0/1 decoding of VTCR and TCR
From: Wei-Lin Chang @ 2026-04-09 12:54 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, kvmarm, linux-kernel, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <87y0izb5o6.wl-maz@kernel.org>
On Tue, Apr 07, 2026 at 08:17:29AM +0100, Marc Zyngier wrote:
> On Mon, 06 Apr 2026 17:46:17 +0100,
> Wei-Lin Chang <weilin.chang@arm.com> wrote:
> >
> > The current code decodes TCR.TG0/TG1 and VTCR.TG0 inline at several
> > places. Extract this logic into helpers so the granule size is derived
> > in one place. This enables us to alter the effective granule size in
> > the same place, which we will need in a later patch.
> >
> > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > ---
> > arch/arm64/kvm/at.c | 73 +++++++++++++++++++++++++----------------
> > arch/arm64/kvm/nested.c | 70 ++++++++++++++++++++++++---------------
> > 2 files changed, 89 insertions(+), 54 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
> > index c5c5644b1878..ff8ba30e917b 100644
> > --- a/arch/arm64/kvm/at.c
> > +++ b/arch/arm64/kvm/at.c
> > @@ -135,14 +135,54 @@ static void compute_s1poe(struct kvm_vcpu *vcpu, struct s1_walk_info *wi)
> > wi->e0poe = (wi->regime != TR_EL2) && (val & TCR2_EL1_E0POE);
> > }
> >
> > +static unsigned int tg0_to_shift(u64 tg0)
> > +{
>
> It'd be better to abstract these helpers a bit more by making them
> take the full TCR_ELx value, and to give them a slightly better name.
>
> I'd suggest something like:
>
> static unsigned int tcr_to_tg0_pgshift(u64 tcr)
> {
> u64 tg0 = tcr & TCR_TG0_MASK, tcr;
>
> which makes it clear that the result is a page shift, as required by
> wi->pgshift.
Makes sense, I'll change it.
>
> > + switch (tg0) {
> > + case TCR_EL1_TG0_4K:
> > + return 12;
> > + case TCR_EL1_TG0_16K:
> > + return 14;
> > + case TCR_EL1_TG0_64K:
>
> Please don't mix the _EL1 definition and those without _EL1 in the
> same file. For a start, that's not always EL1. Also, this makes very
> hard to reason about what is shifted and what is not.
Thanks for pointing this out, will fix.
>
> > + default: /* IMPDEF: treat any other value as 64k */
> > + return 16;
> > + }
> > +}
> > +
> > +static unsigned int tg1_to_shift(u64 tg1)
> > +{
> > + switch (tg1) {
> > + case TCR_EL1_TG1_4K:
> > + return 12;
> > + case TCR_EL1_TG1_16K:
> > + return 14;
> > + case TCR_EL1_TG1_64K:
> > + default: /* IMPDEF: treat any other value as 64k */
> > + return 16;
> > + }
> > +}
> > +
> > +static u64 tcr_tg_shift(struct kvm *kvm, u64 tcr, bool upper_range)
> > +{
> > + unsigned int shift;
> > +
> > + /* Someone was silly enough to encode TG0/TG1 differently */
> > + if (upper_range)
> > + shift = tg1_to_shift(FIELD_GET(TCR_EL1_TG1_MASK, tcr));
> > + else
> > + shift = tg0_to_shift(FIELD_GET(TCR_EL1_TG0_MASK, tcr));
> > +
> > + return shift;
> > +}
> > +
> > static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
> > struct s1_walk_result *wr, u64 va)
> > {
> > - u64 hcr, sctlr, tcr, tg, ps, ia_bits, ttbr;
> > + u64 hcr, sctlr, tcr, ps, ia_bits, ttbr;
> > unsigned int stride, x;
> > - bool va55, tbi, lva;
> > + bool va55, tbi, lva, upper_range;
> >
> > va55 = va & BIT(55);
> > + upper_range = va55 && wi->regime != TR_EL2;
> >
> > if (vcpu_has_nv(vcpu)) {
> > hcr = __vcpu_sys_reg(vcpu, HCR_EL2);
> > @@ -173,35 +213,12 @@ static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
> > BUG();
> > }
> >
> > - /* Someone was silly enough to encode TG0/TG1 differently */
> > - if (va55 && wi->regime != TR_EL2) {
> > + if (upper_range)
> > wi->txsz = FIELD_GET(TCR_T1SZ_MASK, tcr);
> > - tg = FIELD_GET(TCR_TG1_MASK, tcr);
> > -
> > - switch (tg << TCR_TG1_SHIFT) {
> > - case TCR_TG1_4K:
> > - wi->pgshift = 12; break;
> > - case TCR_TG1_16K:
> > - wi->pgshift = 14; break;
> > - case TCR_TG1_64K:
> > - default: /* IMPDEF: treat any other value as 64k */
> > - wi->pgshift = 16; break;
> > - }
> > - } else {
> > + else
> > wi->txsz = FIELD_GET(TCR_T0SZ_MASK, tcr);
> > - tg = FIELD_GET(TCR_TG0_MASK, tcr);
> > -
> > - switch (tg << TCR_TG0_SHIFT) {
> > - case TCR_TG0_4K:
> > - wi->pgshift = 12; break;
> > - case TCR_TG0_16K:
> > - wi->pgshift = 14; break;
> > - case TCR_TG0_64K:
> > - default: /* IMPDEF: treat any other value as 64k */
> > - wi->pgshift = 16; break;
> > - }
> > - }
> >
> > + wi->pgshift = tcr_tg_shift(vcpu->kvm, tcr, upper_range);
> > wi->pa52bit = has_52bit_pa(vcpu, wi, tcr);
> >
> > ia_bits = get_ia_size(wi);
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > index 883b6c1008fb..2bfab3007cb3 100644
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> > @@ -378,20 +378,36 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
> > return 0;
> > }
> >
> > -static void vtcr_to_walk_info(u64 vtcr, struct s2_walk_info *wi)
> > +static unsigned int tg0_to_shift(u64 tg0)
>
> Same comments as above.
Ack.
>
> > +{
> > + switch (tg0) {
> > + case VTCR_EL2_TG0_4K:
> > + return 12;
> > + case VTCR_EL2_TG0_16K:
> > + return 14;
> > + case VTCR_EL2_TG0_64K:
> > + default: /* IMPDEF: treat any other value as 64k */
> > + return 16;
> > + }
> > +}
> > +
> > +static u64 vtcr_tg0_shift(struct kvm *kvm, u64 vtcr)
> > +{
> > + u64 tg0 = FIELD_GET(VTCR_EL2_TG0_MASK, vtcr);
> > + unsigned int shift = tg0_to_shift(tg0);
> > +
> > + return shift;
>
> shift is an unsigned int. Why is the return value a u64? Try and make
> sure that types are consistent, even if they cast nicely in C.
This is an error from me, I'll fix this.
>
> > +}
> > +
> > +static size_t vtcr_tg0_size(struct kvm *kvm, u64 vtcr)
> > +{
> > + return BIT(vtcr_tg0_shift(kvm, vtcr));
> > +}
> > +
> > +static void vtcr_to_walk_info(struct kvm *kvm, u64 vtcr, struct s2_walk_info *wi)
>
> This prototype reads bizarrely. vtcr is per CPU, the walk info is
> evidently per CPU, and yet you pass a kvm struct.
>
> Instead, rename this to:
>
> static void setup_s2_walk(struct kvm_vcpu *vcpu,
> struct s2_walk_info *wi)
> {
> u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
>
> and call that directly. You can then extract vcpu->kvm as needed. It
> also aligns the naming on the s1 part, which isn't a bad thing to do.
Agreed, makes sense.
>
> > {
> > wi->t0sz = vtcr & TCR_EL2_T0SZ_MASK;
> > -
> > - switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
> > - case VTCR_EL2_TG0_4K:
> > - wi->pgshift = 12; break;
> > - case VTCR_EL2_TG0_16K:
> > - wi->pgshift = 14; break;
> > - case VTCR_EL2_TG0_64K:
> > - default: /* IMPDEF: treat any other value as 64k */
> > - wi->pgshift = 16; break;
> > - }
> > -
> > + wi->pgshift = vtcr_tg0_shift(kvm, vtcr);
> > wi->sl = FIELD_GET(VTCR_EL2_SL0_MASK, vtcr);
> > /* Global limit for now, should eventually be per-VM */
> > wi->max_oa_bits = min(get_kvm_ipa_limit(),
> > @@ -414,7 +430,7 @@ int kvm_walk_nested_s2(struct kvm_vcpu *vcpu, phys_addr_t gipa,
> >
> > wi.baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
> >
> > - vtcr_to_walk_info(vtcr, &wi);
> > + vtcr_to_walk_info(vcpu->kvm, vtcr, &wi);
> >
> > wi.be = vcpu_read_sys_reg(vcpu, SCTLR_EL2) & SCTLR_ELx_EE;
> >
> > @@ -515,17 +531,19 @@ static u8 get_guest_mapping_ttl(struct kvm_s2_mmu *mmu, u64 addr)
> > u64 tmp, sz = 0, vtcr = mmu->tlb_vtcr;
> > kvm_pte_t pte;
> > u8 ttl, level;
> > + struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> > + size_t tg0_size = vtcr_tg0_size(kvm, vtcr);
> >
> > - lockdep_assert_held_write(&kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
> > + lockdep_assert_held_write(&kvm->mmu_lock);
> >
> > - switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
> > - case VTCR_EL2_TG0_4K:
> > + switch (tg0_size) {
> > + case SZ_4K:
> > ttl = (TLBI_TTL_TG_4K << 2);
> > break;
> > - case VTCR_EL2_TG0_16K:
> > + case SZ_16K:
> > ttl = (TLBI_TTL_TG_16K << 2);
> > break;
> > - case VTCR_EL2_TG0_64K:
> > + case SZ_64K:
>
> All these unit changes make the patch harder to read than it should
> be. Consider having a separate patch to do that.
Understood, sure.
Thanks for the feedback!
Wei-Lin Chang
>
> Thanks,
>
> M.
>
> --
> Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Andrew Lunn @ 2026-04-09 12:46 UTC (permalink / raw)
To: Josua Mayer
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Yazan Shhady, Mikhail Anikin, Alexander Dahl,
devicetree, linux-kernel, imx, linux-arm-kernel, Vladimir Oltean,
Conor Dooley, Krzysztof Kozlowski, netdev
In-Reply-To: <20260409-imx8dxl-sr-som-v2-3-83ff20629ba0@solid-run.com>
> +&eqos {
> + /* delays are added by connected ethernet-switch cpu port */
> + phy-mode = "rgmii";
> + pinctrl-0 = <&eqos_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + fixed-link {
> + full-duplex;
> + speed = <1000>;
> + };
> +};
> + ethernet-switch@0 {
> + compatible = "nxp,sja1110a";
> + reg = <0>;
> + reset-gpios = <&lsio_gpio4 3 GPIO_ACTIVE_LOW>;
> + spi-max-frequency = <4000000>;
> +
> + ethernet-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* 100Base-TX on connector J26 */
> + port@1 {
> + reg = <0x1>;
> + label = "lan1";
> + phy-handle = <&switch_port1_base_tx_phy>;
> + phy-mode = "internal";
> + status = "okay";
> + };
> +
> + /* CPU */
> + port@2 {
> + reg = <0x2>;
> + ethernet = <&eqos>;
> + label = "cpu";
> + phy-mode = "rgmii-id";
> + rx-internal-delay-ps = <2000>;
> + tx-internal-delay-ps = <2000>;
> + status = "okay";
> +
> + fixed-link {
> + full-duplex;
> + speed = <1000>;
> + };
> + };
> +
> + /* sgmii on addon board connector J21 */
> + port@3 {
> + reg = <0x3>;
> + label = "lan3";
> + status = "disabled";
> + };
> +
> + /* sgmii on addon board connector J21 */
> + port@4 {
> + reg = <0x4>;
> + label = "lan4";
> + status = "disabled";
> + };
> +
> + /* 100base-t1 on addon board connector J21 */
> + port@5 {
> + reg = <0x5>;
> + label = "trx1";
> + phy-handle = <&switch_port5_base_t1_phy>;
> + phy-mode = "internal";
> + status = "disabled";
> + };
> +
> + /* 100base-t1 on addon board connector J21 */
> + port@6 {
> + reg = <0x6>;
> + label = "trx2";
> + phy-handle = <&switch_port6_base_t1_phy>;
> + phy-mode = "internal";
> + status = "disabled";
> + };
> +
> + /* 100base-t1 on addon board connector J21 */
> + port@7 {
> + reg = <0x7>;
> + label = "trx3";
> + phy-handle = <&switch_port7_base_t1_phy>;
> + phy-mode = "internal";
> + status = "disabled";
> + };
> +
> + /* 100base-t1 on addon board connector J21 */
> + port@8 {
> + reg = <0x8>;
> + label = "trx4";
> + phy-handle = <&switch_port8_base_t1_phy>;
> + phy-mode = "internal";
> + status = "disabled";
> + };
> +
> + /* 100base-t1 on addon board connector J21 */
> + port@9 {
> + reg = <0x9>;
> + label = "trx5";
> + phy-handle = <&switch_port9_base_t1_phy>;
> + phy-mode = "internal";
> + status = "disabled";
> + };
> +
> + /* 100Base-T1 on connector J26 */
> + port@a {
> + reg = <0xa>;
> + label = "trx6";
> + phy-handle = <&switch_port10_base_t1_phy>;
> + phy-mode = "internal";
> + status = "okay";
> + };
> + };
> +
> + mdios {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mdio@0 {
> + compatible = "nxp,sja1110-base-t1-mdio";
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* 100base-t1 on addon board connector J21 */
> + switch_port5_base_t1_phy: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c45";
> + reg = <0x1>;
> + status = "disabled";
> + };
> +
> + /* 100base-t1 on addon board connector J21 */
> + switch_port6_base_t1_phy: ethernet-phy@2 {
> + compatible = "ethernet-phy-ieee802.3-c45";
> + reg = <0x2>;
> + status = "disabled";
> + };
> +
> + /* 100base-t1 on addon board connector J21 */
> + switch_port7_base_t1_phy: ethernet-phy@3 {
> + compatible = "ethernet-phy-ieee802.3-c45";
> + reg = <0x3>;
> + status = "disabled";
> + };
> +
> + /* 100base-t1 on addon board connector J21 */
> + switch_port8_base_t1_phy: ethernet-phy@4 {
> + compatible = "ethernet-phy-ieee802.3-c45";
> + reg = <0x4>;
> + status = "disabled";
> + };
> +
> + /* 100base-t1 on addon board connector J21 */
> + switch_port9_base_t1_phy: ethernet-phy@5 {
> + compatible = "ethernet-phy-ieee802.3-c45";
> + reg = <0x5>;
> + status = "disabled";
> + };
> +
> + /* 100Base-T1 on connector J26 */
> + switch_port10_base_t1_phy: ethernet-phy@6 {
> + compatible = "ethernet-phy-ieee802.3-c45";
> + reg = <0x6>;
> + };
> + };
> +
> + mdio@1 {
> + compatible = "nxp,sja1110-base-tx-mdio";
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* 100Base-TX on connector J26 */
> + switch_port1_base_tx_phy: ethernet-phy@1 {
> + reg = <0x1>;
> + };
> + };
For these nodes only:
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
From: Peng Fan @ 2026-04-09 12:45 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland, linux-arm-kernel,
iommu, devicetree, linux-kernel, linux-perf-users, Peng Fan
In-Reply-To: <20260409-outstanding-arboreal-peacock-2de6f1@quoll>
On Thu, Apr 09, 2026 at 10:10:38AM +0200, Krzysztof Kozlowski wrote:
>On Wed, Apr 08, 2026 at 03:51:15PM +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@nxp.com>
>>
>> The Arm SMMU v3 specification defines an optional PMCG (Performance
>
>"optional" in a meaning some SMMUv3 implementations do not have it?
Per SMMUv3 architecture:
Performance monitoring facilities are optional. When implemented, the SMMU has
one or more Performance Monitor Counter Groups (PMCG) associated with it.
>
>> Monitor Control Group) block. Per MMU-700 TRM, it has three 64KB pages,
>> with TCU Performance Monitor Counter Group (PMCG) registers starting at
>> offset 0x02000 in page 0. So PMCG could be described as a child node of the
>> SMMU in Devicetree.
>>
>> Add a patternProperties entry to the arm,smmu-v3 binding to allow child
>> nodes matching "pmu@<addr>" and reference the existing
>> arm,smmu-v3-pmcg.yaml schema.
>>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> ---
>> Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
>> index 82957334bea24402b583e47eb61b5724c91e4378..1d09c5476e5f1a7c3e5c935b677641ee6cc9897e 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
>> @@ -50,6 +50,10 @@ properties:
>> - cmdq-sync # CMD_SYNC complete
>> - priq # PRI Queue not empty
>>
>> + '#address-cells': true
>
>Instead enum [1, 2]
>
>> + '#size-cells': true
>
>Same here
>
>> + ranges: true
>
>I guess only one mapping is allowed so:
>maxItems: 1
Accept above three comments.
>
>> +
>> '#iommu-cells':
>> const: 1
>>
>> @@ -83,6 +87,12 @@ properties:
>> register access with page 0 offsets. Set for Cavium ThunderX2 silicon that
>> doesn't support SMMU page1 register space.
>>
>> +patternProperties:
>> + '^pmu@[0-9a-f]+$':
>> + type: object
>> + $ref: /schemas/perf/arm,smmu-v3-pmcg.yaml#
>> + unevaluatedProperties: false
>
>Please add another example with 4-space indentation.
ok.
Thanks,
Peng
>
>> +
>> allOf:
>> - if:
>> not:
>>
>> --
>> 2.37.1
>>
>
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Josua Mayer @ 2026-04-09 12:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel, Vladimir Oltean,
Conor Dooley, Krzysztof Kozlowski, netdev, Josua Mayer
In-Reply-To: <20260409-imx8dxl-sr-som-v2-0-83ff20629ba0@solid-run.com>
Add support for the SolidRun i.MX8DXL System-on-Module (revision 2.1)
and its corresponding evaluation carrier board, the HummingBoard
Telematics (revision 2.0).
The SoM features:
- eMMC
- GNSS with 1PPS
- V2X DSRC Radio
- Secure Element for V2X Applications
- Inertial Sensor
- Pressure Sensor
- Compass
The HummingBoard Telematics carrier board features:
- Cellular Modem
- WiFi & Bluetooth
- RTC with backup battery
- CAN
- 100Base-TX Ethernet
- 100Base-T1 Ethernet
- Multi-interface I/O connector
- Multi-interface add-on board connector
The multi-interface I/O connector supplies power and provides basic I/O
(Console UART, 100Base-TX, 100Base-T1, CAN, and power-supply logic level
GPIOs). The SolidRun Evaluation Kit includes a suitable cable and
adapter board that breaks these out into RJ45, USB Type-A, microUSB
Console, and Terminal Block connectors.
The multi-interface add-on board connector provides additional
interfaces (4x 100Base-T1, 2x SGMII, USB 2.0 shared with the cellular
modem, CAN, MDIO, SPI, UART, PCIe, I2C, and GPIO). These add-on
interfaces are disabled by default in the base device tree and are
intended to be enabled and extended via device tree overlays.
Note that a few components physically present on the SoM were omitted
from this description due to a lack of upstream bindings and drivers:
- Pressure Sensor
- V2X DSRC Radio
- Secure Element
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../freescale/imx8dxl-hummingboard-telematics.dts | 536 +++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi | 458 ++++++++++++++++++
3 files changed, 996 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 700bab4d3e600..12b946c08400b 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -111,6 +111,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx8dxl-evk.dtb
imx8dxl-evk-pcie-ep-dtbs += imx8dxl-evk.dtb imx-pcie0-ep.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8dxl-evk-pcie-ep.dtb
+DTC_FLAGS_imx8dxl-hummingboard-telematics := -@
+dtb-$(CONFIG_ARCH_MXC) += imx8dxl-hummingboard-telematics.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8dxp-tqma8xdp-mba8xx.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8dxp-tqma8xdps-mb-smarc-2.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts b/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts
new file mode 100644
index 0000000000000..ae23eade64244
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts
@@ -0,0 +1,536 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022-2026 Josua Mayer <josua@solid-run.com>
+ */
+
+/dts-v1/;
+
+#include "imx8dxl-sr-som.dtsi"
+
+/ {
+ compatible = "solidrun,imx8dxl-hummingboard-telematics",
+ "solidrun,imx8dxl-sr-som", "fsl,imx8dxl";
+ model = "SolidRun i.MX8DXL HummingBoard Telematics";
+
+ aliases {
+ /* override ethernat aliases from imx8dxl.dtsi */
+ ethernet0 = &eqos;
+ /delete-property/ ethernet1;
+ gpio8 = &tca6408_u2;
+ mmc2 = &usdhc3;
+ rtc0 = &carrier_rtc;
+ rtc1 = &rtc;
+ serial1 = &lpuart1;
+ };
+
+ v_1_1: regulator-1-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v1";
+ pinctrl-0 = <®ulator_1v1_pins>;
+ pinctrl-names = "default";
+ regulator-always-on;
+ regulator-max-microvolt = <1100000>;
+ regulator-min-microvolt = <1100000>;
+ vin-supply = <&v_5_0>;
+ gpio = <&lsio_gpio4 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_5_0: regulator-5-0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ };
+
+ /* can transceiver builtin regulator (STBN1 pin) */
+ reg_flexcan1_stby: regulator-flexcan1-standby {
+ compatible = "regulator-fixed";
+ regulator-name = "flexcan1-standby";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&tca6408_u2 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ /* can transceiver builtin regulator (STBN2 pin) */
+ reg_flexcan2_stby: regulator-flexcan2-standby {
+ compatible = "regulator-fixed";
+ regulator-name = "flexcan2-standby";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&tca6408_u2 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ modem_vbat: regulator-modem-vbat {
+ compatible = "regulator-fixed";
+ regulator-name = "vbat";
+ pinctrl-0 = <®ulator_modem_vbat_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <3600000>;
+ regulator-min-microvolt = <3600000>;
+ vin-supply = <&v_5_0>;
+ gpio = <&lsio_gpio0 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vbus1: regulator-vbus-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vbus1";
+ pinctrl-0 = <®ulator_usb1_vbus_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ gpio = <&lsio_gpio0 16 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ usdhc3_pwrseq: usdhc3-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&lsio_gpio0 15 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&dma_apbh {
+ status = "disabled";
+};
+
+&eqos {
+ /* delays are added by connected ethernet-switch cpu port */
+ phy-mode = "rgmii";
+ pinctrl-0 = <&eqos_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ fixed-link {
+ full-duplex;
+ speed = <1000>;
+ };
+};
+
+&flexcan1 {
+ pinctrl-0 = <&flexcan1_pins>;
+ pinctrl-names = "default";
+ xceiver-supply = <®_flexcan1_stby>;
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <5000000>;
+ };
+};
+
+&flexcan2 {
+ pinctrl-0 = <&flexcan2_pins>;
+ pinctrl-names = "default";
+ xceiver-supply = <®_flexcan2_stby>;
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <5000000>;
+ };
+};
+
+&i2c2 {
+ /* routed to J14: SDA(51), SCL(53) */
+
+ /* regulator@18 */
+
+ tca6408_u2: gpio@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-line-names = "DIG_IN1", "DIG_IN2", "CAN_STNB1", "CAN_STNB2",
+ "DIG_OUT1", "DIG_OUT2", "", "";
+ interrupts-extended = <&lsio_gpio0 20 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-0 = <&tca6408_u2_int_pins>;
+ pinctrl-names = "default";
+ };
+
+ carrier_rtc: rtc@32 {
+ compatible = "epson,rx8111";
+ reg = <0x32>;
+ };
+};
+
+&iomuxc {
+ bluetooth_pins: pinctrl-bluetooth-grp {
+ fsl,pins = <
+ /* BT_REG_ON: io without pull (module integrates pd) */
+ IMX8DXL_SPI3_SCK_LSIO_GPIO0_IO13 0x0000061
+ >;
+ };
+
+ eqos_pins: pinctrl-eqos-grp {
+ fsl,pins = <
+ /* MDIO to Switch */
+ /* enet0 mdio pads supplied with 3.3v */
+ /* IMX8DXL_COMP_CTL_GPIO_1V8_3V3_GPIOCT */
+ IMX8DXL_ENET0_MDC_CONN_EQOS_MDC 0x06000020
+ IMX8DXL_ENET0_MDIO_CONN_EQOS_MDIO 0x06000020
+ /* RGMII to Switch */
+ IMX8DXL_ENET1_RGMII_TX_CTL_CONN_EQOS_RGMII_TX_CTL 0x06000020
+ IMX8DXL_ENET1_RGMII_TXC_CONN_EQOS_RGMII_TXC 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD0_CONN_EQOS_RGMII_TXD0 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD1_CONN_EQOS_RGMII_TXD1 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD2_CONN_EQOS_RGMII_TXD2 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD3_CONN_EQOS_RGMII_TXD3 0x06000020
+ IMX8DXL_ENET1_RGMII_RXC_CONN_EQOS_RGMII_RXC 0x06000020
+ IMX8DXL_ENET1_RGMII_RX_CTL_CONN_EQOS_RGMII_RX_CTL 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD0_CONN_EQOS_RGMII_RXD0 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD1_CONN_EQOS_RGMII_RXD1 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD2_CONN_EQOS_RGMII_RXD2 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD3_CONN_EQOS_RGMII_RXD3 0x06000020
+ >;
+ };
+
+ flexcan1_pins: pinctrl-flexcan1-grp {
+ fsl,pins = <
+ IMX8DXL_FLEXCAN0_TX_ADMA_FLEXCAN0_TX 0x00000021
+ IMX8DXL_FLEXCAN0_RX_ADMA_FLEXCAN0_RX 0x00000021
+ >;
+ };
+
+ flexcan2_pins: pinctrl-flexcan2-grp {
+ fsl,pins = <
+ IMX8DXL_FLEXCAN1_TX_ADMA_FLEXCAN1_TX 0x00000021
+ IMX8DXL_FLEXCAN1_RX_ADMA_FLEXCAN1_RX 0x00000021
+ >;
+ };
+
+ lpspi0_pins: pinctrl-lpspi0-grp {
+ fsl,pins = <
+ IMX8DXL_SPI0_SCK_ADMA_SPI0_SCK 0x600004c
+ IMX8DXL_SPI0_SDO_ADMA_SPI0_SDO 0x600004c
+ IMX8DXL_SPI0_SDI_ADMA_SPI0_SDI 0x600004c
+ IMX8DXL_SPI0_CS0_LSIO_GPIO1_IO08 0x0000021
+ IMX8DXL_SPI0_CS1_LSIO_GPIO1_IO07 0x0000021
+ >;
+ };
+
+ lpuart1_pins: pinctrl-lpuart1-grp {
+ fsl,pins = <
+ IMX8DXL_UART1_RX_ADMA_UART1_RX 0x06000020
+ IMX8DXL_UART1_TX_ADMA_UART1_TX 0x06000020
+ IMX8DXL_UART1_CTS_B_ADMA_UART1_CTS_B 0x06000020
+ IMX8DXL_UART1_RTS_B_ADMA_UART1_RTS_B 0x06000020
+ >;
+ };
+
+ modem_pins: pinctrl-lte-grp {
+ fsl,pins = <
+ /* modem RESET_N: io open drain drive 2mA */
+ IMX8DXL_ADC_IN3_LSIO_GPIO1_IO11 0x2000061
+
+ /* modem PWRKEY: io open drain with pull-up, drive 2mA */
+ IMX8DXL_ADC_IN2_LSIO_GPIO1_IO12 0x2000021
+ >;
+ };
+
+ regulator_1v1_pins: pinctrl-regulator-1-1-grp {
+ fsl,pins = <
+ /* SW_PE: io without pull-up */
+ IMX8DXL_USB_SS3_TC2_LSIO_GPIO4_IO05 0x0000061
+ >;
+ };
+
+ regulator_modem_vbat_pins: pinctrl-regulator-modem-vbat-grp {
+ fsl,pins = <
+ /*
+ * RF_PWR: io without pull-up,
+ * has either external pull-up (R1117) or pull-down (R1118).
+ * With pull-up Modem will boot at system power-up,
+ * with pull-down modem will enter power-down mode once
+ * vbat is enabled -> toggle pwrkey to boot modem.
+ * Hence pull-up (R1117) is preferred.
+ */
+ IMX8DXL_SPI3_SDO_LSIO_GPIO0_IO14 0x0000061
+ >;
+ };
+
+ regulator_usb1_vbus_pins: pinctrl-regulator-usb1-vbus-grp {
+ fsl,pins = <
+ /* regulator enable: open-drain with pull-up & low drive strength */
+ IMX8DXL_SPI3_CS0_LSIO_GPIO0_IO16 0x2000021
+ >;
+ };
+
+ switch_pins: pinctrl-switch-grp {
+ fsl,pins = <
+ /* SW_RSTn: io without pull-up */
+ IMX8DXL_USB_SS3_TC0_LSIO_GPIO4_IO03 0x0000021
+
+ /* SW_CORE_RSTn: io without pull-up */
+ IMX8DXL_USB_SS3_TC1_LSIO_GPIO4_IO04 0x0000021
+
+ /* INT_N: io without pull-up */
+ IMX8DXL_USB_SS3_TC3_LSIO_GPIO4_IO06 0x0000021
+ >;
+ };
+
+ tca6408_u2_int_pins: pinctrl-tca6408-u2-int-grp {
+ fsl,pins = <
+ /* gpio-expander interrupt: io with pull-up */
+ IMX8DXL_MCLK_OUT0_LSIO_GPIO0_IO20 0x0000021
+ >;
+ };
+
+ usdhc3_pins: pinctrl-usdhc3-grp {
+ fsl,pins = <
+ IMX8DXL_ENET0_RGMII_TXC_CONN_USDHC2_CLK 0x06000040
+ IMX8DXL_ENET0_RGMII_TX_CTL_CONN_USDHC2_CMD 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD0_CONN_USDHC2_DATA0 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD1_CONN_USDHC2_DATA1 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD2_CONN_USDHC2_DATA2 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD3_CONN_USDHC2_DATA3 0x00000021
+ >;
+ };
+
+ wifi_pins: pinctrl-wifi-grp {
+ fsl,pins = <
+ /* WL_REG_ON: io without pull (module integrates pd) */
+ IMX8DXL_SPI3_SDI_LSIO_GPIO0_IO15 0x0000061
+ >;
+ };
+};
+
+&lpspi0 {
+ cs-gpios = <&lsio_gpio1 8 GPIO_ACTIVE_LOW>, <&lsio_gpio1 7 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&lpspi0_pins>, <&switch_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ ethernet-switch@0 {
+ compatible = "nxp,sja1110a";
+ reg = <0>;
+ reset-gpios = <&lsio_gpio4 3 GPIO_ACTIVE_LOW>;
+ spi-max-frequency = <4000000>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 100Base-TX on connector J26 */
+ port@1 {
+ reg = <0x1>;
+ label = "lan1";
+ phy-handle = <&switch_port1_base_tx_phy>;
+ phy-mode = "internal";
+ status = "okay";
+ };
+
+ /* CPU */
+ port@2 {
+ reg = <0x2>;
+ ethernet = <&eqos>;
+ label = "cpu";
+ phy-mode = "rgmii-id";
+ rx-internal-delay-ps = <2000>;
+ tx-internal-delay-ps = <2000>;
+ status = "okay";
+
+ fixed-link {
+ full-duplex;
+ speed = <1000>;
+ };
+ };
+
+ /* sgmii on addon board connector J21 */
+ port@3 {
+ reg = <0x3>;
+ label = "lan3";
+ status = "disabled";
+ };
+
+ /* sgmii on addon board connector J21 */
+ port@4 {
+ reg = <0x4>;
+ label = "lan4";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ port@5 {
+ reg = <0x5>;
+ label = "trx1";
+ phy-handle = <&switch_port5_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ port@6 {
+ reg = <0x6>;
+ label = "trx2";
+ phy-handle = <&switch_port6_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ port@7 {
+ reg = <0x7>;
+ label = "trx3";
+ phy-handle = <&switch_port7_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ port@8 {
+ reg = <0x8>;
+ label = "trx4";
+ phy-handle = <&switch_port8_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ port@9 {
+ reg = <0x9>;
+ label = "trx5";
+ phy-handle = <&switch_port9_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100Base-T1 on connector J26 */
+ port@a {
+ reg = <0xa>;
+ label = "trx6";
+ phy-handle = <&switch_port10_base_t1_phy>;
+ phy-mode = "internal";
+ status = "okay";
+ };
+ };
+
+ mdios {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio@0 {
+ compatible = "nxp,sja1110-base-t1-mdio";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port5_base_t1_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x1>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port6_base_t1_phy: ethernet-phy@2 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x2>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port7_base_t1_phy: ethernet-phy@3 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x3>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port8_base_t1_phy: ethernet-phy@4 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x4>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port9_base_t1_phy: ethernet-phy@5 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x5>;
+ status = "disabled";
+ };
+
+ /* 100Base-T1 on connector J26 */
+ switch_port10_base_t1_phy: ethernet-phy@6 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x6>;
+ };
+ };
+
+ mdio@1 {
+ compatible = "nxp,sja1110-base-tx-mdio";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 100Base-TX on connector J26 */
+ switch_port1_base_tx_phy: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+ };
+ };
+ };
+};
+
+/* bluetooth */
+&lpuart1 {
+ pinctrl-0 = <&lpuart1_pins>, <&bluetooth_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4345c5";
+ /* Murata 1MW module supports max. 3M baud */
+ max-speed = <3000000>;
+ shutdown-gpios = <&lsio_gpio0 13 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&usbotg1 {
+ vbus-supply = <&vbus1>;
+};
+
+/* cellular modem */
+&usbotg2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adp-disable;
+ disable-over-current;
+ dr_mode = "host";
+ hnp-disable;
+ pinctrl-0 = <&modem_pins>;
+ pinctrl-names = "default";
+ power-active-high;
+ srp-disable;
+ vbus-supply = <&v_5_0>;
+ status = "okay";
+
+ usb-device@1 {
+ compatible = "usb2c7c,125";
+ reg = <1>;
+ reset-duration-us = <150000>;
+ reset-gpios = <&lsio_gpio1 11 GPIO_ACTIVE_LOW>;
+ vbus-supply = <&v_3_3>;
+ vdd-supply = <&modem_vbat>;
+ };
+};
+
+&usbphy2 {
+ status = "okay";
+};
+
+/* WiFi */
+&usdhc3 {
+ bus-width = <4>;
+ mmc-pwrseq = <&usdhc3_pwrseq>;
+ non-removable;
+ no-sd;
+ pinctrl-0 = <&usdhc3_pins>, <&wifi_pins>;
+ pinctrl-names = "default";
+ vmmc-supply = <&v_3_3>;
+ vqmmc-supply = <&v_1_8>;
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi b/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi
new file mode 100644
index 0000000000000..93a0eb4d7f770
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi
@@ -0,0 +1,458 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022-2026 Josua Mayer <josua@solid-run.com>
+ */
+
+#include "imx8dxl.dtsi"
+/ {
+ compatible = "solidrun,imx8dxl-sr-som", "fsl,imx8dxl";
+ model = "SolidRun i.MX8DXL SoM";
+
+ aliases {
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ serial0 = &lpuart0;
+ serial2 = &lpuart2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ imx8dxl-cm4 {
+ compatible = "fsl,imx8qxp-cm4";
+ clocks = <&clk_dummy>;
+ mboxes = <&lsio_mu5 0 1 &lsio_mu5 1 1 &lsio_mu5 3 1>;
+ mbox-names = "tx", "rx", "rxdb";
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
+ power-domains = <&pd IMX_SC_R_M4_0_PID0>, <&pd IMX_SC_R_M4_0_MU_1A>;
+ fsl,entry-address = <0x34fe0000>;
+ fsl,resource-id = <IMX_SC_R_M4_0_PID0>;
+ };
+
+ pps {
+ compatible = "pps-gpio";
+ gpios = <&lsio_gpio2 6 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&gnss_pps_pins>;
+ pinctrl-names = "default";
+ };
+
+ v_1_2: regulator-1-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v2";
+ pinctrl-0 = <®ulator_1_2_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <1200000>;
+ regulator-min-microvolt = <1200000>;
+ gpio = <&lsio_gpio1 13 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_1_6: regulator-1-6 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v6";
+ pinctrl-0 = <®ulator_1_6_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <1600000>;
+ regulator-min-microvolt = <1600000>;
+ vin-supply = <&v_1_8>;
+ gpio = <&lsio_gpio1 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_1_8: regulator-1-8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ v_1_8_se: regulator-1-8-secure-element {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8-se";
+ pinctrl-0 = <®ulator_1_8_se_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ vin-supply = <&v_1_8>;
+ gpio = <&lsio_gpio3 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_3_3: regulator-3-3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+
+ reserved-memory {
+ ranges;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ /* global autoconfigured region for contiguous allocations */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ alloc-ranges = <0 0x98000000 0 0x14000000>;
+ reusable;
+ size = <0 0x14000000>;
+ linux,cma-default;
+ };
+
+ vdev0vring0: memory0@90000000 {
+ reg = <0 0x90000000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: memory@90008000 {
+ reg = <0 0x90008000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring0: memory@90010000 {
+ reg = <0 0x90010000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring1: memory@90018000 {
+ reg = <0 0x90018000 0 0x8000>;
+ no-map;
+ };
+
+ rsc_table: memory-rsc-table@900ff000 {
+ reg = <0 0x900ff000 0 0x1000>;
+ no-map;
+ };
+
+ vdevbuffer: memory-vdevbuffer@90400000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x90400000 0 0x100000>;
+ no-map;
+ };
+
+ /*
+ * Memory reserved for optee usage. Please do not use.
+ * This will be automatically added to dtb if OP-TEE is installed.
+ * optee@96000000 {
+ * reg = <0 0x96000000 0 0x2000000>;
+ * no-map;
+ * };
+ */
+ };
+
+ memory@80000000 {
+ reg = <0x00000000 0x80000000 0 0x40000000>;
+ device_type = "memory";
+ };
+};
+
+&i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c2_pins>;
+ pinctrl-1 = <&i2c2_gpio_pins>;
+ pinctrl-names = "default", "gpio";
+ scl-gpios = <&lsio_gpio3 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&lsio_gpio3 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+&i2c3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c3_pins>;
+ pinctrl-1 = <&i2c3_gpio_pins>;
+ pinctrl-names = "default", "gpio";
+ scl-gpios = <&lsio_gpio3 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&lsio_gpio3 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ magnetometer@1e {
+ compatible = "st,iis2mdc";
+ reg = <0x1e>;
+ interrupt-parent = <&lsio_gpio2>;
+ interrupts = <10 IRQ_TYPE_EDGE_RISING>;
+ pinctrl-0 = <&magnetometer_pins>;
+ pinctrl-names = "default";
+ st,drdy-int-pin = <1>;
+ };
+
+ /* pressure-sensor@5c */
+
+ inertial-sensor@6b {
+ compatible = "st,ism330dhcx";
+ reg = <0x6b>;
+ interrupt-parent = <&lsio_gpio2>;
+ interrupts = <11 IRQ_TYPE_EDGE_RISING>;
+ pinctrl-0 = <&imu_pins>;
+ pinctrl-names = "default";
+ st,drdy-int-pin = <1>;
+ };
+};
+
+&iomuxc {
+ pinctrl-0 = <&pinctrl_hog>;
+ pinctrl-names = "default";
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ IMX8DXL_COMP_CTL_GPIO_1V8_3V3_GPIORHB_PAD 0x000514a0
+ IMX8DXL_COMP_CTL_GPIO_1V8_3V3_GPIORHK_PAD 0x000014a0
+ >;
+ };
+
+ dsrc_pins: pinctrl-dsrc-grp {
+ fsl,pins = <
+ /* reset: io without pull */
+ IMX8DXL_ADC_IN0_LSIO_GPIO1_IO10 0x0000060
+
+ /*
+ * boot0: io without pull
+ * After reset, this pin selects radio boot media:
+ * - 0: flash spi
+ * - 1: slave sdio
+ * Once the firmware boots however, the radio controls
+ * this pin for flow-control to signal readiness.
+ */
+ IMX8DXL_ADC_IN1_LSIO_GPIO1_IO09 0x0000060
+ >;
+ };
+
+ gnss_pins: pinctrl-gnss-grp {
+ fsl,pins = <
+ /* gps reset: input with pull-up */
+ IMX8DXL_SNVS_TAMPER_OUT4_LSIO_GPIO2_IO08_IN 0x0000021
+ /* gps interrupt: io without pull-up */
+ IMX8DXL_SNVS_TAMPER_IN0_LSIO_GPIO2_IO09_IN 0x0000061
+ >;
+ };
+
+ gnss_pps_pins: pinctrl-gnss-pps-grp {
+ fsl,pins = <
+ /* gps timepulse: input without pull-up */
+ IMX8DXL_SNVS_TAMPER_OUT2_LSIO_GPIO2_IO06_IN 0x0000061
+ >;
+ };
+
+ i2c2_gpio_pins: pinctrl-i2c2-gpio-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_SCK_LSIO_GPIO3_IO00 0x00000021
+ /* io with pull-up, weak drive, open-drain */
+ IMX8DXL_SPI1_SDO_LSIO_GPIO3_IO01 0x02000021
+ >;
+ };
+
+ i2c2_pins: pinctrl-i2c2-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_SCK_ADMA_I2C2_SDA 0x06000021
+ IMX8DXL_SPI1_SDO_ADMA_I2C2_SCL 0x06000021
+ >;
+ };
+
+ i2c3_gpio_pins: pinctrl-i2c3-gpio-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_CS0_LSIO_GPIO3_IO03 0x00000021
+ /* io with pull-up, weak drive, open-drain */
+ IMX8DXL_SPI1_SDI_LSIO_GPIO3_IO02 0x02000021
+ >;
+ };
+
+ i2c3_pins: pinctrl-i2c3-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_CS0_ADMA_I2C3_SDA 0x06000021
+ IMX8DXL_SPI1_SDI_ADMA_I2C3_SCL 0x06000021
+ >;
+ };
+
+ imu_pins: pinctrl-imu-grp {
+ fsl,pins = <
+ /* interrupt: io with pull-down */
+ IMX8DXL_SNVS_TAMPER_IN2_LSIO_GPIO2_IO11_IN 0x0000041
+ >;
+ };
+
+ lpspi2_pins: pinctrl-lpspi2-grp {
+ fsl,pins = <
+ IMX8DXL_USDHC1_RESET_B_ADMA_SPI2_SCK 0x600004c
+ IMX8DXL_USDHC1_VSELECT_ADMA_SPI2_SDO 0x600004c
+ IMX8DXL_USDHC1_WP_ADMA_SPI2_SDI 0x600004c
+ IMX8DXL_USDHC1_CD_B_LSIO_GPIO4_IO22 0x6000021
+ >;
+ };
+
+ lpuart0_pins: pinctrl-lpuart0-grp {
+ fsl,pins = <
+ IMX8DXL_UART0_RX_ADMA_UART0_RX 0x06000020
+ IMX8DXL_UART0_TX_ADMA_UART0_TX 0x06000020
+ >;
+ };
+
+ lpuart2_pins: pinctrl-lpuart2-grp {
+ fsl,pins = <
+ IMX8DXL_UART2_TX_ADMA_UART2_TX 0x06000020
+ IMX8DXL_UART2_RX_ADMA_UART2_RX 0x06000020
+ >;
+ };
+
+ magnetometer_pins: pinctrl-magnetometer-grp {
+ fsl,pins = <
+ /* interrupt: io with pull-down */
+ IMX8DXL_SNVS_TAMPER_IN1_LSIO_GPIO2_IO10_IN 0x0000041
+ >;
+ };
+
+ regulator_1_2_pins: pinctrl-regulator-1-2-grp {
+ fsl,pins = <
+ /* io without pull-up */
+ /* has etxernal pull-down */
+ IMX8DXL_ADC_IN5_LSIO_GPIO1_IO13 0x0000061
+ >;
+ };
+
+ regulator_1_6_pins: pinctrl-regulator-1-6-grp {
+ fsl,pins = <
+ /* io without pull-up */
+ /* has etxernal pull-down */
+ IMX8DXL_ADC_IN4_LSIO_GPIO1_IO14 0x0000061
+ >;
+ };
+
+ regulator_1_8_se_pins: pinctrl-regulator-1-8-secure-element-grp {
+ fsl,pins = <
+ /* v2x-secure-element power switch: io with pull-down */
+ IMX8DXL_QSPI0B_DATA0_LSIO_GPIO3_IO18 0x0000041
+ >;
+ };
+
+ se_pins: pinctrl-secure-element-grp {
+ fsl,pins = <
+ /* v2x-secure-element reset: io with pull-up */
+ IMX8DXL_QSPI0B_DATA1_LSIO_GPIO3_IO19 0x0000021
+
+ /*
+ * v2x-secure-element gpio0: io with pull-up
+ * pulled low by sxf after boot indicating ready for commands
+ */
+ IMX8DXL_QSPI0B_DATA2_LSIO_GPIO3_IO20 0x0000021
+
+ /* v2x-secure-element gpio1: io with pull-up */
+ IMX8DXL_QSPI0B_DATA3_LSIO_GPIO3_IO21 0x0000021
+ >;
+ };
+
+ usdhc1_pins: pinctrl-usdhc1-grp {
+ fsl,pins = <
+ IMX8DXL_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
+ IMX8DXL_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021
+ IMX8DXL_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021
+ IMX8DXL_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021
+ IMX8DXL_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021
+ IMX8DXL_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021
+ IMX8DXL_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021
+ IMX8DXL_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021
+ IMX8DXL_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021
+ IMX8DXL_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021
+ IMX8DXL_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041
+ IMX8DXL_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x00000061
+ >;
+ };
+
+ usdhc2_pins: pinctrl-usdhc2-grp {
+ fsl,pins = <
+ IMX8DXL_ENET0_RGMII_RXC_CONN_USDHC1_CLK 0x06000040
+ IMX8DXL_ENET0_RGMII_RX_CTL_CONN_USDHC1_CMD 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD0_CONN_USDHC1_DATA0 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD1_CONN_USDHC1_DATA1 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD2_CONN_USDHC1_DATA2 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD3_CONN_USDHC1_DATA3 0x00000021
+ >;
+ };
+};
+
+&lpspi2 {
+ cs-gpios = <&lsio_gpio4 22 GPIO_ACTIVE_LOW>;
+ num-cs = <1>;
+ pinctrl-0 = <&lpspi2_pins>, <&se_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+/* console */
+&lpuart0 {
+ pinctrl-0 = <&lpuart0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+/* gnss */
+&lpuart2 {
+ pinctrl-0 = <&lpuart2_pins>, <&gnss_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&lsio_gpio3 {
+ gpio-line-names = "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "SXF_RST", "SXF_GPIO0", "SXF_GPIO1", "", "",
+ "", "", "", "", "", "", "", "";
+};
+
+&lsio_mu5 {
+ status = "okay";
+};
+
+/* OTG port for boot */
+&usbotg1 {
+ adp-disable;
+ disable-over-current;
+ dr_mode = "peripheral";
+ hnp-disable;
+ power-active-high;
+ srp-disable;
+ status = "okay";
+};
+
+&usbphy1 {
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc1 {
+ bus-width = <8>;
+ cap-mmc-hw-reset;
+ non-removable;
+ no-sd;
+ no-sdio;
+ pinctrl-0 = <&usdhc1_pins>;
+ pinctrl-1 = <&usdhc1_pins>;
+ pinctrl-2 = <&usdhc1_pins>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ vmmc-supply = <&v_3_3>;
+ vqmmc-supply = <&v_1_8>;
+ status = "okay";
+};
+
+/* DSRC Radio */
+&usdhc2 {
+ bus-width = <4>;
+ keep-power-in-suspend;
+ max-frequency = <40000000>;
+ non-removable;
+ no-sd;
+ pinctrl-0 = <&usdhc2_pins>, <&dsrc_pins>;
+ pinctrl-names = "default";
+ vmmc-supply = <&v_3_3>;
+ vqmmc-supply = <&v_1_8>;
+ status = "okay";
+};
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/3] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Josua Mayer @ 2026-04-09 12:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel, Vladimir Oltean,
Conor Dooley, Krzysztof Kozlowski, netdev, Josua Mayer,
Krzysztof Kozlowski
Add bindings and description for SolidRUn i.MX8DXL based SoM and
HummingBoard Telematics.
Modify SJA1110 Ethernet Switch bindings to allow SPI Mode 0.
This patch-set is based on v7.0-rc2, because rc1 was experiencing
deadlocks with imx8qxp clock driver.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Changes in v2:
- Dropped accidental change to unrelated imx8mp-sr-som.dtsi file.
- Fixed phy-mode on fixed link between cpu and ethernet switch.
(Reported-by: Andrew Lunn <andrew@lunn.ch>)
- Removed spi-cpol property from ethernet-switch on spi bus, fixing
sja1110a driver probe.
- Changed SJA1110 bindings to allow removing spi-cpol property.
- Aligned comments on all ethernet switch port nodes to be consistent.
- Dropped regulator-always-on from dsrc radio power-supplies.
- Link to v1: https://lore.kernel.org/r/20260408-imx8dxl-sr-som-v1-0-ce5a39acd713@solid-run.com
---
Josua Mayer (3):
dt-bindings: net: dsa: nxp,sja1105: make spi-cpol optional for sja1110
dt-bindings: arm: fsl: Add SolidRun i.MX8DXL SoM and HummingBoard
arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
Documentation/devicetree/bindings/arm/fsl.yaml | 7 +
.../devicetree/bindings/net/dsa/nxp,sja1105.yaml | 2 -
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../freescale/imx8dxl-hummingboard-telematics.dts | 536 +++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi | 458 ++++++++++++++++++
5 files changed, 1003 insertions(+), 2 deletions(-)
---
base-commit: 11439c4635edd669ae435eec308f4ab8a0804808
change-id: 20260408-imx8dxl-sr-som-f141ec343173
Best regards,
--
Josua Mayer <josua@solid-run.com>
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: arm: fsl: Add SolidRun i.MX8DXL SoM and HummingBoard
From: Josua Mayer @ 2026-04-09 12:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel, Vladimir Oltean,
Conor Dooley, Krzysztof Kozlowski, netdev, Josua Mayer,
Krzysztof Kozlowski
In-Reply-To: <20260409-imx8dxl-sr-som-v2-0-83ff20629ba0@solid-run.com>
Add binding for the SolidRun i.MX8DXL based System on Module, and the
reference HummingBoard Telematics.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 5716d701292cf..c7a885159318f 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1376,6 +1376,13 @@ properties:
- fsl,imx8dxl-evk # i.MX8DXL EVK Board
- const: fsl,imx8dxl
+ - description: SolidRun i.MX8DXL SoM based boards
+ items:
+ - enum:
+ - solidrun,imx8dxl-hummingboard-telematics # SolidRun i.MX8DXL SoM EVK Board
+ - const: solidrun,imx8dxl-sr-som
+ - const: fsl,imx8dxl
+
- description: i.MX8QXP/i.MX8DX Boards with Toradex Colibri iMX8X Modules
items:
- enum:
--
2.51.0
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: make spi-cpol optional for sja1110
From: Josua Mayer @ 2026-04-09 12:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel, Vladimir Oltean,
Conor Dooley, Krzysztof Kozlowski, netdev, Josua Mayer
In-Reply-To: <20260409-imx8dxl-sr-som-v2-0-83ff20629ba0@solid-run.com>
Currently, the binding requires 'spi-cpha' for SJA1105 and 'spi-cpol'
for SJA1110.
However, the SJA1110 supports both SPI modes 0 and 2. Mode 2
(cpha=0, cpol=1) is used by the NXP LX2160 Bluebox 3.
On the SolidRun i.MX8DXL HummingBoard Telematics, mode 0 is stable,
while forcing mode 2 introduces CRC errors especially during bursts.
Drop the requirement on spi-cpol for SJA1110.
Fixes: af2eab1a8243 ("dt-bindings: net: nxp,sja1105: document spi-cpol/cpha")
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
index 607b7fe8d28ee..0486489114cd8 100644
--- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
@@ -143,8 +143,6 @@ allOf:
else:
properties:
spi-cpha: false
- required:
- - spi-cpol
unevaluatedProperties: false
--
2.51.0
^ permalink raw reply related
* Re: [PATCH bpf-next v12 1/5] bpf: Move constants blinding out of arch-specific JITs
From: Xu Kuohai @ 2026-04-09 12:27 UTC (permalink / raw)
To: Emil Tsalapatis, bpf, linux-kernel, linux-arm-kernel
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Yonghong Song, Puranjay Mohan,
Anton Protopopov, Alexis Lothoré, Shahab Vahedi,
Russell King, Tiezhu Yang, Hengqi Chen, Johan Almbladh,
Paul Burton, Hari Bathini, Christophe Leroy, Naveen N Rao,
Luke Nelson, Xi Wang, Björn Töpel, Pu Lehui,
Ilya Leoshkevich, Heiko Carstens, Vasily Gorbik, David S . Miller,
Wang YanQing
In-Reply-To: <DHJNB77853FP.3601X6NYXA9LY@etsalapatis.com>
On 4/4/2026 12:04 AM, Emil Tsalapatis wrote:
>> /* Pass 3: Adjust jump offset and write final image */
>> if (build_body(&ctx, extra_pass) ||
>> - WARN_ON_ONCE(ctx.idx != ctx.epilogue_offset)) {
>> - prog = orig_prog;
>> + WARN_ON_ONCE(ctx.idx != ctx.epilogue_offset))
> This thunk is slightly different now, the WARN_ON_ONCE() won't be checked
> if build_body() succeeds.
Sorry, I do not see the difference here. The WARN_ON_ONCE() is still checked
when build_body() returns 0 (succeeds) due to the '||' evaluation.
> Do we even need it? AFAICT the only case it
> wouldn't trigger if build_body() fails is if it did so at the very last
> instruction. Alternatively, should we check it if build_body() succeeds
> instead to retain the old behavior?
>
>> goto out_free_hdr;
>> - }
>>
^ permalink raw reply
* Re: (subset) [PATCH v13 00/17] Apply drm_bridge_connector and panel_bridge helper for the Analogix DP driver
From: Luca Ceresoli @ 2026-04-09 12:25 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, victor.liu, Frank.Li, shawnguo,
s.hauer, inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1,
p.zabel, hjc, heiko, andy.yan, Damon Ding
Cc: Laurent.pinchart, jonas, jernej.skrabec, kernel, festevam,
alim.akhtar, dmitry.baryshkov, nicolas.frattaroli, dianders,
m.szyprowski, linux-kernel, dri-devel, imx, linux-arm-kernel,
linux-samsung-soc, linux-rockchip
In-Reply-To: <20260409065301.446670-1-damon.ding@rock-chips.com>
On Thu, 09 Apr 2026 14:52:44 +0800, Damon Ding wrote:
> PATCH 1 is to add a new parameter to store the point of next bridge.
> PATCH 2 is to make legacy bridge driver more universal.
> PATCH 3-10 are preparations for apply drm_bridge_connector helper.
> PATCH 11 is to apply the drm_bridge_connector helper.
> PATCH 12-14 are to move the panel/bridge parsing to the Analogix side.
> PATCH 15 is to attach the next bridge on Analogix side uniformly.
> PATCH 16-17 are to apply the panel_bridge helper.
>
> [...]
Applied, thanks!
[01/17] drm/bridge: analogix_dp: Add &analogix_dp_plat_data.next_bridge
commit: d842ed8f3417d848046eea2c40de78a1993eb3df
[02/17] drm/bridge: Move legacy bridge driver out of imx directory for multi-platform use
commit: ba2db93cf3d569a4525a02cd0ed5ec5f979e3afd
[03/17] drm/exynos: exynos_dp: Remove &exynos_dp_device.ptn_bridge
commit: e123c3c5212200c8c443fe0804e7dfc8e9d5986e
[04/17] drm/exynos: exynos_dp: Remove unused &exynos_dp_device.connector
commit: af917a1b95c2b7e58021b4bbe22355323362bbf8
[05/17] drm/exynos: exynos_dp: Apply of-display-mode-bridge to parse the display-timings node
commit: 1b7cee81d8147d341c0240fcc9cbd129b95c0043
[06/17] drm/bridge: analogix_dp: Remove redundant &analogix_dp_plat_data.skip_connector
commit: 312a86806b742dfd6fc543d8ec02ab15ee68c1a2
[07/17] drm/bridge: analogix_dp: Move the color format check to .atomic_check() for Rockchip platforms
commit: d3bdde2e0c123ef406be81d1378749362a1ecb30
[08/17] drm/bridge: analogix_dp: Remove unused &analogix_dp_plat_data.get_modes()
commit: 4226b19edf240b054fc979557533c4a8c47a5535
[09/17] drm/bridge: analogix_dp: Remove unused struct drm_connector* for &analogix_dp_plat_data.attach()
commit: b943aefce6ad0c6119cacd6adcc67225b2699e7f
Best regards,
--
Luca Ceresoli <luca.ceresoli@bootlin.com>
^ permalink raw reply
* Re: [PATCH v7 7/7] KVM: arm64: Normalize cache configuration
From: David Woodhouse @ 2026-04-09 12:25 UTC (permalink / raw)
To: akihiko.odaki, Gutierrez Cantu, Bernardo
Cc: alexandru.elisei, alyssa, asahi, broonie, catalin.marinas,
james.morse, kvmarm, kvmarm, linux-arm-kernel, linux-kernel,
marcan, mathieu.poirier, maz, oliver.upton, suzuki.poulose, sven,
will
In-Reply-To: <20230112023852.42012-8-akihiko.odaki@daynix.com>
[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]
On Thu, 12 Jan 2023 at 11:38:52 +0900, Akihiko Odaki wrote:
> Before this change, the cache configuration of the physical CPU was
> exposed to vcpus. This is problematic because the cache configuration a
> vcpu sees varies when it migrates between vcpus with different cache
> configurations.
>
> Fabricate cache configuration from the sanitized value, which holds the
> CTR_EL0 value the userspace sees regardless of which physical CPU it
> resides on.
>
> CLIDR_EL1 and CCSIDR_EL1 are now writable from the userspace so that
> the VMM can restore the values saved with the old kernel.
(commit 7af0c2534f4c5)
How does the VMM set the values that the old kernel would have set?
Let's say we're deploying a kernel with this change for the first time,
and we need to ensure that we provide a consistent environment to
guests, which can be live migrated back to an older host.
So for new launches, we need to provide the values that the old kernel
*would* have provided to the guest. A new launch isn't a migration;
there are no "values saved with the old kernel".
Userspace can't read the CLIDR_EL1 and CCSIDR_EL1 registers directly,
and AFAICT not everything we need to reconstitute them is in sysfs. How
is this supposed to work?
Shouldn't this change have been made as a capability that the VMM can
explicitly opt in or out of? Environments that don't do cross-CPU
migration absolutely don't care about, and actively don't *want*, the
sanitisation that this commit inflicted on us, surely?
Am I missing something?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* [GIT PULL] clk: samsung: drivers for v7.1
From: Krzysztof Kozlowski @ 2026-04-09 12:25 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: Krzysztof Kozlowski, Chanwoo Choi, linux-clk, Sylwester Nawrocki,
Alim Akhtar, Peter Griffin, linux-arm-kernel, linux-samsung-soc,
linux-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-clk-7.1
for you to fetch changes up to e57c36bc1a3e459239ead492ebce731a88a264b1:
clk: samsung: exynos850: Add APM-to-AP mailbox clock (2026-03-24 13:43:19 +0100)
----------------------------------------------------------------
Samsung SoC clock drivers changes for v7.1
1. Axis ARTPEC-9: Add new PLL clocks and new drivers for eight clock
controllers on the SoC.
2. ExynosAutov920: Add G3D (GPU) clock controller.
3. Exynos850: Define missing clock for the APM mailbox.
4. Few compiler warning fixes cleanups.
----------------------------------------------------------------
Alexey Klimov (2):
dt-bindings: clock: exynos850: Add APM_AP MAILBOX clock
clk: samsung: exynos850: Add APM-to-AP mailbox clock
André Draszik (1):
clk: samsung: gs101: harmonise symbol names (clock arrays)
GyoungBo Min (3):
dt-bindings: clock: Add ARTPEC-9 clock controller
clk: samsung: Add clock PLL support for ARTPEC-9 SoC
clk: samsung: artpec-9: Add initial clock support for ARTPEC-9 SoC
Krzysztof Kozlowski (3):
clk: samsung: pll: Fix possible truncation in a9fraco recalc rate
clk: samsung: Use %pe format to simplify
Merge branch 'for-v7.1/dt-bindings-clk' into next/clk
Raghav Sharma (2):
dt-bindings: clock: exynosautov920: add G3D clock definitions
clk: samsung: exynosautov920: add block G3D clock support
.../bindings/clock/axis,artpec9-clock.yaml | 232 ++++
.../clock/samsung,exynosautov920-clock.yaml | 21 +
drivers/clk/samsung/Makefile | 1 +
drivers/clk/samsung/clk-artpec9.c | 1224 ++++++++++++++++++++
drivers/clk/samsung/clk-exynos850.c | 7 +-
drivers/clk/samsung/clk-exynosautov920.c | 52 +
drivers/clk/samsung/clk-gs101.c | 52 +-
drivers/clk/samsung/clk-pll.c | 185 ++-
drivers/clk/samsung/clk-pll.h | 17 +
drivers/clk/samsung/clk.c | 4 +-
include/dt-bindings/clock/axis,artpec9-clk.h | 195 ++++
include/dt-bindings/clock/exynos850.h | 1 +
include/dt-bindings/clock/samsung,exynosautov920.h | 6 +
13 files changed, 1960 insertions(+), 37 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/axis,artpec9-clock.yaml
create mode 100644 drivers/clk/samsung/clk-artpec9.c
create mode 100644 include/dt-bindings/clock/axis,artpec9-clk.h
^ permalink raw reply
* Re: BUG: net-next (7.0-rc6 based and later) fails to boot on Jetson Xavier NX
From: Will Deacon @ 2026-04-09 12:24 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Robin Murphy, netdev, linux-arm-kernel, linux-kernel, iommu,
linux-ext4, Linus Torvalds, dmaengine, Marek Szyprowski,
Theodore Ts'o, Andreas Dilger, Vinod Koul, Frank Li
In-Reply-To: <adayAMR_dEA6W5vW@shell.armlinux.org.uk>
On Wed, Apr 08, 2026 at 08:52:32PM +0100, Russell King (Oracle) wrote:
> What's the status on the iommu fix? Is it merged into mainline yet?
> If it isn't already, that means net-next remains unbootable going
> into the merge window without manually carrying the fix locally.
I'll pick it up for 7.0 in the iommu tree.
Will
^ permalink raw reply
* Re: [PATCH v2 0/7] thermal: samsung: Add support for Google GS101 TMU
From: Tudor Ambarus @ 2026-04-09 12:22 UTC (permalink / raw)
To: Alexey Klimov, daniel.lezcano
Cc: Rafael J. Wysocki, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Alim Akhtar, Bartlomiej Zolnierkiewicz, Kees Cook,
Gustavo A. R. Silva, Peter Griffin, André Draszik,
willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening
In-Reply-To: <DHNUUPQPD5DR.18P18VV0LNTI8@linaro.org>
On 4/8/26 5:49 PM, Alexey Klimov wrote:
> On Mon Jan 19, 2026 at 12:08 PM GMT, Tudor Ambarus wrote:
>> Add support for the Thermal Management Unit (TMU) on the Google GS101
>> SoC.
>>
>> The GS101 TMU implementation utilizes a hybrid architecture where
>> management is shared between the kernel and the Alive Clock and
>> Power Manager (ACPM) firmware.
>
> Do you plan to update or work on this series? If, by some reason,
I'd like to resubmit, but I got derailed by other tasks.
> this series is postphoned I can rebase it and re-send, for example.
> IIRC it needs a clean rebase as a minimial change.
>
No, it's more than that. When I talked with Daniel about this driver, he
suggested I shall really focus on using the .set_trips callback instead of
.set_trip_temp. I'm not sure if it's possible given the static nature of
the ACPM interface. So it needs a bit of investigation, which I couldn't
do lately.
If we can go initially with .set_trip_temp and then come up with an iterative
patch about .set_trips, I can of course respin, it takes me just a few
minutes to rebase and test. But it's Daniel to decide.
Oh, and the device tree needs a little update on the trip points, but other
than that, we're good to go.
Cheers,
ta
^ permalink raw reply
* [PATCH v1] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Ayushi Makhija @ 2026-04-09 12:21 UTC (permalink / raw)
To: andersson, konrad.dybcio, robh+dt, krzysztof.kozlowski+dt,
conor+dt, dmitry.baryshkov
Cc: Ayushi Makhija, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, quic_rajeevny, quic_vproddut, Dmitry Baryshkov,
Konrad Dybcio
The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
Fixes: 4fca6849864d ("drm/panel: Add Novatek NT37801 panel driver")
Signed-off-by: Ayushi Makhija <ayushi.makhija@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
index 3837f6785320..6ba4e69bf377 100644
--- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
@@ -462,7 +462,7 @@ vreg_l11b_1p0: ldo11 {
vreg_l12b_1p8: ldo12 {
regulator-name = "vreg_l12b_1p8";
- regulator-min-microvolt = <1200000>;
+ regulator-min-microvolt = <1650000>;
regulator-max-microvolt = <1800000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
regulator-allow-set-load;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Josua Mayer @ 2026-04-09 12:18 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Yazan Shhady, Mikhail Anikin, Alexander Dahl,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <aef0a8db-7a16-4620-87dc-d517be946cab@lunn.ch>
Am 09.04.26 um 14:11 schrieb Andrew Lunn:
>> Would it be correct to change phy-mode on the mac to "rgmii",
>> and leave switch port as is?
> Yes, that is O.K. Please add a comment, say that the switch is
> providing the delay.
Thanks!
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
From: Krzysztof Kozlowski @ 2026-04-09 12:15 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <adeVWKcQyfkKKY5J@gregor-framework>
On 09/04/2026 14:02, Gregor Herburger wrote:
> Hi Krzysztof,
>
> thanks for reviewing.
>
> On Thu, Apr 09, 2026 at 10:15:12AM +0200, Krzysztof Kozlowski wrote:
>> On Wed, Apr 08, 2026 at 10:00:17AM +0200, Gregor Herburger wrote:
>>> The Raspberry Pi 5 has two OTP registers (private and customer), add these
>>> to the devicetree.
>>
>> So this sentence confirms my question on bindings - your device
>> raspberrypi,bcm2835-firmware has these, thus you do not need these child
>> nodes at all. Neither compatibles.
>
> I dont't think so. In my understanding the bcm2835-firmware does not
> provide the otp registers but only provides the interface to the
> registers. Though I don't know the details how this is done but [1] says
> that only BCM2712 has 512bits and the others (like bcm2711) have
Still the same. s/otp/interface/ so your device provides interface.
> 256bits. So both devicetrees have the raspberrypi,bcm2835-firmware node
> but only the bcm2712 has the raspberrypi,firmware-otp-private node while the
Why does bcm2712 use bcm2835 compatible?
Nodes and properties are not a solution. See DTS101 question - "...
because my new device, which is compatible with an older one, does not
support ..." and answer: No.
> raspberrypi,firmware-otp-customer is available in all raspberrys.
>
>> Drop entire DTS and binding patches.
>
> If I drop the binding patch how to distinguish the variants? Should I
> add a SoC specific compatible? e.g. `raspberrypi,bcm2712-firmware` and
> use it in the firmware/raspberrypi driver to add the second otp region?
So you have different devices/variants? What is the "variant" here?
Writing-bindings asks you to have per device compatible. Why standard
rules do not apply here? (see also DTS101)
>
> Also what I don't understand why we have all the bindings for
Neither do I.
> 'raspberrypi,firmware-clocks', 'raspberrypi,firmware-gpio',
> 'raspberrypi,firmware-reset', 'raspberrypi,firmware-poe-pwm' and
> 'raspberrypi,firmware-ts'. What is the difference between these devices
> and the otp registers. They are all accessed through the firmware.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 7/8] arm64/cpufeature: Define hwcaps for 2025 dpISA features
From: Mark Brown @ 2026-04-09 12:12 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
linux-kernel, linux-doc, linux-kselftest
In-Reply-To: <adeOnmy60AUQzSvo@arm.com>
[-- Attachment #1: Type: text/plain, Size: 2963 bytes --]
On Thu, Apr 09, 2026 at 12:33:50PM +0100, Catalin Marinas wrote:
> On Mon, Mar 02, 2026 at 10:53:22PM +0000, Mark Brown wrote:
> > @@ -3290,11 +3295,13 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
> > HWCAP_CAP(ID_AA64ISAR1_EL1, I8MM, IMP, CAP_HWCAP, KERNEL_HWCAP_I8MM),
> > HWCAP_CAP(ID_AA64ISAR1_EL1, LS64, LS64, CAP_HWCAP, KERNEL_HWCAP_LS64),
> > HWCAP_CAP(ID_AA64ISAR2_EL1, LUT, IMP, CAP_HWCAP, KERNEL_HWCAP_LUT),
> > + HWCAP_CAP(ID_AA64ISAR2_EL1, LUT, LUT6, CAP_HWCAP, KERNEL_HWCAP_LUT6),
> IIUC that's a LUTI6 SVE instruction which would not be available if
> SVE2p3 is not available (or SVE in general), though we have the
> equivalent SME one with SME2p3 (and a separate HWCAP for it). We should
> rename it to HWCAP_SVE_LUT6 and make it conditional on
> has_sve_feature().
OK, and hope that the SME feature always keeps in sync with this.
> KVM will probably confuse guests here if SVE is disabled but the
> ISAR2.LUT field is not capped (I haven't checked). The conditional
> has_sve_feature() would solve this but it won't address the MRS
> emulation. Arguably it's a KVM problem for exposing inconsistent
> id regs: ISAR2.LUT==0b0010 is not permitted without SVE2p3 or SME2p3.
> But the spec isn't greatly written either - why does a field about
> AdvSIMD all of a sudden reports SVE instructions availability?
Yeah, it's just a generally interesting choice for the architecture.
It'll also be fun if we get a new LUT feature that isn't SVE/SME
specific.
> On SME, unless I'm misreading the spec, the bits seem to have been
> written by three different people in isolation:
> - ID_AA64ZFR0_EL1.SVEver + ID_AA64PFR1_EL1.SME (and if these weren't
> enough, we have ID_AA64SMFR0_EL1.SMEver) tells us that SME2p3 is
> implemented. LUTI6 is mandated by SME2p3
> - ID_AA64SMFR0_EL1.LUT6 means that the LUTI6 instruction is present but
> this field can only be 0b1 with SME2p3
> - ID_AA64ISAR2_EL1.LUT == 0b0010 means that LUTI6 instruction is present
> (if SVE2p3 or SME2p3) and, again, that's the only value permitted by
> SME2p3
> So a lot of redundancy and we did end up reporting the fine-grained
> details to the user already. The SMExpy versions seem to be cumulative
> unless Arm decides to make some of the instructions optional (it still
> doesn't explain why we have the same information in SMFR0 and ISAR2). I
> guess that's where the fine-grained HWCAPs come in handy.
There's a few things like this with the FP extension, I think mostly
with SME - it's future proofing in case we want to allow more
flexibility with when the individual features are available.
> I wonder if the user would ever be able to parse these ID fields
> correctly if using the MRS emulation. We'd need to sanity-check KVM as
> well, not sure it proactively caps id fields.
Yeah, there's some traps here. Generally you're probably best using the
most specific field for a given feature but there's still traps there.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Andrew Lunn @ 2026-04-09 12:11 UTC (permalink / raw)
To: Josua Mayer
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Yazan Shhady, Mikhail Anikin, Alexander Dahl,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <db41d119-2469-4107-94b5-b09e9bbbe9ec@solid-run.com>
> Would it be correct to change phy-mode on the mac to "rgmii",
> and leave switch port as is?
Yes, that is O.K. Please add a comment, say that the switch is
providing the delay.
Andrew
^ permalink raw reply
* Re: [PATCH v2 5/7] soc: samsung: exynos-pmu: add Exynos850 CPU hotplug support
From: Alexey Klimov @ 2026-04-09 12:07 UTC (permalink / raw)
To: Henrik Grimler
Cc: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin, André Draszik, Conor Dooley, Alim Akhtar,
Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260409115630.GA15706@localhost>
Hi Henrik,
On Thu Apr 9, 2026 at 12:57 PM BST, Henrik Grimler wrote:
> Hi Alexey,
>
> This patch breaks compilation for arm(32) exynos devices. Compiling
> with exynos_defconfig I get:
>
> [ ... ]
> CC drivers/soc/samsung/exynos850-pmu.o
> CC [M] fs/squashfs/page_actor.o
> ../drivers/soc/samsung/exynos850-pmu.c:17:21: error: call to undeclared function 'MPIDR_AFFINITY_LEVEL'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 17 | u32 this_cluster = MPIDR_AFFINITY_LEVEL(read_cpuid_mpidr(), 2);
> | ^
> ../drivers/soc/samsung/exynos850-pmu.c:17:42: error: call to undeclared function 'read_cpuid_mpidr'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 17 | u32 this_cluster = MPIDR_AFFINITY_LEVEL(read_cpuid_mpidr(), 2);
> | ^
> ../drivers/soc/samsung/exynos850-pmu.c:48:21: error: call to undeclared function 'MPIDR_AFFINITY_LEVEL'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 48 | u32 this_cluster = MPIDR_AFFINITY_LEVEL(read_cpuid_mpidr(), 2);
> | ^
> ../drivers/soc/samsung/exynos850-pmu.c:48:42: error: call to undeclared function 'read_cpuid_mpidr'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 48 | u32 this_cluster = MPIDR_AFFINITY_LEVEL(read_cpuid_mpidr(), 2);
> | ^
> 4 errors generated.
> make[6]: *** [../scripts/Makefile.build:289: drivers/soc/samsung/exynos850-pmu.o] Error 1
> make[5]: *** [../scripts/Makefile.build:548: drivers/soc/samsung] Error 2
> make[4]: *** [../scripts/Makefile.build:548: drivers/soc] Error 2
> make[3]: *** [../scripts/Makefile.build:548: drivers] Error 2
> make[3]: *** Waiting for unfinished jobs....
> [ ... ]
Thank you! My bad.
I will check for the next series what I missed.
Thanks,
Alexey
^ permalink raw reply
* Re: [PATCH v2 2/3] mailbox: exynos: Add support for Exynos850 mailbox
From: Tudor Ambarus @ 2026-04-09 12:04 UTC (permalink / raw)
To: Alexey Klimov
Cc: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Sam Protsenko, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Jassi Brar, Krzysztof Kozlowski,
Peter Griffin, linux-samsung-soc, linux-arm-kernel, linux-clk,
devicetree, linux-kernel, Juan Yescas
In-Reply-To: <DHNSP3FVR4ZQ.1PIRHF0KJGKI5@linaro.org>
On 4/8/26 4:08 PM, Alexey Klimov wrote:
> Hi Tudor,
Hi!
>> I find it strange that the SoCs use different registers. Are you sure you're
>> using the right direction? i.e. ring the doorbell to APM and not to AP?
>
> Well, I am not sure I correctly understood the questions and comment. So,
> this all was tested with ACPM TMU code with 3 temp sensors and it seems
> to work and sensors react in the right way.
>
> Downstream clearly does the following (see also [1],[2]) when sending
> ACPM msg:
>
> static void apm_interrupt_gen(unsigned int id)
> {
> /* APM NVIC INTERRUPT GENERATE */
> writel((1 << id) << 16, acpm_ipc->intr + INTGR0);
> }
>
Indeed, it looks alright, thanks for the pointers.
> I am aware that gs101 downstream uses INTGR1 in apm_interrupt_gen().
>
> When I use INTGR1 for e850 then I observe acpm timeouts. Hence, out of
> curiosity, what's the expected behaviour when/if I ring the doorbell to
If you raise your own interrupt the APM remains unaware and the AP times out.
You also have a spurious interrupt on yourself.
> AP (to itself as far as I understand)? My understanding that it won't
> work at all in such case unless APM firmware does some very fast
> polling.
>
>
> [1]: https://gitlab.com/Linaro/96boards/e850-96/kernel/-/blob/android-exynos-4.14-linaro/drivers/soc/samsung/acpm/acpm_ipc.c?ref_type=heads#L423
> [2]: https://github.com/samsungexynos850/android_kernel_samsung_exynos850/blob/0af517be2336bf8e09c59d576c4c314446713101/drivers/soc/samsung/acpm/acpm_ipc.c#L426
>
>>> static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>>> @@ -57,7 +104,8 @@ static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>>> return -EINVAL;
>>> }
>>>
>>> - writel(BIT(msg->chan_id), exynos_mbox->regs + EXYNOS_MBOX_INTGR1);
>>> + writel(BIT(msg->chan_id) << exynos_mbox->data->irq_doorbell_shift,
>>> + exynos_mbox->regs + exynos_mbox->data->irq_doorbell_offset);
>>
>> Use FIELD_PREP from <linux/bitfield.h> please. You will use a mask instead of
>> a shift.
>>
>> I would rename irq_doorbell_offset to intgr. It aligns with the register name
>> from the datasheet. You won't need to prepend _offset to the name, we already
>> see it's an offset when doing the writel().
>
> Sure. Thanks. Let's use FIELD_PREP.
>
> "doorbell" naming was chosen for readability and maintainability reasons.
> It seems to be more generic enough name that better reflects the workflow
> of what's going on in ACPM+mailbox machinery. We can rename it to just
> "doorbell" for instance.
>
> From platform data it will be clear to which register it is set, INTGR0
> or INTGR1, to align it with datasheet (which is closed anyway).
>
> Regarding intgr vs doorbell name, the intgr is a bit unclear for a
> reader if it means interrupt generation register or something else.
interrupt generation registers sounds sane to me
> But if you prefer, I can go with "intgr".
I think I prefer intgr, yes. If you choose doorbell, you'll have:
writel(FIELD_PREP(data->doorbell_mask), BIT(msg->chan_id),
exynos_mbox->regs + data->doorbell);
or maybe s/doorbell/doorbell_reg? But that would duplicate
exynos_mbox->regs, we already see that doorbell is a reg offset.
Doorbell is too generic for my taste.
And then how would you refer to the interrupt mask register? You
already have a doorbell_mask in the example above.
I won't push back too hard, I'll let you choose. If you can find a good
naming scheme for the interrupt generation reg and interrupt mask reg,
then fine.
>
> One more option is add a comment, smth like /* Ring the doorbell */
> before that writel().
I'm okay with such comment.
Cheers,
ta
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
From: Gregor Herburger @ 2026-04-09 12:02 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260409-imposing-strict-snail-5d2a6f@quoll>
Hi Krzysztof,
thanks for reviewing.
On Thu, Apr 09, 2026 at 10:15:12AM +0200, Krzysztof Kozlowski wrote:
> On Wed, Apr 08, 2026 at 10:00:17AM +0200, Gregor Herburger wrote:
> > The Raspberry Pi 5 has two OTP registers (private and customer), add these
> > to the devicetree.
>
> So this sentence confirms my question on bindings - your device
> raspberrypi,bcm2835-firmware has these, thus you do not need these child
> nodes at all. Neither compatibles.
I dont't think so. In my understanding the bcm2835-firmware does not
provide the otp registers but only provides the interface to the
registers. Though I don't know the details how this is done but [1] says
that only BCM2712 has 512bits and the others (like bcm2711) have
256bits. So both devicetrees have the raspberrypi,bcm2835-firmware node
but only the bcm2712 has the raspberrypi,firmware-otp-private node while the
raspberrypi,firmware-otp-customer is available in all raspberrys.
> Drop entire DTS and binding patches.
If I drop the binding patch how to distinguish the variants? Should I
add a SoC specific compatible? e.g. `raspberrypi,bcm2712-firmware` and
use it in the firmware/raspberrypi driver to add the second otp region?
Also what I don't understand why we have all the bindings for
'raspberrypi,firmware-clocks', 'raspberrypi,firmware-gpio',
'raspberrypi,firmware-reset', 'raspberrypi,firmware-poe-pwm' and
'raspberrypi,firmware-ts'. What is the difference between these devices
and the otp registers. They are all accessed through the firmware.
[1] https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#device-specific-private-key
Best regards
Gregor
^ permalink raw reply
* [PATCH 3/3] arm64: dts: imx95: Add iommus property and enable SMMU
From: Peng Fan (OSS) @ 2026-04-09 12:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260409-imx95-s-dts-v1-0-858e83ae1a37@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add iommus property for SDHC and EDMA
Enable SMMU by default.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx95.dtsi | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 3e35c956a4d7af88310b3dfaef7e3d064f530e07..adcc0e1d3696b93250ab97fcac7c181b187d3d10 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -777,6 +777,7 @@ edma3: dma-controller@42210000 {
<GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&scmi_clk IMX95_CLK_BUSWAKEUP>;
clock-names = "dma";
+ iommus = <&smmu 0x0>;
};
mu7: mailbox@42430000 {
@@ -1242,6 +1243,7 @@ usdhc1: mmc@42850000 {
bus-width = <8>;
fsl,tuning-start-tap = <1>;
fsl,tuning-step = <2>;
+ iommus = <&smmu 0x1>;
status = "disabled";
};
@@ -1259,6 +1261,7 @@ usdhc2: mmc@42860000 {
bus-width = <4>;
fsl,tuning-start-tap = <1>;
fsl,tuning-step = <2>;
+ iommus = <&smmu 0x2>;
status = "disabled";
};
@@ -1276,6 +1279,7 @@ usdhc3: mmc@428b0000 {
bus-width = <4>;
fsl,tuning-start-tap = <1>;
fsl,tuning-step = <2>;
+ iommus = <&smmu 0x3>;
status = "disabled";
};
};
@@ -1768,7 +1772,6 @@ smmu: iommu@490d0000 {
<GIC_SPI 326 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "eventq", "gerror", "priq", "cmdq-sync";
#iommu-cells = <1>;
- status = "disabled";
};
pmu@490d2000 {
--
2.37.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: imx95: Add SMMU PMU nodes
From: Peng Fan (OSS) @ 2026-04-09 12:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260409-imx95-s-dts-v1-0-858e83ae1a37@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
MMU-700 supports TCU PMU and TBU PMU. There are one TCU PMU and
11 TBU PMUs, add them all.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx95.dtsi | 84 ++++++++++++++++++++++++++++++++
1 file changed, 84 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 28b19a47a59daaff308fecce6e7b9ffe14133f74..3e35c956a4d7af88310b3dfaef7e3d064f530e07 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1770,6 +1770,90 @@ smmu: iommu@490d0000 {
#iommu-cells = <1>;
status = "disabled";
};
+
+ pmu@490d2000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x490d2000 0x1000>,
+ <0x490f2000 0x1000>;
+ interrupts = <GIC_SPI 333 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ pmu@49112000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x49112000 0x1000>,
+ <0x49122000 0x1000>;
+ interrupts = <GIC_SPI 323 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ pmu@49132000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x49132000 0x1000>,
+ <0x49142000 0x1000>;
+ interrupts = <GIC_SPI 323 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ pmu@49152000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x49152000 0x1000>,
+ <0x49162000 0x1000>;
+ interrupts = <GIC_SPI 323 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ pmu@49172000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x49172000 0x1000>,
+ <0x49182000 0x1000>;
+ interrupts = <GIC_SPI 323 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ pmu@49192000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x49192000 0x1000>,
+ <0x491a2000 0x1000>;
+ interrupts = <GIC_SPI 323 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ pmu@491b2000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x491b2000 0x1000>,
+ <0x491c2000 0x1000>;
+ interrupts = <GIC_SPI 323 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ pmu@491d2000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x491d2000 0x1000>,
+ <0x491e2000 0x1000>;
+ interrupts = <GIC_SPI 323 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ pmu@491f2000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x491f2000 0x1000>,
+ <0x49202000 0x1000>;
+ interrupts = <GIC_SPI 323 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ pmu@49212000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x49212000 0x1000>,
+ <0x49222000 0x1000>;
+ interrupts = <GIC_SPI 323 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ pmu@49232000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x49232000 0x1000>,
+ <0x49242000 0x1000>;
+ interrupts = <GIC_SPI 323 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ pmu@49252000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x49252000 0x1000>,
+ <0x49262000 0x1000>;
+ interrupts = <GIC_SPI 323 IRQ_TYPE_EDGE_RISING>;
+ };
};
usb3: usb@4c010010 {
--
2.37.1
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: imx95: Correct SMMU reg
From: Peng Fan (OSS) @ 2026-04-09 12:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260409-imx95-s-dts-v1-0-858e83ae1a37@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Update SMMU reg size to 0x40000, because MMU-700 TCU occupies 4 pages with
each page 64KB and the last page is reserved.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx95.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 71394871d8dd0fe80ea244feff4469e536321b1c..28b19a47a59daaff308fecce6e7b9ffe14133f74 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1761,7 +1761,7 @@ aips4: bus@49000000 {
smmu: iommu@490d0000 {
compatible = "arm,smmu-v3";
- reg = <0x490d0000 0x100000>;
+ reg = <0x490d0000 0x40000>;
interrupts = <GIC_SPI 325 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 328 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 334 IRQ_TYPE_EDGE_RISING>,
--
2.37.1
^ 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