* 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 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/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 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 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: 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 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: [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 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 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 7/8] ARM: dts: Declare UARTs on zx297520v3 boards
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-7-ace038e63515@gmail.com>
On Tue, Apr 21, 2026 at 11:23:15PM +0300, Stefan Dösinger wrote:
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> ---
>
Same comments about subject and squashing. This cannot be a separate
commit.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 7/8] ARM: dts: Declare UARTs on zx297520v3 boards
From: Krzysztof Kozlowski @ 2026-04-22 7:11 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: <20260422-vigorous-beautiful-peacock-4ac41b@quoll>
On 22/04/2026 09:10, Krzysztof Kozlowski wrote:
> On Tue, Apr 21, 2026 at 11:23:15PM +0300, Stefan Dösinger wrote:
>> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>>
>> ---
>>
>
> Same comments about subject and squashing. This cannot be a separate
> commit.
>
Heh, and with empty commit msg!
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/9] ASoC: dt-bindings: mt2701-afe-pcm: add HDMI audio path clocks
From: Krzysztof Kozlowski @ 2026-04-22 7:19 UTC (permalink / raw)
To: Daniel Golle
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Arnd Bergmann, Cyril Chao,
Nícolas F. R. A. Prado, Kuninori Morimoto, Eugen Hristev,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <69f0b69e49068695db4ba6164c0757ccdf9786fd.1776646435.git.daniel@makrotopia.org>
On Mon, Apr 20, 2026 at 02:13:05AM +0100, Daniel Golle wrote:
> clock-names:
> + minItems: 34
> items:
> - const: infra_sys_audio_clk
> - const: top_audio_mux1_sel
> @@ -104,6 +110,10 @@ properties:
> - const: audio_a1sys_pd
> - const: audio_a2sys_pd
> - const: audio_mrgif_pd
> + - const: hadds2pll_294m
> + - const: audio_hdmi_pd
> + - const: audio_spdf_pd
> + - const: audio_apll_pd
>
> required:
> - compatible
> @@ -114,3 +124,16 @@ required:
> - clock-names
>
> additionalProperties: false
> +
> +allOf:
allOf goes before additionalProperties
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/9] ASoC: dt-bindings: mediatek,mt2701-hdmi-audio: add MT2701 HDMI audio
From: Krzysztof Kozlowski @ 2026-04-22 7:23 UTC (permalink / raw)
To: Daniel Golle
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Arnd Bergmann, Cyril Chao,
Nícolas F. R. A. Prado, Kuninori Morimoto, Eugen Hristev,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <072c4db4a01ac125e9ee5e34f992cd169c78e117.1776646435.git.daniel@makrotopia.org>
On Mon, Apr 20, 2026 at 02:13:13AM +0100, Daniel Golle wrote:
> Describe the sound card node that routes the MT2701/MT7623N AFE
> HDMI playback path to the on-chip HDMI transmitter. This is
> separate from the AFE platform binding (mediatek,mt2701-audio)
> because it represents board-level audio routing between the AFE
> and the HDMI codec, not an additional IP block. MT7623N boards
> carry the same IP and use the mt7623n- compatible as a fallback
> to mt2701-.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> v2:
> * Fix subject prefix to use schema filename (Krzysztof Kozlowski)
> * Rewrite title and description to describe hardware, not driver
> (Krzysztof Kozlowski)
> * Clarify in commit message why this is a separate binding from
> mediatek,mt2701-audio (Krzysztof Kozlowski)
>
> .../sound/mediatek,mt2701-hdmi-audio.yaml | 48 +++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 1/1] arm64: dts: add tqma9596la-mba95xxca
From: Alexander Stein @ 2026-04-22 7:24 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Markus Niebel, imx, linux-arm-kernel, devicetree, linux-kernel,
linux, linux-renesas-soc, 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>
---
Changes in v3:
* Moved reserved-memory to board-lebel
* Remove VPU reserved memory (unused for now)
* Fix typo in connector comment
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 | 961 ++++++++++++++++++
.../boot/dts/freescale/imx95-tqma9596la.dtsi | 278 +++++
3 files changed, 1240 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 711e36cc2c990..b47db26224bb9 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -507,6 +507,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
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-nonwifi-dahlia.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..82d1d2f150124
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
@@ -0,0 +1,961 @@
+// 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;
+ };
+
+ 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;
+ };
+ };
+
+ 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 + SFP */
+&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..aa2756c14e461
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
@@ -0,0 +1,278 @@
+// 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>;
+ };
+
+ 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>;
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: New warning in linus/master
From: Christophe Leroy (CS GROUP) @ 2026-04-22 7:26 UTC (permalink / raw)
To: Thomas Weißschuh, Ricardo Ribalda
Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20260422071541-9a295128-d913-418f-a21c-1386fca30290@linutronix.de>
Le 22/04/2026 à 07:56, Thomas Weißschuh a écrit :
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Flinux-media%2Fusers%2Fribalda%2F-%2Fpipelines%2F1649144%2Ftest_report%3Fjob_name%3Dcross-gcc&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C5c0f15ee20a44072f47108dea0340304%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639124342424606113%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9Tvp2aYfB02ijxVGLzCOYcMwZlPvqVDufxEporLl1mc%3D&reserved=0
>
> 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.
You are likely in a special case where vdso_get_timestamp() returns
false without setting &sec, and some versions of GCC and/or CLANG fail
to see that vdso_set_timespec() is not called when vdso_get_timestamp()
returns false.
Christophe
^ permalink raw reply
* Re: New warning in linus/master
From: Thomas Weißschuh @ 2026-04-22 7:32 UTC (permalink / raw)
To: Ricardo Ribalda; +Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <CANiDSCviww1L1p2+MvF59Biqb6hc7WdL1J37kBjFd1NXz-Yt8A@mail.gmail.com>
On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
> On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
> <thomas.weissschuh@linutronix.de> wrote:
> > 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
Ack.
> 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
Both reproducers do *not* reproduce the issue for me.
(It is more or less exactly what I tried before)
Please note that this line does not work in general:
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make arch/arm64/kernel/vdso/vgettimeofday.o
The vDSO object files can not be built in this way like regular kernel object
files and will produce a compiler error, but not the one under discussion.
Instead the vDSO on arm64 is built during the 'make prepare' phase.
(Other architectures work differently, of course...)
(...)
Thomas
^ permalink raw reply
* Re: [PATCH v2] mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
From: David Hildenbrand (Arm) @ 2026-04-22 7:32 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Andrew Morton, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Zi Yan, Lance Yang, Ryan Roberts, Mark Brown,
Dev Jain, linux-kernel, linux-mm, stable
In-Reply-To: <20260421-zerotags-v2-1-05cb1035482e@kernel.org>
> }
> diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> index 6c75df30a281..d79049291b1a 100644
> --- a/include/linux/gfp_types.h
> +++ b/include/linux/gfp_types.h
> @@ -273,11 +273,11 @@ enum {
> *
> * %__GFP_ZERO returns a zeroed page on success.
> *
> - * %__GFP_ZEROTAGS zeroes memory tags at allocation time if the memory itself
> - * is being zeroed (either via __GFP_ZERO or via init_on_alloc, provided that
> - * __GFP_SKIP_ZERO is not set). This flag is intended for optimization: setting
> - * memory tags at the same time as zeroing memory has minimal additional
> - * performance impact.
> + * %__GFP_ZEROTAGS zeroes memory tags at allocation time. Setting memory tags at
> + * the same time as zeroing memory (e.g., with __GPF_ZERO) has minimal
As pointed out by AI review s/__GPF_ZERO/__GFP_ZERO/.
I assume this can be fixed up when applying.
--
Cheers,
David
^ permalink raw reply
* Re: New warning in linus/master
From: Ricardo Ribalda @ 2026-04-22 8:06 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20260422092713-4021a1a5-3a54-4260-878a-aec1bef3f8c7@linutronix.de>
Hi Thomas
On Wed, 22 Apr 2026 at 15:32, Thomas Weißschuh
<thomas.weissschuh@linutronix.de> wrote:
>
> On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
> > On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
> > <thomas.weissschuh@linutronix.de> wrote:
> > > 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
>
> Ack.
>
> > 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
>
> Both reproducers do *not* reproduce the issue for me.
> (It is more or less exactly what I tried before)
Ok, I think I found what is going on. media-ci was forcing
KCFLAGS=-Wmaybe-uninitialized
https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/test-build.sh?ref_type=heads#L29
And something has changed in the kernel in the last version that
triggers a (hopefully) false positive.
can you try with:
CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
KCFLAGS=-Wmaybe-uninitialized allyesconfig
CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
KCFLAGS=-Wmaybe-uninitialized prepare
?
>
> Please note that this line does not work in general:
> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make arch/arm64/kernel/vdso/vgettimeofday.o
>
> The vDSO object files can not be built in this way like regular kernel object
> files and will produce a compiler error, but not the one under discussion.
> Instead the vDSO on arm64 is built during the 'make prepare' phase.
> (Other architectures work differently, of course...)
>
> (...)
>
>
> Thomas
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH RFC 0/4] arm64: rockchip: The hunt for exact pixel clocks on RK3576
From: Alexey Charkov @ 2026-04-22 8:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Brian Masney, Sebastian Reichel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Pavel Zhovner, Andy Yan, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-clk, Cristian Ciocaltea
In-Reply-To: <20260421-quirky-tough-robin-817a1c@houat>
Hi Sebastian, Brian, Maxime,
Thanks a lot for your inputs!
On Tue, Apr 21, 2026 at 8:10 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> Hi Brian, Alexey,
>
> On Mon, Apr 20, 2026 at 12:02:58PM -0400, Brian Masney wrote:
> > On Sat, Apr 18, 2026 at 12:24:57AM +0200, Sebastian Reichel wrote:
> > > On Fri, Apr 17, 2026 at 07:11:43PM +0400, Alexey Charkov wrote:
> > > > Dear all,
> > > >
> > > > Need the help of the collective wisdom of the community.
> > > >
> > > > The problem I'm trying to solve is reliably obtaining the exact pixel
> > > > clock for arbitrary display modes supported by the RK3576 SoC.
> > > >
> > > > Rockchip RK3576 has three display output processors VP0~VP2, each
> > > > supporting different ranges of display modes, roughly as follows:
> > > > - VP0: 4K 120Hz
> > > > - VP1: 2.5k 60Hz
> > > > - VP2: 1080p 60Hz
>
> Do any of those have an additional multiplier or divider after the PLL?
>
> I'm asking because 4k@120Hz is 1188MHz, and 1080p@60Hz is 148.5 (so 1188
> / 8). 2.5k @ 60 might be a bit more problematic, but my point is that
> for HDMI/DP, most resolutions all have a pixel clock that are multiples
> of 148.5MHz.
>
> If you manage to get the PLL to the highest you need (1188MHz), and then
> apply dividers, you don't need to change the PLL frequency anymore.
Yes, each of them has an (integer-only) divider between the PLL and
the respective mux. The problem though is that displays' EDIDs want
modes that are all over the place and don't seem to converge to any
common numbers generally (it looks like display manufacturers haven't
heard of VESA modes these days).
Following Heiko's nudge from the other sub-thread (thanks for the
pointers Heiko!), I derived the fractional PLL parameters for the
modes which couldn't be obtained cleanly from existing PLL values. It
ended up being 35(!) different rates for just the 7 displays my
colleagues and I could get our hands on, majority of which only
representable with the fractional delta-sigma component. That's after
consolidating the clocks which can be driven from the same
higher-frequency PLL configuration with small integer dividers. Seeing
all of that I couldn't help but think, "Surely those should be
possible to consolidate further by allowing for some error margin!" -
but had to guess again. Even a deviation as small as 0.2% of the
effective clock from the requested rate causes blank screens in my
sample - sometimes less than that.
This further leads me to believe that Brian's rate negotiation series
won't save me here, as the chances of two different displays at two
different weird modes magically agreeing on a PLL rate that is a
common multiple of their respective pixel clocks seem infinitesimal.
And their modes will most likely differ, as VP outputs are asymmetric.
Unless of course everything is 1920x1080@60 with a standard 148.5 MHz
pixel clock or its integer multiple - then the problem doesn't exist,
as this particular mode works even in the current configuration on all
VPs.
> > > > Each one obviously needs a pixel clock. The required frequencies for the
> > > > pixel clocks vary greatly depending on the display mode, and need to be
> > > > matched within a tight tolerance, or else many displays will refuse to
> > > > work. E.g. the preferred (maximum) display mode out of VP1 is particularly
> > > > awkward, because it requires a pixel clock of 248.88 MHz, which cannot
> > > > be obtained using integer dividers from its default clock source (GPLL
> > > > at 1188 MHz), and the nearest approximation is 237.6 MHz, which is well
> > > > outside the tolerance of e.g. DP specification, resulting in a blank
> > > > screen on most displays by default.
> > > >
> > > > The clock sources are of course configurable, in particular there are muxes
> > > > connected to each VP for selecting the source of the pixel clock:
> > > > - Each VP can take the clock either from the (single!) HDMI PHY or from
> > > > its dedicated dclk_vpX_src mux
> > > > - The dclk_vpX_src mux can select the clock from a number of system PLLs
> > > > (GPLL, CPLL, VPLL, BPLL, LPLL)
> > > >
> > > > While the system PLLs can be configured to output a wide range of
> > > > frequencies, they are shared between many system components. E.g. on the
> > > > current mainline kernel on one of my RK3576 boards I've got the following:
> > > > GPLL: 1188 MHz, enable count 20
> > > > CPLL: 1000 MHz, enable count 17
> > > > VPLL: 594 MHz, enable count 0 (yaay!)
> > > > BPLL, LPLL: 816 MHz, enable count 0 (but these last ones don't have
> > > > predividers, so are less flexible)
> > > >
> > > > So ultimately there is exactly one free fractional PLL (VPLL) which can be
> > > > used to generate arbitrary pixel clocks, but we have up to three consumers
> > > > trying to drive different display modes from it (e.g. HDMI on VP0, DP on
> > > > VP1 and MIPI DSI on VP2). We also want to be able to adjust the PLL output
> > > > frequency on the fly to satisfy the requirements of the selected display
> > > > mode.
> > > >
> > > > And this is where I'm stuck. Trying to satisfy the requirements of up to
> > > > three consumers while changing the PLL frequency on the fly sounds like
> > > > a poorly tractable mathematical problem (is it 3-SAT?). We can take the
> > > > HDMI output out of the equation, because it can be driven from the HDMI
> > > > PHY (which is capable of arbitrary rates) instead of the mux, but that
> > > > makes the decision of which dclk source to use for a VP block dependent on
> > > > which downstream consumer is connected to it (HDMI vs. something else).
> > >
> > > It becomes more messy: The HDMI PHY cannot be used as clock source
> > > for modes exceeding 4K@60Hz.
Thanks for the pointer! I've checked, and indeed it automatically
switches to the PHY clock for anything below 600 MHz.
This is in fact a notable improvement, because then only a handful of
higher-rate modes out of my modest sample need a dedicated PLL for the
VP0+HDMI setup: specifically, 3840x2160@160 (1478740 kHz),
3840x2160@144 (1275830 kHz), 3840x2160@119.88 (1186813 kHz - this one
might work with 1188000 if CCF allows returning higher-than-requested
effective rates) and 2560x1440@165.08 (645000 kHz).
3840x2160@120 can be driven from the current GPLL, as it's exactly 1188 MHz.
The configuration / policy to enable that transparently for the user
seems non-trivial though:
- If the output is HDMI and the display clock is <=600 MHz, always
source it from HDMI PHY (easy)
- Otherwise, if the display clock is 1188 MHz or its integer quotient,
always source it from GPLL, and disallow parent rate changes
- Otherwise, reparent to any active PLL whose current rate is an
integer multiple of the required display clock, and disallow parent
rate changes
- Otherwise, see if VPLL is free. If it is, reparent to it and request
its rate change to the required display clock (or its integer
multiple)
- Otherwise, tell the user the mode set failed (and let them retry
with a different mode, or own the pieces)
I'd love to learn if the above (or anything close) is representable in
the kernel, although I suspect it's not:
- Allowing or disallowing parent rate changes depends on the selected
parent here, while in the current clock implementation it's an
attribute of the child
- All PLLs are equal, but one (VPLL) is more equal than the others by
the virtue of being free more often, and also having the required
delta-sigma component
- Reparenting to an already running PLL if its rate permits should be
preferred to monopolizing the VPLL
> > > > Even then we somehow need two devices to cooperate in picking a PLL
> > > > frequency that satisfies the requirements of both of them, and change to it
> > > > without display corruption. I'm not even sure if the CCF has mechanisms
> > > > for that?..
>
> It's not *just* the CCF though. You will disrupt the other, already
> active display, which might affect the user because the screen will
> blank, throw off the vblank timings and thus userspace, etc.
Indeed. Changing the rate of a PLL while it's in use sounds scary,
even if a solution for the rate exists and can be found in reasonable
time.
> Brian's solution is great progress on that front already, but if you can
> just save yourself the trouble, I'd advise you to do that instead :)
I'd love to, but it seems that displays won't let me :-D
It might be helpful to pre-filter the allowed display modes to only
offer those which can be derived from the currently available PLL
frequencies. The problem is that it makes an extremely limited subset
on real-world displays.
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-04-22 8:36 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov, mbrugger
In-Reply-To: <aeeMp1XBDxSZ1qrl@monoceros>
Hi Uwe,
On 16:50 Tue 21 Apr , Uwe Kleine-König wrote:
> Hello Andrea,
>
> On Mon, Apr 20, 2026 at 06:27:45PM +0200, Andrea della Porta wrote:
> > On 12:50 Fri 17 Apr , Uwe Kleine-König wrote:
> > > What happens if sync is asserted while a disabled channel didn't
> > > complete the last period yet?
> >
> > The output stops immediately without waiting for the current period to finish.
>
> This is a good info for the Limitations block.
Yup, already added, plus a couple other edge cases.
>
> > > Maybe it's worth to test the following procedure for updating duty and
> > > period:
> > >
> > > disable channel
> > > configure duty
> > > configure period
> > > enable
> > > set update flag
> > >
> > > Assumint disable is delayed until the end of the currently running
> > > period, the effect of this procedure might be that no glitch happens if
> > > the update flag is asserted before the currently running period ends and
> > > the anormality is reduced to a longer inactive state if the updates are
> > > not that lucky (in contrast to more severe glitches).
> >
> > The disable isn't delayed as explained above. Setting just the new period/duty
> > (which do not depend on the sync bit) correctly waits for the end of the current
> > period without noticeable glitches (tested with a scope).
>
> So if you happen to change both and one is done before the end of the
> current period and the other shortly afterwards (which might happen as
> those are configured in two different registers and the update trigger
> isn't used), you get a mixed output for one cycle, right? If yes, please
> also mention that in the Limitations paragraph.
Confirmed, tested with the scope and a very long period time.
>
> > > > Let's say that teh user want 10 tick period, we have to use
> > > > 9 instead to account for the extra tick at the end, so that the complete period
> > > > contains that extra tick?
> > >
> > > I would describe that a bit differently, but in general: yes.
> > >
> > > The more straight forward description is that setting
> > >
> > > RP1_PWM_RANGE(pwm->hwpwm) := x
> > >
> > > results in a period of x + 1 ticks.
> >
> > Exactly. So whatever the user request I have to subtract one from the value
> > to be written to the RANGE register.
>
> Unless the calculation is already rounded to 0, in that case don't
> subtract 1 and let the tohw callback return 1.
Sure.
>
> > > > This also means that if we ask for 100% duty cycle, the output waveform will
> > > > have the high part of the signal lasting one tick less than expected.a I guess
> > > > this is the accepted compromise.
> > >
> > > I assume you considered something like:
> > >
> > > RP1_PWM_RANGE(pwm->hwpwm) := 17
> > > RP1_PWM_DUTY(pwm->hwpwm) := 18
> > >
> > > to get a 100% relative duty?
> >
> > Ah right! It's working fine and I've got 100% duty. So at hw register level
> > the duty can be greater that the period.
>
> In that case please make sure to not use the maximal value for
> RP1_PWM_RANGE(pwm->hwpwm) to ensure that for each (possible) period
> length a 100% relative duty cycle can be configured.
Ack.
>
> > > My (not so well articulated) point is: Please be stringent about clock
> > > handling to not bank up technical dept more than necessary and such that
> > > the driver can be made unbindable if and when syscons grow
> > > that feature. Optionally wail at the syscon guys :-)
> >
> > Hmmm not sure I've understood your point: is it a requirement that the driver
> > must be unbindable? In this case I should avoid registering the syscon. Or
> > should I just provide a .remove callback in case there will be a way to
> > unregister the syscon (even if this callback will not be called as of now)?
>
> It's a requirement to properly manage the resources you allocate. If a
> driver isn't unbindable due to restrictions of other subsystems that's
> unfortunate and I don't like it, but I wouldn't block a patch because of
> that.
I totally agree, of course. From a practical perspective I take it as "even
if it's not ideal, you don't need to do further coding action on that side".
Many thanks,
Andrea
>
> Best regards
> Uwe
^ permalink raw reply
* [PATCH] dt-bindings: arm-smmu: qcom:: Fix Hawi compatible placement
From: Mukesh Ojha @ 2026-04-22 8:33 UTC (permalink / raw)
To: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robin Murphy, Mukesh Ojha
Cc: Robin Murphy, Krzysztof Kozlowski, linux-arm-kernel, iommu,
devicetree, linux-kernel
qcom,hawi-smmu-500 was placed in the wrong enum block of GPU. Move it to
the correct location alongside other Qualcomm SMMU-500 compatibles for
CPU.
Fixes: 5e8323c3d528 ("dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC")
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 06fb5c8e7547..ba9ad1f5a8ff 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -37,6 +37,7 @@ properties:
- enum:
- qcom,eliza-smmu-500
- qcom,glymur-smmu-500
+ - qcom,hawi-smmu-500
- qcom,kaanapali-smmu-500
- qcom,milos-smmu-500
- qcom,qcm2290-smmu-500
@@ -93,7 +94,6 @@ properties:
items:
- enum:
- qcom,glymur-smmu-500
- - qcom,hawi-smmu-500
- qcom,kaanapali-smmu-500
- qcom,milos-smmu-500
- qcom,qcm2290-smmu-500
--
2.53.0
^ permalink raw reply related
* Re: i.MX8M Plus PCIe link regression
From: Thorsten Leemhuis @ 2026-04-22 8:39 UTC (permalink / raw)
To: Alexander Stein, Hongxing Zhu, Manivannan Sadhasivam
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, Linux kernel regressions list
In-Reply-To: <6102060.LvFx2qVVIh@steina-w>
Lo! What happened to this regression? It looks like it was never
resolved. Is that something everybody can live with in some way? Or
something we have to live with, as reverting the culprit at this point
would create a regression and thus creates even more trouble then it solves?
Ciao, Thorsten
On 3/4/26 09:47, Alexander Stein wrote:
>
> Am Mittwoch, 4. März 2026, 07:32:48 CET schrieb Manivannan Sadhasivam:
>> On Wed, Mar 04, 2026 at 02:55:51AM +0000, Hongxing Zhu wrote:
>>>> -----Original Message-----
>>>> From: Manivannan Sadhasivam <mani@kernel.org>
>>>> Sent: 2026年3月4日 0:42
>>>> To: Hongxing Zhu <hongxing.zhu@nxp.com>; Alexander Stein
>>>> <alexander.stein@ew.tq-group.com>
>>>> Cc: linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>>> imx@lists.linux.dev
>>>> Subject: Re: i.MX8M Plus PCIe link regression
>>>>
>>>> On Tue, Mar 03, 2026 at 01:38:13PM +0100, Alexander Stein wrote:
>>>>> Hi,
>>>>>
>>>>> these days I noticed that there is a PCIe link regression on my
>>>>> i.MX8MP platform (TQMa8MPxL) running next-20260227.
>>>>> I could bisect it back to commit 9c03e30e3ade3 ("PCI: imx6: Skip link
>>>>> up workaround for newer platforms"). I always get the following errors:
>>>>>
>>>>> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM:
>>>>> CFG_LINKWD_START imx6q-pcie 33800000.pcie: probe with driver
>>>>> imx6q-pcie failed with error -110
>>>>>
>>>>> Connected is a Gen1 PCIe -> Ethernet adapter. Interestingly a Gen2
>>>>> device is detected without issues.
>>>>>
>>>>> Reverting 3c96a61dd2e098dda8dcac3dce3d38a3c87afbfc and
>>>>> b9a8d28ebbf118bb3eac953f4a37abbd341257ab "fixes" my platform, both
>>>> Gen
>>>>> 1 and Gen 2 devices are detect. Commit
>>>>> 3c96a61dd2e098dda8dcac3dce3d38a3c87afbfc is only required for conflict
>>>> free revert.
>>>>>
>>>>> Here is a summary with outputs:
>>>>> Gen 1 device
>>>>>> 00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)
>>>>>> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>>>>>> RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev
>>>>>> 01)
>>>>>
>>>>> Gen 2 device
>>>>>> 00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)
>>>>>> 01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9128 PCIe
>>>>>> SATA 6 Gb/s RAID controller (rev 20)
>>>>>
>>>>> output of "dmesg | grep imx6q-pcie". Common part for all tests:
>>>>>> imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
>>>>>> imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff ->
>>>>>> 0x0000000000
>>>>>> imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff ->
>>>>>> 0x0018000000
>>>>>> imx6q-pcie 33800000.pcie: config reg[1] 0x1ff00000 == cpu 0x1ff00000
>>>>>> imx6q-pcie 33800000.pcie: iATU: unroll T, 4 ob, 4 ib, align 64K,
>>>>>> limit 16G
>>>>>
>>>>> next-20260227
>>>>> Gen 1
>>>>>> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM:
>>>>>> CFG_LINKWD_START imx6q-pcie 33800000.pcie: probe with driver
>>>>>> imx6q-pcie failed with error -110
>>>>>
>>>>> Gen 2
>>>>>> imx6q-pcie 33800000.pcie: PCIe Gen.2 x1 link up imx6q-pcie
>>>>>> 33800000.pcie: PCI host bridge to bus 0000:00
>>>>>
>>>>> next-20260227 + reverts
>>>>> Gen 1
>>>>>> imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up imx6q-pcie
>>>>>> 33800000.pcie: PCIe Gen.1 x1 link up imx6q-pcie 33800000.pcie: PCI
>>>>>> host bridge to bus 0000:00
>>>>>
>>>>> Gen 2
>>>>>> imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up imx6q-pcie
>>>>>> 33800000.pcie: PCIe Gen.2 x1 link up imx6q-pcie 33800000.pcie: PCI
>>>>>> host bridge to bus 0000:00
>>>>>
>>>>> What can we do here? I'm wondering why Gen 2 trains correctly, while
>>>>> Gen 1 doesn't.
>>>>>
>>>>
>>>> Thanks for the report and sorry for the breakage. Commit 9c03e30e3ade3,
>>>> mentions that the workaround is only needed for the i.MX6 platforms. So
>>>> I'm not sure why the patch breaks i.MX8M and that too only for Gen 1
>>>> speed.
>>>>
>>>> Also, before 9c03e30e3ade3, LTSSM was always started in Gen 1, but as per
>>>> your finding, only Gen 1 devices fail to work. So the code till
>>>> imx_pcie_wait_for_speed_change() shouldn't have an impact. Maybe the
>>>> issue is due to skipping imx_pcie_wait_for_speed_change()?
>>>>
>>>> Richard, thoughts?
>>> Hi Maini:
>>> Prior to calling imx_pcie_wait_for_speed_change(), the PCIe link must
>>> already be established. Before commit 9c03e30e3ade3, the speed change
>>> procedure was only initiated after the initial Gen1 link was successfully
>>> brought up.
>>>
>>> Hi Alexander:
>>> Sorry for the breakage.
>>> Before commit 9c03e30e3ade3, i.MX8MP PCIe forced Gen1 link training
>>> initially, then switched to Gen3 after link-up by triggering a speed
>>> change. After commit 9c03e30e3ade3, link training starts directly at
>>> the Gen3 capability level.
>>>
>>> The two link training methods differ only in the i.MX8MP Root Complex (RC)
>>> link capability configuration prior to link training: one method forces
>>> Gen1 speed, while the other retains the default Gen3 setting in your tests.
>>>
>>
>> I still don't understand why the link fails to train at Gen 1.
>
> Independently from the configured maximum link speed, shouldn't the initial
> link be Gen1 anyway and upgraded to Gen 2 later on?
>
> I added some debug output to dw_pcie_link_up()
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 3
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f704
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x28000000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f722
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM: CFG_LINKWD_START
> imx6q-pcie 33800000.pcie: probe with driver imx6q-pcie failed with error -110
>
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 2
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x28000000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x28000000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM: CFG_LINKWD_START
> imx6q-pcie 33800000.pcie: probe with driver imx6q-pcie failed with error -110
>
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 1
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08000010
> imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up
> imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
>
> So for any maximum speed above Gen1 it seems that LTSSM is stuck at link
> training.
> Unfortunately only link training and link up bits are defined and RM doesn't
> show anything, so I don't know what the other bits are indicating.
>
> For a Gen2 device the link training succeeds right away.
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 2
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08000010
> imx6q-pcie 33800000.pcie: PCIe Gen.2 x1 link up
> imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
>
> Best regards,
> Alexander
^ permalink raw reply
* Re: [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Jakub Raczynski @ 2026-04-22 8:42 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
linux-arm-kernel, linux-stm32
In-Reply-To: <7eb9e4d4-909c-4203-833d-bd8b664fdfbc@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
On Tue, Apr 21, 2026 at 02:39:15PM +0200, Andrew Lunn wrote:
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > @@ -78,7 +78,7 @@ static const struct stmmac_stats stmmac_gstrings_stats[] = {
> > STMMAC_STAT(rx_vlan),
> > STMMAC_STAT(rx_split_hdr_pkt_n),
> > /* Tx/Rx IRQ error info */
> > - STMMAC_STAT(tx_undeflow_irq),
> > + STMMAC_STAT(tx_underflow_irq),
>
> Please take another look at this one and think about it.
>
> Andrew
>
> ---
> pw-bot: cr
>
I don't see anything wrong with it?
- naming is correct, same as stmmac_extra_stats from common.h, as it
wouldn't compile otherwise
- string length is ok, as max name length is ETH_GSTRING_LEN=32 and it is
not close
- ethtool just polls data from driver and in my tests it is ok
- all instances of 'undeflow' are changed
- 'underflow' semantic is ok, 'undeflow' is just not correct
Please correct me if I am wrong, but imo no issues with this patch.
Regards
Jakub Raczynski
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: New warning in linus/master
From: Thomas Weißschuh @ 2026-04-22 8:45 UTC (permalink / raw)
To: Ricardo Ribalda; +Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <CANiDSCtfiPDiqzhjZGoCJbLC0fRoH1HLKrvYUt7jLDYEBQHqgg@mail.gmail.com>
On Wed, Apr 22, 2026 at 04:06:45PM +0800, Ricardo Ribalda wrote:
> On Wed, 22 Apr 2026 at 15:32, Thomas Weißschuh
> <thomas.weissschuh@linutronix.de> wrote:
> >
> > On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
> > > On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
> > > <thomas.weissschuh@linutronix.de> wrote:
> > > > 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
> >
> > Ack.
> >
> > > 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
> >
> > Both reproducers do *not* reproduce the issue for me.
> > (It is more or less exactly what I tried before)
>
>
> Ok, I think I found what is going on. media-ci was forcing
> KCFLAGS=-Wmaybe-uninitialized
>
> https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/test-build.sh?ref_type=heads#L29
>
> And something has changed in the kernel in the last version that
> triggers a (hopefully) false positive.
>
> can you try with:
>
> CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> KCFLAGS=-Wmaybe-uninitialized allyesconfig
> CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> KCFLAGS=-Wmaybe-uninitialized prepare
That works!
The warning was introduced in ed78b7b2c5ae ("vdso/gettimeofday: Add a helper to
read the sequence lock of a time namespace aware clock").
It is *not* a false-positive, specifically:
do {
if (vdso_read_begin_timens(vc, &seq)) {
vd = __arch_get_vdso_u_timens_data(vd);
vc = &vd->aux_clock_data[idx];
/* Re-read from the real time data page */
continue;
This 'continue' jumps to the end of the loop body and if the real vDSO datapage
by chance has a sequence counter of '1' will exit the loop, leaving 'sec' and
'nsec' uninitialized. My believe was that the 'continue' would jump to the
*beginning* of the loop body, which is cleary wrong. Previously there was an
inner while loop() which would make the 'continue' effectively start at the
beginning of the outer do-while loop.
}
/* Auxclock disabled? */
if (vc->clock_mode == VDSO_CLOCKMODE_NONE)
return false;
if (!vdso_get_timestamp(vd, vc, VDSO_BASE_AUX, &sec, &ns))
return false;
} while (vdso_read_retry(vc, seq));
vdso_set_timespec(ts, sec, ns);
I'm working on a fix.
Thomas
^ 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