* Re: [PATCH] arm64: dts: amlogic: t7: khadas-vim4: fix board model name
From: Neil Armstrong @ 2026-03-26 9:06 UTC (permalink / raw)
To: khilman, martin.blumenstingl, jbrunet, Nick Xie
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260306030756.2421841-1-nick@khadas.com>
Hi,
On Fri, 06 Mar 2026 11:07:56 +0800, Nick Xie wrote:
> Update the model property to "Khadas VIM4" to match the official
> product branding and maintain consistency with other Khadas boards
> (e.g., VIM1, VIM2, VIM3) in the kernel tree.
>
>
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/1] arm64: dts: amlogic: t7: khadas-vim4: fix board model name
https://git.kernel.org/amlogic/c/771d092af02a11ec565494052d18ddfb5e2f1428
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: amlogic: t7: khadas-vim4: fix memory layout for 8GB RAM
From: Neil Armstrong @ 2026-03-26 9:02 UTC (permalink / raw)
To: khilman, martin.blumenstingl, jbrunet, Nick Xie
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel, Ronald Claveau
In-Reply-To: <20260319023446.3422695-1-nick@khadas.com>
Hi,
On Thu, 19 Mar 2026 10:34:46 +0800, Nick Xie wrote:
> The Khadas VIM4 features 8GB of LPDDR4X RAM. The previous memory node
> mapped a single incorrect region. This caused the kernel to map MMIO
> and secure firmware (ATF/TrustZone) memory holes as standard RAM,
> leading to an Asynchronous SError Interrupt during early boot
> (paging_init) when the kernel attempted to clear those pages.
>
> Fix this by splitting the 8GB memory layout into three separate
> regions to properly avoid the memory holes (e.g., 0xe0000000 -
> 0xffffffff):
> - 3.5GB @ 0x000000000
> - 3.5GB @ 0x100000000
> - 1.0GB @ 0x200000000
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/1] arm64: dts: amlogic: t7: khadas-vim4: fix memory layout for 8GB RAM
https://git.kernel.org/amlogic/c/4b3917cd8492d72e576b837f78c0c398bda4ec27
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: (subset) [PATCH 0/4] arm64: dts: imx8mp-skov: add new 7" variant
From: Neil Armstrong @ 2026-03-26 9:02 UTC (permalink / raw)
To: Jessica Zhang, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Steffen Trumtrar
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-0-10255d236439@pengutronix.de>
Hi,
On Wed, 25 Mar 2026 12:31:58 +0100, Steffen Trumtrar wrote:
> Add a new board variant for the Skov i.MX8MP based family of boards.
>
> This variant uses a different 7" panel than the existing ones.
>
>
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[1/4] dt-bindings: display: simple: Add JuTouch JT070TM041 panel
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/87535f27061f3443e813a64f59fb1b0fcb916e08
[2/4] drm/panel: simple: add JuTouch JT070TM041
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/7a5b966952c0232d7083a496261880fc11cc8c4a
--
Neil
^ permalink raw reply
* Re: (subset) [PATCH 0/7] arm64: dts: Drop CPU masks from GICv3 PPI interrupts
From: Neil Armstrong @ 2026-03-26 8:58 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Peter Griffin,
André Draszik, Tudor Ambarus, Alim Akhtar, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Bjorn Andersson, Konrad Dybcio, Thierry Reding, Marc Zyngier,
Geert Uytterhoeven
Cc: linux-arm-kernel, linux-amlogic, linux-samsung-soc, imx,
linux-arm-msm, linux-renesas-soc, linux-kernel
In-Reply-To: <cover.1772643434.git.geert+renesas@glider.be>
Hi,
On Wed, 04 Mar 2026 18:10:57 +0100, Geert Uytterhoeven wrote:
> Hi all,
>
> Unlike older GIC variants, the GICv3 DT bindings do not support
> specifying a CPU mask in PPI interrupt specifiers. Hence this patch
> series drop all such masks where they are still present.
>
> This has been compile-tested only. But note that all such masks were
> removed before from Renesas SoCs in commit 8b6a006c914aac17 ("arm64:
> dts: renesas: Drop specifying the GIC_CPU_MASK_SIMPLE() for GICv3
> systems")).
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/7] arm64: dts: amlogic: s6: Drop CPU masks from GICv3 PPI interrupts
https://git.kernel.org/amlogic/c/ff6c02a40dc8706c0b13b3b12cfe228c38bb7857
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH v2 09/12] arm64: dts: imx8mp-sr-som: Correct PAD settings for PMIC_nINT
From: Laurent Pinchart @ 2026-03-26 8:58 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Daniel Scally, Marco Felsch, Gilles Talis, Viorel Suman,
Shengjiu Wang, Jagan Teki, Manoj Sai, Matteo Lisi, Ray Chang,
Richard Hu, Heiko Schocher, Martyn Welch, Josua Mayer,
Goran Rađenović, Börge Strümpfel,
Christoph Niedermaier, Marek Vasut, devicetree, imx,
linux-arm-kernel, linux-kernel, kernel, Peng Fan
In-Reply-To: <20260326-imx8mp-dts-fix-v2-v2-9-62c4ce727448@nxp.com>
On Thu, Mar 26, 2026 at 03:28:13PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
> there might be interrupt storm for this board. Need to set PAD PUE and PU
> together to make pull up work properly.
>
> Fixes: a009c0c66ecb4 ("arm64: dts: add description for solidrun imx8mp som and cubox-m")
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
> index 3cdb0bc0ab721709fc892931ea00a538ec6216ff..c3f7daa773eaf335deb6cc976a5e120abdae5967 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
> @@ -174,7 +174,7 @@ pmic: pmic@25 {
> pinctrl-0 = <&pmic_pins>;
> pinctrl-names = "default";
> interrupt-parent = <&gpio1>;
> - interrupts = <3 GPIO_ACTIVE_LOW>;
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
This is a good change, but it should be mentioned in the commit message,
or split to a separate patch. Same for other patches in this series
where you make the same change.
> nxp,i2c-lt-enable;
>
> regulators {
> @@ -417,7 +417,7 @@ MX8MP_IOMUXC_SAI1_RXD1__GPIO4_IO03 0x160
>
> pmic_pins: pinctrl-pmic-grp {
> fsl,pins = <
> - MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
> + MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
> >;
> };
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-03-26 8:57 UTC (permalink / raw)
To: Aaro Koskinen, Janusz Krzysztofik
Cc: Arnd Bergmann, Bartosz Golaszewski, Tony Lindgren, Russell King,
Dmitry Torokhov, Hans de Goede, Linux-OMAP, linux-arm-kernel,
linux-kernel, Kevin Hilman
In-Reply-To: <CAMRc=McosSU39SERKtjmhJdTv2cPi44PG=bYqAcfQLDX4QB0Tg@mail.gmail.com>
On Mon, Mar 16, 2026 at 9:50 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Fri, Mar 6, 2026 at 1:31 AM Kevin Hilman <khilman@kernel.org> wrote:
> >
> > Bartosz Golaszewski <brgl@kernel.org> writes:
> >
> > > On Thu, Feb 12, 2026 at 12:46 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > >>
> > >> On Thu, Feb 12, 2026, at 12:25, Bartosz Golaszewski wrote:
> > >> > Currently the board file for Nokia 770 creates dummy software nodes not
> > >> > attached in any way to the actual GPIO controller devices and uses the
> > >> > fact that GPIOLIB matching swnode's name to the GPIO chip's label during
> > >> > software node lookup. This behavior is wrong and we want to remove it.
> > >> > To that end, we need to first convert all existing users to creating
> > >> > actual fwnode links.
> > >> >
> > >> > Create real software nodes for GPIO controllers on OMAP16xx and
> > >> > reference them from the software nodes in the nokia board file.
> > >> >
> > >> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > >>
> > >> Acked-by: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Aaro, Janusz: Can you please pick it up for v7.1?
> >
> > I can take this via the OMAP tree once I have confirmation from
> > Aaro/Janusz that they've tested.
> >
> > Kevin
>
> Gentle ping.
>
> Bart
Hi again! Any chance we could get this queued? Janusz, Aaro: any objections?
Bart
^ permalink raw reply
* Re: [PATCH v2 0/4] arm64: Add BRBE support for bpf_get_branch_snapshot()
From: Puranjay Mohan @ 2026-03-26 8:57 UTC (permalink / raw)
To: bpf, Mark Rutland, Catalin Marinas, Will Deacon
Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Leo Yan, Rob Herring, Breno Leitao, linux-arm-kernel,
linux-perf-users, kernel-team
In-Reply-To: <20260318171706.2840512-1-puranjay@kernel.org>
Hi Catalin, Mark, and Will,
Would you mind taking a look at this patchset when you have a chance?
Thanks,
Puranjay
On Wed, Mar 18, 2026 at 5:17 PM Puranjay Mohan <puranjay@kernel.org> wrote:
>
> v1: https://lore.kernel.org/all/20260313180352.3800358-1-puranjay@kernel.org/
> Changes in v2:
> - Rebased on arm64/for-next/core
> - Add per-CPU brbe_active flag to guard against UNDEFINED sysreg access
> on non-BRBE CPUs in heterogeneous big.LITTLE systems.
> - Fix pre-existing bug in perf_clear_branch_entry_bitfields() that missed
> zeroing new_type and priv bitfields, added as a separate patch with
> Fixes tags (new patch 2).
> - Use architecture-specific selftest threshold (#if defined(__aarch64__))
> instead of raising the global threshold, to preserve x86 regression
> detection.
>
> RFC: https://lore.kernel.org/all/20260102214043.1410242-1-puranjay@kernel.org/
> Changes from RFC:
> - Fix pre-existing NULL pointer dereference in armv8pmu_sched_task()
> found by Leo Yan during testing (patch 1)
> - Pause BRBE before local_daif_save() to avoid branch pollution from
> trace_hardirqs_off()
> - Use local_daif_save() to prevent pNMI race from counter overflow
> (Mark Rutland)
> - Reuse perf_entry_from_brbe_regset() instead of duplicating register
> read logic, by making it accept NULL event (Mark Rutland)
> - Invalidate BRBE after reading to maintain record contiguity for
> other consumers (Mark Rutland)
> - Adjust selftest wasted_entries threshold for ARM64 (patch 3)
> - Tested on ARM FVP with BRBE enabled
>
> This series enables the bpf_get_branch_snapshot() BPF helper on ARM64
> by implementing the perf_snapshot_branch_stack static call for ARM's
> Branch Record Buffer Extension (BRBE).
>
> bpf_get_branch_snapshot() [1] allows BPF programs to capture hardware
> branch records on-demand from any BPF tracing context. This was
> previously only available on x86 (Intel LBR) since v5.16. With BRBE
> available on ARMv9, this series closes the gap for ARM64.
>
> Usage model
> -----------
>
> The helper works in conjunction with perf events. The userspace
> component of the BPF application opens a perf event with
> PERF_SAMPLE_BRANCH_STACK on each CPU, which configures the hardware
> to continuously record branches into BRBE (on ARM64) or LBR (on x86).
> A BPF program attached to a tracepoint, kprobe, or fentry hook can
> then call bpf_get_branch_snapshot() to snapshot the branch buffer at
> any point. Without an active perf event, BRBE is not recording and
> the buffer is empty.
>
> On-demand branch snapshots from BPF are useful for diagnosing which
> specific code path was taken inside a function. Stack traces only show
> function boundaries, but branch records reveal the exact sequence of
> jumps, calls, and returns within a function -- making it possible to
> identify which specific error check triggered a failure, or which
> callback implementation was invoked through a function pointer.
>
> For example, retsnoop [2] is a BPF-based tool for non-intrusive
> mass-tracing of kernel internals. Its LBR mode (--lbr) creates per-CPU
> perf events with PERF_SAMPLE_BRANCH_STACK and then uses
> bpf_get_branch_snapshot() in its fentry/fexit BPF programs to capture
> branch records whenever a traced function returns an error.
>
> Consider debugging a bpf() syscall that returns -EINVAL when creating
> a BPF map with invalid parameters. Running retsnoop on an ARM64 FVP
> with BRBE to trace the bpf() syscall and array_map_alloc_check():
>
> $ retsnoop -e '*sys_bpf' -a 'array_map_alloc_check' --lbr=any \
> -F -k vmlinux --debug full-lbr
> $ simfail bpf-bad-map-max-entries-array # in another terminal
>
> Output of retsnoop:
>
> --- fentry BPF program (entries #63-#17) ---
>
> [#63-#59] __htab_map_lookup_elem: hash table walk with memcmp (hashtab.c)
> [#58] __htab_map_lookup_elem+0x98 -> dump_bpf_prog+0xc850 (hashtab.c:750)
> [#57-#55] ... dump_bpf_prog internal branches ...
> [#54] dump_bpf_prog+0xcab8 -> bpf_get_current_pid_tgid+0x0 (helpers.c:225)
> [#53] bpf_get_current_pid_tgid+0x1c -> dump_bpf_prog+0xcabc (helpers.c:225)
> [#52-#51] ... dump_bpf_prog -> __htab_map_lookup_elem ...
> [#50-#47] __htab_map_lookup_elem: htab_map_hash (jhash2), select_bucket
> [#46-#42] lookup_nulls_elem_raw: hash chain walk with memcmp (hashtab.c:717)
> [#41] __htab_map_lookup_elem+0x98 -> dump_bpf_prog+0xcaf8 (hashtab.c:750)
> [#40-#37] ... dump_bpf_prog -> bpf_ktime_get_ns ...
> [#36] bpf_ktime_get_ns+0x10 -> ktime_get_mono_fast_ns+0x0 (helpers.c:178)
> [#35-#32] ktime_get_mono_fast_ns: tk_clock_read -> arch_counter_get_cntpct
> [#31] ktime_get_mono_fast_ns+0x9c -> bpf_ktime_get_ns+0x14 (timekeeping.c:493)
> [#30] bpf_ktime_get_ns+0x18 -> dump_bpf_prog+0xcd50 (helpers.c:178)
> [#29-#25] ... dump_bpf_prog internal branches ...
> [#24] dump_bpf_prog+0x11b28 -> __bpf_prog_exit_recur+0x0 (trampoline.c:1190)
> [#23-#17] __bpf_prog_exit_recur: rcu_read_unlock, migrate_enable (trampoline.c:1195)
>
> --- array_map_alloc_check (entries #16-#12) ---
>
> [#16] dump_bpf_prog+0x11b38 -> array_map_alloc_check+0x8 (arraymap.c:55)
> [#15] array_map_alloc_check+0x18 -> array_map_alloc_check+0xb8 (arraymap.c:56)
> . bpf_map_attr_numa_node . bpf_map_attr_numa_node
> [#14] array_map_alloc_check+0xbc -> array_map_alloc_check+0x20 (arraymap.c:59)
> . bpf_map_attr_numa_node
> [#13] array_map_alloc_check+0x24 -> array_map_alloc_check+0x94 (arraymap.c:64)
> [#12] array_map_alloc_check+0x98 -> dump_bpf_prog+0x11b3c (arraymap.c:82)
>
> --- fexit trampoline overhead (entries #11-#00) ---
>
> [#11] dump_bpf_prog+0x11b5c -> __bpf_prog_enter_recur+0x0 (trampoline.c:1145)
> [#10-#03] __bpf_prog_enter_recur: rcu_read_lock, migrate_disable (trampoline.c:1146)
> [#02] __bpf_prog_enter_recur+0x114 -> dump_bpf_prog+0x11b60 (trampoline.c:1157)
> [#01] dump_bpf_prog+0x11b6c -> dump_bpf_prog+0xd230
> [#00] dump_bpf_prog+0xd340 -> arm_brbe_snapshot_branch_stack+0x0 (arm_brbe.c:814)
>
> el0t_64_sync+0x168
> el0t_64_sync_handler+0x98
> el0_svc+0x28
> do_el0_svc+0x4c
> invoke_syscall.constprop.0+0x54
> 373us [-EINVAL] __arm64_sys_bpf+0x8
> __sys_bpf+0x87c
> map_create+0x120
> 95us [-EINVAL] array_map_alloc_check+0x8
>
> The FVP's BRBE buffer has 64 entries (BRBE supports 8, 16, 32, or
> 64). Of these, entries #63-#17 (47) are consumed by the fentry BPF
> trampoline that ran before the function, and entries #11-#00 (12)
> are consumed by the fexit trampoline that runs after. Entry #00
> shows the very last branch recorded before BRBE is paused: the call
> into arm_brbe_snapshot_branch_stack().
>
> The 5 useful entries (#16-#12) show the exact path taken inside
> array_map_alloc_check(). Record #14 shows a jump from line 56
> (bpf_map_attr_numa_node) to line 59 (the if-condition), and #13
> shows an immediate jump from line 59 (attr->max_entries == 0) to
> line 64 (return -EINVAL), skipping lines 60-63. This pinpoints
> max_entries==0 as the cause -- a diagnosis impossible with stack
> traces alone.
>
> [1] 856c02dbce4f ("bpf: Introduce helper bpf_get_branch_snapshot")
> [2] https://github.com/anakryiko/retsnoop
>
> Puranjay Mohan (4):
> perf/arm_pmuv3: Fix NULL pointer dereference in armv8pmu_sched_task()
> perf: Fix uninitialized bitfields in
> perf_clear_branch_entry_bitfields()
> perf/arm64: Add BRBE support for bpf_get_branch_snapshot()
> selftests/bpf: Adjust wasted entries threshold for ARM64 BRBE
>
> drivers/perf/arm_brbe.c | 79 ++++++++++++++++++-
> drivers/perf/arm_brbe.h | 9 +++
> drivers/perf/arm_pmuv3.c | 16 +++-
> include/linux/perf_event.h | 2 +
> .../bpf/prog_tests/get_branch_snapshot.c | 13 ++-
> 5 files changed, 110 insertions(+), 9 deletions(-)
>
>
> base-commit: d118f32246fdabfb4f6a3fd2e511dc5e622bc553
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64/entry: Fix involuntary preemption exception masking
From: Jinjie Ruan @ 2026-03-26 8:56 UTC (permalink / raw)
To: Thomas Gleixner, Mark Rutland
Cc: vladimir.murzin, peterz, catalin.marinas, linux-kernel, luto,
will, linux-arm-kernel
In-Reply-To: <87ecl7gbeu.ffs@tglx>
On 2026/3/25 23:46, Thomas Gleixner wrote:
> On Wed, Mar 25 2026 at 11:03, Mark Rutland wrote:
>> On Sun, Mar 22, 2026 at 12:25:06AM +0100, Thomas Gleixner wrote:
>>> The current sequence on entry is:
>>>
>>> // interrupts are disabled by interrupt/exception entry
>>> enter_from_kernel_mode()
>>> irqentry_enter(regs);
>>> mte_check_tfsr_entry();
>>> mte_disable_tco_entry();
>>> daif_inherit(regs);
>>> // interrupts are still disabled
>>
>> That last comment isn't quite right: we CAN and WILL enable interrupts
>> in local_daif_inherit(), if and only if they were enabled in the context
>> the exception was taken from.
>
> Ok.
>
>> As mentioned above, when handling an interrupt (rather than a
>> synchronous exception), we don't use local_daif_inherit(), and instead
>> use a different DAIF function to unmask everything except interrupts.
>>
>>> which then becomes:
>>>
>>> // interrupts are disabled by interrupt/exception entry
>>> irqentry_enter(regs)
>>> establish_state();
>>> // RCU is watching
>>> arch_irqentry_enter_rcu()
>>> mte_check_tfsr_entry();
>>> mte_disable_tco_entry();
>>> daif_inherit(regs);
>>> // interrupts are still disabled
>>>
>>> Which is equivalent versus the MTE/DAIF requirements, no?
>>
>> As above, we can't use local_daif_inherit() here because we want
>> different DAIF masking behavior for entry to interrupts and entry to
>> synchronous exceptions. While we could pass some token around to
>> determine the behaviour dynamically, that's less clear, more
>> complicated, and results in worse code being generated for something we
>> know at compile time.
>
> I get it. Duh what a maze.
>
>> If we can leave DAIF masked early on during irqentry_enter(), I don't
>> see why we can't leave all DAIF exceptions masked until the end of
>> irqentry_enter().
>
> Yes. Entry is not an issue.
>
>> I *think* what would work for us is we could split some of the exit
>> handling (including involuntary preemption) into a "prepare" step, as we
>> have for return to userspace. That way, arm64 could handle exiting
>> something like:
>>
>> local_irq_disable();
>> irqentry_exit_prepare(); // new, all generic logic
>> local_daif_mask();
>> arm64_exit_to_kernel_mode() {
>> ...
>> irqentry_exit(); // ideally irqentry_exit_to_kernel_mode().
>> ...
>> }
>>
>> ... and other architectures can use a combined exit_to_kernel_mode() (or
>> whatever we call that), which does both, e.g.
>>
>> // either noinstr, __always_inline, or a macro
>> void irqentry_prepare_and_exit(void)
>
> That's a bad idea as that would require to do a full kernel rename of
> all existing irqentry_exit() users.
I see your point about the rename. However, we can avoid a tree-wide
rename by keeping the irqentry_exit() name and interface exactly as it is.
The idea is to perform an internal refactoring: split the existing logic
into two helpers (e.g., irqentry_exit_prepare() and a core helper), and
then have the original irqentry_exit() call both of them. This way,
existing users like RISC-V remain untouched, while arm64 can choose to
call the two sub-functions individually to insert the DAIF masking in
between."
>
>> {
>> irqentry_exit_prepare();
>> irqentry_exit();
>> }
>
> Aside of the naming that should work.
>
> Thanks,
>
> tglx
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH v2 08/13] firmware: arm_scmi: Harden clock protocol initialization
From: Alexander Stein @ 2026-03-26 8:55 UTC (permalink / raw)
To: Marek Szyprowski, Cristian Marussi
Cc: Cristian Marussi, linux-kernel, linux-arm-kernel, arm-scmi,
linux-clk, linux-renesas-soc, sudeep.holla, philip.radford,
james.quinlan, f.fainelli, vincent.guittot, etienne.carriere,
peng.fan, michal.simek, dan.carpenter, geert+renesas,
kuninori.morimoto.gx, marek.vasut+renesas
In-Reply-To: <acPUxJ3N0QptmtlJ@pluto>
Hi,
Am Mittwoch, 25. März 2026, 13:27:48 CET schrieb Cristian Marussi:
> On Wed, Mar 25, 2026 at 12:02:41PM +0100, Marek Szyprowski wrote:
> > On 10.03.2026 19:40, Cristian Marussi wrote:
> > > Add proper error handling on failure to enumerate clocks features or
> > > rates.
> > >
> > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> >
>
> Hi Marek,
>
> > This patch landed yesterday in linux-next as commit 0d8b0c8068a8
> > ("firmware: arm_scmi: Harden clock protocol initialization"). In my
> > tests I found that it causes a regression on RK3568 Odroid-M1 board
> > (arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts), cpufreq and GPU
> > device are not probed properly:
> >
> > # dmesg | grep scmi
> > scmi_core: SCMI protocol bus registered
> > arm-scmi arm-scmi.0.auto: Using scmi_smc_transport
> > arm-scmi arm-scmi.0.auto: SCMI max-rx-timeout: 30ms / max-msg-size:
> > 104bytes / max-msg: 20
> > scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
> > arm-scmi arm-scmi.0.auto: SCMI Notifications - Core Enabled.
> > arm-scmi arm-scmi.0.auto: Malformed reply - real_sz:8 calc_sz:4
> > (loop_num_ret:1)
> > arm-scmi arm-scmi.0.auto: SCMI Protocol v2.0 'rockchip:' Firmware
> > version 0x0
> > arm-scmi arm-scmi.0.auto: Enabling SCMI Quirk
> > [quirk_clock_rates_triplet_out_of_spec]
> > scmi-clocks scmi_dev.3: probe with driver scmi-clocks failed with error -22
> >
>
> Yes there are multiple reports of issues on this hardening, the series
> is on hold and wont go into v7.1 as of now...it needs some basic fixes
> and various quirks probably to address non-compliant firmwares...
>
> It will be pushed to next again with a few more fixes in the coming
> days and then we'll need to figure out how many quirks will be needed on
> top of that and if it is acceptable at all...
Just for the records: imx95 (maybe imx94 as well) is also affected by this.
My board doesn't boot at all, because all the clocks are provided by SCMI.
With this diff I can see it's the 'ext' clock
-->8---
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -1253,8 +1253,11 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
for (clkid = 0; clkid < cinfo->num_clocks; clkid++) {
cinfo->clkds[clkid].id = clkid;
ret = scmi_clock_attributes_get(ph, clkid, cinfo);
- if (ret)
+ if (ret) {
+ dev_warn(ph->dev, "scmi_clock_attributes_get failed for '%s': %d\n",
+ cinfo->clkds->info.name, ret);
return ret;
+ }
ret = scmi_clock_describe_rates_get(ph, clkid, cinfo);
if (ret)
-->8---
> arm-scmi arm-scmi.0.auto: scmi_clock_attributes_get failed for 'ext': -2
> scmi-clocks scmi_dev.6: probe with driver scmi-clocks failed with error -2
What's the idea of how to proceeed as apparently several platforms are
affected?
Best regards,
Alexander
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH v4 9/9] arm64: dts: amlogic: t7: khadas-vim4: Add MMC nodes
From: Neil Armstrong @ 2026-03-26 8:54 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-9-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Enable and configure the three MMC controllers for the Khadas VIM4 board:
> - sd_emmc_a: SDIO interface for the BCM43752 Wi-Fi module
> - sd_emmc_b: SD card slot
> - sd_emmc_c: eMMC storage
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 90 +++++++++++++++++++++-
> 1 file changed, 89 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index 770f06b0b16c7..5a73ae081036c 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -14,7 +14,10 @@ / {
> compatible = "khadas,vim4", "amlogic,a311d2", "amlogic,t7";
>
> aliases {
> - serial0 = &uart_a;
> + serial0 = &uart_a;
Spurious change
> + mmc0 = &sd_emmc_c;
> + mmc1 = &sd_emmc_b;
> + mmc2 = &sd_emmc_a;
> };
>
> memory@0 {
> @@ -159,6 +162,91 @@ &pwm_ab {
> pinctrl-names = "default";
> };
>
> +/* SDIO */
> +&sd_emmc_a {
> + status = "okay";
> + pinctrl-0 = <&sdio_pins>;
> + pinctrl-1 = <&sdio_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + cap-sdio-irq;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> + no-mmc;
> + no-sd;
> +
> + power-domains = <&pwrc PWRC_T7_SDIO_A_ID>;
> +
> + keep-power-in-suspend;
> +
> + mmc-pwrseq = <&sdio_pwrseq>;
> +
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddao_1v8>;
> +
> + brcmf: wifi@1 {
> + reg = <1>;
> + compatible = "brcm,bcm43752-fmac", "brcm,bcm4329-fmac";
> + };
> +};
> +
> +/* SD card */
> +&sd_emmc_b {
> + status = "okay";
> + pinctrl-0 = <&sdcard_pins>;
> + pinctrl-1 = <&sdcard_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + max-frequency = <200000000>;
> + disable-wp;
> + no-sdio;
> + no-mmc;
> +
> + power-domains = <&pwrc PWRC_T7_SDIO_B_ID>;
> +
> + cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
> + vmmc-supply = <&sd_3v3>;
> + vqmmc-supply = <&vddio_c>;
> +};
> +
> +/* eMMC */
> +&sd_emmc_c {
> + status = "okay";
> + pinctrl-0 = <&emmc_ctrl_pins>, <&emmc_data_8b_pins>, <&emmc_ds_pins>;
> + pinctrl-1 = <&emmc_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> +
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + max-frequency = <200000000>;
> + disable-wp;
> + non-removable;
> + no-sdio;
> + no-sd;
> +
> + power-domains = <&pwrc PWRC_T7_EMMC_ID>;
> +
> + vmmc-supply = <&vddio_3v3>;
> + vqmmc-supply = <&vddio_1v8>;
> +};
> +
> &uart_a {
> status = "okay";
> clocks = <&xtal>, <&xtal>, <&xtal>;
>
With that:
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 7/9] arm64: dts: amlogic: t7: khadas-vim4: Add SDIO power sequence and WiFi clock
From: Neil Armstrong @ 2026-03-26 8:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-7-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add the SDIO power sequence node using mmc-pwrseq-simple and a
> 32.768kHz PWM-based clock required by the Wi-Fi module.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index 2450084d37642..770f06b0b16c7 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -67,6 +67,15 @@ sd_3v3: regulator-sdcard-3v3 {
> regulator-always-on;
> };
>
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
> + post-power-on-delay-ms = <500>;
> + power-off-delay-us = <200000>;
> + clocks = <&wifi32k>;
> + clock-names = "ext_clock";
> + };
> +
> vcc5v: regulator-vcc-5v {
> compatible = "regulator-fixed";
> regulator-name = "VCC5V";
> @@ -135,6 +144,19 @@ vddio_c: regulator-gpio-c {
> states = <1800000 1
> 3300000 0>;
> };
> +
> + wifi32k: wifi32k {
> + compatible = "pwm-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + pwms = <&pwm_ab 0 30518 0>;
> + };
> +};
> +
> +&pwm_ab {
> + status = "okay";
> + pinctrl-0 = <&pwm_a_pins>;
> + pinctrl-names = "default";
> };
>
> &uart_a {
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
From: Neil Armstrong @ 2026-03-26 8:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-6-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add voltage regulator nodes describing the VIM4 power tree,
> required by peripheral nodes such as the SD card controller.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 90 ++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index fffdab96b12eb..2450084d37642 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -6,6 +6,8 @@
> /dts-v1/;
>
> #include "amlogic-t7.dtsi"
> +#include <dt-bindings/gpio/amlogic,t7-periphs-pinctrl.h>
> +#include <dt-bindings/gpio/gpio.h>
>
> / {
> model = "Khadas vim4";
> @@ -45,6 +47,94 @@ xtal: xtal-clk {
> #clock-cells = <0>;
> };
>
> + dc_in: regulator-dc-in {
> + compatible = "regulator-fixed";
> + regulator-name = "DC_IN";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +
> + sd_3v3: regulator-sdcard-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "SD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddao_3v3>;
> + gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
> + regulator-boot-on;
> + enable-active-low;
> + regulator-always-on;
> + };
> +
> + vcc5v: regulator-vcc-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC5V";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&dc_in>;
> +
> + gpio = <&gpio GPIOH_4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + vcc5v0_usb: regulator-vcc-usb {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC5V0_USB";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vcc5v>;
> +
> + gpio = <&gpio GPIOY_5 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + vddao_1v8: regulator-vddao-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vddao_3v3>;
> + regulator-always-on;
> + };
> +
> + vddao_3v3: regulator-vddao-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&dc_in>;
> + regulator-always-on;
> + };
> +
> + vddio_1v8: regulator-vddio-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vddio_3v3>;
> + regulator-always-on;
> + };
> +
> + vddio_3v3: regulator-vddio-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddao_3v3>;
> + regulator-always-on;
> + };
> +
> + vddio_c: regulator-gpio-c {
> + compatible = "regulator-gpio";
> + regulator-name = "VDDIO_C";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddio_3v3>;
> + gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
> + states = <1800000 1
> + 3300000 0>;
> + };
> };
>
> &uart_a {
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 5/9] arm64: dts: amlogic: t7: Add PWM controller nodes
From: Neil Armstrong @ 2026-03-26 8:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Nick Xie
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-5-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add device tree nodes for the seven PWM controllers available
> on the Amlogic T7 SoC, using amlogic,meson-s4-pwm as fallback compatible.
> All nodes are disabled by default and should be
> enabled in the board-specific DTS file.
>
> Co-developed-by: Nick Xie <nick@khadas.com>
> Signed-off-by: Nick Xie <nick@khadas.com>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 63 +++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index eb09a26bcd0e0..581cdaebfe637 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -511,6 +511,69 @@ sec_ao: ao-secure@10220 {
> amlogic,has-chip-id;
> };
>
> + pwm_ao_ef: pwm@30000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x30000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_E>,
> + <&clkc_periphs CLKID_PWM_AO_F>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ao_gh: pwm@32000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x32000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_G>,
> + <&clkc_periphs CLKID_PWM_AO_H>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ab: pwm@58000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x58000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_A>,
> + <&clkc_periphs CLKID_PWM_B>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_cd: pwm@5a000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x5a000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_C>,
> + <&clkc_periphs CLKID_PWM_D>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ef: pwm@5c000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x5c000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_E>,
> + <&clkc_periphs CLKID_PWM_F>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ao_ab: pwm@5e000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x5e000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_A>,
> + <&clkc_periphs CLKID_PWM_AO_B>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ao_cd: pwm@60000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x60000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_C>,
> + <&clkc_periphs CLKID_PWM_AO_D>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> sd_emmc_a: mmc@88000 {
> compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> reg = <0x0 0x88000 0x0 0x800>;
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 4/9] arm64: dts: amlogic: t7: Add PWM pinctrl nodes
From: Neil Armstrong @ 2026-03-26 8:52 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-4-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> These pinctrl nodes are required by the PWM drivers to configure
> pin muxing at runtime.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 136 ++++++++++++++++++++++++++++
> 1 file changed, 136 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 62c87d0ef7065..eb09a26bcd0e0 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -307,6 +307,142 @@ mux {
> };
> };
>
> + pwm_a_pins: pwm-a {
> + mux {
> + groups = "pwm_a";
> + function = "pwm_a";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_a_pins: pwm-ao-a {
> + mux {
> + groups = "pwm_ao_a";
> + function = "pwm_ao_a";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_b_pins: pwm-ao-b {
> + mux {
> + groups = "pwm_ao_b";
> + function = "pwm_ao_b";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_c_pins: pwm-ao-c {
> + mux {
> + groups = "pwm_ao_c";
> + function = "pwm_ao_c";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_c_hiz_pins: pwm-ao-c-hiz {
> + mux {
> + groups = "pwm_ao_c_hiz";
> + function = "pwm_ao_c_hiz";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_d_pins: pwm-ao-d {
> + mux {
> + groups = "pwm_ao_d";
> + function = "pwm_ao_d";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_e_pins: pwm-ao-e {
> + mux {
> + groups = "pwm_ao_e";
> + function = "pwm_ao_e";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_f_pins: pwm-ao-f {
> + mux {
> + groups = "pwm_ao_f";
> + function = "pwm_ao_f";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_g_pins: pwm-ao-g {
> + mux {
> + groups = "pwm_ao_g";
> + function = "pwm_ao_g";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_g_hiz_pins: pwm-ao-g-hiz {
> + mux {
> + groups = "pwm_ao_g_hiz";
> + function = "pwm_ao_g_hiz";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_h_pins: pwm-ao-h {
> + mux {
> + groups = "pwm_ao_h";
> + function = "pwm_ao_h";
> + bias-disable;
> + };
> + };
> +
> + pwm_b_pins: pwm-b {
> + mux {
> + groups = "pwm_b";
> + function = "pwm_b";
> + bias-disable;
> + };
> + };
> +
> + pwm_c_pins: pwm-c {
> + mux {
> + groups = "pwm_c";
> + function = "pwm_c";
> + bias-disable;
> + };
> + };
> +
> + pwm_d_pins: pwm-d {
> + mux {
> + groups = "pwm_d";
> + function = "pwm_d";
> + bias-disable;
> + };
> + };
> +
> + pwm_e_pins: pwm-e {
> + mux {
> + groups = "pwm_e";
> + function = "pwm_e";
> + bias-disable;
> + };
> + };
> +
> + pwm_f_pins: pwm-f {
> + mux {
> + groups = "pwm_f";
> + function = "pwm_f";
> + bias-disable;
> + };
> + };
> +
> + pwm_vs_pins: pwm-vs {
> + mux {
> + groups = "pwm_vs";
> + function = "pwm_vs";
> + bias-disable;
> + };
> + };
> +
> sdcard_pins: sdcard {
> mux {
> groups = "sdcard_d0",
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 3/9] arm64: dts: amlogic: t7: Add MMC controller nodes
From: Neil Armstrong @ 2026-03-26 8:52 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-3-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add device tree nodes for the three MMC controllers available
> on the Amlogic T7 SoC, using amlogic,meson-axg-mmc as fallback compatible.
> All nodes are disabled by default and should be
> enabled in the board-specific DTS file.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 39 +++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 016b5429c8d1b..62c87d0ef7065 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -374,6 +374,45 @@ sec_ao: ao-secure@10220 {
> reg = <0x0 0x10220 0x0 0x140>;
> amlogic,has-chip-id;
> };
> +
> + sd_emmc_a: mmc@88000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x88000 0x0 0x800>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
move disabled at the end of the properties
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_A>,
> + <&clkc_periphs CLKID_SD_EMMC_A>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_A_SEL>;
> + assigned-clock-parents = <&xtal>;
> + };
> +
> + sd_emmc_b: mmc@8a000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x8a000 0x0 0x800>;
> + interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
Ditto
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_B>,
> + <&clkc_periphs CLKID_SD_EMMC_B>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_B_SEL>;
> + assigned-clock-parents = <&xtal>;
> + };
> +
> + sd_emmc_c: mmc@8c000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x8c000 0x0 0x800>;
> + interrupts = <GIC_SPI 178 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
Ditto
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_C>,
> + <&clkc_periphs CLKID_SD_EMMC_C>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_C_SEL>;
> + assigned-clock-parents = <&xtal>;
> + };
> };
>
> };
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64/entry: Fix involuntary preemption exception masking
From: Jinjie Ruan @ 2026-03-26 8:52 UTC (permalink / raw)
To: Mark Rutland, Thomas Gleixner
Cc: vladimir.murzin, peterz, catalin.marinas, linux-kernel, luto,
will, linux-arm-kernel
In-Reply-To: <acPAzdtjK5w-rNqC@J2N7QTR9R3>
On 2026/3/25 19:03, Mark Rutland wrote:
> On Sun, Mar 22, 2026 at 12:25:06AM +0100, Thomas Gleixner wrote:
>> On Fri, Mar 20 2026 at 17:31, Mark Rutland wrote:
>>> On Fri, Mar 20, 2026 at 05:26:47PM +0100, Thomas Gleixner wrote:
>>> I *think* you're saying that because the arch code would manage DAIF
>>> early during entry and late during exit, that would all be in one place.
>>
>> That was my thought, see below.
>>
>>> However, that doubles the number of times we have to write to DAIF: at
>>> entry we'd have to poke it once to unmask everything except IRQs, then
>>> again to unmask IRQs, and exit would need the inverse. We'd also have to
>>> split the inheritance logic into inherit-everything-but-interrupt and
>>> inherit-only-interrupt, which is doable but not ideal. With pseudo-NMI
>>> it's even worse, but that's largely because pseudo-NMI is
>>> over-complicated today.
>>
>> Interrupts are not unmasked on interrupt/exception entry ever and I
>> don't understand your concerns at all, but as always I might be missing
>> something.
>
> I think one problem is that we're using the same words to describe
> distinct things, because the terminology is overloaded; I've tried to
> clarify some of that below.
>
> I think another is that there are a large number of interacting
> constraints, and it's easily possible to find something that for most
> but not all of those. I *think* there's an approach that satisfies all
> of our requirements; see below where I say "I *think* what would work
> for us ...".
>
> For context, when I said "at entry" and "at exit" I was including
> *everything* we have to do before/after the "real" logic to handle an
> exception, including parts that surround the generic entry code. I'm
> happy to use a different term for those periods, but I can't immediately
> think of something better.
>
> For example, for faults handled by arm64's el1_abort(), I was
> characterising this as:
>
> /* -------- "entry" begins here -------- */
>
> [[ entry asm ]]
> [[ early triage, branch to el1_abort() ]]
>
> static void noinstr el1_abort(struct pt_regs *regs, unsigned long esr)
> {
> unsigned long far = read_sysreg(far_el1);
> irqentry_state_t state;
>
> state = enter_from_kernel_mode(regs) {
> ...
> irqentry_enter(regs);
> ...
> }
> local_daif_inherit(regs); // <----------- might unmask interrupts
> /* -------- "entry" ends here ---------- */
>
>
> /* -------- "real logic" begins here --- */
> do_mem_abort(far, esr, regs);
> /* -------- "real logic" ends here ----- */
>
>
> /* -------- "exit" begins here --------- */
> local_daif_mask(); // <------------------------- masks interrupts
> exit_to_kernel_mode(regs, state) {
> ...
> irqentry_exit(regs);
> ...
> }
> }
>
> [[ return from el1_abort() ]]
> [[ exit asm ]]
>
> /* -------- "exit" ends here ----------- */
>
> Please note, el1_abort() is indicative of what arm64 does for
> (most) synchronous exceptions, but there are slight differences for
> other exceptions. For anything maskable (including interupts) we DO NOT
> use local_daif_inherit() and instead unmask specific higher-priority
> maskable exceptions via other functions that write to DAIF, etc.
>
> Interrupts are an odd middle ground where we use irqentry_{enter,exit}()
> but do not use local_daif_inherit().
>
>> The current sequence on entry is:
>>
>> // interrupts are disabled by interrupt/exception entry
>> enter_from_kernel_mode()
>> irqentry_enter(regs);
>> mte_check_tfsr_entry();
>> mte_disable_tco_entry();
>> daif_inherit(regs);
>> // interrupts are still disabled
>
> That last comment isn't quite right: we CAN and WILL enable interrupts
> in local_daif_inherit(), if and only if they were enabled in the context
> the exception was taken from.
>
> As mentioned above, when handling an interrupt (rather than a
> synchronous exception), we don't use local_daif_inherit(), and instead
> use a different DAIF function to unmask everything except interrupts.
>
>> which then becomes:
>>
>> // interrupts are disabled by interrupt/exception entry
>> irqentry_enter(regs)
>> establish_state();
>> // RCU is watching
>> arch_irqentry_enter_rcu()
>> mte_check_tfsr_entry();
>> mte_disable_tco_entry();
>> daif_inherit(regs);
>> // interrupts are still disabled
>>
>> Which is equivalent versus the MTE/DAIF requirements, no?
>
> As above, we can't use local_daif_inherit() here because we want
> different DAIF masking behavior for entry to interrupts and entry to
> synchronous exceptions. While we could pass some token around to
> determine the behaviour dynamically, that's less clear, more
> complicated, and results in worse code being generated for something we
> know at compile time.
>
> If we can leave DAIF masked early on during irqentry_enter(), I don't
> see why we can't leave all DAIF exceptions masked until the end of
> irqentry_enter().
>
> I *think* what would work for us is we could split some of the exit
> handling (including involuntary preemption) into a "prepare" step, as we
> have for return to userspace. That way, arm64 could handle exiting
> something like:
>
> local_irq_disable();
> irqentry_exit_prepare(); // new, all generic logic
> local_daif_mask();
> arm64_exit_to_kernel_mode() {
> ...
> irqentry_exit(); // ideally irqentry_exit_to_kernel_mode().
> ...
> }
I agree. Having a symmetric 'prepare' step for kernel-mode exit as we do
for userspace would be much cleaner. It effectively addresses the DAIF
masking constraints on arm64.
arm64_exit_to_user_mode(struct pt_regs *regs)
-> local_irq_disable(); // only mask irqs
^^^^^^^^^^^^^^^^^^^^^^
-> exit_to_user_mode_prepare_legacy(regs);
-> schedule() // schedule if need resched
-> local_daif_mask(); // set daif to mask all exceptions
^^^^^^^^^^^^^^^^^^^^^
-> mte_check_tfsr_exit();
-> exit_to_user_mode();
This approach can also align with generic implementations like RISC-V.
We can split irqentry_exit() into two sub-functions:
irqentry_exit_prepare() to handle scheduling-related tasks, and the
remaining logic in a simplified irqentry_exit() (or a specific helper).
This way, arm64 can call these two helpers with the DAIF masking
operation inserted in between, while architectures like RISC-V can
continue to use the full irqentry_exit() functionality as they do now.
void do_page_fault(struct pt_regs *regs)
-> irqentry_state_t state = irqentry_enter(regs);
-> handle_page_fault(regs);
-> local_irq_disable();
-> irqentry_exit(regs, state);
>
> ... and other architectures can use a combined exit_to_kernel_mode() (or
> whatever we call that), which does both, e.g.
>
> // either noinstr, __always_inline, or a macro
> void irqentry_prepare_and_exit(void)
> {
> irqentry_exit_prepare();
> irqentry_exit();
> }
>
> That way:
>
> * There's a clear separation between the "prepare" and subsequent exit
> steps, which minimizes the risk that a change subtly breaks arm64's
> exception masking.
>
> * This would mirror the userspace return path, and so would be more
> consistent over all.
>
> * All of arm64's arch-specific exception masking can live in
> arch/arm64/kernel/entry-common.c, explicit in the straight line code
> rather than partially hidden behind arch_*() callbacks.
>
> * There's no unnecessary cost to other architectures.
>
> * There's no/minimal maintenance cost for the generic code. There are no
> arch_*() callbacks, and we'd have to enforce ordering between the
> prepare/exit steps anyhow...
>
> If you don't see an obvious problem with that, I will go and try that
> now.
>
>> The current broken sequence vs. preemption on exit is:
>>
>> // interrupts are disabled
>> exit_to_kernel_mode
>> daif_mask();
>> mte_check_tfsr_exit();
>> irqentry_exit(regs, state);
>>
>> which then becomes:
>>
>> // interrupts are disabled
>> irqentry_exit(regs, state)
>> // includes preemption
>> prepare_for_exit();
>>
>> // RCU is still watching
>> arch_irqentry_ecit_rcu()
>> daif_mask();
>> mte_check_tfsr_exit();
>>
>> if (state.exit_rcu)
>> ct_irq_exit();
>
> As above, I'd strongly prefer if we could pull the "prepare" step out of
> irqentry_exit(). Especially since for the entry path we can't push the
> DAIF masking into irqentry_enter(), and I'd very strongly prefer that
> the masking and unmasking occur in the same logical place, rather than
> having one of those hidden behind an arch_() callback.
>
>> Which is equivalent versus the MTE/DAIF requirements and fixes the
>> preempt on exit issue too, no?
>>
>> That change would be trivial enough for backporting, right?
>>
>> It also prevents you from staring at the bug reports which are going to
>> end up in your mailbox after I merged the patch which moves the
>> misplaced rcu_irq_exit_check_preempt() check _before_ the
>> preempt_count() check where it belongs.
>
> I intend to fix that issue, so hopefully I'm not staring at those for
> long.
>
> Just to check, do you mean that you've already queued that (I didn't
> spot it in tip), or that you intend to? I'll happily test/review/ack a
> patch adding that, but hopefully we can fix arm64 first.
>
>> I fully agree that ARM64 is special vs. CPU state handling, but it's not
>> special enough to justify it's own semantically broken preemption logic.
>
> Sure. To be clear, I'm not arguing for broken preemption logic. I'd
> asked those initial two questions because I suspected this approach
> wasn't quite right.
>
> As above, I think we can solve this in an actually generic way by
> splitting out a "prepare to exit" step, and still keep the bulk of the
> logic generic.
>
>> Looking at those details made me also look at this magic
>> arch_irqentry_exit_need_resched() inline function.
>
> I see per your other reply that you figured out this part was ok:
>
> https://lore.kernel.org/linux-arm-kernel/87se9ph129.ffs@tglx/
>
> ... though I agree we can clean that up further.
>
> Mark.
>
^ permalink raw reply
* Re: [PATCH v4 1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
From: Neil Armstrong @ 2026-03-26 8:52 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-1-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> These pinctrl nodes are required by the eMMC, SD card and SDIO drivers
> to configure pin muxing at runtime.
>
> - eMMC: control, 4-bit/8-bit data, data strobe and clock gate pins
> - SD card: data, clock, command and clock gate pins
> - SDIO: data, clock, command and clock gate pins
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 98 +++++++++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 6510068bcff92..016b5429c8d1b 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -250,6 +250,104 @@ gpio: bank@4000 {
> #gpio-cells = <2>;
> gpio-ranges = <&periphs_pinctrl 0 0 157>;
> };
> +
> + emmc_ctrl_pins: emmc-ctrl {
> + mux-0 {
> + groups = "emmc_cmd";
> + function = "emmc";
> + bias-pull-up;
> + };
> +
> + mux-1 {
> + groups = "emmc_clk";
> + function = "emmc";
> + bias-disable;
> + };
> + };
> +
> + emmc_data_4b_pins: emmc-data-4b {
> + mux-0 {
No need for "-0"
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_data_8b_pins: emmc-data-8b {
> + mux-0 {
No need for "-0"
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3",
> + "emmc_nand_d4",
> + "emmc_nand_d5",
> + "emmc_nand_d6",
> + "emmc_nand_d7";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_ds_pins: emmc-ds {
> + mux {
> + groups = "emmc_nand_ds";
> + function = "emmc";
> + bias-pull-down;
> + };
> + };
> +
> + emmc_clk_gate_pins: emmc-clk-gate {
> + mux {
> + groups = "GPIOB_8";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdcard_pins: sdcard {
> + mux {
> + groups = "sdcard_d0",
> + "sdcard_d1",
> + "sdcard_d2",
> + "sdcard_d3",
> + "sdcard_clk",
> + "sdcard_cmd";
> + function = "sdcard";
> + bias-pull-up;
> + };
> + };
> +
> + sdcard_clk_gate_pins: sdcard-clk-gate {
> + mux {
> + groups = "GPIOC_4";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdio_pins: sdio {
> + mux-0 {
No need for "-0"
> + groups = "sdio_d0",
> + "sdio_d1",
> + "sdio_d2",
> + "sdio_d3",
> + "sdio_clk",
> + "sdio_cmd";
> + function = "sdio";
> + bias-pull-up;
> + };
> + };
> +
> + sdio_clk_gate_pins: sdio-clk-gate {
> + mux {
> + groups = "GPIOX_4";
> + function = "gpio_periphs";
> + bias-pull-up;
> + };
> + };
> };
>
> gpio_intc: interrupt-controller@4080 {
>
^ permalink raw reply
* Re: [PATCH v3] gpio: mxc: map Both Edge pad wakeup to Rising Edge
From: Bartosz Golaszewski @ 2026-03-26 8:41 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Frank Li, Sascha Hauer,
Shenwei Wang
Cc: Bartosz Golaszewski, Pengutronix Kernel Team, Fabio Estevam,
Peng Fan, linux-gpio, imx, linux-arm-kernel, linux-kernel,
linux-imx, stable
In-Reply-To: <20260324192129.2797237-1-shenwei.wang@nxp.com>
On Tue, 24 Mar 2026 14:21:29 -0500, Shenwei Wang wrote:
> Suspend may fail on i.MX8QM when Falling Edge is used as a pad wakeup
> trigger due to a hardware bug in the detection logic. Since the hardware
> does not support Both Edge wakeup, remap requests for Both Edge to Rising
> Edge by default to avoid hitting this issue.
>
> A warning is emitted when Falling Edge is selected on i.MX8QM.
>
> [...]
Applied, thanks!
[1/1] gpio: mxc: map Both Edge pad wakeup to Rising Edge
https://git.kernel.org/brgl/c/c720fb57d56274213d027b3c5ab99080cf62a306
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] gpio: fix up CONFIG_OF dependencies
From: Bartosz Golaszewski @ 2026-03-26 8:41 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Arnd Bergmann
Cc: Bartosz Golaszewski, Arnd Bergmann, Yixun Lan, Matthias Brugger,
AngeloGioacchino Del Regno, linux-gpio, linux-kernel, linux-riscv,
spacemit, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260325100144.1696731-1-arnd@kernel.org>
On Wed, 25 Mar 2026 11:01:14 +0100, Arnd Bergmann wrote:
> A number of GPIO drivers that used to have a CONFIG_OF_GPIO dependency now fail
> to build on targets without CONFIG_OF:
>
> WARNING: unmet direct dependencies detected for GPIO_SYSCON
> Depends on [n]: GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && OF [=n]
> Selected by [y]:
> - GPIO_SAMA5D2_PIOBU [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && (ARCH_AT91 || COMPILE_TEST [=y])
>
> [...]
Applied, thanks!
[1/1] gpio: fix up CONFIG_OF dependencies
https://git.kernel.org/brgl/c/af475c16bc02a08ed6af6ca0c920f98a45611fe6
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] gpio: fix up CONFIG_OF dependencies
From: Bartosz Golaszewski @ 2026-03-26 8:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Yixun Lan, Matthias Brugger,
AngeloGioacchino Del Regno, open list:GPIO SUBSYSTEM,
linux-kernel, linux-riscv, spacemit, linux-arm-kernel,
linux-mediatek, Linus Walleij
In-Reply-To: <1789ce66-5a18-4b54-bbad-3b2049f2c26d@app.fastmail.com>
On Wed, Mar 25, 2026 at 11:41 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, Mar 25, 2026, at 11:32, Bartosz Golaszewski wrote:
> > On Wed, 25 Mar 2026 11:01:14 +0100, Arnd Bergmann <arnd@kernel.org> said:
> >>
> >> WARNING: unmet direct dependencies detected for GPIO_SYSCON
> >> Depends on [n]: GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && OF [=n]
> >> Selected by [y]:
> >> - GPIO_SAMA5D2_PIOBU [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && (ARCH_AT91 || COMPILE_TEST [=y])
> >>
> >
> > Thanks and sorry for the breakage. However, I'm wondering if it wouldn't make
> > sense to do the following:
> >
> >
> > -#if defined(CONFIG_OF_GPIO)
> > /*
> > * If CONFIG_OF_GPIO is enabled, then all GPIO controllers described in
> > * the device tree automatically may have an OF translation
> ...
> > Symbols from linux/of.h are stubbed out and these drivers can build just fine
> > with !CONFIG_OF. This would naturally increase the build coverage.
>
> I don't think we need to worry about the build coverage here, CONFIG_OF
> is still included in x86 allmodconfig and half the randconfig builds,
> so the drivers get enough exposure either way.
>
> On the other hand, dropping the build time check may help avoid
> future Kconfig dependency issues, so that still sounds like a
> reasonable suggestion. At least CONFIG_GPIO_SAMA5D2_PIOBU
> is going to need the 'depends on OF' regardless though to work
> around the other build error I cited above.
>
> Arnd
Fair enough, I'll queue this patch.
Bart
^ permalink raw reply
* Re: [PATCH] i2c: s3c24xx: check the size of the SMBUS message before using it
From: Greg Kroah-Hartman @ 2026-03-26 8:39 UTC (permalink / raw)
To: Andi Shyti
Cc: linux-arm-kernel, linux-samsung-soc, linux-i2c, linux-kernel,
Krzysztof Kozlowski, Alim Akhtar, stable
In-Reply-To: <acQYnURilS0_fTvS@zenone.zhora.eu>
On Wed, Mar 25, 2026 at 06:17:58PM +0100, Andi Shyti wrote:
> Hi Greg,
>
> On Mon, Feb 23, 2026 at 06:05:15PM +0100, Greg Kroah-Hartman wrote:
> > The first byte of an i2c SMBUS message is the size, and it should be
> > verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX
> > before processing it.
> >
> > This is the same logic that was added in commit a6e04f05ce0b ("i2c:
> > tegra: check msg length in SMBUS block read") to the i2c tegra driver.
> >
> > Cc: Krzysztof Kozlowski <krzk@kernel.org>
> > Cc: Alim Akhtar <alim.akhtar@samsung.com>
> > Cc: Andi Shyti <andi.shyti@kernel.org>
> > Cc: stable <stable@kernel.org>
> > Assisted-by: gkh_clanker_2000
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> merged to i2c/i2c-host.
Thanks!
^ permalink raw reply
* Re: [PATCH 2/4] drm/panel: simple: add JuTouch JT070TM041
From: Neil Armstrong @ 2026-03-26 8:38 UTC (permalink / raw)
To: Steffen Trumtrar, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-2-10255d236439@pengutronix.de>
On 3/25/26 12:32, Steffen Trumtrar wrote:
> Add JuTouch Technology JT070TM041 7" 1024x600 LVDS panel support.
>
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 91ab280869bac..6ac263f83793b 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2940,6 +2940,35 @@ static const struct panel_desc innolux_zj070na_01p = {
> },
> };
>
> +static const struct display_timing jutouch_jt070tm041_timing = {
> + .pixelclock = { 40800000, 51200000, 67200000 },
> + .hactive = { 1024, 1024, 1024 },
> + .hfront_porch = { 16, 160, 216 },
> + .hback_porch = { 160, 160, 160 },
> + .hsync_len = { 1, 1, 140 },
> + .vactive = { 600, 600, 600 },
> + .vfront_porch = { 1, 12, 127 },
> + .vback_porch = { 23, 23, 23 },
> + .vsync_len = { 1, 1, 20 },
> +};
> +
> +static const struct panel_desc jutouch_jt070tm041 = {
> + .timings = &jutouch_jt070tm041_timing,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 154,
> + .height = 86,
> + },
> + .delay = {
> + .enable = 50,
> + .disable = 50,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH,
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
> +};
> +
> static const struct display_timing jutouch_jt101tm023_timing = {
> .pixelclock = { 66300000, 72400000, 78900000 },
> .hactive = { 1280, 1280, 1280 },
> @@ -5352,6 +5381,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "innolux,zj070na-01p",
> .data = &innolux_zj070na_01p,
> + }, {
> + .compatible = "jutouch,jt070tm041",
> + .data = &jutouch_jt070tm041,
> }, {
> .compatible = "jutouch,jt101tm023",
> .data = &jutouch_jt101tm023,
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: iio: adc: amlogic,meson-saradc: add S4 compatible
From: Krzysztof Kozlowski @ 2026-03-26 8:19 UTC (permalink / raw)
To: Nick Xie
Cc: neil.armstrong, khilman, martin.blumenstingl, jbrunet, jic23,
dlechner, andy, krzk+dt, robh, conor+dt, linux-iio, linux-amlogic,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260325070618.81955-2-nick@khadas.com>
On Wed, Mar 25, 2026 at 03:06:15PM +0800, Nick Xie wrote:
> Add the compatible string for the SARADC (Successive Approximation
> Register ADC) IP block found in the Amlogic Meson S4 SoC.
>
> There are no known differences between the SARADC on S4 and the one
> on G12A. Therefore, it uses "amlogic,meson-g12a-saradc" as a proper
> specific fallback.
>
> Also add a comment indicating that "amlogic,meson-saradc" must not be
> used for new devices. It's a made up compatible string that does not
> correspond to a specific hardware generation and is not used to match
> any driver. For old devices we keep it as it's part of the ABI.
>
> Signed-off-by: Nick Xie <nick@khadas.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* RE: Clear CLKREQ# override breaks functionality
From: Hongxing Zhu @ 2026-03-26 8:17 UTC (permalink / raw)
To: Franz Schnyder
Cc: Franz Schnyder, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org, Francesco Dolcini,
Manivannan Sadhasivam, Frank Li
In-Reply-To: <jfefktil6ywvugvbxdplbvry6g5efka5g4bpr2dwhha2mtrkm5@6gkcmj2glvwo>
> -----Original Message-----
> From: Franz Schnyder <fra.schnyder@gmail.com>
> Sent: 2026年3月26日 16:00
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: Franz Schnyder <franz.schnyder@toradex.com>;
> linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> imx@lists.linux.dev; linux-kernel@vger.kernel.org; Francesco Dolcini
> <francesco@dolcini.it>; Manivannan Sadhasivam <mani@kernel.org>; Frank
> Li <frank.li@nxp.com>
> Subject: Clear CLKREQ# override breaks functionality
>
> Hi Richard,
>
> While integrating the `supports-clkreq` DT property on our iMX95-based
> SoM, we had failures in our CI on one of the two M.2 PCIe slots on our
> development board.
> The failing slot uses a card that does not advertise L1 PM substates.
> This issue comes from commit a152a90f5390 ("PCI: imx6: Clear CLKREQ#
> override if 'supports-clkreq' DT property is available"), which clears the
> CLKREQ# override based only on the DT property.
>
> It seems that clearing the CLKREQ# override should happen only when the
> driver knows that the downstream device advertises L1 PM Substates.
> Otherwise CLKREQ# should remain asserted to keep compatibility with cards
> that do not support L1 PM Substates.
>
> Thoughts?
Hi Franz:
No, CLKREQ# is not dependent on L1 PM Substates capabilities.
According to the PCI Express Card Electromechanical Specification r6.0,
Section 2 (Auxiliary Signals):
"CLKREQ# (optional) signal is an open drain, active low signal that is driven
low by the card to request that the PCI Express reference clock be available
(active clock state) to allow the PCI Express interface to send/receive data."
When the 'supports-clkreq' property is present, it indicates that the endpoint
device supports CLKREQ# signaling and will actively drive the signal low when
it needs the reference clock.
Therefore, the RC (Root Complex) controller can safely clear any CLKREQ#
active-low override settings, allowing the endpoint to control the clock
request through proper CLKREQ# signaling.
If the endpoint devices on your platform can't drive the CLKREQ# signal to
low, remove 'supports-clkreq' property from your board's device tree file.
Best Regards
Richard Zhu
>
> Kind Regards
>
> Franz
^ permalink raw reply
* [PATCH v2 2/2] regulator: mt6315: Add regulator supplies
From: Chen-Yu Tsai @ 2026-03-26 8:10 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-kernel, Chen-Yu Tsai, linux-arm-kernel, linux-mediatek,
devicetree
In-Reply-To: <20260326081050.1115201-1-wenst@chromium.org>
The MT6315 family of PMICs has 4 buck regulators. Each regulator has a
separate supply.
Add these supplies to the driver.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/regulator/mt6315-regulator.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/mt6315-regulator.c b/drivers/regulator/mt6315-regulator.c
index d3f93aae0fc5..231e64fb0596 100644
--- a/drivers/regulator/mt6315-regulator.c
+++ b/drivers/regulator/mt6315-regulator.c
@@ -31,10 +31,11 @@ struct mt6315_chip {
struct regmap *regmap;
};
-#define MT_BUCK(_name, _bid, _vsel) \
+#define MT_BUCK(_name, _bid, _supply, _vsel) \
[_bid] = { \
.desc = { \
.name = _name, \
+ .supply_name = _supply, \
.of_match = of_match_ptr(_name), \
.regulators_node = "regulators", \
.ops = &mt6315_volt_range_ops, \
@@ -190,10 +191,10 @@ static const struct regulator_ops mt6315_volt_range_ops = {
};
static const struct mt6315_regulator_info mt6315_regulators[MT6315_VBUCK_MAX] = {
- MT_BUCK("vbuck1", MT6315_VBUCK1, MT6315_BUCK_TOP_ELR0),
- MT_BUCK("vbuck2", MT6315_VBUCK2, MT6315_BUCK_TOP_ELR2),
- MT_BUCK("vbuck3", MT6315_VBUCK3, MT6315_BUCK_TOP_ELR4),
- MT_BUCK("vbuck4", MT6315_VBUCK4, MT6315_BUCK_TOP_ELR6),
+ MT_BUCK("vbuck1", MT6315_VBUCK1, "pvdd1", MT6315_BUCK_TOP_ELR0),
+ MT_BUCK("vbuck2", MT6315_VBUCK2, "pvdd2", MT6315_BUCK_TOP_ELR2),
+ MT_BUCK("vbuck3", MT6315_VBUCK3, "pvdd3", MT6315_BUCK_TOP_ELR4),
+ MT_BUCK("vbuck4", MT6315_VBUCK4, "pvdd4", MT6315_BUCK_TOP_ELR6),
};
static const struct regmap_config mt6315_regmap_config = {
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox