* Re: [PATCH v5 5/8] ARM: dts: Add an armv7 timer for zx297520v3
From: Krzysztof Kozlowski @ 2026-04-22 7:10 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260421-send-v5-5-ace038e63515@gmail.com>
On Tue, Apr 21, 2026 at 11:23:13PM +0300, Stefan Dösinger wrote:
> The stock kernel does not use this timer, but it seems to work fine. The
> board has other board-specific timers that would need a driver and I see
> no reason to bother with them since the arm standard timer works.
>
> The caveat is the non-standard GIC setup needed to handle the timer's
> level-low PPI. This is the responsibility of the boot loader and
> documented in Documentation/arch/arm/zte/zx297520v3.rst.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> ---
> arch/arm/boot/dts/zte/zx297520v3.dtsi | 24 ++++++++++++++++++++++++
This must be squashed. You add new SoC - that's one commit. One logical
change. Adding "not working SoC" and then "let's fix it" are not two
separate tasks.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 3/8] ARM: dts: Add D-Link DWR-932M support
From: Krzysztof Kozlowski @ 2026-04-22 7:09 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260421-send-v5-3-ace038e63515@gmail.com>
On Tue, Apr 21, 2026 at 11:23:11PM +0300, Stefan Dösinger wrote:
> This adds base DT definition for zx297520v3 and one board that consumes it.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
subject - missing zte prefix.
Please use subject prefixes matching the subsystem. You can get them for
example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
...
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0>;
> + };
> + };
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + interrupt-parent = <&gic>;
> + ranges;
> +
> + gic: interrupt-controller@f2000000 {
> + compatible = "arm,gic-v3";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xf2000000 0x10000>,
> + <0xf2040000 0x20000>;
> + };
This is pretty incomplete DTS. The first submission must have a working,
basic device support which requires at least one interface, e.g. serial.
Otherwise how is this usable?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v7 3/4] KVM: arm64: PMU: Introduce FIXED_COUNTERS_ONLY
From: Akihiko Odaki @ 2026-04-22 7:02 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
kvmarm, linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <86ldeh20xg.wl-maz@kernel.org>
On 2026/04/20 22:53, Marc Zyngier wrote:
> On Mon, 20 Apr 2026 13:07:15 +0100,
> Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>>
>> On 2026/04/20 18:51, Marc Zyngier wrote:
>>> On Mon, 20 Apr 2026 09:36:16 +0100,
>>> Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>>>>
>>>> On 2026/04/20 2:19, Marc Zyngier wrote:
>>>>> On Sat, 18 Apr 2026 09:14:25 +0100,
>>>>> Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>>>>>>
>>>>>> On a heterogeneous arm64 system, KVM's PMU emulation is based on the
>>>>>> features of a single host PMU instance. When a vCPU is migrated to a
>>>>>> pCPU with an incompatible PMU, counters such as PMCCNTR_EL0 stop
>>>>>> incrementing.
>>>>>>
>>>>>> Although this behavior is permitted by the architecture, Windows does
>>>>>> not handle it gracefully and may crash with a division-by-zero error.
>>>>>>
>>>>>> The current workaround requires VMMs to pin vCPUs to a set of pCPUs
>>>>>> that share a compatible PMU. This is difficult to implement correctly in
>>>>>> QEMU/libvirt, where pinning occurs after vCPU initialization, and it
>>>>>> also restricts the guest to a subset of available pCPUs.
>>>>>>
>>>>>> Introduce the KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY attribute to
>>>>>> create a "fixed-counters-only" PMU. When set, KVM exposes a PMU that is
>>>>>> compatible with all pCPUs but that does not support programmable
>>>>>> event counters which may have different feature sets on different PMUs.
>>>>>>
>>>>>> This allows Windows guests to run reliably on heterogeneous systems
>>>>>> without crashing, even without vCPU pinning, and enables VMMs to
>>>>>> schedule vCPUs across all available pCPUs, making full use of the host
>>>>>> hardware.
>>>>>>
>>>>>> Much like KVM_ARM_VCPU_PMU_V3_IRQ and other read-write attributes, this
>>>>>> attribute provides a getter that facilitates kernel and userspace
>>>>>> debugging/testing.
>>>>>
>>>>> OK, so that's the sales pitch. But how is it implemented? I would like
>>>>> to be able to read a high-level description of the implementation
>>>>> trade-offs.
>>>>
>>>> Implementation-wise it is very trivial. Essentially the following
>>>> addition in kvm_arm_pmu_v3_get_attr() is the entire implementation:
>>>> + case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
>>>> + if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY,
>>>> &vcpu->kvm->arch.flags))
>>>> + return 0;
>>>>
>>>> Both its functionality and code complexity is trivial. So we can argue that:
>>>> - the functionality is too trivial to be useful or
>>>> - the interface/implementation complexity is so trivial that it does not
>>>> incur maintenance burden
>>>>
>>>> In this case the selftest uses the getter so I was more inclined to
>>>> have it, but adding one just for the selftest sounds too ad-hoc, so
>>>> here I looked into other attributes to ensure that it was not
>>>> introducing inconsistency with existing interfaces.
>>>>
>>>> As the result, I found there are other read-write attributes; in fact
>>>> there are more read-write attributes than write-only ones.
>>>
>>> You're completely missing the point. I'm referring to the whole of the
>>> commit message, which is more of a marketing slide than a technical
>>> description.
>>
>> In terms of implementation, the obvious tradeoff is that it adds more
>> code to implement the feature. One thing to note is that
>> kvm_vcpu_load_pmu() is added and is called each time a vCPU migrates
>> across pCPUs. The heavy part, making the KVM_REQ_RELOAD_PMU request,
>> only happens when the feature is enabled.
>
> Well, that's what I want to see. The repeated blurb about Windows
> being broken is cover letter material, but not fir for a commit
> message.
I understand. I'll leave the Windows issue the cover letter and write
focused patch messages after splitting patches.
>
> [...]
>
>>>>> "for the first time" gives the impression that it will work if you try
>>>>> again. I'd rather we say that "This feature is incompatible with the
>>>>> existence of a PMU event filter".
>>>>
>>>> The following sequence will work:
>>>> 1. Set KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY
>>>> 2. Set KVM_ARM_VCPU_PMU_V3_FILTER
>>>> 3. Set KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY
>>>>
>>>> This is to make the behavior conistent with KVM_ARM_VCPU_PMU_V3_SET_PMU.
>>>
>>> I don't think this is correct. Filtering is completely at odds with
>>> this patch, and I don't want to have to reason about the combination.
>>
>> kvm_arm_pmu_v3_set_pmu() has the following condition:
>>
>> if (kvm_vm_has_ran_once(kvm) ||
>> (kvm->arch.pmu_filter && kvm->arch.arm_pmu != arm_pmu)) {
>> ret = -EBUSY;
>> break;
>> }
>>
>> kvm_arm_pmu_v3_set_pmu_fixed_counters_only() has the corresponding
>> condition for consistency:
>>
>> if (kvm_vm_has_ran_once(kvm) ||
>> (kvm->arch.pmu_filter &&
>> !test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY,
>> &kvm->arch.flags)))
>> return -EBUSY;
>>
>> We can of course kill the PMU event filter for
>> FIXED_COUNTERS_ONLY. The filter is effectively no-op with
>> FIXED_COUNTERS_ONLY and I don't think that consistency matters much.
>
> We shouldn't allow weird combinations in the UAPI. Since it makes no
> sense to have both fixed-function *and* filters, we should make them
> mutually exclusive.
Then I think it makes sense to make KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS
mutually exclusive for consistency, but I found something weird with it.
The documentation says it already "mandates that a PMU has explicitly
been selected via KVM_ARM_VCPU_PMU_V3_SET_PMU", but apparently that's
not properly implemented.
kvm_arm_pmu_v3_set_nr_counters() has the following check:
if (!kvm->arch.arm_pmu)
return -EINVAL;
I suspect it is intended to check if a PMU has explicitly been selected,
but this check is effectively no-op because kvm_arm_set_default_pmu()
has already set kvm->arch.arm_pmu before reaching there.
Furthermore, tools/testing/selftests/kvm/arm64/vpmu_counter_access.c
seems to expect KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS to work without
selecting a PMU via KVM_ARM_VCPU_PMU_V3_SET_PMU.
How should we deal with the discrepancy between the documentation and
the implementation/selftest?
>
> [...]
>
>>>> I expect migration will be handled with the conventional register
>>>> getters and setters, but please share if you have a concern.
>>>
>>> At the very least I want to see some documentation explaining that.
>>
>> What kind of documentation do you expect?
>
> A description of what counters are exposed by this feature, and what
> architectural features they are dependent on.
I'll update the attribute documentation accordingly.
>
>> If we change kvm_vcpu_load_pmu() to avoid for_each_set_bit(), there
>> would be a good chance to forget updating it when mechanically
>> updating existing for_each_set_bit() instances, so it is a candidate
>> for documentation. But I don't have a good idea where to place it
>> either.
>
> The moment we introduce FEAT_PMUv3_ICNTR, the whole PMUv3 emulation
> will catch fire anyway, as we already limit ourselves to 32 bits for
> reset and nesting switch.
>
> So this will be a major redesign anyway. If you are really worried,
> leave a comment in there.
I'll leave one line comment in the implementation corresponding to the
attribute documentation.
Regards,
Akihiko Odaki
^ permalink raw reply
* Re: [PATCH v5 2/8] dt-bindings: arm: Add zx297520v3 board binding
From: Krzysztof Kozlowski @ 2026-04-22 7:06 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260421-send-v5-2-ace038e63515@gmail.com>
On Tue, Apr 21, 2026 at 11:23:10PM +0300, Stefan Dösinger wrote:
> +maintainers:
> + - Stefan Dösinger <stefandoesinger@gmail.com>
> +
> +properties:
> + $nodename:
> + const: "/"
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - dlink,dwr932m
> + - hgsd,r310
> + - tecno,tr118
> + - zte,k10
Where are users of these bindings? We do not need unused ABI.
Best regards,
Krzysztof
^ permalink raw reply
* Re: New warning in linus/master
From: Ricardo Ribalda @ 2026-04-22 7:00 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20260422071541-9a295128-d913-418f-a21c-1386fca30290@linutronix.de>
Hi Thomas
Thanks for the prompt reply
On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
<thomas.weissschuh@linutronix.de> wrote:
>
> Hi Ricardo,
>
> On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
> > Media-CI has found a couple of new warnings in the latest kernel
> > version for aarch64 and powerpc. They get fixed with this patch and
> > before moving I wanted to know if this was under your radar.
>
> Thanks for the report. I was not aware of these so far.
>
> > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > index 7dec05dd33b7..65914842fae0 100644
> > --- a/arch/arm64/kernel/vdso/Makefile
> > +++ b/arch/arm64/kernel/vdso/Makefile
> > @@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
> > CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
> >
> > ifneq ($(c-gettimeofday-y),)
> > - CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > + CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > -Wno-maybe-uninitialized
> > endif
>
> (...)
>
> I'd like to know exactly what is going on before suppressing the warning.
> It is a non-standard warning, only enabled by *some* of the vDSO builds
> for some reason.
>
> > https://gitlab.freedesktop.org/linux-media/users/ribalda/-/pipelines/1649144/test_report?job_name=cross-gcc
>
> While I was able to download a configuration from this job and also use the
> same container image, I can not reproduce the issue. Is the configuration the
> full one or only the template?
>
> Could you provide full reproduction steps?
You can try repro with:
work/linux $ podman run -v .:/workdir/ --rm -it
registry.freedesktop.org/linux-media/media-ci/build:latest
$ cd /workdir
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
arch/arm64/kernel/vdso/vgettimeofday.o
The gcc version discrepancy is because I the error was due to old gcc
version and I was playing around with that... but it fails in both
gcc14 and gcc15
You can try with debian testing with
work/linux$ podman run -v .:/workdir/ --rm -it debian:testing
$ apt-get update
$ apt-get install gcc-aarch64-linux-gnu build-essential flex bison libssl-dev bc
$ cd /workdir
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
arch/arm64/kernel/vdso/vgettimeofday.o
Regards!
>
> > CONFIG_CC_VERSION_TEXT="aarch64-linux-gnu-gcc (Debian 15.2.0-16) 15.2.0"
>
> The linked test log shows GCC 14.2, not 15.2.
> Not that I could reproduce it with either one...
>
> > SYNC include/config/auto.conf
> > CC arch/arm64/kernel/vdso/vgettimeofday.o
> > In file included from <command-line>:
> > In function ‘vdso_set_timespec’,
> > inlined from ‘do_aux’ at /workdir/lib/vdso/gettimeofday.c:266:2,
> > inlined from ‘__cvdso_clock_gettime_common’ at
> > /workdir/lib/vdso/gettimeofday.c:293:10,
> > inlined from ‘__cvdso_clock_gettime_data.constprop’ at
> > /workdir/lib/vdso/gettimeofday.c:306:7:
> > /workdir/lib/vdso/gettimeofday.c:104:26: warning: ‘sec’ may be used
> > uninitialized [-Wmaybe-uninitialized]
> > 104 | ts->tv_sec = sec + __iter_div_u64_rem(ns, NSEC_PER_SEC, &ns);
> > | ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > /workdir/lib/vdso/gettimeofday.c: In function
> > ‘__cvdso_clock_gettime_data.constprop’:
> > /workdir/lib/vdso/gettimeofday.c:242:13: note: ‘sec’ was declared here
> > 242 | u64 sec, ns;
> > | ^~~
>
> The same pattern is used in some other do_ handlers, which do not generate this
> warning. I also can't immediately see what is wrong.
>
> (...)
>
>
> Thomas
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH v4 35/49] KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive
From: Marc Zyngier @ 2026-04-22 6:55 UTC (permalink / raw)
To: Vishnu Pajjuri
Cc: Fuad Tabba, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Christoffer Dall, Mark Brown, kvm, linux-arm-kernel,
kvmarm, Darren Hart
In-Reply-To: <86a4vo49ni.wl-maz@kernel.org>
[+ Darren]
On Tue, 31 Mar 2026 10:42:57 +0100,
Marc Zyngier <maz@kernel.org> wrote:
>
> On Tue, 31 Mar 2026 07:31:54 +0100,
> Vishnu Pajjuri <vishnu@os.amperecomputing.com> wrote:
> >
> > >> LOG:
> > >> [ 164.647367] Call trace:
> > >> [ 164.647368] smp_call_function_many_cond+0x334/0x7a0 (P)
> > >> [ 164.647372] smp_call_function_many+0x20/0x40
> > >> [ 164.647374] kvm_make_all_cpus_request+0xec/0x1b8
> > >> [ 164.647377] vgic_queue_irq_unlock+0x1c8/0x2c8
> > >> [ 164.647380] kvm_vgic_inject_irq+0x194/0x1e0
> > >> [ 164.647381] kvm_vm_ioctl_irq_line+0x170/0x400
> > >> [ 164.647386] kvm_vm_ioctl+0x7b8/0xc88
> > >> [ 164.647389] __arm64_sys_ioctl+0xb4/0x118
> > >> [ 164.647393] invoke_syscall+0x6c/0x100
> > >> [ 164.647397] el0_svc_common.constprop.0+0x48/0xf0
> > >> [ 164.647398] do_el0_svc+0x24/0x38
> > >> [ 164.647400] el0_svc+0x3c/0x170
> > >> [ 164.647403] el0t_64_sync_handler+0xa0/0xe8
> > >> [ 164.647405] el0t_64_sync+0x1b0/0x1b8
> > >
> > > This trace is about interrupt injection from userspace, not
> > > deactivation of a HW interrupt.
> > > None of that makes much sense.
> >
> > Although this behavior is puzzling, it matches the trace I typically
> > observe on L0. After reverting the patch, I was able to boot L2 guests
> > successfully.
>
> Well, this patch fixes real bugs, so it isn't going anywhere.
>
> The patch you are reverting addresses the deactivation of a HW
> interrupt, which is likely to be a timer (that's the only one we
> support). The stacktrace points to the userspace injection of an SPI.
>
> If we need to broadcast IPI, that's because there is no other SPI
> currently in flight. But if a CPU is not responding to the IPI, what
> is it doing? How does this interact with the patch you are reverting?
>
> Given that I don't know what you're running, how you are running it,
> that I don't have access to whatever HW you are using, and that you
> are providing no useful information that'd help me debug this, I will
> leave it up to you to debug it and come back with a detailed analysis
> of the problem.
Have you made progress on this? I can't reproduce it at all despite my
best effort. I'm perfectly happy to help, but you need to give me
*something* to go on.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 02/20] drm/atomic: Drop drm_private_state.obj assignment from create_state
From: Maxime Ripard @ 2026-04-22 6:51 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Maarten Lankhorst, David Airlie, Simona Vetter, Jonathan Corbet,
Shuah Khan, Dmitry Baryshkov, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <bbb554a6-2034-4f6e-9b48-fa9e10b4a95a@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]
On Tue, Apr 21, 2026 at 03:03:50PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> > The initial intent of the atomic_create_state helper was to simply
> > allocate a proper drm_private_state and returning it, without any side
> > effect.
> >
> > However, the __drm_atomic_helper_private_obj_create_state() introduces a
> > side effect by setting the drm_private_obj.state to the newly allocated
> > state.
> >
> > This assignment defeats the purpose, but is also redundant since
> > the only caller, drm_atomic_private_obj_init(), will also set this
> > pointer to the newly allocated state.
>
> Is this paragraph no longer up to date? Grepping for
> __drm_atomic_helper_private_obj_create_state returns plenty of callers.
No, it's still up to date but super confusing. I didn't mean that there
wase one single caller of __drm_atomic_helper_private_obj_create_state()
that would set obj->state, but rather that the
drm_private_state_funcs.atomic_create_state hook is called only by
drm_atomic_private_obj_init() and it will set obj->state.
So, you're right, there's plenty of drivers calling
__drm_atomic_helper_private_obj_create_state() but we always end up
there through drm_atomic_private_obj_init().
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()
From: Geert Uytterhoeven @ 2026-04-22 6:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto, arm-scmi, linux-arm-kernel, linux-renesas-soc,
linux-clk, devicetree, linux-pm, linux-kernel
In-Reply-To: <72e2a0e7a5abda02fe36b3f5851842f7a77b2593.1776793163.git.geert+renesas@glider.be>
On Tue, 21 Apr 2026 at 20:12, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Currently non-SCMI drivers cannot find out what the specific versions of
> each SCMI provider implementation on the running system are.
>
> However, different versions may use different ABIs (e.g. different clock
> IDs), or behave different, requiring remapping or workarounds in other
> drivers.
>
> Add a public function to obtain base protocol information for the
> selected SCMI provider. This will be used by the R-Car X5H Clock Pulse
> Generator and Module Controller drivers.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -3504,6 +3504,37 @@ int scmi_inflight_count(const struct scmi_handle *handle)
> }
> }
>
> +/**
> + * scmi_get_base_info() - Get SCMI base protocol information
> + *
> + * @of_node: pointer to a device node for an SCMI provider
> + * @version: pointer to write base protocol information
> + *
> + * Check if an SCMI device has been instantiated for the passed device node
> + * pointer, and, if found, return its base info.
> +
Missing asterisk, reported by the kernel test robot.
> + * Return: 0 on Success or -ENOENT.
> + */
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 15/20] drm/drv: Call drm_mode_config_create_state() by default
From: Maxime Ripard @ 2026-04-22 6:45 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Maarten Lankhorst, David Airlie, Simona Vetter, Jonathan Corbet,
Shuah Khan, Dmitry Baryshkov, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <dd39f423-1598-4749-8c95-98b8daf69680@suse.de>
[-- Attachment #1: Type: text/plain, Size: 3483 bytes --]
Hi Thomas,
On Tue, Apr 21, 2026 at 05:33:12PM +0200, Thomas Zimmermann wrote:
> Am 21.04.26 um 15:38 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> > > Almost all drivers, and our documented skeleton, call
> > > drm_mode_config_reset() prior to calling drm_dev_register() to
> > > initialize its DRM object states.
> > >
> > > Now that we have drm_mode_config_create_state() to create that initial
> > > state if it doesn't exist, we can call it directly in
> > > drm_dev_register(). That way, we know that the initial atomic state will
> > > always be allocated without any boilerplate.
> > >
> > > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 2915118436ce8a6640cfb0c59936031990727ed1..820106d56ab399a39cac56d98662b5ddbcae8ded
> > > 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -1097,10 +1097,14 @@ int drm_dev_register(struct drm_device *dev,
> > > unsigned long flags)
> > > if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> > > ret = drm_modeset_register_all(dev);
> > > if (ret)
> > > goto err_unload;
> > > +
> > > + ret = drm_mode_config_create_state(dev);
> > > + if (ret)
> > > + goto err_unload;
> >
> > Way too late. Lets rather go through drivers and call this where they
> > currently call drm_mode_config_reset() for initialization. This can be a
> > single-patch mass conversion IMHO.
I think that was Ville's main objection too. He suggested to do it in
the object initialization instead, but I believe it would be too early.
> On a second thought, can't we modify the suspend code and leave the reset
> as-is for now? I'd still be interested to use reset as a means of
> initializing the hardware or loading state on probe. So keeping the _reset()
> calls in place might be helpful for that.
>
> What's the long-term plan here?
So, the way I was thinking about this is reset is done for several
things right now: initial state creation and software reset, and
hardware reset.
The latter isn't really commonly used. Most drivers, basically all
drivers that use the reset helpers, will not perform the hardware reset
as part of drm_mode_config_reset but will do it in probe or similar.
This is also a concern for hardware state read-out, since you don't want
that reset to happen.
So, eventually, I wanted to have something like try a readout, and if it
fails for any reason (disabled, unsupported, or failing to perform the
readout), we fallback to allocating a pristine state + resetting the
hardware.
To do that, we need create_state introduced here both for the readout
and non-readout paths, but also a (possibly device wide?) hw_reset hook
that will *only* reset the device without affecting the software state.
So:
- probe with readout would be create_state + readout_state for all objects
- probe without readout would be create_state + hw_reset for all objects
- resume would be create_state + hw_reset for a limited number of objects
And then we don't need .reset at all anymore and / or can implement
drm_mode_config_reset() on top of that.
I wanted to work on that next when done with this series.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Allow disabling Stage 1 translation
From: Evangelos Petrongonas @ 2026-04-22 6:44 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Nicolin Chen,
Pranjal Shrivastava, Lu Baolu, linux-arm-kernel, iommu,
linux-kernel, nh-open-source, Zeev Zilberman
In-Reply-To: <20260420124032.GO2577880@ziepe.ca>
On Mon, Apr 20, 2026 at 09:40:32AM -0300 Jason Gunthorpe wrote:
> On Mon, Apr 20, 2026 at 12:32:01PM +0000, Evangelos Petrongonas wrote:
> > When the hardware advertises both Stage 1 and Stage 2 translation, the
> > driver prefers Stage 1 for DMA domain allocation and only falls back to
> > Stage 2 if Stage 1 is not supported.
> >
> > Some configurations may want to force Stage 2 translation even when the
> > hardware supports Stage 1.
>
> Why? You really need to explain why for a patch like this.
>
> If there really is some HW issue I think it is more appropriate to get
> an IORT flag or IDR detection that the HW has a problem.
It's not a hardware bug there's no IORT or IDR bit that would make sense
here.
The motivation is live update of the hypervisor: we want to kexec into a
new kernel while keeping DMA from passthrough devices flowing, which
means the SMMU's translation state has to survive the handover. The Live
Update Orchestrator work [1] and the in-progress "iommu: Add live
update state preservation" series [2] are building exactly this plumbing
on top of KHO; [2]'s cover letter calls out Arm SMMUv3 support as future
work, and an earlier RFC from Amazon [3] sketched the same idea for
iommufd.
For this use case, Stage 2 is materially easier to persist than Stage 1,
for structural rather than performance reasons: An S2 STE carries the
whole translation configuration inline. To hand over an S2 domain, the
pre-kexec kernel only needs to preserve the stream table pages and the
S2 pgtable pages. An S1 STE points at a Context Descriptor table and as
a result Persisting S1 therefore requires preserving the CD table pages
too, and because the CD is keyed by ASID coordinating ASID identity
across the handover.
In the long term the plan should be to persist both stages.
However, until a patch series that properly introduces SMMU support for
is developed/posted we would like to experiment with S1+S2-capable
hardware with an easier to implement handover machinery, that relies on
S2 translations.
[1] https://lwn.net/Articles/1021442/ — Live Update Orchestrator
[2] https://lore.kernel.org/all/20260203220948.2176157-1-skhawaja@google.com/ —
[PATCH 00/14] iommu: Add live update state preservation
[3] https://lore.kernel.org/all/20240916113102.710522-1-jgowans@amazon.com/ — [RFC
PATCH 00/13] Support iommu(fd) persistence for live update
> Jason
Kind Regards,
Evangelos
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply
* Re: [PATCH v3 01/11] PCI: Propagate FLR return values to callers
From: Baolu Lu @ 2026-04-22 6:13 UTC (permalink / raw)
To: Nicolin Chen, Will Deacon, Robin Murphy, Joerg Roedel,
Bjorn Helgaas, Jason Gunthorpe
Cc: Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Kevin Tian, linux-arm-kernel, iommu, linux-kernel, linux-acpi,
linux-pci, vsethi, Shuai Xue
In-Reply-To: <8bc784e505dc04ca81582307c4a70babbf58eca0.1776381841.git.nicolinc@nvidia.com>
On 4/17/26 07:28, Nicolin Chen wrote:
> A reset failure implies that the device might be unreliable. E.g. its ATC
> might still retain stale entries. Thus, the IOMMU layer cannot trust this
> device to resume its ATS function that can lead to memory corruption. So,
> the pci_dev_reset_iommu_done() won't recover the device's IOMMU pathway if
> the device reset fails.
>
> Those functions in the pci_dev_reset_methods array invoke pcie_flr(), but
> do not check the return value. Propagate them correctly.
>
> Given that these functions have been running okay, and the return values
> will be only needed for an incoming work. This is not treated as bug fix.
>
> Suggested-by: Kevin Tian <kevin.tian@intel.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/pci/quirks.c | 22 ++++++++++++----------
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 48946cca4be72..05ce12b6b2f76 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3957,7 +3957,7 @@ static int reset_intel_82599_sfp_virtfn(struct pci_dev *dev, bool probe)
> * supported.
> */
> if (!probe)
> - pcie_flr(dev);
> + return pcie_flr(dev);
> return 0;
> }
>
> @@ -4015,6 +4015,7 @@ static int reset_chelsio_generic_dev(struct pci_dev *dev, bool probe)
> {
> u16 old_command;
> u16 msix_flags;
> + int ret;
>
> /*
> * If this isn't a Chelsio T4-based device, return -ENOTTY indicating
> @@ -4060,7 +4061,7 @@ static int reset_chelsio_generic_dev(struct pci_dev *dev, bool probe)
> PCI_MSIX_FLAGS_ENABLE |
> PCI_MSIX_FLAGS_MASKALL);
>
> - pcie_flr(dev);
> + ret = pcie_flr(dev);
It makes more sense to return early here on failure. There is no need to
perform the subsequent steps if pcie_flr() fails. Would something like
the following work?
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 757a296eae41..9e0f29ac9f95 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4015,6 +4015,7 @@ static int reset_chelsio_generic_dev(struct
pci_dev *dev, bool probe)
{
u16 old_command;
u16 msix_flags;
+ int ret;
/*
* If this isn't a Chelsio T4-based device, return -ENOTTY
indicating
@@ -4060,7 +4061,9 @@ static int reset_chelsio_generic_dev(struct
pci_dev *dev, bool probe)
PCI_MSIX_FLAGS_ENABLE |
PCI_MSIX_FLAGS_MASKALL);
- pcie_flr(dev);
+ ret = pcie_flr(dev);
+ if (ret)
+ return ret;
/*
* Restore the configuration information (BAR values, etc.)
including
>
> /*
> * Restore the configuration information (BAR values, etc.) including
> @@ -4069,7 +4070,7 @@ static int reset_chelsio_generic_dev(struct pci_dev *dev, bool probe)
> */
> pci_restore_state(dev);
> pci_write_config_word(dev, PCI_COMMAND, old_command);
> - return 0;
> + return ret;
> }
>
> #define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
> @@ -4152,9 +4153,7 @@ static int nvme_disable_and_flr(struct pci_dev *dev, bool probe)
>
> pci_iounmap(dev, bar);
>
> - pcie_flr(dev);
> -
> - return 0;
> + return pcie_flr(dev);
> }
>
> /*
> @@ -4166,14 +4165,16 @@ static int nvme_disable_and_flr(struct pci_dev *dev, bool probe)
> */
> static int delay_250ms_after_flr(struct pci_dev *dev, bool probe)
> {
> + int ret;
> +
> if (probe)
> return pcie_reset_flr(dev, PCI_RESET_PROBE);
>
> - pcie_reset_flr(dev, PCI_RESET_DO_RESET);
> + ret = pcie_reset_flr(dev, PCI_RESET_DO_RESET);
>
> msleep(250);
The same there, ...
>
> - return 0;
> + return ret;
> }
>
> #define PCI_DEVICE_ID_HINIC_VF 0x375E
> @@ -4189,6 +4190,7 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
> unsigned long timeout;
> void __iomem *bar;
> u32 val;
> + int ret;
>
> if (probe)
> return 0;
> @@ -4209,7 +4211,7 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
> val = val | HINIC_VF_FLR_PROC_BIT;
> iowrite32be(val, bar + HINIC_VF_OP);
>
> - pcie_flr(pdev);
> + ret = pcie_flr(pdev);
... and here.
>
> /*
> * The device must recapture its Bus and Device Numbers after FLR
> @@ -4236,7 +4238,7 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
> reset_complete:
> pci_iounmap(pdev, bar);
>
> - return 0;
> + return ret;
> }
>
> static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
Thanks,
baolu
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: add tqma9596la-mba95xxca
From: Alexander Stein @ 2026-04-22 5:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo, linux-arm-kernel
Cc: Markus Niebel, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc, Daniel Baluta
In-Reply-To: <4f436a21-ecfa-44ef-9002-c64ebd5e30ee@oss.nxp.com>
Am Dienstag, 21. April 2026, 16:48:25 CEST schrieb Daniel Baluta:
> [..]
>
> > +
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + linux_cma: linux,cma {
> > + compatible = "shared-dma-pool";
> > + reusable;
> > + size = <0 0x28000000>;
> > + alloc-ranges = <0 0x80000000 0 0x80000000>;
> > + linux,cma-default;
> > + };
> > +
> > + vpu_boot: vpu_boot@a0000000 {
>
> Should this be memory@a0000000 ?
According to schema in dt-schema repository [1] the node name should
describe the purpose, so I would keep that. But despite that it should be
vpu-boot@a0000000 (without underscore). But as this is unused for now,
I will remove it.
Thanks and best regards,
Alexander
[1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml#L25-L28
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: New warning in linus/master
From: Thomas Weißschuh @ 2026-04-22 5:56 UTC (permalink / raw)
To: Ricardo Ribalda; +Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <CANiDSCsOy0P1if-gJZqOM5pTJ0RDcwVfru1B7KFbTOEMqjPKJw@mail.gmail.com>
Hi Ricardo,
On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
> Media-CI has found a couple of new warnings in the latest kernel
> version for aarch64 and powerpc. They get fixed with this patch and
> before moving I wanted to know if this was under your radar.
Thanks for the report. I was not aware of these so far.
> diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> index 7dec05dd33b7..65914842fae0 100644
> --- a/arch/arm64/kernel/vdso/Makefile
> +++ b/arch/arm64/kernel/vdso/Makefile
> @@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
> CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
>
> ifneq ($(c-gettimeofday-y),)
> - CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> + CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> -Wno-maybe-uninitialized
> endif
(...)
I'd like to know exactly what is going on before suppressing the warning.
It is a non-standard warning, only enabled by *some* of the vDSO builds
for some reason.
> https://gitlab.freedesktop.org/linux-media/users/ribalda/-/pipelines/1649144/test_report?job_name=cross-gcc
While I was able to download a configuration from this job and also use the
same container image, I can not reproduce the issue. Is the configuration the
full one or only the template?
Could you provide full reproduction steps?
> CONFIG_CC_VERSION_TEXT="aarch64-linux-gnu-gcc (Debian 15.2.0-16) 15.2.0"
The linked test log shows GCC 14.2, not 15.2.
Not that I could reproduce it with either one...
> SYNC include/config/auto.conf
> CC arch/arm64/kernel/vdso/vgettimeofday.o
> In file included from <command-line>:
> In function ‘vdso_set_timespec’,
> inlined from ‘do_aux’ at /workdir/lib/vdso/gettimeofday.c:266:2,
> inlined from ‘__cvdso_clock_gettime_common’ at
> /workdir/lib/vdso/gettimeofday.c:293:10,
> inlined from ‘__cvdso_clock_gettime_data.constprop’ at
> /workdir/lib/vdso/gettimeofday.c:306:7:
> /workdir/lib/vdso/gettimeofday.c:104:26: warning: ‘sec’ may be used
> uninitialized [-Wmaybe-uninitialized]
> 104 | ts->tv_sec = sec + __iter_div_u64_rem(ns, NSEC_PER_SEC, &ns);
> | ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /workdir/lib/vdso/gettimeofday.c: In function
> ‘__cvdso_clock_gettime_data.constprop’:
> /workdir/lib/vdso/gettimeofday.c:242:13: note: ‘sec’ was declared here
> 242 | u64 sec, ns;
> | ^~~
The same pattern is used in some other do_ handlers, which do not generate this
warning. I also can't immediately see what is wrong.
(...)
Thomas
^ permalink raw reply
* Re: [PATCH] soc: ti: k3-ringacc: Fix access mode for k3_ringacc_ring_pop_tail_io()
From: Siddharth Vadapalli @ 2026-04-22 4:54 UTC (permalink / raw)
To: Hari Prasath G E
Cc: nm, ssantosh, stable, linux-kernel, linux-arm-kernel, srk,
s-adivi, s-vadapalli
In-Reply-To: <d36239c2-98d5-4e5b-b99e-470f4d753a52@ti.com>
On 21/04/26 21:20, Hari Prasath G E wrote:
> Hello Siddharth,
>
> Thanks for the patch.
>
> On 4/13/2026 12:21 PM, Siddharth Vadapalli wrote:
>> k3_ringacc_ring_pop_tail_io() invokes k3_ringacc_ring_access_io() with the
>> access mode incorrectly set to K3_RINGACC_ACCESS_MODE_POP_HEAD instead of
>> K3_RINGACC_ACCESS_MODE_POP_TAIL. Fix this.
>>
>> Fixes: 3277e8aa2504 ("soc: ti: k3: add navss ringacc driver")
>> Cc: <stable@vger.kernel.org>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> ---
>>
>> Hello,
>>
>> This patch is based on commit
>> 028ef9c96e96 Linux 7.0
>> of Mainline Linux.
>>
>> I noticed (visually) the incorrect access mode while working on:
>> https://lore.kernel.org/r/20260325123850.638748-1-s-vadapalli@ti.com/
>>
>> Regards,
>> Siddharth.
>>
>> drivers/soc/ti/k3-ringacc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
>> index 7602b8a909b0..24f658e8c1dc 100644
>> --- a/drivers/soc/ti/k3-ringacc.c
>> +++ b/drivers/soc/ti/k3-ringacc.c
>> @@ -1083,7 +1083,7 @@ static int k3_ringacc_ring_pop_io(struct k3_ring
>> *ring, void *elem)
>> static int k3_ringacc_ring_pop_tail_io(struct k3_ring *ring, void *elem)
>> {
>> return k3_ringacc_ring_access_io(ring, elem,
>> - K3_RINGACC_ACCESS_MODE_POP_HEAD);
>> + K3_RINGACC_ACCESS_MODE_POP_TAIL);
>
> I see that you have noticed this visually and fixed this,was there any
> impact you faced without this change like data corruption or something ?
I haven't tested it with / without the fix above. But if I have to guess,
the impact will be out-of-order completions for transmit descriptors and
out-of-order of packets on receive. Although I have described it in the
context of Networking, the out-of-order (reversed order to be precise)
issue will be faced by any user.
> It would be better to mention the impact this change brings-in by doing
> some analysis.
>
> There is a similar function k3_ringacc_ring_pop_tail_proxy() few lines
> above where the same change might be required.
Thank you for pointing it out. I will fix that function as well in the v2
patch.
Regards,
Siddharth.
^ permalink raw reply
* Re: [PATCH v2] pwm: atmel-tcb: Cache clock rates and mark chip as atomic
From: Sangyun Kim @ 2026-04-22 4:49 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: nicolas.ferre, alexandre.belloni, claudiu.beznea, linux-pwm,
linux-arm-kernel, linux-kernel
In-Reply-To: <aedfEzeRH5tH0-Fb@monoceros>
On Tue, Apr 21, 2026 at 01:40:55 PM +0200, Uwe Kleine-König wrote:
>Hello Sangyun,
Hi Uwe,
Thanks for the review.
>
>On Sun, Apr 19, 2026 at 05:08:38PM +0900, Sangyun Kim wrote:
>> @@ -438,16 +441,33 @@ static int atmel_tcb_pwm_probe(struct platform_device *pdev)
>> if (err)
>> goto err_gclk;
>>
>> + err = clk_rate_exclusive_get(tcbpwmc->clk);
>> + if (err)
>> + goto err_disable_clk;
>> +
>> + err = clk_rate_exclusive_get(tcbpwmc->slow_clk);
>> + if (err)
>> + goto err_clk_unlock;
>> +
>> + tcbpwmc->rate = clk_get_rate(tcbpwmc->clk);
>> + tcbpwmc->slow_rate = clk_get_rate(tcbpwmc->slow_clk);
>> +
>
>Only one concern left: clk_get_rate() should only be called on enabled
>clocks. I don't know the architecture details and how expensive it is to
>have .clk enabled (or if it's enabled anyhow).
>
>If you're ok, I'd squash the following diff into your patch:
That makes sense. clk_get_rate() should indeed only be used on enabled
clocks, and your change is the simplest way to ensure correctness while
respecting the clk API constraints. I’m happy with squashing your diff
into my patch.
>
>diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
>index 1a2832f1ace2..3d30aeab507e 100644
>--- a/drivers/pwm/pwm-atmel-tcb.c
>+++ b/drivers/pwm/pwm-atmel-tcb.c
>@@ -437,13 +437,17 @@ static int atmel_tcb_pwm_probe(struct platform_device *pdev)
> tcbpwmc->channel = channel;
> tcbpwmc->width = config->counter_width;
>
>- err = clk_prepare_enable(tcbpwmc->slow_clk);
>+ err = clk_prepare_enable(tcbpwmc->clk);
> if (err)
> goto err_gclk;
>
>+ err = clk_prepare_enable(tcbpwmc->slow_clk);
>+ if (err)
>+ goto err_disable_clk;;
>+
> err = clk_rate_exclusive_get(tcbpwmc->clk);
> if (err)
>- goto err_disable_clk;
>+ goto err_disable_slow_clk;
>
> err = clk_rate_exclusive_get(tcbpwmc->slow_clk);
> if (err)
>@@ -469,6 +473,9 @@ static int atmel_tcb_pwm_probe(struct platform_device *pdev)
> clk_rate_exclusive_put(tcbpwmc->clk);
>
> err_disable_clk:
>+ clk_disable_unprepare(tcbpwmc->clk);
>+
>+err_disable_slow_clk:
> clk_disable_unprepare(tcbpwmc->slow_clk);
>
> err_gclk:
>@@ -492,6 +499,7 @@ static void atmel_tcb_pwm_remove(struct platform_device *pdev)
>
> clk_rate_exclusive_put(tcbpwmc->slow_clk);
> clk_rate_exclusive_put(tcbpwmc->clk);
>+ clk_disable_unprepare(tcbpwmc->clk);
> clk_disable_unprepare(tcbpwmc->slow_clk);
> clk_put(tcbpwmc->gclk);
> clk_put(tcbpwmc->clk);
>
>
>This has the downside that clk is kept enabled the whole driver
>lifetime, but that's the easiest way to make your fix honor the clk API
>constraints. This allows to fast-track the patch fixing the sleeping
>function called from invalid context issue and the optimisation can then
>be addressed with more time during the next development cycles.
Keeping the clock enabled for the driver lifetime is acceptable for now
to fast-track the fix, and we can revisit potential optimizations in a
follow-up patch.
Thanks again for the suggestion.
>
>Best regards
>Uwe
Best regards,
Sangyun
^ permalink raw reply
* [PATCH net v6] net: stmmac: Prevent NULL deref when RX memory exhausted
From: Sam Edwards @ 2026-04-22 4:45 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Maxime Coquelin, Alexandre Torgue, Russell King (Oracle),
Maxime Chevallier, Ovidiu Panait, Vladimir Oltean, Baruch Siach,
Serge Semin, Giuseppe Cavallaro, netdev, linux-stm32,
linux-arm-kernel, linux-kernel, Sam Edwards, stable, Russell King
The CPU receives frames from the MAC through conventional DMA: the CPU
allocates buffers for the MAC, then the MAC fills them and returns
ownership to the CPU. For each hardware RX queue, the CPU and MAC
coordinate through a shared ring array of DMA descriptors: one
descriptor per DMA buffer. Each descriptor includes the buffer's
physical address and a status flag ("OWN") indicating which side owns
the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set
the flag and the MAC is only allowed to clear it, and both must move
through the ring in sequence: thus the ring is used for both
"submissions" and "completions."
In the stmmac driver, stmmac_rx() bookmarks its position in the ring
with the `cur_rx` index. The main receive loop in that function checks
for rx_descs[cur_rx].own=0, gives the corresponding buffer to the
network stack (NULLing the pointer), and increments `cur_rx` modulo the
ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its
position with `dirty_rx`, allocates fresh buffers and rearms the
descriptors (setting OWN=1). If it fails any allocation, it simply stops
early (leaving OWN=0) and will retry where it left off when next called.
This means descriptors have a three-stage lifecycle (terms my own):
- `empty` (OWN=1, buffer valid)
- `full` (OWN=0, buffer valid and populated)
- `dirty` (OWN=0, buffer NULL)
But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In
the past (see 'Fixes:'), there was a bug where the loop could cycle
`cur_rx` all the way back to the first descriptor it dirtied, resulting
in a NULL dereference when mistaken for `full`. The aforementioned
commit resolved that *specific* failure by capping the loop's iteration
limit at `dma_rx_size - 1`, but this is only a partial fix: if the
previous stmmac_rx_refill() didn't complete, then there are leftover
`dirty` descriptors that the loop might encounter without needing to
cycle fully around. The current code therefore panics (see 'Closes:')
when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to
catch up to `dirty_rx`.
Fix this by explicitly checking, before advancing `cur_rx`, if the next
entry is dirty; exit the loop if so. This prevents processing of the
final, used descriptor until stmmac_rx_refill() succeeds, but
fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix
intended: so remove the clamp as well. Since stmmac_rx_zc() is a
copy-paste-and-tweak of stmmac_rx() and the code structure is identical,
any fix to stmmac_rx() will also need a corresponding fix for
stmmac_rx_zc(). Therefore, apply the same check there.
In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the
MAC sets OWN=0 on the final descriptor, it will be unable to send any
further DMA-complete IRQs until it's given more `empty` descriptors.
Currently, the driver simply *hopes* that the next stmmac_rx_refill()
succeeds, risking an indefinite stall of the receive process if not. But
this is not a regression, so it can be addressed in a future change.
Fixes: b6cb4541853c7 ("net: stmmac: avoid rx queue overrun")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221010
Cc: stable@vger.kernel.org
Suggested-by: Russell King <linux@armlinux.org.uk>
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
---
This is v6 of [1], which was itself split out of [2]. This patch prevents a
NULL dereference in the stmmac receive path, and (at Russell's suggestion) in
the zero-copy path as well.
The approach is different from the previous version and checks the dirty_rx
index in the loop proper, copied directly from Russell's suggestion [3]. Parts
of the commit message also use his phrasing. For these reasons he is credited
with `Suggested-by`.
The commit message now acknowledges the pipeline stall that can occur in case
of failure of the next stmmac_rx_refill() after the MAC consumes the final
descriptor. I still intend to fix that bug when I can find the time to finish
investigating and implement the timer as requested by Jakub, however I'm
sending this patch now to resolve the outright _panic_ and simplify review.
The stmmac_rx_zc() path is not affected by this stall.
[1] https://lore.kernel.org/netdev/20260415023947.7627-1-CFSworks@gmail.com/
[2] https://lore.kernel.org/netdev/20260401041929.12392-1-CFSworks@gmail.com/
[3] https://lore.kernel.org/netdev/ad-LAB08-_rpmMzK@shell.armlinux.org.uk/
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ca68248dbc78..3591755ea30b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5549,9 +5549,12 @@ static int stmmac_rx_zc(struct stmmac_priv *priv, int limit, u32 queue)
break;
/* Prefetch the next RX descriptor */
- rx_q->cur_rx = STMMAC_NEXT_ENTRY(rx_q->cur_rx,
- priv->dma_conf.dma_rx_size);
- next_entry = rx_q->cur_rx;
+ next_entry = STMMAC_NEXT_ENTRY(rx_q->cur_rx,
+ priv->dma_conf.dma_rx_size);
+ if (unlikely(next_entry == rx_q->dirty_rx))
+ break;
+
+ rx_q->cur_rx = next_entry;
np = stmmac_get_rx_desc(priv, rx_q, next_entry);
@@ -5686,7 +5689,6 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
dma_dir = page_pool_get_dma_dir(rx_q->page_pool);
bufsz = DIV_ROUND_UP(priv->dma_conf.dma_buf_sz, PAGE_SIZE) * PAGE_SIZE;
- limit = min(priv->dma_conf.dma_rx_size - 1, (unsigned int)limit);
if (netif_msg_rx_status(priv)) {
void *rx_head = stmmac_get_rx_desc(priv, rx_q, 0);
@@ -5733,9 +5735,12 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
if (unlikely(status & dma_own))
break;
- rx_q->cur_rx = STMMAC_NEXT_ENTRY(rx_q->cur_rx,
- priv->dma_conf.dma_rx_size);
- next_entry = rx_q->cur_rx;
+ next_entry = STMMAC_NEXT_ENTRY(rx_q->cur_rx,
+ priv->dma_conf.dma_rx_size);
+ if (unlikely(next_entry == rx_q->dirty_rx))
+ break;
+
+ rx_q->cur_rx = next_entry;
np = stmmac_get_rx_desc(priv, rx_q, next_entry);
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v5 3/4] thermal: qoriq: workaround unexpected temperature readings from tmu
From: Frank Li @ 2026-04-22 3:56 UTC (permalink / raw)
To: Jacky Bai
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB6861B0C33CF3030D6C9293B8872C2@VI1PR04MB6861.eurprd04.prod.outlook.com>
On Tue, Apr 21, 2026 at 09:56:18AM +0000, Jacky Bai wrote:
> > Subject: Re: [PATCH v5 3/4] thermal: qoriq: workaround unexpected
> > temperature readings from tmu
> >
>
> [...]
>
> > >
> > > + /* ERR052243: If a raising or falling edge happens, try later */
> > > + if (qoriq_tmu_has_errata(qdata->drvdata, TMU_ERR052243)) {
> > > + regmap_read(qdata->regmap, REGS_TIDR, &tidr);
> > > + if (tidr & TEMP_RATE_IRQ_MASK) {
> > > + regmap_write(qdata->regmap, REGS_TIDR,
> > TEMP_RATE_IRQ_MASK);
> > > + return -EAGAIN;
> > > + }
> > > + }
> > > +
> > > if (regmap_read_poll_timeout(qdata->regmap,
> > > REGS_TRITSR(qsensor->id),
> > > val,
> > > @@ -130,6 +159,15 @@ static int tmu_get_temp(struct
> > thermal_zone_device *tz, int *temp)
> > > 10 * USEC_PER_MSEC))
> > > return -ENODATA;
> > >
> > > + /*ERR052243: If a raising or falling edge happens, try later */
> > > + if (qoriq_tmu_has_errata(qdata->drvdata, TMU_ERR052243)) {
> > > + regmap_read(qdata->regmap, REGS_TIDR, &tidr);
> > > + if (tidr & TEMP_RATE_IRQ_MASK) {
> > > + regmap_write(qdata->regmap, REGS_TIDR,
> > TEMP_RATE_IRQ_MASK);
> > > + return -EAGAIN;
> > > + }
> > > + }
> > > +
> >
> > The above two code blocks are the same. Use helper function to avoid
> > duplicat code. And why need check twice?
> >
> > ret = qoriq_tmu_err052243()
> > if (ret)
> > return ret;
> >
>
> The first check is to make sure no error already happened. if any error, no need
> to polling read the sensor value from tmu, return early to save time. The secondary
> check is to make sure the sensor value just read out is still a valid one as the error may
> happen after the first check.
>
> It should be ok to remove the first check. As the error only happens in some rare
> corner case, the sensor read polling delay is acceptable.
>
> If only keep the secondary check, I think no need to wrap this code block into a helper function?
Yes
Frank
>
> BR
>
> > Frank
> >
> > > if (qdata->ver == TMU_VER1) {
> > > *temp = (val & GENMASK(7, 0)) * MILLIDEGREE_PER_DEGREE;
> > > } else {
> > > @@ -247,6 +285,14 @@ static void qoriq_tmu_init_device(struct
> > qoriq_tmu_data *data)
> > > regmap_write(data->regmap, REGS_V2_TEUMR(0), teumr0_val);
> > > }
> > >
> > > + /* ERR052243: Set the raising & falling edge monitor */
> > > + if (qoriq_tmu_has_errata(data->drvdata, TMU_ERR052243)) {
> > > + regmap_write(data->regmap, TMRTRCTR, TMRTRCTR_EN |
> > > + FIELD_PREP(TMRTRCTR_TEMP_MASK,
> > TEMP_RATE_THR_LVL));
> > > + regmap_write(data->regmap, TMFTRCTR, TMFTRCTR_EN |
> > > + FIELD_PREP(TMFTRCTR_TEMP_MASK,
> > TEMP_RATE_THR_LVL));
> > > +
> > > + }
> > > /* Disable monitoring */
> > > regmap_write(data->regmap, REGS_TMR, TMR_DISABLE); } @@
> > -400,6
> > > +446,7 @@ static const struct tmu_drvdata imx8mq_tmu_data = {
> > >
> > > static const struct tmu_drvdata imx93_data = {
> > > .teumr0 = TEUMR0_V21,
> > > + .tmu_errata = TMU_ERR052243,
> > > };
> > >
> > > static const struct of_device_id qoriq_tmu_match[] = {
> > >
> > > --
> > > 2.34.1
> > >
^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: imx95: switch usb3 controller to flattened model
From: Frank Li @ 2026-04-22 3:53 UTC (permalink / raw)
To: Xu Yang
Cc: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, devicetree,
imx, linux-arm-kernel, linux-kernel, jun.li
In-Reply-To: <20260421105503.1416566-2-xu.yang_2@nxp.com>
On Tue, Apr 21, 2026 at 06:55:01PM +0800, Xu Yang wrote:
> Switch to use flattened model for USB3 controller. To enable USB
> controller with restricted DMA access range to work correctly, add a
> pseudo simple-bus to constrain the dma address.
i.mx95 should fix >4G dma space's problem. Does it impact other no-nxp
boards?
Need do break compatible judgement such as
i.MX95 is new SoC and still is heave development. The break compatible is
accepable at development early phase.
You can rephrase it.
Frank
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx95.dtsi | 48 ++++++++++++------------
> 1 file changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
> index 71394871d8dd..91048501a692 100644
> --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
> @@ -1772,45 +1772,45 @@ smmu: iommu@490d0000 {
> };
> };
>
> - usb3: usb@4c010010 {
> - compatible = "fsl,imx95-dwc3", "fsl,imx8mp-dwc3";
> - reg = <0x0 0x4c010010 0x0 0x04>,
> - <0x0 0x4c1f0000 0x0 0x20>;
> - clocks = <&scmi_clk IMX95_CLK_HSIO>,
> - <&scmi_clk IMX95_CLK_32K>;
> - clock-names = "hsio", "suspend";
> - interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
> + hsio_blk_ctl: syscon@4c0100c0 {
> + compatible = "nxp,imx95-hsio-blk-ctl", "syscon";
> + reg = <0x0 0x4c0100c0 0x0 0x1>;
> + #clock-cells = <1>;
> + clocks = <&clk_sys100m>;
> + power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
> + };
> +
> + bus@4c100000 {
> + compatible = "simple-bus";
> #address-cells = <2>;
> #size-cells = <2>;
> - ranges;
> - power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
> dma-ranges = <0x0 0x0 0x0 0x0 0x10 0x0>;
> - status = "disabled";
> + ranges;
>
> - usb3_dwc3: usb@4c100000 {
> - compatible = "snps,dwc3";
> - reg = <0x0 0x4c100000 0x0 0x10000>;
> + usb3: usb3_dwc3: usb@4c100000 {
> + compatible = "nxp,imx8mp-dwc3";
> + reg = <0x0 0x4c100000 0x0 0x10000>,
> + <0x0 0x4c010010 0x0 0x04>,
> + <0x0 0x4c1f0000 0x0 0x20>;
> + reg-names = "core", "blkctl", "glue";
> clocks = <&scmi_clk IMX95_CLK_HSIO>,
> + <&scmi_clk IMX95_CLK_HSIO>,
> <&scmi_clk IMX95_CLK_24M>,
> <&scmi_clk IMX95_CLK_32K>;
> - clock-names = "bus_early", "ref", "suspend";
> - interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "hsio", "bus_early", "ref", "suspend";
> + interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "dwc_usb3", "wakeup";
> + power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
> phys = <&usb3_phy>, <&usb3_phy>;
> phy-names = "usb2-phy", "usb3-phy";
> snps,gfladj-refclk-lpm-sel-quirk;
> snps,parkmode-disable-ss-quirk;
> iommus = <&smmu 0xe>;
> + status = "disabled";
> };
> };
>
> - hsio_blk_ctl: syscon@4c0100c0 {
> - compatible = "nxp,imx95-hsio-blk-ctl", "syscon";
> - reg = <0x0 0x4c0100c0 0x0 0x1>;
> - #clock-cells = <1>;
> - clocks = <&clk_sys100m>;
> - power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
> - };
> -
> usb3_phy: phy@4c1f0040 {
> compatible = "fsl,imx95-usb-phy", "fsl,imx8mp-usb-phy";
> reg = <0x0 0x4c1f0040 0x0 0x40>,
> --
> 2.34.1
>
^ permalink raw reply
* New warning in linus/master
From: Ricardo Ribalda @ 2026-04-22 3:51 UTC (permalink / raw)
To: Thomas Weißschuh, linux-arm-kernel,
Linux Kernel Mailing List, linuxppc-dev
Hi Thomas
Media-CI has found a couple of new warnings in the latest kernel
version for aarch64 and powerpc. They get fixed with this patch and
before moving I wanted to know if this was under your radar.
diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index 7dec05dd33b7..65914842fae0 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
ifneq ($(c-gettimeofday-y),)
- CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
+ CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
-Wno-maybe-uninitialized
endif
ifneq ($(c-getrandom-y),)
diff --git a/arch/powerpc/kernel/vdso/Makefile
b/arch/powerpc/kernel/vdso/Makefile
index 8834dfe9d727..4b8d40b1dfeb 100644
--- a/arch/powerpc/kernel/vdso/Makefile
+++ b/arch/powerpc/kernel/vdso/Makefile
@@ -12,12 +12,12 @@ obj-vdso32 += getrandom-32.o vgetrandom-chacha-32.o
obj-vdso64 += getrandom-64.o vgetrandom-chacha-64.o
ifneq ($(c-gettimeofday-y),)
- CFLAGS_vgettimeofday-32.o += -include $(c-gettimeofday-y)
+ CFLAGS_vgettimeofday-32.o += -include $(c-gettimeofday-y)
-Wno-maybe-uninitialized
# Go prior to 1.16.x assumes r30 is not clobbered by any VDSO code.
That used to be true
# by accident when the VDSO was hand-written asm code, but may not be
now that the VDSO is
# compiler generated. To avoid breaking Go tell GCC not to use r30.
Impact on code
# generation is minimal, it will just use r29 instead.
- CFLAGS_vgettimeofday-64.o += -include $(c-gettimeofday-y) $(call
cc-option, -ffixed-r30)
+ CFLAGS_vgettimeofday-64.o += -include $(c-gettimeofday-y) $(call
cc-option, -ffixed-r30) -Wno-maybe-uninitialized
endif
ifneq ($(c-getrandom-y),)
https://gitlab.freedesktop.org/linux-media/users/ribalda/-/pipelines/1649144/test_report?job_name=cross-gcc
CONFIG_CC_VERSION_TEXT="aarch64-linux-gnu-gcc (Debian 15.2.0-16) 15.2.0"
SYNC include/config/auto.conf
CC arch/arm64/kernel/vdso/vgettimeofday.o
In file included from <command-line>:
In function ‘vdso_set_timespec’,
inlined from ‘do_aux’ at /workdir/lib/vdso/gettimeofday.c:266:2,
inlined from ‘__cvdso_clock_gettime_common’ at
/workdir/lib/vdso/gettimeofday.c:293:10,
inlined from ‘__cvdso_clock_gettime_data.constprop’ at
/workdir/lib/vdso/gettimeofday.c:306:7:
/workdir/lib/vdso/gettimeofday.c:104:26: warning: ‘sec’ may be used
uninitialized [-Wmaybe-uninitialized]
104 | ts->tv_sec = sec + __iter_div_u64_rem(ns, NSEC_PER_SEC, &ns);
| ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/workdir/lib/vdso/gettimeofday.c: In function
‘__cvdso_clock_gettime_data.constprop’:
/workdir/lib/vdso/gettimeofday.c:242:13: note: ‘sec’ was declared here
242 | u64 sec, ns;
| ^~~
In file included from /workdir/lib/vdso/gettimeofday.c:11:
In function ‘__iter_div_u64_rem’,
inlined from ‘vdso_set_timespec’ at /workdir/lib/vdso/gettimeofday.c:104:21,
inlined from ‘do_aux’ at /workdir/lib/vdso/gettimeofday.c:266:2,
inlined from ‘__cvdso_clock_gettime_common’ at
/workdir/lib/vdso/gettimeofday.c:293:10,
inlined from ‘__cvdso_clock_gettime_data.constprop’ at
/workdir/lib/vdso/gettimeofday.c:306:7:
./include/vdso/math64.h:10:25: warning: ‘ns’ may be used uninitialized
[-Wmaybe-uninitialized]
10 | while (dividend >= divisor) {
| ~~~~~~~~~^~~~~~~~~~
/workdir/lib/vdso/gettimeofday.c: In function
‘__cvdso_clock_gettime_data.constprop’:
/workdir/lib/vdso/gettimeofday.c:242:18: note: ‘ns’ was declared here
242 | u64 sec, ns;
| ^~
LD arch/arm64/kernel/vdso/vdso.so.dbg
VDSOSYM include/generated/vdso-offsets.h
OBJCOPY arch/arm64/kernel/vdso/vdso.so
/workdir/lib/vdso/gettimeofday.c:104:26: warning: ‘sec’ may be used
uninitialized [-Wmaybe-uninitialized]
./include/vdso/math64.h:10:25: warning: ‘ns’ may be used uninitialized
[-Wmaybe-uninitialized]
CONFIG_CC_VERSION_TEXT="powerpc64-linux-gnu-gcc (Debian 15.2.0-15) 15.2.0"
SYNC include/config/auto.conf
VDSO32C arch/powerpc/kernel/vdso/vgettimeofday-32.o
In file included from <command-line>:
In function ‘vdso_set_timespec’,
inlined from ‘do_aux’ at /workdir/lib/vdso/gettimeofday.c:266:2,
inlined from ‘__cvdso_clock_gettime_common’ at
/workdir/lib/vdso/gettimeofday.c:293:10,
inlined from ‘__cvdso_clock_gettime32_data’ at
/workdir/lib/vdso/gettimeofday.c:327:7:
/workdir/lib/vdso/gettimeofday.c:104:26: warning: ‘sec’ may be used
uninitialized [-Wmaybe-uninitialized]
104 | ts->tv_sec = sec + __iter_div_u64_rem(ns, NSEC_PER_SEC, &ns);
| ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/workdir/lib/vdso/gettimeofday.c: In function ‘__cvdso_clock_gettime32_data’:
/workdir/lib/vdso/gettimeofday.c:242:13: note: ‘sec’ was declared here
242 | u64 sec, ns;
| ^~~
In file included from /workdir/lib/vdso/gettimeofday.c:11:
In function ‘__iter_div_u64_rem’,
inlined from ‘vdso_set_timespec’ at /workdir/lib/vdso/gettimeofday.c:104:21,
inlined from ‘do_aux’ at /workdir/lib/vdso/gettimeofday.c:266:2,
inlined from ‘__cvdso_clock_gettime_common’ at
/workdir/lib/vdso/gettimeofday.c:293:10,
inlined from ‘__cvdso_clock_gettime32_data’ at
/workdir/lib/vdso/gettimeofday.c:327:7:
./include/vdso/math64.h:10:25: warning: ‘ns’ may be used uninitialized
[-Wmaybe-uninitialized]
10 | while (dividend >= divisor) {
| ~~~~~~~~~^~~~~~~~~~
/workdir/lib/vdso/gettimeofday.c: In function ‘__cvdso_clock_gettime32_data’:
/workdir/lib/vdso/gettimeofday.c:242:18: note: ‘ns’ was declared here
242 | u64 sec, ns;
| ^~
In function ‘vdso_set_timespec’,
inlined from ‘do_aux’ at /workdir/lib/vdso/gettimeofday.c:266:2,
inlined from ‘__cvdso_clock_gettime_common’ at
/workdir/lib/vdso/gettimeofday.c:293:10,
inlined from ‘__cvdso_clock_gettime_data’ at
/workdir/lib/vdso/gettimeofday.c:306:7:
/workdir/lib/vdso/gettimeofday.c:104:26: warning: ‘sec’ may be used
uninitialized [-Wmaybe-uninitialized]
104 | ts->tv_sec = sec + __iter_div_u64_rem(ns, NSEC_PER_SEC, &ns);
| ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/workdir/lib/vdso/gettimeofday.c: In function ‘__cvdso_clock_gettime_data’:
/workdir/lib/vdso/gettimeofday.c:242:13: note: ‘sec’ was declared here
242 | u64 sec, ns;
| ^~~
In function ‘__iter_div_u64_rem’,
inlined from ‘vdso_set_timespec’ at /workdir/lib/vdso/gettimeofday.c:104:21,
inlined from ‘do_aux’ at /workdir/lib/vdso/gettimeofday.c:266:2,
inlined from ‘__cvdso_clock_gettime_common’ at
/workdir/lib/vdso/gettimeofday.c:293:10,
inlined from ‘__cvdso_clock_gettime_data’ at
/workdir/lib/vdso/gettimeofday.c:306:7:
./include/vdso/math64.h:10:25: warning: ‘ns’ may be used uninitialized
[-Wmaybe-uninitialized]
10 | while (dividend >= divisor) {
| ~~~~~~~~~^~~~~~~~~~
/workdir/lib/vdso/gettimeofday.c: In function ‘__cvdso_clock_gettime_data’:
/workdir/lib/vdso/gettimeofday.c:242:18: note: ‘ns’ was declared here
242 | u64 sec, ns;
| ^~
VDSO32L arch/powerpc/kernel/vdso/vdso32.so.dbg
VDSO32SYM include/generated/vdso32-offsets.h
CC arch/powerpc/kernel/vdso/vgettimeofday-64.o
VDSO64L arch/powerpc/kernel/vdso/vdso64.so.dbg
VDSO64SYM include/generated/vdso64-offsets.h
/workdir/lib/vdso/gettimeofday.c:104:26: warning: ‘sec’ may be used
uninitialized [-Wmaybe-uninitialized]
./include/vdso/math64.h:10:25: warning: ‘ns’ may be used uninitialized
[-Wmaybe-uninitialized]
/workdir/lib/vdso/gettimeofday.c:104:26: warning: ‘sec’ may be used
uninitialized [-Wmaybe-uninitialized]
./include/vdso/math64.h:10:25: warning: ‘ns’ may be used uninitialized
[-Wmaybe-uninitialized]
Thanks
--
Ricardo Ribalda
^ permalink raw reply related
* Re: [PATCH 1/4] arm64: dts: imx8mp: switch usb controller to flattened model
From: Frank Li @ 2026-04-22 3:45 UTC (permalink / raw)
To: Xu Yang
Cc: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, devicetree,
imx, linux-arm-kernel, linux-kernel, jun.li
In-Reply-To: <20260421105503.1416566-1-xu.yang_2@nxp.com>
On Tue, Apr 21, 2026 at 06:55:00PM +0800, Xu Yang wrote:
> Switch to use flattened model for all USB controllers. To enable USB
> controllers with restricted DMA access range to work correctly, add a
> pseudo simple-bus to constrain the dma address.
This should not "pseudo", and bus is physical existed, which limited dma
range since it transparent to SW, which may not mention in spec.
>
> Also reorder USB-related nodes.
this need new patch to just do reorder.
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 161 ++++++++++------------
> 1 file changed, 76 insertions(+), 85 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> index 90d7bb8f5619..8b3aab14ccf1 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -2329,6 +2329,82 @@ gpu2d: gpu@38008000 {
> power-domains = <&pgc_gpu2d>;
> };
>
> + bus@38100000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + dma-ranges = <0x40000000 0x40000000 0xc0000000>;
> + ranges;
> +
> + usb3_0: usb_dwc3_0: usb@38100000 {
> + compatible = "nxp,imx8mp-dwc3";
> + reg = <0x38100000 0x10000>,
> + <0x32f10100 0x8>,
> + <0x381f0000 0x20>;
> + reg-names = "core", "blkctl", "glue";
> + clocks = <&clk IMX8MP_CLK_HSIO_ROOT>,
> + <&clk IMX8MP_CLK_USB_ROOT>,
> + <&clk IMX8MP_CLK_USB_CORE_REF>,
> + <&clk IMX8MP_CLK_USB_SUSP>;
> + clock-names = "hsio", "bus_early", "ref", "suspend";
> + interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "dwc_usb3", "wakeup";
> + power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_USB>;
> + phys = <&usb3_phy0>, <&usb3_phy0>;
> + phy-names = "usb2-phy", "usb3-phy";
> + snps,gfladj-refclk-lpm-sel-quirk;
> + snps,parkmode-disable-ss-quirk;
> + status = "disabled";
> + };
> +
> + usb3_1: usb_dwc3_1: usb@38200000 {
> + compatible = "nxp,imx8mp-dwc3";
> + reg = <0x38200000 0x10000>,
> + <0x32f10108 0x8>,
> + <0x382f0000 0x20>;
> + reg-names = "core", "blkctl", "glue";
> + clocks = <&clk IMX8MP_CLK_HSIO_ROOT>,
> + <&clk IMX8MP_CLK_USB_ROOT>,
> + <&clk IMX8MP_CLK_USB_CORE_REF>,
> + <&clk IMX8MP_CLK_USB_SUSP>;
> + clock-names = "hsio", "bus_early", "ref", "suspend";
> + interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "dwc_usb3", "wakeup";
> + power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_USB>;
> + phys = <&usb3_phy1>, <&usb3_phy1>;
> + phy-names = "usb2-phy", "usb3-phy";
> + snps,gfladj-refclk-lpm-sel-quirk;
> + snps,parkmode-disable-ss-quirk;
> + status = "disabled";
> + };
> + };
> +
> + usb3_phy0: usb-phy@381f0040 {
> + compatible = "fsl,imx8mp-usb-phy";
> + reg = <0x381f0040 0x40>;
> + clocks = <&clk IMX8MP_CLK_USB_PHY_ROOT>;
> + clock-names = "phy";
> + assigned-clocks = <&clk IMX8MP_CLK_USB_PHY_REF>;
> + assigned-clock-parents = <&clk IMX8MP_CLK_24M>;
> + power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_USB_PHY1>;
> + #phy-cells = <0>;
> + status = "disabled";
> + };
> +
> + usb3_phy1: usb-phy@382f0040 {
> + compatible = "fsl,imx8mp-usb-phy";
> + reg = <0x382f0040 0x40>;
> + clocks = <&clk IMX8MP_CLK_USB_PHY_ROOT>;
> + clock-names = "phy";
> + assigned-clocks = <&clk IMX8MP_CLK_USB_PHY_REF>;
> + assigned-clock-parents = <&clk IMX8MP_CLK_24M>;
> + power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_USB_PHY2>;
> + #phy-cells = <0>;
> + status = "disabled";
> + };
> +
> vpu_g1: video-codec@38300000 {
> compatible = "nxp,imx8mm-vpu-g1";
> reg = <0x38300000 0x10000>;
> @@ -2407,91 +2483,6 @@ ddr-pmu@3d800000 {
> interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> - usb3_phy0: usb-phy@381f0040 {
> - compatible = "fsl,imx8mp-usb-phy";
> - reg = <0x381f0040 0x40>;
> - clocks = <&clk IMX8MP_CLK_USB_PHY_ROOT>;
> - clock-names = "phy";
> - assigned-clocks = <&clk IMX8MP_CLK_USB_PHY_REF>;
> - assigned-clock-parents = <&clk IMX8MP_CLK_24M>;
> - power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_USB_PHY1>;
> - #phy-cells = <0>;
> - status = "disabled";
> - };
> -
> - usb3_0: usb@32f10100 {
> - compatible = "fsl,imx8mp-dwc3";
Delete these will broken back compatible. You can delete later or descript
impact judgement in commit message.
Frank
> - reg = <0x32f10100 0x8>,
> - <0x381f0000 0x20>;
> - clocks = <&clk IMX8MP_CLK_HSIO_ROOT>,
> - <&clk IMX8MP_CLK_USB_SUSP>;
> - clock-names = "hsio", "suspend";
> - interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
> - power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_USB>;
> - #address-cells = <1>;
> - #size-cells = <1>;
> - dma-ranges = <0x40000000 0x40000000 0xc0000000>;
> - ranges;
> - status = "disabled";
> -
> - usb_dwc3_0: usb@38100000 {
> - compatible = "snps,dwc3";
> - reg = <0x38100000 0x10000>;
> - clocks = <&clk IMX8MP_CLK_USB_ROOT>,
> - <&clk IMX8MP_CLK_USB_CORE_REF>,
> - <&clk IMX8MP_CLK_USB_SUSP>;
> - clock-names = "bus_early", "ref", "suspend";
> - interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> - phys = <&usb3_phy0>, <&usb3_phy0>;
> - phy-names = "usb2-phy", "usb3-phy";
> - snps,gfladj-refclk-lpm-sel-quirk;
> - snps,parkmode-disable-ss-quirk;
> - };
> -
> - };
> -
> - usb3_phy1: usb-phy@382f0040 {
> - compatible = "fsl,imx8mp-usb-phy";
> - reg = <0x382f0040 0x40>;
> - clocks = <&clk IMX8MP_CLK_USB_PHY_ROOT>;
> - clock-names = "phy";
> - assigned-clocks = <&clk IMX8MP_CLK_USB_PHY_REF>;
> - assigned-clock-parents = <&clk IMX8MP_CLK_24M>;
> - power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_USB_PHY2>;
> - #phy-cells = <0>;
> - status = "disabled";
> - };
> -
> - usb3_1: usb@32f10108 {
> - compatible = "fsl,imx8mp-dwc3";
> - reg = <0x32f10108 0x8>,
> - <0x382f0000 0x20>;
> - clocks = <&clk IMX8MP_CLK_HSIO_ROOT>,
> - <&clk IMX8MP_CLK_USB_SUSP>;
> - clock-names = "hsio", "suspend";
> - interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
> - power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_USB>;
> - #address-cells = <1>;
> - #size-cells = <1>;
> - dma-ranges = <0x40000000 0x40000000 0xc0000000>;
> - ranges;
> - status = "disabled";
> -
> - usb_dwc3_1: usb@38200000 {
> - compatible = "snps,dwc3";
> - reg = <0x38200000 0x10000>;
> - clocks = <&clk IMX8MP_CLK_USB_ROOT>,
> - <&clk IMX8MP_CLK_USB_CORE_REF>,
> - <&clk IMX8MP_CLK_USB_SUSP>;
> - clock-names = "bus_early", "ref", "suspend";
> - interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> - phys = <&usb3_phy1>, <&usb3_phy1>;
> - phy-names = "usb2-phy", "usb3-phy";
> - snps,gfladj-refclk-lpm-sel-quirk;
> - snps,parkmode-disable-ss-quirk;
> - };
> - };
> -
> dsp: dsp@3b6e8000 {
> compatible = "fsl,imx8mp-hifi4";
> reg = <0x3b6e8000 0x88000>;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: add tqma9596la-mba95xxca
From: Frank Li @ 2026-04-22 3:10 UTC (permalink / raw)
To: Alexander Stein
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Shawn Guo, Markus Niebel, devicetree, linux-kernel,
imx, linux-arm-kernel, linux, linux-renesas-soc
In-Reply-To: <2831050.mvXUDI8C0e@steina-w>
On Tue, Apr 21, 2026 at 04:09:15PM +0200, Alexander Stein wrote:
> Hi,
>
> Am Donnerstag, 26. März 2026, 12:03:30 CEST schrieb Alexander Stein:
> > From: Markus Niebel <Markus.Niebel@ew.tq-group.com>
> >
> > This adds support for TQMa95xxLA modules, designed to be soldered
> > on a carrier board. MBa95xxCA is a carrier reference board / starter kit
> > design.
> >
> > There is a common device tree for all variants with e.g. reduced
> > CPU core / feature count.
> >
> > Enable the external accessible PCIe controllers as host,
> > add clocking and reset GPIO. While at it, add hogs for GPIO
> > lines from the M.2 slots until M.2 connector driver is available.
> >
> > Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
> > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
>
> Any feedback on this? Patch 1 is already picked in commit d44627c13049e
> ("dt-bindings: arm: add bindings for TQMa95xxLA")
Most likely missed pick windows, I will take care after v7.1-rc1 out.
Frank
>
> Thank and best regards,
> Alexander
>
> > ---
> > Changes in v2:
> > * removed useless regulator
> > * added USB PD source configuration
> > * Removed unused uart-has-rtscts properties (unused by LPUART)
> > * Fixed RTS/CTS pullups in pinctrl
> > * Added thermalzone on module
> >
> > arch/arm64/boot/dts/freescale/Makefile | 1 +
> > .../freescale/imx95-tqma9596la-mba95xxca.dts | 947 ++++++++++++++++++
> > .../boot/dts/freescale/imx95-tqma9596la.dtsi | 297 ++++++
> > 3 files changed, 1245 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
> > create mode 100644 arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> > index 2879d567dede0..df79e56771319 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -554,6 +554,7 @@ 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-toradex-smarc-dev.dtb
> > +dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596la-mba95xxca.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-tqma9596la-mba95xxca.dts b/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
> > new file mode 100644
> > index 0000000000000..f75580bb91e3e
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
> > @@ -0,0 +1,947 @@
> > +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> > +/*
> > + * Copyright (c) 2024-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
> > + * D-82229 Seefeld, Germany.
> > + * Author: Alexander Stein
> > + * Author: Markus Niebel
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/leds/common.h>
> > +#include <dt-bindings/net/ti-dp83867.h>
> > +#include <dt-bindings/pwm/pwm.h>
> > +#include <dt-bindings/usb/pd.h>
> > +#include "imx95-tqma9596la.dtsi"
> > +
> > +/ {
> > + model = "TQ-Systems i.MX95 TQMa95xxLA on MBa95xxCA";
> > + compatible = "tq,imx95-tqma9596la-mba95xxca", "tq,imx95-tqma9596la", "fsl,imx95";
> > + chassis-type = "embedded";
> > +
> > + aliases {
> > + ethernet0 = &enetc_port0;
> > + ethernet1 = &enetc_port1;
> > + ethernet2 = &enetc_port2;
> > + gpio0 = &gpio1;
> > + gpio1 = &gpio2;
> > + gpio2 = &gpio3;
> > + gpio3 = &gpio4;
> > + i2c0 = &lpi2c1;
> > + i2c1 = &lpi2c2;
> > + i2c2 = &lpi2c3;
> > + i2c3 = &lpi2c4;
> > + i2c4 = &lpi2c5;
> > + i2c5 = &lpi2c6;
> > + i2c6 = &lpi2c7;
> > + i2c7 = &lpi2c8;
> > + mmc0 = &usdhc1;
> > + mmc1 = &usdhc2;
> > + rtc0 = &pcf85063;
> > + rtc1 = &scmi_bbm;
> > + serial0 = &lpuart1;
> > + serial1 = &lpuart2;
> > + serial2 = &lpuart3;
> > + serial3 = &lpuart4;
> > + serial4 = &lpuart5;
> > + serial5 = &lpuart6;
> > + serial6 = &lpuart7;
> > + serial7 = &lpuart8;
> > + spi0 = &flexspi1;
> > + };
> > +
> > + chosen {
> > + stdout-path = &lpuart1;
> > + };
> > +
> > + backlight_lvds: backlight-lvds {
> > + compatible = "pwm-backlight";
> > + pwms = <&tpm5 2 100000 0>;
> > + brightness-levels = <0 4 8 16 32 64 128 255>;
> > + default-brightness-level = <7>;
> > + enable-gpios = <&expander2 6 GPIO_ACTIVE_HIGH>;
> > + power-supply = <®_12v0>;
> > + status = "disabled";
> > + };
> > +
> > + clk_eth: clk-eth {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <156250000>;
> > + };
> > +
> > + /*
> > + * TODO: gate is disabled for now and GPIO are hogged
> > + * ENETC driver switches the clock far too late for ENETC2 + SFP
> > + */
> > + clk_eth_gate: clk-eth-gate {
> > + compatible = "gpio-gate-clock";
> > + enable-gpios = <&expander2 0 GPIO_ACTIVE_HIGH>;
> > + clocks = <&clk_eth>;
> > + #clock-cells = <0>;
> > + status = "disabled";
> > + };
> > +
> > + clk_xtal25: clk-xtal25 {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <25000000>;
> > + };
> > +
> > + gpio-keys {
> > + compatible = "gpio-keys";
> > + autorepeat;
> > +
> > + button-b {
> > + label = "BUTTON_B#";
> > + linux,code = <BTN_1>;
> > + gpios = <&expander1 0 GPIO_ACTIVE_LOW>;
> > + wakeup-source;
> > + };
> > + };
> > +
> > + gpio-leds {
> > + compatible = "gpio-leds";
> > +
> > + led-1 {
> > + color = <LED_COLOR_ID_GREEN>;
> > + function = LED_FUNCTION_STATUS;
> > + gpios = <&expander2 13 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "default-on";
> > + };
> > +
> > + led-2 {
> > + color = <LED_COLOR_ID_AMBER>;
> > + function = LED_FUNCTION_HEARTBEAT;
> > + gpios = <&expander2 14 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "heartbeat";
> > + };
> > + };
> > +
> > + iio-hwmon {
> > + compatible = "iio-hwmon";
> > + io-channels = <&adc1 0>, <&adc1 1>, <&adc1 2>, <&adc1 3>,
> > + <&adc1 4>, <&adc1 5>, <&adc1 6>, <&adc1 7>;
> > + };
> > +
> > + reg_v1v8_mb: regulator-v1v8-mb {
> > + compatible = "regulator-fixed";
> > + regulator-name = "V_1V8_MB";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-always-on;
> > + };
> > +
> > + reg_v3v3_mb: regulator-v3v3-mb {
> > + compatible = "regulator-fixed";
> > + regulator-name = "V_3V3_MB";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-always-on;
> > + };
> > +
> > + reg_3v3a_10g: regulator-3v3a-10g {
> > + compatible = "regulator-fixed";
> > + regulator-name = "3V3A_10G";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + gpio = <&expander2 15 GPIO_ACTIVE_HIGH>;
> > + startup-delay-us = <2000>;
> > + enable-active-high;
> > + };
> > +
> > + reg_12v0: regulator-12v0 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "12V0";
> > + regulator-min-microvolt = <12000000>;
> > + regulator-max-microvolt = <12000000>;
> > + gpio = <&expander1 15 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +
> > + reg_pwm_fan: regulator-pwm-fan {
> > + compatible = "regulator-fixed";
> > + regulator-name = "FAN_PWR";
> > + regulator-min-microvolt = <12000000>;
> > + regulator-max-microvolt = <12000000>;
> > + gpio = <&expander3 15 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + vin-supply = <®_12v0>;
> > + };
> > +
> > + reg_lvds: regulator-lvds {
> > + compatible = "regulator-fixed";
> > + regulator-name = "LCD_PWR_EN";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + gpio = <&expander2 7 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +
> > + /* USB NC limitations, RM 162.1.2 VBUS limitations */
> > + reg_vbus_usb3: regulator-vbus-usb3 {
> > + compatible = "regulator-fixed";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + regulator-name = "USB3_VBUS";
> > + gpio = <&gpio4 1 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +
> > + sfp_xfi: sfp-xfi {
> > + compatible = "sff,sfp";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_sfp>;
> > + i2c-bus = <&lpi2c7>;
> > + maximum-power-milliwatt = <2000>;
> > + mod-def0-gpios = <&expander1 3 GPIO_ACTIVE_LOW>;
> > + tx-fault-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
> > + los-gpios = <&gpio2 31 GPIO_ACTIVE_HIGH>;
> > + tx-disable-gpios = <&expander2 2 GPIO_ACTIVE_HIGH>;
> > + };
> > +
> > + sound {
> > + compatible = "fsl,imx-audio-tlv320aic32x4";
> > + model = "tqm-tlv320aic32";
> > + audio-codec = <&tlv320aic3x04>;
> > + audio-cpu = <&sai3>;
> > + audio-routing =
> > + "IN3_L", "Mic Jack",
> > + "Mic Jack", "Mic Bias",
> > + "Headphone Jack", "HPL",
> > + "Headphone Jack", "HPR",
> > + "IN1_L", "Line In Jack",
> > + "IN1_R", "Line In Jack",
> > + "Line Out Jack", "LOL",
> > + "Line Out Jack", "LOR";
> > + };
> > +};
> > +
> > +&adc1 {
> > + status = "okay";
> > +};
> > +
> > +&enetc_port0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_enetc0>;
> > + phy-handle = <ðphy0>;
> > + phy-mode = "rgmii-id";
> > + status = "okay";
> > +};
> > +
> > +&enetc_port1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_enetc1>;
> > + phy-handle = <ðphy1>;
> > + phy-mode = "rgmii-id";
> > + status = "okay";
> > +};
> > +
> > +/* No support for XFI yet */
> > +&enetc_port2 {
> > + sfp = <&sfp_xfi>;
> > + phy-mode = "10gbase-r";
> > + clocks = <&clk_eth>;
> > + clock-names = "enet_ref_clk";
> > + managed = "in-band-status";
> > + status = "disabled";
> > +};
> > +
> > +&flexcan1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_flexcan1>;
> > + status = "okay";
> > +};
> > +
> > +&flexcan2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_flexcan2>;
> > + status = "okay";
> > +};
> > +
> > +&lpi2c2 {
> > + tlv320aic3x04: audio-codec@18 {
> > + compatible = "ti,tlv320aic32x4";
> > + reg = <0x18>;
> > + clocks = <&scmi_clk IMX95_CLK_SAI3>;
> > + clock-names = "mclk";
> > + reset-gpios = <&expander1 14 GPIO_ACTIVE_LOW>;
> > + iov-supply = <®_v3v3_mb>;
> > + ldoin-supply = <®_v3v3_mb>;
> > + };
> > +
> > + fan_controller: fan-controller@2f {
> > + compatible = "microchip,emc2301", "microchip,emc2305";
> > + reg = <0x2f>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + #pwm-cells = <3>;
> > + status = "okay";
> > +
> > + fan: fan@0 {
> > + reg = <0x0>;
> > + pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED 1>;
> > + #cooling-cells = <2>;
> > + fan-supply = <®_pwm_fan>;
> > + };
> > + };
> > +
> > + ptn5110: usb-typec@50 {
> > + compatible = "nxp,ptn5110", "tcpci";
> > + reg = <0x50>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_typec>;
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + typec_con: connector {
> > + compatible = "usb-c-connector";
> > + label = "X9";
> > + power-role = "source";
> > + data-role = "dual";
> > + source-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)>;
> > + self-powered;
> > +
> > + port {
> > + typec_con_hs: endpoint {
> > + remote-endpoint = <&typec_hs>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + sensor_mb: temperature-sensor@1e {
> > + compatible = "nxp,se97b", "jedec,jc-42.4-temp";
> > + reg = <0x1e>;
> > + };
> > +
> > + eeprom_mb: eeprom@56 {
> > + compatible = "nxp,se97b", "atmel,24c02";
> > + reg = <0x56>;
> > + pagesize = <16>;
> > + vcc-supply = <®_v3v3_mb>;
> > + };
> > +
> > + pcieclk: clock-generator@68 {
> > + compatible = "renesas,9fgv0441";
> > + reg = <0x68>;
> > + clocks = <&clk_xtal25>;
> > + #clock-cells = <1>;
> > + };
> > +
> > + /* D39 IN/OUT 3V3 */
> > + expander1: gpio@74 {
> > + compatible = "ti,tca9539";
> > + reg = <0x74>;
> > + vcc-supply = <®_v3v3_mb>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_expander1>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
> > +
> > + gpio-line-names =
> > + /* 00 */ "BUTTON_B#", "CAM0_SYNC_3V3",
> > + /* 02 */ "CAM1_SYNC_3V3", "SFP_MOD_ABS",
> > + /* 04 */ "DIG_IN1", "DIG_IN2",
> > + /* 06 */ "DIG_IN3", "DIG_IN4",
> > + /* 08 */ "DIG_OUT_1_2_STATE", "DIG_OUT_3_4_STATE",
> > + /* 10 */ "DIG_OUT_1_EN", "DIG_OUT_2_EN",
> > + /* 12 */ "DIG_OUT_3_EN", "DIG_OUT_4_EN",
> > + /* 14 */ "AUDIO_RST#", "12V_EN";
> > + };
> > +
> > + /* D40 OUT 3V3 */
> > + expander2: gpio@75 {
> > + compatible = "ti,tca9539";
> > + reg = <0x75>;
> > + vcc-supply = <®_3v3>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > +
> > + gpio-line-names =
> > + /* 00 */ "ETH10G_REFCLK_EN", "ETH10G_REFCLK_RST#",
> > + /* 02 */ "SFP_TX_DIS", "USB3_RESET#",
> > + /* 04 */ "USB2_RESET#", "LCD_RESET#",
> > + /* 06 */ "LCD_BLT_EN", "LCD_PWR_EN",
> > + /* 08 */ "M2_KEYE_PERST#", "M2_KEYE_WDISABLE1#",
> > + /* 10 */ "M2_KEYE_WDISABLE2#", "M2_KEYB_PERST#",
> > + /* 12 */ "M2_KEYB_WDISABLE1#", "USER_LED1",
> > + /* 14 */ "USER_LED2", "3V3A_10G_EN";
> > +
> > + eth10g-refclk-en-hog {
> > + gpio-hog;
> > + gpios = <0 GPIO_ACTIVE_HIGH>;
> > + output-high;
> > + line-name = "ETH10G_REFCLK_EN";
> > + };
> > +
> > + eth10g-refclk-rst-hog {
> > + gpio-hog;
> > + gpios = <1 GPIO_ACTIVE_LOW>;
> > + output-low;
> > + line-name = "ETH10G_REFCLK_RST#";
> > + };
> > +
> > + m2_keye_wdisable1_hog: m2-keye-wdisable1-hog {
> > + gpio-hog;
> > + gpios = <9 GPIO_ACTIVE_LOW>;
> > + output-low;
> > + line-name = "M2_KEYE_WDISABLE1#";
> > + };
> > +
> > + m2_keye_wdisable2_hog: m2-keye-wdisable2-hog {
> > + gpio-hog;
> > + gpios = <10 GPIO_ACTIVE_LOW>;
> > + output-low;
> > + line-name = "M2_KEYE_WDISABLE2#";
> > + };
> > +
> > + m2-keyb-wdisable1-hog {
> > + gpio-hog;
> > + gpios = <12 GPIO_ACTIVE_LOW>;
> > + output-low;
> > + line-name = "M2_KEYB_WDISABLE1#";
> > + };
> > + };
> > +
> > + /* D41 OUT 1V8 */
> > + expander3: gpio@76 {
> > + compatible = "ti,tca9539";
> > + reg = <0x76>;
> > + vcc-supply = <®_v1v8_mb>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > +
> > + gpio-line-names =
> > + /* 00 */ "ENET1_RESET#", "ENET2_RESET#",
> > + /* 02 */ "M2_KEYE_SDIO_RST#", "M2_KEYE_DEV_WLAN_WAKE#",
> > + /* 04 */ "M2_KEYE_DEV_BT_WAKE", "M2_KEYB_W_DISABLE2#",
> > + /* 06 */ "M2_KEYB_RST#", "M2_KEYB_FULL_CARD_PWR_OFF#",
> > + /* 08 */ "M2_KEYB_DPR", "CAM0_PWR#",
> > + /* 10 */ "CAM1_PWR#", "CAM0_RST#",
> > + /* 12 */ "CAM1_RST#", "CAM0_TRIGGER",
> > + /* 14 */ "CAM1_TRIGGER", "FAN_PWR_EN";
> > +
> > + m2-keye-sdio-rst-hog {
> > + gpio-hog;
> > + gpios = <2 GPIO_ACTIVE_LOW>;
> > + output-low;
> > + line-name = "M2_KEYE_SDIO_RST#";
> > + };
> > +
> > + m2-keye-dev_wlan-wake-hog {
> > + gpio-hog;
> > + gpios = <3 GPIO_ACTIVE_LOW>;
> > + input;
> > + line-name = "M2_KEYE_DEV_WLAN_WAKE#";
> > + };
> > +
> > + m2-keye-dev_bt-wake-hog {
> > + gpio-hog;
> > + gpios = <4 GPIO_ACTIVE_LOW>;
> > + input;
> > + line-name = "M2_KEYE_DEV_BT_WAKE#";
> > + };
> > +
> > + m2-keyb-wdisable2-hog {
> > + gpio-hog;
> > + gpios = <5 GPIO_ACTIVE_LOW>;
> > + output-low;
> > + line-name = "M2_KEYB_WDISABLE1#";
> > + };
> > +
> > + m2-keyb-rst-hog {
> > + gpio-hog;
> > + gpios = <6 GPIO_ACTIVE_LOW>;
> > + output-low;
> > + line-name = "M2_KEYB_RST#";
> > + };
> > +
> > + m2-keyb-full-card-pwr-off-hog {
> > + gpio-hog;
> > + gpios = <7 GPIO_ACTIVE_LOW>;
> > + output-low;
> > + line-name = "M2_KEYB_FULL_CARD_PWR_OFF#";
> > + };
> > + };
> > +};
> > +
> > +/* X4 + XFP */
> > +&lpi2c7 {
> > + clock-frequency = <400000>;
> > + pinctrl-names = "default", "gpio";
> > + pinctrl-0 = <&pinctrl_lpi2c7>;
> > + pinctrl-1 = <&pinctrl_lpi2c7_recovery>;
> > + scl-gpios = <&gpio2 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> > + sda-gpios = <&gpio2 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> > + status = "okay";
> > +
> > + /* TODO: 0x19: retimer */
> > +
> > + /* 0x50 / 0x51: SFP EEPROM */
> > +};
> > +
> > +/* X4 */
> > +&lpspi4 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lpspi4>;
> > + cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>, <&gpio5 14 GPIO_ACTIVE_LOW>;
> > + status = "okay";
> > +};
> > +
> > +&lpuart1 {
> > + /* console */
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lpuart1>;
> > + status = "okay";
> > +};
> > +
> > +&lpuart2 {
> > + /* SM */
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lpuart2>;
> > + status = "reserved";
> > +};
> > +
> > +&lpuart5 {
> > + /* X16 M.2 KEY E */
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lpuart5>;
> > + status = "okay";
> > +};
> > +
> > +&lpuart7 {
> > + /* X5 */
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lpuart7>;
> > + status = "okay";
> > +};
> > +
> > +&lpuart8 {
> > + /* X15 */
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lpuart8>;
> > + linux,rs485-enabled-at-boot-time;
> > + status = "okay";
> > +};
> > +
> > +&netc_blk_ctrl {
> > + status = "okay";
> > +};
> > +
> > +&netc_emdio {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_emdio>;
> > + status = "okay";
> > +
> > + /* IRQ pin is AON GPIO, not usable */
> > + ethphy0: ethernet-phy@0 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <0>;
> > + reset-gpios = <&expander3 0 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <500000>;
> > + reset-deassert-us = <50000>;
> > + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> > + ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> > + ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
> > + ti,dp83867-rxctrl-strap-quirk;
> > + ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
> > + };
> > +
> > + ethphy1: ethernet-phy@1 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <1>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_ethphy1>;
> > + reset-gpios = <&expander3 1 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <500000>;
> > + reset-deassert-us = <50000>;
> > + interrupt-parent = <&gpio4>;
> > + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> > + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> > + ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> > + ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
> > + ti,dp83867-rxctrl-strap-quirk;
> > + ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
> > + };
> > +};
> > +
> > +&netc_timer {
> > + status = "okay";
> > +};
> > +
> > +&netcmix_blk_ctrl {
> > + status = "okay";
> > +};
> > +
> > +/* X16 M2 / E-Key mPCIe */
> > +&pcie0 {
> > + pinctrl-0 = <&pinctrl_pcie0>;
> > + pinctrl-names = "default";
> > + clocks = <&scmi_clk IMX95_CLK_HSIO>,
> > + <&scmi_clk IMX95_CLK_HSIOPLL>,
> > + <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
> > + <&scmi_clk IMX95_CLK_HSIOPCIEAUX>,
> > + <&pcieclk 1>;
> > + clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux", "ref";
> > + reset-gpios = <&expander2 8 GPIO_ACTIVE_LOW>;
> > + /* Not supported on REV.0100 */
> > + /* supports-clkreq; */
> > + status = "okay";
> > +};
> > +
> > +/* X17 M2 / B-Key PCIe */
> > +&pcie1 {
> > + pinctrl-0 = <&pinctrl_pcie1>;
> > + pinctrl-names = "default";
> > + clocks = <&scmi_clk IMX95_CLK_HSIO>,
> > + <&scmi_clk IMX95_CLK_HSIOPLL>,
> > + <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
> > + <&scmi_clk IMX95_CLK_HSIOPCIEAUX>,
> > + <&pcieclk 0>;
> > + clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux", "ref";
> > + reset-gpios = <&expander2 11 GPIO_ACTIVE_LOW>;
> > + /* Not supported on REV.0100 */
> > + /* supports-clkreq; */
> > + status = "okay";
> > +};
> > +
> > +®_sdvmmc {
> > + status = "okay";
> > +};
> > +
> > +&sai3 {
> > + #sound-dai-cells = <0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_sai3>;
> > + 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_SAI3>;
> > + assigned-clock-parents = <0>, <0>, <0>, <0>,
> > + <&scmi_clk IMX95_CLK_AUDIOPLL1>;
> > + assigned-clock-rates = <3932160000>,
> > + <3612672000>, <393216000>,
> > + <361267200>, <12288000>;
> > + fsl,sai-mclk-direction-output;
> > + status = "okay";
> > +};
> > +
> > +&scmi_bbm {
> > + linux,code = <KEY_POWER>;
> > +};
> > +
> > +&thermal_zones {
> > + a55-thermal {
> > + trips {
> > + cpu_active0: trip-active0 {
> > + temperature = <40000>;
> > + hysteresis = <5000>;
> > + type = "active";
> > + };
> > +
> > + cpu_active1: trip-active1 {
> > + temperature = <48000>;
> > + hysteresis = <3000>;
> > + type = "active";
> > + };
> > +
> > + cpu_active2: trip-active2 {
> > + temperature = <60000>;
> > + hysteresis = <10000>;
> > + type = "active";
> > + };
> > + };
> > +
> > + cooling-maps {
> > + map1 {
> > + trip = <&cpu_active0>;
> > + cooling-device = <&fan 0 2>;
> > + };
> > +
> > + map2 {
> > + trip = <&cpu_active1>;
> > + cooling-device = <&fan 3 5>;
> > + };
> > +
> > + map3 {
> > + trip = <&cpu_active2>;
> > + cooling-device = <&fan 6 10>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&tpm3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_tpm3>;
> > + status = "okay";
> > +};
> > +
> > +&tpm5 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_tpm5>;
> > +};
> > +
> > +&usb2 {
> > + dr_mode = "otg";
> > + hnp-disable;
> > + srp-disable;
> > + adp-disable;
> > + usb-role-switch;
> > + disable-over-current;
> > + samsung,picophy-pre-emp-curr-control = <3>;
> > + samsung,picophy-dc-vol-level-adjust = <7>;
> > + status = "okay";
> > +
> > + port {
> > + typec_hs: endpoint {
> > + remote-endpoint = <&typec_con_hs>;
> > + };
> > + };
> > +};
> > +
> > +&usb3 {
> > + status = "okay";
> > +};
> > +
> > +&usb3_dwc3 {
> > + dr_mode = "host";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "okay";
> > +
> > + hub_2_0: hub@1 {
> > + compatible = "usb451,8142";
> > + reg = <1>;
> > + peer-hub = <&hub_3_0>;
> > + reset-gpios = <&expander2 3 GPIO_ACTIVE_LOW>;
> > + vdd-supply = <®_v3v3_mb>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + hub_2_1: hub@1 {
> > + compatible = "usb424,2514";
> > + reg = <1>;
> > + reset-gpios = <&expander2 4 GPIO_ACTIVE_LOW>;
> > + vdd-supply = <®_v3v3_mb>;
> > + vdda-supply = <®_v3v3_mb>;
> > + };
> > + };
> > +
> > + hub_3_0: hub@2 {
> > + compatible = "usb451,8140";
> > + reg = <2>;
> > + peer-hub = <&hub_2_0>;
> > + reset-gpios = <&expander2 3 GPIO_ACTIVE_LOW>;
> > + vdd-supply = <®_v3v3_mb>;
> > + };
> > +};
> > +
> > +&usb3_phy {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usb3>;
> > + vbus-supply = <®_vbus_usb3>;
> > + status = "okay";
> > +};
> > +
> > +/* X7 µSD */
> > +&usdhc2 {
> > + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> > + pinctrl-0 = <&pinctrl_usdhc2>;
> > + pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
> > + pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
> > + vmmc-supply = <®_sdvmmc>;
> > + cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
> > + no-mmc;
> > + no-sdio;
> > + disable-wp;
> > + bus-width = <4>;
> > + status = "okay";
> > +};
> > +
> > +&scmi_iomuxc {
> > + pinctrl_enetc0: enetc0grp {
> > + fsl,pins = <IMX95_PAD_ENET1_RD0__NETCMIX_TOP_ETH0_RGMII_RD0 0x1100>,
> > + <IMX95_PAD_ENET1_RD1__NETCMIX_TOP_ETH0_RGMII_RD1 0x1100>,
> > + <IMX95_PAD_ENET1_RD2__NETCMIX_TOP_ETH0_RGMII_RD2 0x1100>,
> > + <IMX95_PAD_ENET1_RD3__NETCMIX_TOP_ETH0_RGMII_RD3 0x1100>,
> > + <IMX95_PAD_ENET1_RXC__NETCMIX_TOP_ETH0_RGMII_RX_CLK 0x1100>,
> > + <IMX95_PAD_ENET1_RX_CTL__NETCMIX_TOP_ETH0_RGMII_RX_CTL 0x1100>,
> > + <IMX95_PAD_ENET1_TD0__NETCMIX_TOP_ETH0_RGMII_TD0 0x11e>,
> > + <IMX95_PAD_ENET1_TD1__NETCMIX_TOP_ETH0_RGMII_TD1 0x11e>,
> > + <IMX95_PAD_ENET1_TD2__NETCMIX_TOP_ETH0_RGMII_TD2 0x11e>,
> > + <IMX95_PAD_ENET1_TD3__NETCMIX_TOP_ETH0_RGMII_TD3 0x11e>,
> > + <IMX95_PAD_ENET1_TXC__NETCMIX_TOP_ETH0_RGMII_TX_CLK 0x11e>,
> > + <IMX95_PAD_ENET1_TX_CTL__NETCMIX_TOP_ETH0_RGMII_TX_CTL 0x11e>;
> > + };
> > +
> > + pinctrl_enetc1: enetc1grp {
> > + fsl,pins = <IMX95_PAD_ENET2_RD0__NETCMIX_TOP_ETH1_RGMII_RD0 0x1100>,
> > + <IMX95_PAD_ENET2_RD1__NETCMIX_TOP_ETH1_RGMII_RD1 0x1100>,
> > + <IMX95_PAD_ENET2_RD2__NETCMIX_TOP_ETH1_RGMII_RD2 0x1100>,
> > + <IMX95_PAD_ENET2_RD3__NETCMIX_TOP_ETH1_RGMII_RD3 0x1100>,
> > + <IMX95_PAD_ENET2_RXC__NETCMIX_TOP_ETH1_RGMII_RX_CLK 0x1100>,
> > + <IMX95_PAD_ENET2_RX_CTL__NETCMIX_TOP_ETH1_RGMII_RX_CTL 0x1100>,
> > + <IMX95_PAD_ENET2_TD0__NETCMIX_TOP_ETH1_RGMII_TD0 0x11e>,
> > + <IMX95_PAD_ENET2_TD1__NETCMIX_TOP_ETH1_RGMII_TD1 0x11e>,
> > + <IMX95_PAD_ENET2_TD2__NETCMIX_TOP_ETH1_RGMII_TD2 0x11e>,
> > + <IMX95_PAD_ENET2_TD3__NETCMIX_TOP_ETH1_RGMII_TD3 0x11e>,
> > + <IMX95_PAD_ENET2_TXC__NETCMIX_TOP_ETH1_RGMII_TX_CLK 0x11e>,
> > + <IMX95_PAD_ENET2_TX_CTL__NETCMIX_TOP_ETH1_RGMII_TX_CTL 0x11e>;
> > + };
> > +
> > + pinctrl_ethphy0: ethphy0grp {
> > + fsl,pins = <IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x1100>;
> > + };
> > +
> > + pinctrl_ethphy1: ethphy1grp {
> > + fsl,pins = <IMX95_PAD_ENET1_MDC__GPIO4_IO_BIT0 0x1100>;
> > + };
> > +
> > + pinctrl_expander1: expander1grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO14__GPIO2_IO_BIT14 0x1100>;
> > + };
> > +
> > + pinctrl_flexcan1: flexcan1grp {
> > + fsl,pins = <IMX95_PAD_SAI1_TXC__AONMIX_TOP_CAN1_RX 0x1300>,
> > + <IMX95_PAD_SAI1_TXD0__AONMIX_TOP_CAN1_TX 0x31e>;
> > + };
> > +
> > + pinctrl_flexcan2: flexcan2grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO25__CAN2_TX 0x31e>,
> > + <IMX95_PAD_GPIO_IO27__CAN2_RX 0x1300>;
> > + };
> > +
> > + pinctrl_lpi2c7: lpi2c7grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO07__LPI2C7_SCL 0x40001b1e>,
> > + <IMX95_PAD_GPIO_IO06__LPI2C7_SDA 0x40001b1e>;
> > + };
> > +
> > + pinctrl_lpi2c7_recovery: lpi2c7recoverygrp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO07__GPIO2_IO_BIT7 0x40001b1e>,
> > + <IMX95_PAD_GPIO_IO06__GPIO2_IO_BIT6 0x40001b1e>;
> > + };
> > +
> > + pinctrl_lpspi4: lpspi4grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO37__LPSPI4_SCK 0x91e>,
> > + <IMX95_PAD_GPIO_IO19__LPSPI5_SIN 0x191e>,
> > + <IMX95_PAD_GPIO_IO36__LPSPI4_SOUT 0x91e>,
> > + <IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14 0x91e>,
> > + <IMX95_PAD_GPIO_IO33__GPIO5_IO_BIT13 0x91e>;
> > + };
> > +
> > + pinctrl_lpuart1: lpuart1grp {
> > + fsl,pins = <IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX 0x31e>,
> > + <IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX 0x1300>;
> > + };
> > +
> > + pinctrl_lpuart2: lpuart2grp {
> > + fsl,pins = <IMX95_PAD_UART2_TXD__AONMIX_TOP_LPUART2_TX 0x31e>,
> > + <IMX95_PAD_UART2_RXD__AONMIX_TOP_LPUART2_RX 0x1300>;
> > + };
> > +
> > + pinctrl_lpuart5: lpuart5grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO00__LPUART5_TX 0x31e>,
> > + <IMX95_PAD_GPIO_IO01__LPUART5_RX 0x1300>,
> > + <IMX95_PAD_GPIO_IO02__LPUART5_CTS_B 0x1300>,
> > + <IMX95_PAD_GPIO_IO03__LPUART5_RTS_B 0x31e>;
> > + };
> > +
> > + pinctrl_lpuart7: lpuart7grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO08__LPUART7_TX 0x31e>,
> > + <IMX95_PAD_GPIO_IO09__LPUART7_RX 0x1300>,
> > + <IMX95_PAD_GPIO_IO10__LPUART7_CTS_B 0x1300>,
> > + <IMX95_PAD_GPIO_IO11__LPUART7_RTS_B 0x31e>;
> > + };
> > +
> > + pinctrl_lpuart8: lpuart8grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO12__LPUART8_TX 0x31e>,
> > + <IMX95_PAD_GPIO_IO13__LPUART8_RX 0x1300>,
> > + <IMX95_PAD_GPIO_IO15__LPUART8_RTS_B 0x31e>;
> > + };
> > +
> > + pinctrl_emdio: emdiogrp {
> > + fsl,pins = <IMX95_PAD_ENET2_MDC__NETCMIX_TOP_NETC_MDC 0x51e>,
> > + <IMX95_PAD_ENET2_MDIO__NETCMIX_TOP_NETC_MDIO 0x51e>;
> > + };
> > +
> > + pinctrl_pcie0: pcie0grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO32__HSIOMIX_TOP_PCIE1_CLKREQ_B 0x111e>;
> > + };
> > +
> > + pinctrl_pcie1: pcie1grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x111e>;
> > + };
> > +
> > + pinctrl_sai3: sai3grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO16__SAI3_TX_BCLK 0x51e>,
> > + <IMX95_PAD_GPIO_IO17__SAI3_MCLK 0x51e>,
> > + <IMX95_PAD_GPIO_IO20__SAI3_RX_DATA_BIT0 0x1300>,
> > + <IMX95_PAD_GPIO_IO21__SAI3_TX_DATA_BIT0 0x51e>,
> > + <IMX95_PAD_GPIO_IO26__SAI3_TX_SYNC 0x51e>;
> > + };
> > +
> > + pinctrl_retimer: retirmergrp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO29__GPIO2_IO_BIT29 0x1100>;
> > + };
> > +
> > + pinctrl_sfp: sfpgrp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO30__GPIO2_IO_BIT30 0x1100>,
> > + <IMX95_PAD_GPIO_IO31__GPIO2_IO_BIT31 0x1100>;
> > + };
> > +
> > + pinctrl_tpm3: tpm3grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO24__TPM3_CH3 0x51e>;
> > + };
> > +
> > + pinctrl_tpm5: tpm5grp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO18__TPM5_CH2 0x51e>;
> > + };
> > +
> > + pinctrl_typec: typcegrp {
> > + fsl,pins = <IMX95_PAD_GPIO_IO28__GPIO2_IO_BIT28 0x1100>;
> > + };
> > +
> > + pinctrl_usb3: usb3grp {
> > + fsl,pins = <IMX95_PAD_ENET1_MDIO__GPIO4_IO_BIT1 0x31e>;
> > + };
> > +
> > + pinctrl_usdhc2: usdhc2grp {
> > + fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
> > + <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x51e>,
> > + <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x31e>,
> > + <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x131e>,
> > + <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x131e>,
> > + <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x131e>,
> > + <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x131e>,
> > + <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
> > + };
> > +
> > + pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
> > + fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
> > + <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x58e>,
> > + <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x38e>,
> > + <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e>,
> > + <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e>,
> > + <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e>,
> > + <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e>,
> > + <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
> > + };
> > +
> > + pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
> > + fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
> > + <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x5fe>,
> > + <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x3fe>,
> > + <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x13fe>,
> > + <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x13fe>,
> > + <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x13fe>,
> > + <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x13fe>,
> > + <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
> > + };
> > +};
> > diff --git a/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi b/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
> > new file mode 100644
> > index 0000000000000..cc572171bf253
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
> > @@ -0,0 +1,297 @@
> > +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> > +/*
> > + * Copyright (c) 2024-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
> > + * D-82229 Seefeld, Germany.
> > + * Author: Alexander Stein
> > + * Author: Markus Niebel
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include "imx95.dtsi"
> > +
> > +/ {
> > + memory@80000000 {
> > + device_type = "memory";
> > + /*
> > + * DRAM base addr, size : 2048 MiB DRAM
> > + * should be corrected by bootloader
> > + */
> > + reg = <0 0x80000000 0 0x80000000>;
> > + };
> > +
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + linux_cma: linux,cma {
> > + compatible = "shared-dma-pool";
> > + reusable;
> > + size = <0 0x28000000>;
> > + alloc-ranges = <0 0x80000000 0 0x80000000>;
> > + linux,cma-default;
> > + };
> > +
> > + vpu_boot: vpu_boot@a0000000 {
> > + reg = <0 0xa0000000 0 0x100000>;
> > + no-map;
> > + };
> > + };
> > +
> > + reg_1v8: regulator-1v8 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "V_1V8";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-always-on;
> > + };
> > +
> > + reg_3v3: regulator-3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "V_3V3";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-always-on;
> > + };
> > +
> > + reg_sdvmmc: regulator-sdvmmc {
> > + compatible = "regulator-fixed";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_sdvmmc>;
> > + regulator-name = "SD_PWR_EN";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
> > + off-on-delay-us = <12000>;
> > + enable-active-high;
> > + /* can be enabled by mainboard with SD-Card support */
> > + status = "disabled";
> > + };
> > +};
> > +
> > +&adc1 {
> > + vref-supply = <®_1v8>;
> > +};
> > +
> > +&flexspi1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_flexspi1>;
> > + status = "okay";
> > +
> > + flash0: flash@0 {
> > + compatible = "jedec,spi-nor";
> > + reg = <0>;
> > + spi-max-frequency = <66000000>;
> > + spi-tx-bus-width = <4>;
> > + spi-rx-bus-width = <4>;
> > + vcc-supply = <®_1v8>;
> > +
> > + partitions {
> > + compatible = "fixed-partitions";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + };
> > + };
> > +};
> > +
> > +/* System Manager */
> > +&gpio1 {
> > + status = "reserved";
> > +};
> > +
> > +/* System Manager */
> > +&lpi2c1 {
> > + status = "reserved";
> > +};
> > +
> > +&lpi2c2 {
> > + clock-frequency = <400000>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lpi2c2>;
> > + status = "okay";
> > +
> > + pcf85063: rtc@51 {
> > + compatible = "nxp,pcf85063a";
> > + reg = <0x51>;
> > + quartz-load-femtofarads = <7000>;
> > + };
> > +
> > + m24c64: eeprom@54 {
> > + compatible = "atmel,24c64";
> > + reg = <0x54>;
> > + pagesize = <32>;
> > + vcc-supply = <®_3v3>;
> > + };
> > +
> > + /* protectable identification memory (part of M24C64-D @54) */
> > + eeprom@5c {
> > + compatible = "atmel,24c64d-wl";
> > + reg = <0x5c>;
> > + pagesize = <32>;
> > + vcc-supply = <®_3v3>;
> > + };
> > +
> > + imu@6b {
> > + compatible = "st,ism330dhcx";
> > + reg = <0x6b>;
> > + vdd-supply = <®_3v3>;
> > + vddio-supply = <®_3v3>;
> > + };
> > +};
> > +
> > +&thermal_zones {
> > + pf09-thermal {
> > + polling-delay = <2000>;
> > + polling-delay-passive = <250>;
> > + thermal-sensors = <&scmi_sensor 2>;
> > +
> > + trips {
> > + pf09_alert: trip0 {
> > + hysteresis = <2000>;
> > + temperature = <140000>;
> > + type = "passive";
> > + };
> > +
> > + pf09_crit: trip1 {
> > + hysteresis = <2000>;
> > + temperature = <155000>;
> > + type = "critical";
> > + };
> > + };
> > + };
> > +
> > + pf53arm-thermal {
> > + polling-delay = <2000>;
> > + polling-delay-passive = <250>;
> > + thermal-sensors = <&scmi_sensor 4>;
> > +
> > + cooling-maps {
> > + map0 {
> > + trip = <&pf5301_alert>;
> > + cooling-device =
> > + <&A55_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&A55_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&A55_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&A55_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&A55_4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&A55_5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > + };
> > + };
> > +
> > + trips {
> > + pf5301_alert: trip0 {
> > + hysteresis = <2000>;
> > + temperature = <140000>;
> > + type = "passive";
> > + };
> > +
> > + pf5301_crit: trip1 {
> > + hysteresis = <2000>;
> > + temperature = <155000>;
> > + type = "critical";
> > + };
> > + };
> > + };
> > +
> > + pf53soc-thermal {
> > + polling-delay = <2000>;
> > + polling-delay-passive = <250>;
> > + thermal-sensors = <&scmi_sensor 3>;
> > +
> > + trips {
> > + pf5302_alert: trip0 {
> > + hysteresis = <2000>;
> > + temperature = <140000>;
> > + type = "passive";
> > + };
> > +
> > + pf5302_crit: trip1 {
> > + hysteresis = <2000>;
> > + temperature = <155000>;
> > + type = "critical";
> > + };
> > + };
> > + };
> > +};
> > +
> > +&usdhc1 {
> > + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> > + pinctrl-0 = <&pinctrl_usdhc1>;
> > + pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
> > + pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
> > + bus-width = <8>;
> > + non-removable;
> > + no-sdio;
> > + no-sd;
> > + status = "okay";
> > +};
> > +
> > +&wdog3 {
> > + status = "okay";
> > +};
> > +
> > +&scmi_iomuxc {
> > + pinctrl_flexspi1: flexspi1grp {
> > + fsl,pins = <IMX95_PAD_XSPI1_SS0_B__FLEXSPI1_A_SS0_B 0x19e>,
> > + <IMX95_PAD_XSPI1_DATA0__FLEXSPI1_A_DATA_BIT0 0x19e>,
> > + <IMX95_PAD_XSPI1_DATA1__FLEXSPI1_A_DATA_BIT1 0x19e>,
> > + <IMX95_PAD_XSPI1_DATA2__FLEXSPI1_A_DATA_BIT2 0x19e>,
> > + <IMX95_PAD_XSPI1_DATA3__FLEXSPI1_A_DATA_BIT3 0x19e>,
> > + /* SION to allow clock loopback from pad */
> > + <IMX95_PAD_XSPI1_SCLK__FLEXSPI1_A_SCLK 0x4000019e>,
> > + <IMX95_PAD_XSPI1_DQS__FLEXSPI1_A_DQS 0x4000019e>;
> > + };
> > +
> > + pinctrl_lpi2c2: lpi2c2grp {
> > + fsl,pins = <IMX95_PAD_I2C2_SCL__AONMIX_TOP_LPI2C2_SCL 0x4000191e>,
> > + <IMX95_PAD_I2C2_SDA__AONMIX_TOP_LPI2C2_SDA 0x4000191e>;
> > + };
> > +
> > + pinctrl_sdvmmc: sdvmmcgrp {
> > + fsl,pins = <IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7 0x11e>;
> > + };
> > +
> > + pinctrl_usdhc1: usdhc1grp {
> > + fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>,
> > + <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e>,
> > + <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e>,
> > + <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e>,
> > + <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e>,
> > + <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e>,
> > + <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e>,
> > + <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e>,
> > + <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e>,
> > + <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e>,
> > + <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e>;
> > + };
> > +
> > + pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
> > + fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>,
> > + <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e>,
> > + <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e>,
> > + <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e>,
> > + <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e>,
> > + <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e>,
> > + <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e>,
> > + <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e>,
> > + <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e>,
> > + <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e>,
> > + <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e>;
> > + };
> > +
> > + pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
> > + fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x15fe>,
> > + <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x13fe>,
> > + <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x13fe>,
> > + <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x13fe>,
> > + <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x13fe>,
> > + <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x13fe>,
> > + <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x13fe>,
> > + <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x13fe>,
> > + <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x13fe>,
> > + <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x13fe>,
> > + <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe>;
> > + };
> > +};
> >
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
>
^ permalink raw reply
* Re: [PATCH] arm64: traps: Add a macro to simplify the condition codes check
From: Jinjie Ruan @ 2026-04-22 3:06 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, kees, maz, ada.coupriediaz,
smostafa, leitao, mrigendra.chaubey, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260320082846.1235016-1-ruanjinjie@huawei.com>
On 3/20/2026 4:28 PM, Jinjie Ruan wrote:
> Add DEFINE_COND_CHECK macro to define the simple __check_* functions
> to simplify the condition codes check.
>
> No functional changes.
Gentle ping.
>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/arm64/kernel/traps.c | 59 ++++++++++-----------------------------
> 1 file changed, 15 insertions(+), 44 deletions(-)
>
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 914282016069..6216fe9e8e42 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -49,45 +49,21 @@
> #include <asm/system_misc.h>
> #include <asm/sysreg.h>
>
> -static bool __kprobes __check_eq(unsigned long pstate)
> -{
> - return (pstate & PSR_Z_BIT) != 0;
> -}
> -
> -static bool __kprobes __check_ne(unsigned long pstate)
> -{
> - return (pstate & PSR_Z_BIT) == 0;
> -}
> -
> -static bool __kprobes __check_cs(unsigned long pstate)
> -{
> - return (pstate & PSR_C_BIT) != 0;
> -}
> -
> -static bool __kprobes __check_cc(unsigned long pstate)
> -{
> - return (pstate & PSR_C_BIT) == 0;
> -}
> -
> -static bool __kprobes __check_mi(unsigned long pstate)
> -{
> - return (pstate & PSR_N_BIT) != 0;
> -}
> -
> -static bool __kprobes __check_pl(unsigned long pstate)
> -{
> - return (pstate & PSR_N_BIT) == 0;
> -}
> -
> -static bool __kprobes __check_vs(unsigned long pstate)
> -{
> - return (pstate & PSR_V_BIT) != 0;
> -}
> -
> -static bool __kprobes __check_vc(unsigned long pstate)
> -{
> - return (pstate & PSR_V_BIT) == 0;
> -}
> +#define DEFINE_COND_CHECK(name, flag, expected) \
> +static bool __kprobes __check_##name(unsigned long pstate) \
> +{ \
> + return ((pstate & (flag)) != 0) == (expected); \
> +}
> +
> +DEFINE_COND_CHECK(eq, PSR_Z_BIT, true)
> +DEFINE_COND_CHECK(ne, PSR_Z_BIT, false)
> +DEFINE_COND_CHECK(cs, PSR_C_BIT, true)
> +DEFINE_COND_CHECK(cc, PSR_C_BIT, false)
> +DEFINE_COND_CHECK(mi, PSR_N_BIT, true)
> +DEFINE_COND_CHECK(pl, PSR_N_BIT, false)
> +DEFINE_COND_CHECK(vs, PSR_V_BIT, true)
> +DEFINE_COND_CHECK(vc, PSR_V_BIT, false)
> +DEFINE_COND_CHECK(al, 0, false) /* Always true */
>
> static bool __kprobes __check_hi(unsigned long pstate)
> {
> @@ -131,11 +107,6 @@ static bool __kprobes __check_le(unsigned long pstate)
> return (temp & PSR_N_BIT) != 0;
> }
>
> -static bool __kprobes __check_al(unsigned long pstate)
> -{
> - return true;
> -}
> -
> /*
> * Note that the ARMv8 ARM calls condition code 0b1111 "nv", but states that
> * it behaves identically to 0b1110 ("al").
^ permalink raw reply
* Re: [PATCH v2] mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
From: Lance Yang @ 2026-04-22 2:47 UTC (permalink / raw)
To: david
Cc: linux-arm-kernel, catalin.marinas, will, akpm, ljs, Liam.Howlett,
vbabka, rppt, surenb, mhocko, jackmanb, hannes, ziy, lance.yang,
ryan.roberts, broonie, dev.jain, linux-kernel, linux-mm, stable
In-Reply-To: <20260421-zerotags-v2-1-05cb1035482e@kernel.org>
On Tue, Apr 21, 2026 at 05:39:07PM +0200, David Hildenbrand (Arm) wrote:
>__GFP_ZEROTAGS semantics are currently a bit weird, but effectively this
>flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.
>
>If we run with init_on_free, we will zero out pages during
>__free_pages_prepare(), to skip zeroing on the allocation path.
>
>However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will
>consequently not only skip clearing page content, but also skip
>clearing tag memory.
>
>Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that
>will get mapped to user space through set_pte_at() later: set_pte_at() and
>friends will detect that the tags have not been initialized yet
>(PG_mte_tagged not set), and initialize them.
>
>However, for the huge zero folio, which will be mapped through a PMD
>marked as special, this initialization will not be performed, ending up
>exposing whatever tags were still set for the pages.
>
>The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state
>that allocation tags are set to 0 when a page is first mapped to user
>space. That no longer holds with the huge zero folio when init_on_free
>is enabled.
>
>Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to
>tag_clear_highpages() whether we want to also clear page content.
>
>Invert the meaning of the tag_clear_highpages() return value to have
>clearer semantics.
>
>Reproduced with the huge zero folio by modifying the check_buffer_fill
>arm64/mte selftest to use a 2 MiB area, after making sure that pages have
>a non-0 tag set when freeing (note that, during boot, we will not
>actually initialize tags, but only set KASAN_TAG_KERNEL in the page
>flags).
>
> $ ./check_buffer_fill
> 1..20
> ...
> not ok 17 Check initial tags with private mapping, sync error mode and mmap memory
> not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory
> ...
>
>This code needs more cleanups; we'll tackle that next, like
>decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN.
>
>Fixes: adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio")
>Cc: stable@vger.kernel.org
>Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>---
Tested this fix on MTE with both kasan=on and kasan=off. Works as
expected in both cases.
Nothing jumped out at me, LGTM!
Tested-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Andrew Jeffery @ 2026-04-22 2:30 UTC (permalink / raw)
To: Conor Dooley, Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Linus Walleij, Bartosz Golaszewski, Ryan Chen,
Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20260421-valid-expanse-ae6b5a9289f2@spud>
On Tue, 2026-04-21 at 18:57 +0100, Conor Dooley wrote:
> Billy, Linus,
>
> On Tue, Apr 21, 2026 at 06:15:44AM +0000, Billy Tsai wrote:
> > > > > > > > + properties:
> > > > > > > > + function:
> > > > > > > > + enum:
> > > > > > > > + - EMMC
> > > > > > > > + - JTAGDDR
> > > > > > > > + - JTAGM0
> > > > > > > > + - JTAGPCIEA
> > > > > > > > + - JTAGPCIEB
> > > > > > > > + - JTAGPSP
> > > > > > > > + - JTAGSSP
> > > > > > > > + - JTAGTSP
> > > > > > > > + - JTAGUSB3A
> > > > > > > > + - JTAGUSB3B
> > > > > > > > + - PCIERC0PERST
> > > > > > > > + - PCIERC1PERST
> > > > > > > > + - TSPRSTN
> > > > > > > > + - UFSCLKI
> > > > > > > > + - USB2AD0
> > > > > > > > + - USB2AD1
> > > > > > > > + - USB2AH
> > > > > > > > + - USB2AHP
> > > > > > > > + - USB2AHPD0
> > > > > > > > + - USB2AXH
> > > > > > > > + - USB2AXH2B
> > > > > > > > + - USB2AXHD1
> > > > > > > > + - USB2AXHP
> > > > > > > > + - USB2AXHP2B
> > > > > > > > + - USB2AXHPD1
> > > > > > > > + - USB2BD0
> > > > > > > > + - USB2BD1
> > > > > > > > + - USB2BH
> > > > > > > > + - USB2BHP
> > > > > > > > + - USB2BHPD0
> > > > > > > > + - USB2BXH
> > > > > > > > + - USB2BXH2A
> > > > > > > > + - USB2BXHD1
> > > > > > > > + - USB2BXHP
> > > > > > > > + - USB2BXHP2A
> > > > > > > > + - USB2BXHPD1
> > > > > > > > + - USB3AXH
> > > > > > > > + - USB3AXH2B
> > > > > > > > + - USB3AXHD
> > > > > > > > + - USB3AXHP
> > > > > > > > + - USB3AXHP2B
> > > > > > > > + - USB3AXHPD
> > > > > > > > + - USB3BXH
> > > > > > > > + - USB3BXH2A
> > > > > > > > + - USB3BXHD
> > > > > > > > + - USB3BXHP
> > > > > > > > + - USB3BXHP2A
> > > > > > > > + - USB3BXHPD
> > > > > > > > + - VB
> > > > > > > > + - VGADDC
> > > > > > > > +
> > > > > > > > + groups:
> > > > > > > > + enum:
> > > > > > > > + - EMMCCDN
> > > > > > > > + - EMMCG1
> > > > > > > > + - EMMCG4
> > > > > > > > + - EMMCG8
> > > > > > > > + - EMMCWPN
> > > > > > > > + - JTAG0
> > > > > > > > + - PCIERC0PERST
> > > > > > > > + - PCIERC1PERST
> > > > > > > > + - TSPRSTN
> > > > > > > > + - UFSCLKI
> > > > > > > > + - USB2A
> > > > > > > > + - USB2AAP
> > > > > > > > + - USB2ABP
> > > > > > > > + - USB2ADAP
> > > > > > > > + - USB2AH
> > > > > > > > + - USB2AHAP
> > > > > > > > + - USB2B
> > > > > > > > + - USB2BAP
> > > > > > > > + - USB2BBP
> > > > > > > > + - USB2BDBP
> > > > > > > > + - USB2BH
> > > > > > > > + - USB2BHBP
> > > > > > > > + - USB3A
> > > > > > > > + - USB3AAP
> > > > > > > > + - USB3ABP
> > > > > > > > + - USB3B
> > > > > > > > + - USB3BAP
> > > > > > > > + - USB3BBP
> > > > > > > > + - VB0
> > > > > > > > + - VB1
> > > > > > > > + - VGADDC
> > > > > > > > + pins:
> > > > > > > > + enum:
> > > > > > > > + - AB13
> > > > > > > > + - AB14
> > > > > > > > + - AC13
> > > > > > > > + - AC14
> > > > > > > > + - AD13
> > > > > > > > + - AD14
> > > > > > > > + - AE13
> > > > > > > > + - AE14
> > > > > > > > + - AE15
> > > > > > > > + - AF13
> > > > > > > > + - AF14
> > > > > > > > + - AF15
> >
> > > > > > > Why do you have groups and pins?
> > > > > > > Is it valid in your device to have groups and pins in the same node?
> >
> > > > > > The intent is to support both group-based mux selection and
> > > > > > configuration, as well as per-pin configuration.
> >
> > > > > > In our hardware:
> > > > > > - `function` + `groups` are used for pinmux selection.
> > > > > > - `pins` is used for per-pin configuration (e.g. drive strength,
> > > > > > bias settings).
> > > > > > - `groups` may also be used for group-level configuration.
> >
> > > > > > As a result, both `groups` and `pins` may appear in the same node,
> > > > > > but they serve different purposes and do not conflict:
> > > > > > - `groups` selects the mux function and may apply configuration to
> > > > > > the entire group.
> > > > > > - `pins` allows overriding or specifying configuration for individual
> > > > > > pins.
> >
> > > > > > In most cases, only one of them is needed, but both are allowed when
> > > > > > both group-level and per-pin configuration are required.
> >
> > > > > To be honest, that sounds like your groups are not sufficiently
> > > > > granular and should be reduced such that you can use them for pin
> > > > > settings.
> >
> > > > The intent was to keep the binding flexible, but in practice the mixed
> > > > use of `groups` and `pins` in the same node is not expected to be used.
> > > >
> > > > Given that, I agree this flexibility is unnecessary and makes the
> > > > binding semantics less clear. I'll rework the binding to make the
> > > > expected usage explicit rather than allowing combinations that do not
> > > > correspond to a real use case.
> > > >
> > > > In particular, I'll split the constraints as follows:
> > > >
> > > > - For pinmux, the presence of `function` will require `groups`, and
> > > > `pins` will not be allowed. This reflects the hardware design, where
> > > > the groups are defined by the pins affected by a given mux expression
> > > >
> > > > - For pin configuration, exactly one of `groups` or `pins` will be
> > > > required (using oneOf), so that configuration is applied either at
> > > > group level or per-pin, but not both.
> > > >
> > > >
> > > > - if:
> > > > required:
> > > > - function
> > > > then:
> > > > required:
> > > > - groups
> > > > not:
> > > > required:
> > > > - pins
> > > > else:
> > > > oneOf:
> > > > - required:
> > > > - groups
> > > > not:
> > > > required:
> > > > - pins
> > > > - required:
> > > > - pins
> > > > not:
> > > > required:
> > > > - groups
> > > > Does this match what you had in mind?
> >
> > > It's an improvement I think, but I am wondering why you cannot do
> > > without pins entirely and apply pinconf stuff at the group level?
> > > Of course that may not be possible with the current groups, but if you
> > > made the groups more granular, would it be possible?
> >
> > Within a given group, it is not always the case that all pins share the
> > same configuration requirements (e.g. drive strength or bias settings),
> > so applying pinconf purely at the group level would be too restrictive.
>
> Right. That's pretty normal.
>
> > Making the groups more granular to match all possible configuration
> > combinations would not reflect the actual mux granularity and would
> > significantly increase the number of groups.
>
> >
> > For example, we have encountered a timing issue due to the PCB layout,
> > where only the eMMC clock pin requires a different drive strength:
> >
> > # The EMMCG4 group includes pins AC14, AE15, AD14, AE14, AF14, AB13
> > # AC14: clock
> > # AE15: command
> > # AD14–AB13: data
> >
> > pinconf_emmc_clk: emmc-clk-pinconf {
> > pins = "AC14";
> > drive-strength = <8>;
> > };
> >
> > In this case, applying pin configuration at the group level would affect
> > all pins in the group, which is not desirable. Allowing per-pin
> > configuration via `pins` is therefore necessary.
> >
> > For this reason, `groups` is used for mux selection, while `pins` is
> > required to express per-pin configuration where needed.
>
> Right, yeah, I figured your objection to it was because of how
> annoyingly small it would make the groups. I suppose the alternative is
> going without groups and always using pins.
As the author of the pinctrl drivers and bindings for the earlier
Aspeed SoC families, I prefer we don't discard the groups here.
These legacy pin controller designs from Aspeed are quite complex. The
function and group are often not decoupled in the register interface,
but a given mux function may only reflect a subset of the necessary
behaviour for a bus (or it may not). Thus the groups are intended to
reflect the pins implied by the function - they should be neither
under- nor over- specified with respect to the hardware behaviour. I'm
concerned that shifting the group definitions to the devicetree implies
they are more configurable than is the case, and shifts the group
membership of pins away from related information in the driver. I am
more comfortable with the interface being defined in terms of groups
for the purpose of pinmux.
That said, from a pinconf perspective, it needs to be possible to apply
work-arounds for board design issues as Billy described above.
I feel the constraints that Billy proposed above are reasonable. We
shouldn't see both 'groups' and 'pins' in the same node as a
consequence, rather we can use multiple phandles in the pinctrl-0
property to affect the pinmux and pinconf settings required via
separate nodes.
Andrew
^ permalink raw reply
* Re: [PATCH 3/3] MAINTAINERS: add Axiado SGPIO controller
From: Prasad Bolisetty @ 2026-04-22 1:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Petar Stepanovic, Tzu-Hao Wei, Swark Yang,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Harshit Shah, SriNavmani A
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <cadd1ab2-a70a-4f7f-9bd8-3146ddacc2cc@kernel.org>
On 4/14/2026 7:12 AM, Krzysztof Kozlowski wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On 14/04/2026 15:48, Petar Stepanovic wrote:
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 67db88b04537..56835c0a1863 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -4234,6 +4234,15 @@ S: Maintained
>> F: Documentation/devicetree/bindings/sound/axentia,*
>> F: sound/soc/atmel/tse850-pcm5142.c
>>
>> +AXIADO SGPIO DRIVER
>> +M: Petar Stepanovic <pstepanovic@axiado.com>
>> +M: SriNavmani A <srinavmani@axiado.com>
>> +M: Prasad Bolisetty <pbolisetty@axiado.com>
>
> I also expect reviews from the remaining maintainers, especially in all
> the trivialities like posting very old code patterns.
>
> Best regards,
> Krzysztof
We had an internal review prior to the submission,
and we will double-check the old code pattern in the future.
Thank you for the review, and we will fix all the review comments.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox