* Re: [PATCH 05/10] entry: Split preemption from irqentry_exit_to_kernel_mode()
From: Jinjie Ruan @ 2026-04-08 9:17 UTC (permalink / raw)
To: Mark Rutland, linux-arm-kernel, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner
Cc: vladimir.murzin, will, linux-kernel, catalin.marinas
In-Reply-To: <20260407131650.3813777-6-mark.rutland@arm.com>
On 2026/4/7 21:16, Mark Rutland wrote:
> Some architecture-specific work needs to be performed between the state
> management for exception entry/exit and the "real" work to handle the
> exception. For example, arm64 needs to manipulate a number of exception
> masking bits, with different exceptions requiring different masking.
>
> Generally this can all be hidden in the architecture code, but for arm64
> the current structure of irqentry_exit_to_kernel_mode() makes this
> particularly difficult to handle in a way that is correct, maintainable,
> and efficient.
>
> The gory details are described in the thread surrounding:
>
> https://lore.kernel.org/lkml/acPAzdtjK5w-rNqC@J2N7QTR9R3/
>
> The summary is:
>
> * Currently, irqentry_exit_to_kernel_mode() handles both involuntary
> preemption AND state management necessary for exception return.
>
> * When scheduling (including involuntary preemption), arm64 needs to
> have all arm64-specific exceptions unmasked, though regular interrupts
> must be masked.
>
> * Prior to the state management for exception return, arm64 needs to
> mask a number of arm64-specific exceptions, and perform some work with
> these exceptions masked (with RCU watching, etc).
>
> While in theory it is possible to handle this with a new arch_*() hook
> called somewhere under irqentry_exit_to_kernel_mode(), this is fragile
> and complicated, and doesn't match the flow used for exception return to
> user mode, which has a separate 'prepare' step (where preemption can
> occur) prior to the state management.
>
> To solve this, refactor irqentry_exit_to_kernel_mode() to match the
> style of {irqentry,syscall}_exit_to_user_mode(), moving preemption logic
> into a new irqentry_exit_to_kernel_mode_preempt() function, and moving
> state management in a new irqentry_exit_to_kernel_mode_after_preempt()
> function. The existing irqentry_exit_to_kernel_mode() is left as a
> caller of both of these, avoiding the need to modify existing callers.
>
> There should be no functional change as a result of this patch.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Jinjie Ruan <ruanjinjie@huawei.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Vladimir Murzin <vladimir.murzin@arm.com>
> Cc: Will Deacon <will@kernel.org>
> ---
> include/linux/irq-entry-common.h | 26 +++++++++++++++++++++-----
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> Thomas/Peter/Andy, as mentioned on IRC, I haven't created kerneldoc
> comments for these new functions because the existing comments don't
> seem all that consistent (e.g. for user mode vs kernel mode), and I
> suspect we want to rewrite them all in one go for wider consistency.
>
> I'm happy to respin this, or to follow-up with that as per your
> preference.
>
> Mark.
>
> diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h
> index 2206150e526d8..24830baa539c6 100644
> --- a/include/linux/irq-entry-common.h
> +++ b/include/linux/irq-entry-common.h
> @@ -421,10 +421,18 @@ static __always_inline irqentry_state_t irqentry_enter_from_kernel_mode(struct p
> return ret;
> }
>
> -static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, irqentry_state_t state)
> +static inline void irqentry_exit_to_kernel_mode_preempt(struct pt_regs *regs, irqentry_state_t state)
> {
> - lockdep_assert_irqs_disabled();
> + if (regs_irqs_disabled(regs) || state.exit_rcu)
> + return;
> +
> + if (IS_ENABLED(CONFIG_PREEMPTION))
> + irqentry_exit_cond_resched();
> +}
>
> +static __always_inline void
> +irqentry_exit_to_kernel_mode_after_preempt(struct pt_regs *regs, irqentry_state_t state)
> +{
> if (!regs_irqs_disabled(regs)) {
> /*
> * If RCU was not watching on entry this needs to be done
> @@ -443,9 +451,6 @@ static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, i
> }
>
> instrumentation_begin();
> - if (IS_ENABLED(CONFIG_PREEMPTION))
> - irqentry_exit_cond_resched();
> -
> /* Covers both tracing and lockdep */
> trace_hardirqs_on();
> instrumentation_end();
> @@ -459,6 +464,17 @@ static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, i
> }
> }
>
> +static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, irqentry_state_t state)
> +{
> + lockdep_assert_irqs_disabled();
> +
> + instrumentation_begin();
> + irqentry_exit_to_kernel_mode_preempt(regs, state);
> + instrumentation_end();
I think the below AI's feedback makes sense. Directly calling
irqentry_exit_to_kernel_mode_preempt() on arm64/other archs could lead
to missing instrumentation_begin()/end() markers.
https://sashiko.dev/#/patchset/20260407131650.3813777-1-mark.rutland%40arm.com
> +
> + irqentry_exit_to_kernel_mode_after_preempt(regs, state);
> +}
> +
> /**
> * irqentry_enter - Handle state tracking on ordinary interrupt entries
> * @regs: Pointer to pt_regs of interrupted context
^ permalink raw reply
* Re: [RFC PATCH 0/8] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Dev Jain @ 2026-04-08 9:14 UTC (permalink / raw)
To: Barry Song (Xiaomi), linux-mm, linux-arm-kernel, catalin.marinas,
will, akpm, urezki
Cc: linux-kernel, anshuman.khandual, ryan.roberts, ajd, rppt, david,
Xueyuan.chen21
In-Reply-To: <20260408025115.27368-1-baohua@kernel.org>
On 08/04/26 8:21 am, Barry Song (Xiaomi) wrote:
> This patchset accelerates ioremap, vmalloc, and vmap when the memory
> is physically fully or partially contiguous. Two techniques are used:
>
> 1. Avoid page table zigzag when setting PTEs/PMDs for multiple memory
> segments
> 2. Use batched mappings wherever possible in both vmalloc and ARM64
> layers
>
> Patches 1–2 extend ARM64 vmalloc CONT-PTE mapping to support multiple
> CONT-PTE regions instead of just one.
>
> Patches 3–4 extend vmap_small_pages_range_noflush() to support page
> shifts other than PAGE_SHIFT. This allows mapping multiple memory
> segments for vmalloc() without zigzagging page tables.
>
> Patches 5–8 add huge vmap support for contiguous pages. This not only
> improves performance but also enables PMD or CONT-PTE mapping for the
> vmapped area, reducing TLB pressure.
>
> Many thanks to Xueyuan Chen for his substantial testing efforts
> on RK3588 boards.
>
> On the RK3588 8-core ARM64 SoC, with tasks pinned to CPU2 and
> the performance CPUfreq policy enabled, Xueyuan’s tests report:
>
> * ioremap(1 MB): 1.2× faster
> * vmalloc(1 MB) mapping time (excluding allocation) with
> VM_ALLOW_HUGE_VMAP: 1.5× faster
> * vmap(): 5.6× faster when memory includes some order-8 pages,
> with no regression observed for order-0 pages
>
> Barry Song (Xiaomi) (8):
> arm64/hugetlb: Extend batching of multiple CONT_PTE in a single PTE
> setup
> arm64/vmalloc: Allow arch_vmap_pte_range_map_size to batch multiple
> CONT_PTE
> mm/vmalloc: Extend vmap_small_pages_range_noflush() to support larger
> page_shift sizes
> mm/vmalloc: Eliminate page table zigzag for huge vmalloc mappings
> mm/vmalloc: map contiguous pages in batches for vmap() if possible
> mm/vmalloc: align vm_area so vmap() can batch mappings
> mm/vmalloc: Coalesce same page_shift mappings in vmap to avoid pgtable
> zigzag
> mm/vmalloc: Stop scanning for compound pages after encountering small
> pages in vmap
>
> arch/arm64/include/asm/vmalloc.h | 6 +-
> arch/arm64/mm/hugetlbpage.c | 10 ++
> mm/vmalloc.c | 178 +++++++++++++++++++++++++------
> 3 files changed, 161 insertions(+), 33 deletions(-)
>
On Linux VM on Apple M3, running mm-selftests:
./run_vmtests.sh -t "hugetlb"
TAP version 13
# -----------------------
# running ./hugepage-mmap
# -----------------------
# TAP version 13
# 1..1
# # Returned address is 0xffffe7c00000
[ 30.884630] kernel BUG at mm/page_table_check.c:86!
[ 30.884701] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[ 30.886803] Modules linked in:
[ 30.887217] CPU: 3 UID: 0 PID: 1869 Comm: hugepage-mmap Not tainted 7.0.0-rc5+ #86 PREEMPT
[ 30.888218] Hardware name: linux,dummy-virt (DT)
[ 30.889413] pstate: a1400005 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 30.889901] pc : page_table_check_clear.part.0+0x128/0x1a0
[ 30.890337] lr : page_table_check_clear.part.0+0x7c/0x1a0
[ 30.890714] sp : ffff800084da3ad0
[ 30.890946] x29: ffff800084da3ad0 x28: 0000000000000001 x27: 0010000000000001
[ 30.891434] x26: 0040000000000040 x25: ffffa06bb8fb9000 x24: 00000000ffffffff
[ 30.891932] x23: 0000000000000001 x22: 0000000000000000 x21: ffffa06bb8997810
[ 30.892514] x20: 0000000000113e39 x19: 0000000000113e38 x18: 0000000000000000
[ 30.893007] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 30.893500] x14: ffffa06bb7013780 x13: 0000fffff7f90fff x12: 0000000000000000
[ 30.893990] x11: 1fffe0001a1282c1 x10: ffff0000d094160c x9 : ffffa06bb568a858
[ 30.894479] x8 : ffff5f95c8474000 x7 : 0000000000000000 x6 : ffff00017fffc500
[ 30.894973] x5 : ffff000191208fc0 x4 : 0000000000000000 x3 : 0000000000004000
[ 30.895449] x2 : 0000000000000000 x1 : 00000000ffffffff x0 : ffff0000c071f1b8
[ 30.895875] Call trace:
[ 30.896027] page_table_check_clear.part.0+0x128/0x1a0 (P)
[ 30.896369] page_table_check_clear+0xc8/0x138
[ 30.896776] __page_table_check_ptes_set+0xe4/0x1e8
[ 30.897073] __set_ptes_anysz+0x2e4/0x308
[ 30.897327] set_huge_pte_at+0xec/0x210
[ 30.897561] hugetlb_no_page+0x1ec/0x8e0
[ 30.897807] hugetlb_fault+0x188/0x740
[ 30.898036] handle_mm_fault+0x294/0x2c0
[ 30.898283] do_page_fault+0x120/0x748
[ 30.898539] do_translation_fault+0x68/0x90
[ 30.898796] do_mem_abort+0x4c/0xa8
[ 30.899011] el0_da+0x2c/0x90
[ 30.899205] el0t_64_sync_handler+0xd0/0xe8
[ 30.899461] el0t_64_sync+0x198/0x1a0
[ 30.899688] Code: 91001021 b8f80022 51000441 36fffd41 (d4210000)
[ 30.900053] ---[ end trace 0000000000000000 ]---
The bug is at
BUG_ON(atomic_dec_return(&ptc->file_map_count) < 0);
My tree is mm-unstable, commit 3fa44141e0bb.
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
From: Neil Armstrong @ 2026-04-08 9:12 UTC (permalink / raw)
To: linux-kernel, linux-amlogic, linux-arm-kernel, devicetree,
Jun Yan
Cc: robh, krzk+dt, conor+dt, khilman, jbrunet, martin.blumenstingl
In-Reply-To: <20260330145111.115318-1-jerrysteve1101@gmail.com>
Hi,
On Mon, 30 Mar 2026 22:51:11 +0800, Jun Yan wrote:
> Correct the interrupt number assigned to the Realtek PHY in the p230
>
> following the same logic as commit 3106507e1004 ("ARM64: dts: meson-gxm:
> fix q200 interrupt number"),as reported in [PATCH 0/2] Ethernet PHY
> interrupt improvements [1].
>
> [1] https://lore.kernel.org/all/20171202214037.17017-1-martin.blumenstingl@googlemail.com/
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/1] arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
https://git.kernel.org/amlogic/c/b18d1b23558114b3c64fec7b515ca80c76e58171
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 1/2] dt-bindings: pinctrl: pinctrl-single: Add brcm,bcm7038-padconf
From: Krzysztof Kozlowski @ 2026-04-08 9:11 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tony Lindgren, Haojian Zhuang,
open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-2-florian.fainelli@broadcom.com>
On Tue, Apr 07, 2026 at 04:56:10PM -0700, Florian Fainelli wrote:
> Add the "brcm,bcm7038-padconf" compatible to the pinctrl-single binding.
>
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> index 9135788cf62e..afe7329a1df2 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> @@ -38,6 +38,10 @@ properties:
> - enum:
> - marvell,pxa1908-padconf
> - const: pinconf-single
> + - items:
> + - enum:
> + - brcm,bcm7038-padconf
> + - const: pinctrl-single
If there is going to be a new version, entire block should be placed
before 'ti' to have some sort of sorting by compatible.
But no need to resend just for that.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v5 0/9] arm64: dts: amlogic: Add MMC/SD/SDIO support for Khadas VIM4 (Amlogic T7)
From: Neil Armstrong @ 2026-04-08 9:10 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley, Xianwei Zhao, Nick Xie
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr>
Hi,
On Thu, 26 Mar 2026 10:59:11 +0100, Ronald Claveau wrote:
> This patch series depends on Jian's SCMI clock patches yet to merge
> https://lore.kernel.org/all/20260313070022.700437-1-jian.hu@amlogic.com/
>
> This series adds device tree support for the MMC, SD card and SDIO
> interfaces on the Amlogic T7 SoC and the Khadas VIM4 board.
>
> The first patches add the necessary building blocks in the T7 SoC
> DTSI: pinctrl nodes for pin muxing, PWM controller nodes, and MMC
> controller nodes. The amlogic,t7-mmc and amlogic,t7-pwm compatible
> strings are introduced with fallbacks to existing drivers, avoiding
> the need for new driver code.
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[3/9] arm64: dts: amlogic: t7: Add MMC controller nodes
https://git.kernel.org/amlogic/c/759613b88fbf051c8a977a5e5b046b28a18ed5c7
[5/9] arm64: dts: amlogic: t7: Add PWM controller nodes
https://git.kernel.org/amlogic/c/596e3c1bfa7869cf15079e5c6e586575013b2fc3
[7/9] arm64: dts: amlogic: t7: khadas-vim4: Add SDIO power sequence and WiFi clock
https://git.kernel.org/amlogic/c/647228c014ddbd336a97e74bde81cbb2f7cbd927
[9/9] arm64: dts: amlogic: t7: khadas-vim4: Add MMC nodes
https://git.kernel.org/amlogic/c/00cca65deacb29947ef32011827ff88fd59dab55
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/2] Fix Amlogic T7 null reset ops and DT required property
From: Neil Armstrong @ 2026-04-08 9:10 UTC (permalink / raw)
To: Philipp Zabel, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-0-eb95b625234c@aliel.fr>
Hi,
On Tue, 31 Mar 2026 16:24:03 +0200, Ronald Claveau wrote:
> 1. As reset is required for MMC DT, this patch series aims to add the currently missing required driver ops.
>
> Whithout this patch the following kernel null error appears:
>
> [ 0.459197] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> [ 0.459978] Mem abort info:
> [ 0.460324] ESR = 0x0000000096000004
> [ 0.460791] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 0.461471] SET = 0, FnV = 0
> [ 0.461830] EA = 0, S1PTW = 0
> [ 0.462220] FSC = 0x04: level 0 translation fault
> [ 0.462722] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> [ 0.462826] Data abort info:
> [ 0.462829] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> [ 0.462842] Mem abort info:
> [ 0.462849] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [ 0.462859] ESR = 0x0000000096000004
> [ 0.462865] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 0.462874] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 0.462882] [0000000000000000] user address but active_mm is swapper
> [ 0.462890] SET = 0, FnV = 0
> [ 0.462901] Internal error: Oops: 0000000096000004 [#1] SMP
> [ 0.462909] EA = 0, S1PTW = 0
> [ 0.462917] Modules linked in:
> [ 0.462925] FSC = 0x04: level 0 translation fault
> [ 0.462932]
> [ 0.462939] Data abort info:
> [ 0.462951] CPU: 4 UID: 0 PID: 90 Comm: kworker/u34:3 Not tainted 7.0.0-rc4-next-20260319 #41 PREEMPT
> [ 0.463920] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> [ 0.463927] Hardware name: Khadas VIM4 (DT)
> [ 0.463940] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [ 0.463951] Workqueue: async async_run_entry_fn
> [ 0.464277] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 0.464286]
> [ 0.464294] [0000000000000000] user address but active_mm is swapper
> [ 0.464304] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.465935] pc : reset_control_reset+0x48/0x1d0
> [ 0.466409] lr : reset_control_reset+0x38/0x1d0
> [ 0.479907] sp : ffff800083943b60
> [ 0.479911] x29: ffff800083943b60 x28: 0000000000000000 x27: 0000000000000000
> [ 0.479926] x26: ffff80008310a9c0 x25: 0000000000000000 x24: ffff000100372005
> [ 0.481212] x23: ffff0001003a4000 x22: ffff000100fee988 x21: 0000000000000000
> [ 0.482976] x20: ffff00023f00a788 x19: ffff000100fee980 x18: 0000000000000006
> [ 0.483865] x17: 64656c62616e655f x16: 7469647561206465 x15: ffff800083943530
> [ 0.484753] x14: 0000000000000000 x13: 000000000000022d x12: 0000000000002000
> [ 0.485642] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
> [ 0.486530] x8 : ffff00023efd8a40 x7 : fffffffffffffe70 x6 : ffff00023efd89e0
> [ 0.487418] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
> [ 0.488307] x2 : ffff000102002488 x1 : ffff8000822248c0 x0 : 0000000000000000
> [ 0.489196] Call trace:
> [ 0.489500] reset_control_reset+0x48/0x1d0 (P)
> [ 0.490062] __device_reset+0xc8/0xfc
> [ 0.490517] meson_mmc_probe+0xe8/0x3d4
> [ 0.490994] platform_probe+0x5c/0x98
> [ 0.491448] really_probe+0xbc/0x298
> [ 0.491892] __driver_probe_device+0x78/0x12c
> [ 0.492434] driver_probe_device+0xd4/0x164
> [ 0.492954] __device_attach_driver+0xb8/0x140
> [ 0.493507] bus_for_each_drv+0x84/0xe0
> [ 0.493983] __device_attach_async_helper+0xac/0xd0
> [ 0.494590] async_run_entry_fn+0x34/0xe0
> [ 0.495089] process_one_work+0x158/0x29c
> [ 0.495587] worker_thread+0x18c/0x308
> [ 0.496053] kthread+0x11c/0x128
> [ 0.496453] ret_from_fork+0x10/0x20
> [ 0.496904] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
> [ 0.497661] ---[ end trace 0000000000000000 ]---
> [ 0.498234] Internal error: Oops: 0000000096000004 [#2] SMP
> [ 0.498935] Modules linked in:
> [ 0.499319] CPU: 1 UID: 0 PID: 88 Comm: kworker/u34:1 Tainted: G D 7.0.0-rc4-next-20260319 #41 PREEMPT
> [ 0.500669] Tainted: [D]=DIE
> [ 0.501025] Hardware name: Khadas VIM4 (DT)
> [ 0.501547] Workqueue: async async_run_entry_fn
> [ 0.502109] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.502975] pc : reset_control_reset+0x48/0x1d0
> [ 0.503538] lr : reset_control_reset+0x38/0x1d0
> [ 0.504102] sp : ffff800083903b60
> [ 0.504513] x29: ffff800083903b60 x28: 0000000000000000 x27: 0000000000000000
> [ 0.505402] x26: ffff000100059028 x25: 0000000000000000 x24: ffff000100372005
> [ 0.506290] x23: ffff000100ec9400 x22: ffff0001003f6e08 x21: 0000000000000000
> [ 0.507178] x20: ffff00023f00b440 x19: ffff0001003f6e00 x18: 00000000ffffffff
> [ 0.508067] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000839037e0
> [ 0.508955] x14: 0000000000000000 x13: 0000000000000290 x12: 0000000000002000
> [ 0.509843] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
> [ 0.510732] x8 : ffff00023efd8bc0 x7 : fffffffffffffe70 x6 : ffff00023efd8b60
> [ 0.511620] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
> [ 0.512508] x2 : ffff000102002488 x1 : ffff800082224a40 x0 : 0000000000000000
> [ 0.513397] Call trace:
> [ 0.513700] reset_control_reset+0x48/0x1d0 (P)
> [ 0.514263] __device_reset+0xc8/0xfc
> [ 0.514718] meson_mmc_probe+0xe8/0x3d4
> [ 0.515195] platform_probe+0x5c/0x98
> [ 0.515650] really_probe+0xbc/0x298
> [ 0.516094] __driver_probe_device+0x78/0x12c
> [ 0.516636] driver_probe_device+0xd4/0x164
> [ 0.517156] __device_attach_driver+0xb8/0x140
> [ 0.517709] bus_for_each_drv+0x84/0xe0
> [ 0.518185] __device_attach_async_helper+0xac/0xd0
> [ 0.518792] async_run_entry_fn+0x34/0xe0
> [ 0.519290] process_one_work+0x158/0x29c
> [ 0.519788] worker_thread+0x18c/0x308
> [ 0.520254] kthread+0x11c/0x128
> [ 0.520655] ret_from_fork+0x10/0x20
> [ 0.521103] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
> [ 0.521860] ---[ end trace 0000000000000000 ]---
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[2/2] arm64: dts: amlogic: t7: Fix missing required reset property
https://git.kernel.org/amlogic/c/98da3e91a6157d2833af356620665a9734d26133
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 v3 0/3] Add the missing mpll3 clock and clock controller nodes
From: Neil Armstrong @ 2026-04-08 9:09 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, Martin Blumenstingl, Stephen Boyd,
Michael Turquette, robh+dt, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jian Hu
Cc: devicetree, linux-clk, linux-amlogic, linux-kernel,
linux-arm-kernel, Ronald Claveau, Ferass El Hafidi
In-Reply-To: <20260326092645.1053261-1-jian.hu@amlogic.com>
Hi,
On Thu, 26 Mar 2026 17:26:42 +0800, Jian Hu wrote:
> This series adds the missing mpll3 parent clock and completes the
> Amlogic T7 SoC clock controller DT support.
>
> - Fix redundant hyphen in for gp1 pll
> - Add the missing mpll3 parent clock definition to t7-peripherals-clkc.yaml
> - Add Amlogic T7 SoC clock controller nodes
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[3/3] arm64: dts: amlogic: t7: Add clock controller nodes
https://git.kernel.org/amlogic/c/5f727a999f80a72dae7326577e0d832799ddeaa3
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 10/10] arm64: Check DAIF (and PMR) at task-switch time
From: Mark Rutland @ 2026-04-08 9:08 UTC (permalink / raw)
To: Jinjie Ruan
Cc: vladimir.murzin, peterz, Catalin Marinas, linux-kernel, tglx,
luto, Will Deacon, linux-arm-kernel
In-Reply-To: <26642def-7676-e081-98f3-9ab883048375@huawei.com>
On Wed, Apr 08, 2026 at 10:17:56AM +0800, Jinjie Ruan wrote:
> On 2026/4/7 21:16, Mark Rutland wrote:
> > +static inline void debug_switch_state(void)
> > +{
> > + if (system_uses_irq_prio_masking()) {
> > + unsigned long daif_expected = 0;
> > + unsigned long daif_actual = read_sysreg(daif);
> > + unsigned long pmr_expected = GIC_PRIO_IRQOFF;
> > + unsigned long pmr_actual = read_sysreg_s(SYS_ICC_PMR_EL1);
> > +
> > + WARN_ONCE(daif_actual != daif_expected ||
> > + pmr_actual != pmr_expected,
> > + "Unexpected DAIF + PMR: 0x%lx + 0x%lx (expected 0x%lx + 0x%lx)\n",
> > + daif_actual, pmr_actual,
> > + daif_expected, pmr_expected);
> > + } else {
> > + unsigned long daif_expected = DAIF_PROCCTX_NOIRQ;
> > + unsigned long daif_actual = read_sysreg(daif);
> > +
> > + WARN_ONCE(daif_actual != daif_expected,
> > + "Unexpected DAIF value: 0x%lx (expected 0x%lx)\n",
> > + daif_actual, daif_expected);
> > + }
>
> This logic seems consistent with arm64's local_irq_disable()
> implementation. Do we need to wrap these debug checks in a config option
> (e.g., CONFIG_ARM64_DEBUG_PRIORITY_MASKING) to avoid unnecessary overhead?
Possibly. I'd expected this was infrequent enough that there wouldn't be
a noticeable overhead, but admittedly I don't have numbers.
Given Thomas seems happy to queue the preparatory bits, (hopefully) we
can queue the rest of this as-is, and I reckon it's probably best to
drop this patch for now and follow up with a better version later.
There are some other bits of state I'd like to check here (e.g. PAN),
and I think this requires a bit more work.
Thanks for looking at this!
Mark.
>
>
> __schedule()
> -> local_irq_disable()
> -> arch_local_irq_disable()
>
> 52 static __always_inline void __daif_local_irq_disable(void)
> 53 {
> 54 barrier();
> 55 asm volatile("msr daifset, #3");
> 56 barrier();
> 57 }
> 58
> 59 static __always_inline void __pmr_local_irq_disable(void)
> 60 {
> 61 if (IS_ENABLED(CONFIG_ARM64_DEBUG_PRIORITY_MASKING)) {
> 62 u32 pmr = read_sysreg_s(SYS_ICC_PMR_EL1);
> 63 WARN_ON_ONCE(pmr != GIC_PRIO_IRQON && pmr !=
> GIC_PRIO_IRQOFF);
> 64 }
> 65
> 66 barrier();
> 67 write_sysreg_s(GIC_PRIO_IRQOFF, SYS_ICC_PMR_EL1);
> 68 barrier();
> 69 }
> 70
> 71 static inline void arch_local_irq_disable(void)
> 72 {
> 73 if (system_uses_irq_prio_masking()) {
> 74 __pmr_local_irq_disable();
> 75 } else {
> 76 __daif_local_irq_disable();
> 77 }
> 78 }
>
>
> > +}
> > +
> > /*
> > * Thread switching.
> > */
> > @@ -708,6 +731,8 @@ struct task_struct *__switch_to(struct task_struct *prev,
> > {
> > struct task_struct *last;
> >
> > + debug_switch_state();
> > +
> > fpsimd_thread_switch(next);
> > tls_thread_switch(next);
> > hw_breakpoint_thread_switch(next);
^ permalink raw reply
* Re: [PATCH 1/2] coresight: etm4x: fix inconsistencies with sysfs configration
From: Yeoreum Yun @ 2026-04-08 9:07 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, mike.leach,
james.clark, alexander.shishkin, leo.yan
In-Reply-To: <f62c7138-bddc-4bf1-932d-bafa683f5ee0@arm.com>
Hi Suzuki,
[...]
>
> >
> > To resolve these inconsistencies, the configuration should be separated into:
> >
> > - active_config, which represents the currently applied configuration
>
> To be more precise, it is the "Applied configuration for the current
> session"
Thanks for suggestion. I'll change it.
>
> > - config, which stores the settings configured via sysfs.
>
> While we are at it, should we stop using the drvdata->config for the
> "capabilities" for the ETM (e.g., TRCSSCSRn in ss_status ?) Instead
> we could save it in "drvdata->ss_status". This keeps everything
> separated:
>
> 1. Boot time probed capabilities of ETM
> 2. Sysfs configuration for the next Run
> 3. Current active configuration for the ETM (sysfs or perf)
Agree. with the Leo's suggestion, I'll change it.
Thanks!
[...]
^ permalink raw reply
* Re: [PATCH 00/10] arm64/entry:
From: Catalin Marinas @ 2026-04-08 9:06 UTC (permalink / raw)
To: Mark Rutland
Cc: vladimir.murzin, Peter Zijlstra, ruanjinjie, linux-kernel,
Thomas Gleixner, Andy Lutomirski, Will Deacon, linux-arm-kernel
In-Reply-To: <adYZpA3-Tx6s1VOp@J2N7QTR9R3>
On Wed, Apr 08, 2026 at 10:02:28AM +0100, Mark Rutland wrote:
> On Tue, Apr 07, 2026 at 11:08:36PM +0200, Thomas Gleixner wrote:
> > On Tue, Apr 07 2026 at 14:16, Mark Rutland wrote:
> > > I've split the series into a prefix of changes for generic irqentry,
> > > followed by changes to the arm64 code. I'm hoping that we can queue the
> > > generic irqentry patches onto a stable branch, or take those via arm64.
> > > The patches are as follows:
> > >
> > > * Patches 1 and 2 are cleanup to the generic irqentry code. These have no
> > > functional impact, and I think these can be taken regardless of the
> > > rest of the series.
> > >
> > > * Patches 3 to 5 refactor the generic irqentry code as described above,
> > > providing separate irqentry_{enter,exit}() functions and providing a
> > > split form of irqentry_exit_to_kernel_mode() similar to what exists
> > > for irqentry_exit_to_user_mode(). These patches alone should have no
> > > functional impact.
> >
> > I looked through them and I can't find any problem with them. I queued
> > them localy and added the missing kernel doc as I promised you on IRC.
>
> Thanks! Much appreciated!
>
> > As I have quite a conflict pending in the tip tree with other changes
> > related to the generic entry code, I suggest that I queue 1-5, tag them
> > for arm64 consumption and merge them into the conflicting branch to
> > avoid trouble with pull request ordering and headaches for the -next
> > people.
> >
> > Does that work for you?
>
> That sounds good to me.
>
> Catalin, Will, does that work for you?
Yes, it does. Thanks!
--
Catalin
^ permalink raw reply
* Re: [PATCH 00/10] arm64/entry:
From: Mark Rutland @ 2026-04-08 9:02 UTC (permalink / raw)
To: Thomas Gleixner, Catalin Marinas, Will Deacon
Cc: vladimir.murzin, Peter Zijlstra, ruanjinjie, linux-kernel,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <87cy0a4gx7.ffs@tglx>
On Tue, Apr 07, 2026 at 11:08:36PM +0200, Thomas Gleixner wrote:
> On Tue, Apr 07 2026 at 14:16, Mark Rutland wrote:
> > I've split the series into a prefix of changes for generic irqentry,
> > followed by changes to the arm64 code. I'm hoping that we can queue the
> > generic irqentry patches onto a stable branch, or take those via arm64.
> > The patches are as follows:
> >
> > * Patches 1 and 2 are cleanup to the generic irqentry code. These have no
> > functional impact, and I think these can be taken regardless of the
> > rest of the series.
> >
> > * Patches 3 to 5 refactor the generic irqentry code as described above,
> > providing separate irqentry_{enter,exit}() functions and providing a
> > split form of irqentry_exit_to_kernel_mode() similar to what exists
> > for irqentry_exit_to_user_mode(). These patches alone should have no
> > functional impact.
>
> I looked through them and I can't find any problem with them. I queued
> them localy and added the missing kernel doc as I promised you on IRC.
Thanks! Much appreciated!
> As I have quite a conflict pending in the tip tree with other changes
> related to the generic entry code, I suggest that I queue 1-5, tag them
> for arm64 consumption and merge them into the conflicting branch to
> avoid trouble with pull request ordering and headaches for the -next
> people.
>
> Does that work for you?
That sounds good to me.
Catalin, Will, does that work for you?
Mark.
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: aspeed: anacapa: add EVT1 devicetree and point wrapper to it
From: Krzysztof Kozlowski @ 2026-04-08 9:00 UTC (permalink / raw)
To: Colin Huang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, colin.huang2
In-Reply-To: <CAPBH0A-ER9-_KpknyOKTmS2sBk-xv0c016y9WsLOvZ8CjSiwCw@mail.gmail.com>
On 08/04/2026 10:52, Colin Huang wrote:
> Hi Krzysztof,
> Thanks for reply.
Do not top post.
> Could you let me know what kind test I need to run?
> Following is what I do before send.
> * I build this dts with linux 6.6.x
v6.6? That's like 2.5 years ago.
No, you must work on recent kernel.
> * run "b4 prep --check"
Google - how to validate DTS in Linux kernel
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 net-next 10/14] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
From: Wei Fang @ 2026-04-08 8:59 UTC (permalink / raw)
To: Jakub Kicinski, Vladimir Oltean
Cc: Claudiu Manoil, Clark Wang, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
f.fainelli@gmail.com, Frank Li, chleroy@kernel.org,
horms@kernel.org, linux@armlinux.org.uk, andrew@lunn.ch,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011738.1795644-1-kuba@kernel.org>
> > +static int netc_init_switch_id(struct netc_switch *priv)
> > +{
> > + struct netc_switch_regs *regs = &priv->regs;
> > + struct dsa_switch *ds = priv->ds;
> > +
> > + /* The value of 0 is reserved for the VEPA switch and cannot
> > + * be used.
> > + */
> > + if (ds->index > SWCR_SWID || !ds->index) {
> > + dev_err(priv->dev, "Switch index %d out of range\n",
> > + ds->index);
> > + return -ERANGE;
> > + }
>
> Does this check cause the probe to fail unconditionally for standard
> single-switch topologies?
>
> The DSA core typically assigns ds->index = 0 by default for the first switch.
> Because !ds->index evaluates to true for index 0, this setup function will
> always fail unless the dsa,member property is explicitly overridden in the
> device tree.
As I mentioned in another mail, we added the 'dsa,member' property to the
netc switch DT-binding doc, specifying that the 'member' (switch index) value
cannot be 0. And 'dsa,member' is a required property for netc switch.
>
> Could the driver translate the hardware ID internally, for example by writing
> ds->index + 1 to NETC_SWCR, rather than forcing this hardware-specific
> restriction onto the software DSA index?
The current approach is based on Vladimir's suggestion. I need to confirm with
Vladimir which approach is better.
Hi Vladimir,
What are your thoughts on this suggestion? Is this approach better?
>
> [ ... ]
> > + for_each_available_child_of_node_scoped(ports, child) {
> > + /* If the node does not have phy-handle property, then
> > + * the port does not connect to a PHY, so the port is
> > + * not the EMDIO consumer.
> > + */
> > + phy_node = of_parse_phandle(child, "phy-handle", 0);
> > + if (!phy_node)
> > + continue;
> > +
> > + if (!netc_port_is_emdio_consumer(child)) {
> > + of_node_put(phy_node);
> > + continue;
> > + }
> > +
> > + phydev = of_phy_find_device(phy_node);
> > + of_node_put(phy_node);
> > + if (!phydev) {
> > + err = -EPROBE_DEFER;
> > + goto out;
> > + }
>
> Could this logic cause an infinite probe deferral loop for ports sharing an
> internal MDIO bus?
>
> The netc_port_is_emdio_consumer() function assumes any port node without
> an
> mdio child is an EMDIO consumer waiting for an external controller. However,
> if multiple sibling ports on the same switch share a single internal MDIO bus
> defined under one port, the other ports will lack an mdio child node.
>
> This would cause those ports to be mistakenly treated as external EMDIO
> consumers, calling of_phy_find_device(). Because the internal MDIO bus is not
> registered until later in netc_setup(), the PHY device cannot be found, and
> the driver returns -EPROBE_DEFER.
>
> Since netc_setup() is never reached, the MDIO bus is never registered,
> causing an infinite deferral loop. Could the driver more accurately identify
> whether the PHY belongs to its own switch before deferring?
This case will not be true, from the hardware perspective, the switch ports
do not support share a single internal MDIO bus defined under one port.
The internal MDIO bus of a port can only access its own external PHY. So
a switch port must either use EMDIO to access its PHY or its internal MDIO
bus to access its PHY.
>
> > +
> > + put_device(&phydev->mdio.dev);
> > + }
> > +
> > +out:
> > + of_node_put(ports);
> > +
> > + return err;
> > +}
> > +
> > +static int netc_switch_pci_init(struct pci_dev *pdev)
> > +{
> [ ... ]
> > + regs->base = pci_ioremap_bar(pdev, NETC_REGS_BAR);
> > + if (!regs->base) {
> > + err = -ENXIO;
> > + dev_err(dev, "pci_ioremap_bar() failed\n");
> > + goto release_mem_regions;
> > + }
> [ ... ]
> > +static void netc_switch_pci_destroy(struct pci_dev *pdev)
> > +{
> > + struct netc_switch *priv = pci_get_drvdata(pdev);
> > +
> > + iounmap(priv->regs.base);
> > + pci_release_mem_regions(pdev);
> > + pci_disable_device(pdev);
> > +}
>
> Does unmapping the memory here introduce a use-after-unmap issue when the
> MDIO bus is unregistered?
>
> The driver registers the MDIO bus using devm_of_mdiobus_register(), meaning
> devres cleans it up asynchronously after the remove function returns or when
> probe fails.
>
> However, in netc_switch_pci_destroy(), the driver explicitly unmaps the PCI
> I/O memory via iounmap(). Since netc_switch_pci_destroy() is called
> synchronously inside the remove function and probe error paths, the memory is
> unmapped before the MDIO bus is unregistered by devres.
>
> When devres eventually unregisters the MDIO bus, it detaches PHY devices,
> which often perform MDIO transactions during removal. Because the
> underlying
> memory priv->regs.base is already unmapped, these MDIO read/write callbacks
> could trigger a synchronous external abort or kernel panic.
>
> Would it be better to use pcim_iomap() to tie the memory mapping lifecycle to
> devres, ensuring it outlives the MDIO bus?
Great, I will pcim_iomap().
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: aspeed: anacapa: add EVT1 devicetree and point wrapper to it
From: Colin Huang @ 2026-04-08 8:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, colin.huang2
In-Reply-To: <20260408-glorious-vehement-robin-b6def3@quoll>
Hi Krzysztof,
Thanks for reply.
Could you let me know what kind test I need to run?
Following is what I do before send.
* I build this dts with linux 6.6.x
* run "b4 prep --check"
BR,
Colin Huang
Krzysztof Kozlowski <krzk@kernel.org> 於 2026年4月8日週三 下午3:52寫道：
>
> On Tue, Apr 07, 2026 at 09:54:33PM +0800, Colin Huang wrote:
> > This change introduces a development-phase devicetree for the
> > Facebook Anacapa BMC EVT1 hardware revision and updates the Anacapa
> > wrapper DTS to reference it.
> >
> > A dedicated EVT1 DTS is added for revision-specific hardware while
> > keeping a single, Anacapa entrypoint used by the build and deployment
> > flow. The top-level aspeed-bmc-facebook-anacapa.dts
> >
> > Signed-off-by: Colin Huang <u8813345@gmail.com>
> > ---
> > .../aspeed/aspeed-bmc-facebook-anacapa-evt1.dts | 1069 ++++++++++++++++++++
> > .../dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 1064 +------------------
> > 2 files changed, 1070 insertions(+), 1063 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts
> > new file mode 100644
> > index 000000000000..a29b7fa1155b
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts
> > @@ -0,0 +1,1069 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +
> > +/dts-v1/;
> > +#include "aspeed-g6.dtsi"
> > +#include <dt-bindings/gpio/aspeed-gpio.h>
> > +#include <dt-bindings/i2c/i2c.h>
> > +
> > +/ {
> > + model = "Facebook Anacapa BMC";
> > + compatible = "facebook,anacapa-bmc-evt1",
> > + "facebook,anacapa-bmc",
> > + "aspeed,ast2600";
>
> Test your DTS before you send, not after. Your binding clearly said
> something else.
>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 3/4] perf arm_spe: Decode Arm N1 IMPDEF events
From: James Clark @ 2026-04-08 8:47 UTC (permalink / raw)
To: Ian Rogers
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Adrian Hunter, Al Grant,
linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <CAP-5=fXNb50wXT3YH0i=-U8bXwizzH4bv8EL8mC9BMQE0Anp9Q@mail.gmail.com>
On 07/04/2026 7:26 pm, Ian Rogers wrote:
> On Tue, Apr 7, 2026 at 5:35 AM James Clark <james.clark@linaro.org> wrote:
>>
>>
>>
>> On 02/04/2026 4:26 pm, Ian Rogers wrote:
>>> On Wed, Apr 1, 2026 at 7:26 AM James Clark <james.clark@linaro.org> wrote:
>>>>
>>>> From the TRM [1], N1 has one IMPDEF event which isn't covered by the
>>>> common list. Add a framework so that more cores can be added in the
>>>> future and that the N1 IMPDEF event can be decoded. Also increase the
>>>> size of the buffer because we're adding more strings and if it gets
>>>> truncated it falls back to a hex dump only.
>>>>
>>>> [1]: https://developer.arm.com/documentation/100616/0401/Statistical-Profiling-Extension/implementation-defined-features-of-SPE
>>>> Suggested-by: Al Grant <al.grant@arm.com>
>>>> Signed-off-by: James Clark <james.clark@linaro.org>
>>>> ---
>>>> tools/perf/util/arm-spe-decoder/Build | 2 +
>>>> .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 45 ++++++++++++++++++++--
>>>> .../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 ++-
>>>> tools/perf/util/arm-spe.c | 13 ++++---
>>>> 4 files changed, 54 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/tools/perf/util/arm-spe-decoder/Build b/tools/perf/util/arm-spe-decoder/Build
>>>> index ab500e0efe24..97a298d1e279 100644
>>>> --- a/tools/perf/util/arm-spe-decoder/Build
>>>> +++ b/tools/perf/util/arm-spe-decoder/Build
>>>> @@ -1 +1,3 @@
>>>> perf-util-y += arm-spe-pkt-decoder.o arm-spe-decoder.o
>>>> +
>>>> +CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/ -I$(OUTPUT)arch/arm64/include/generated/
>>>> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
>>>> index c880b0dec3a1..42a7501d4dfe 100644
>>>> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
>>>> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
>>>> @@ -15,6 +15,8 @@
>>>>
>>>> #include "arm-spe-pkt-decoder.h"
>>>>
>>>> +#include "../../arm64/include/asm/cputype.h"
>>>
>>> Sashiko spotted:
>>> https://sashiko.dev/#/patchset/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c%40linaro.org
>>> """
>>> This isn't a bug, but does this include directive rely on accidental
>>> path normalization?
>>>
>>> The relative path ../../arm64/include/asm/cputype.h does not exist relative
>>> to arm-spe-pkt-decoder.c. It only compiles because the Build file adds
>>> -I$(srctree)/tools/arch/arm64/include/ to CFLAGS.
>>>
>>> Would it be cleaner to use #include <asm/cputype.h> to explicitly rely on
>>> the include path?
>>> [ ... ]
>>> """
>>> I wouldn't use <asm/cputype.h> due to cross-compilation and the like,
>>> instead just add the extra "../" into the include path.
>>>
>>
>> Do you mean change the #include to this?
>>
>> #include "../../../arm64/include/asm/cputype.h"
>>
>> I still need to add:
>>
>> CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/
>>
>> To make the this include in cputype.h work:
>>
>> #include <asm/sysreg.h>
>>
>> Which probably only works because there isn't a sysreg.h on other
>> architectures. But I'm not sure what the significance of ../../ vs
>> ../../../ is if either compile? arm-spe.c already does it with ../../
>> which is what I copied.
>
> Hmm.. maybe the path should be
> "../../../arch/arm64/include/asm/cputype.h". The include preference is
> for a path relative to the source file and
> ../../arm64/include/asm/cputype.h doesn't exist. It is kind of horrid
Up 3 dirs from arm-spe-pkt-decoder.c would be
"tools/arm64/include/asm/cputype.h" which doesn't exist either unless
I'm missing something?
If get the compiler to print the path it uses with 3 then it would use
the x86 uapi include path which doesn't seem any less weird to me:
...
In file included from util/arm-spe-decoder/arm-spe-pkt-decoder.c:19:
linux/tools/arch/x86/include/uapi/../../../arm64/include/asm/cputype.h:254:10:
> to add an include path and then use a relative path to escape into a
> higher-level directory. arm-spe.c is a little different as it is one
> directory higher in the directory layout.
>
It is one folder higher, but arm-spe.c still relies on adding a special
include path to CFLAGS_arm-spe.o to make it work. It's not including a
real path relative to the source either.
Yeah it's a bit horrible but I don't think the asm/ thing combined with
copying headers from the kernel to tools expected to handle the case
where we would want to use asm/ stuff for a different arch than the
compile one. It might not be normal to use relative include paths to
escape to higher directories, but it's not a normal situation either. I
think it's a special case for a special scenario. I'm not sure of a
better way, but this is working for now.
> Thanks,
> Ian
>
>>>> +
>>>> static const char * const arm_spe_packet_name[] = {
>>>> [ARM_SPE_PAD] = "PAD",
>>>> [ARM_SPE_END] = "END",
>>>> @@ -307,6 +309,11 @@ static const struct ev_string common_ev_strings[] = {
>>>> { .event = 0, .desc = NULL },
>>>> };
>>>>
>>>> +static const struct ev_string n1_event_strings[] = {
>>>> + { .event = 12, .desc = "LATE-PREFETCH" },
>>>> + { .event = 0, .desc = NULL },
>>>> +};
>>>> +
>>>> static u64 print_event_list(int *err, char **buf, size_t *buf_len,
>>>> const struct ev_string *ev_strings, u64 payload)
>>>> {
>>>> @@ -318,14 +325,44 @@ static u64 print_event_list(int *err, char **buf, size_t *buf_len,
>>>> return payload;
>>>> }
>>>>
>>>> +struct event_print_handle {
>>>> + const struct midr_range *midr_ranges;
>>>> + const struct ev_string *ev_strings;
>>>> +};
>>>> +
>>>> +#define EV_PRINT(range, strings) \
>>>> + { \
>>>> + .midr_ranges = range, \
>>>> + .ev_strings = strings, \
>>>> + }
>>>> +
>>>> +static const struct midr_range n1_event_encoding_cpus[] = {
>>>> + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
>>>> + {},
>>>> +};
>>>> +
>>>> +static const struct event_print_handle event_print_handles[] = {
>>>> + EV_PRINT(n1_event_encoding_cpus, n1_event_strings),
>>>> +};
>>>> +
>>>> static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
>>>> - char *buf, size_t buf_len)
>>>> + char *buf, size_t buf_len, u64 midr)
>>>> {
>>>> u64 payload = packet->payload;
>>>> int err = 0;
>>>>
>>>> arm_spe_pkt_out_string(&err, &buf, &buf_len, "EV");
>>>> - print_event_list(&err, &buf, &buf_len, common_ev_strings, payload);
>>>> + payload = print_event_list(&err, &buf, &buf_len, common_ev_strings,
>>>> + payload);
>>>> +
>>>> + /* Try to decode IMPDEF bits for known CPUs */
>>>> + for (unsigned int i = 0; i < ARRAY_SIZE(event_print_handles); i++) {
>>>> + if (is_midr_in_range_list(midr,
>>>> + event_print_handles[i].midr_ranges))
>>>> + payload = print_event_list(&err, &buf, &buf_len,
>>>> + event_print_handles[i].ev_strings,
>>>> + payload);
>>>> + }
>>>>
>>>> return err;
>>>> }
>>>> @@ -506,7 +543,7 @@ static int arm_spe_pkt_desc_counter(const struct arm_spe_pkt *packet,
>>>> }
>>>>
>>>> int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
>>>> - size_t buf_len)
>>>> + size_t buf_len, u64 midr)
>>>> {
>>>> int idx = packet->index;
>>>> unsigned long long payload = packet->payload;
>>>> @@ -522,7 +559,7 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
>>>> arm_spe_pkt_out_string(&err, &buf, &blen, "%s", name);
>>>> break;
>>>> case ARM_SPE_EVENTS:
>>>> - err = arm_spe_pkt_desc_event(packet, buf, buf_len);
>>>> + err = arm_spe_pkt_desc_event(packet, buf, buf_len, midr);
>>>> break;
>>>> case ARM_SPE_OP_TYPE:
>>>> err = arm_spe_pkt_desc_op_type(packet, buf, buf_len);
>>>> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
>>>> index adf4cde320aa..17b067fe3c87 100644
>>>> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
>>>> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
>>>> @@ -11,7 +11,7 @@
>>>> #include <stddef.h>
>>>> #include <stdint.h>
>>>>
>>>> -#define ARM_SPE_PKT_DESC_MAX 256
>>>> +#define ARM_SPE_PKT_DESC_MAX 512
>>>>
>>>> #define ARM_SPE_NEED_MORE_BYTES -1
>>>> #define ARM_SPE_BAD_PACKET -2
>>>> @@ -186,5 +186,6 @@ const char *arm_spe_pkt_name(enum arm_spe_pkt_type);
>>>> int arm_spe_get_packet(const unsigned char *buf, size_t len,
>>>> struct arm_spe_pkt *packet);
>>>>
>>>> -int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len);
>>>> +int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len,
>>>> + u64 midr);
>>>> #endif
>>>> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
>>>> index 7447b000f9cd..46f0309c092b 100644
>>>> --- a/tools/perf/util/arm-spe.c
>>>> +++ b/tools/perf/util/arm-spe.c
>>>> @@ -135,7 +135,7 @@ struct data_source_handle {
>>>> }
>>>>
>>>> static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
>>>> - unsigned char *buf, size_t len)
>>>> + unsigned char *buf, size_t len, u64 midr)
>>>> {
>>>> struct arm_spe_pkt packet;
>>>> size_t pos = 0;
>>>> @@ -161,7 +161,7 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
>>>> color_fprintf(stdout, color, " ");
>>>> if (ret > 0) {
>>>> ret = arm_spe_pkt_desc(&packet, desc,
>>>> - ARM_SPE_PKT_DESC_MAX);
>>>> + ARM_SPE_PKT_DESC_MAX, midr);
>>>> if (!ret)
>>>> color_fprintf(stdout, color, " %s\n", desc);
>>>> } else {
>>>> @@ -174,10 +174,10 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
>>>> }
>>>>
>>>> static void arm_spe_dump_event(struct arm_spe *spe, unsigned char *buf,
>>>> - size_t len)
>>>> + size_t len, u64 midr)
>>>> {
>>>> printf(".\n");
>>>> - arm_spe_dump(spe, buf, len);
>>>> + arm_spe_dump(spe, buf, len, midr);
>>>> }
>>>>
>>>> static int arm_spe_get_trace(struct arm_spe_buffer *b, void *data)
>>>> @@ -1469,8 +1469,11 @@ static int arm_spe_process_auxtrace_event(struct perf_session *session,
>>>> /* Dump here now we have copied a piped trace out of the pipe */
>>>> if (dump_trace) {
>>>> if (auxtrace_buffer__get_data(buffer, fd)) {
>>>> + u64 midr = 0;
>>>> +
>>>> + arm_spe__get_midr(spe, buffer->cpu.cpu, &midr);
>>>
>>> Sashiko claims to have spotted an issue here:
>>> """
>>> Is it possible for arm_spe__get_midr() to cause a segmentation fault here?
>>>
>>> If the trace is from an older recording (metadata version 1) and the
>>> environment lacks a CPUID string (such as during cross-architecture
>>> analysis), perf_env__cpuid() returns NULL.
>>>
>>> It appears arm_spe__get_midr() then passes this NULL pointer to
>>> strtol(cpuid, NULL, 16), which leads to undefined behavior.
>>> """
>>>
>>> But this feels like, if this happens you're already having a bad time
>>> and these changes aren't necessarily making things worse.
>>>
>>> Thanks,
>>> Ian
>>>
>>
>> Yeah I think it might be possible so I can add an error instead of a
>> segfault. I'll check the rest of the Sashiko comments too.
>>
>>>> arm_spe_dump_event(spe, buffer->data,
>>>> - buffer->size);
>>>> + buffer->size, midr);
>>>> auxtrace_buffer__put_data(buffer);
>>>> }
>>>> }
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>
^ permalink raw reply
* [PATCH] Subject: ASoC stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J
From: Tomasz Merta @ 2026-04-08 8:40 UTC (permalink / raw)
To: alsa-devel
Cc: olivier.moysan, arnaud.pouliquen, lgirdwood, broonie, perex,
tiwai, mcoquelin.stm32, alexandre.torgue, linux-stm32,
linux-arm-kernel, linux-kernel, Tomasz Merta, Tomasz Merta
From: Tomasz Merta <tomasz.merta@arrow.com>
The STM32 SAI driver do not set the clock strobing bit (CKSTR) for DSP_A,
DSP_B and LEFT_J formats, causing data to be sampled on the wrong BCLK
edge when SND_SOC_DAIFMT_NB_NF is used.
Per ALSA convention, NB_NF requires sampling on the rising BCLK edge.
The STM32MP25 SAI reference manual states that CKSTR=1 is required for
signals received by the SAI to be sampled on the SCK rising edge.
Without setting CKSTR=1, the SAI samples on the falling edge, violating
the NB_NF convention. For comparison, the NXP FSL SAI driver correctly
sets FSL_SAI_CR2_BCP for DSP_A, DSP_B and LEFT_J, consistent with its
I2S handling.
This patch adds SAI_XCR1_CKSTR for DSP_A, DSP_B and LEFT_J in
stm32_sai_set_dai_fmt which was verified empirically with a cs47l35 codec.
RIGHT_J (LSB) is not investigated and addressed by this patch.
Note: the STM32 I2S driver (stm32_i2s_set_dai_fmt) may have the same issue
for DSP_A mode, as I2S_CGFR_CKPOL is not set. This has not been verified
and is left for a separate investigation.
Signed-off-by: Tomasz Merta <tommerta@gmail.com>
---
sound/soc/stm/stm32_sai_sub.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/soc/stm/stm32_sai_sub.c b/sound/soc/stm/stm32_sai_sub.c
index 450e1585edee..3e82fa90e719 100644
--- a/sound/soc/stm/stm32_sai_sub.c
+++ b/sound/soc/stm/stm32_sai_sub.c
@@ -802,6 +802,7 @@ static int stm32_sai_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt)
break;
/* Left justified */
case SND_SOC_DAIFMT_MSB:
+ cr1 |= SAI_XCR1_CKSTR;
frcr |= SAI_XFRCR_FSPOL | SAI_XFRCR_FSDEF;
break;
/* Right justified */
@@ -809,9 +810,11 @@ static int stm32_sai_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt)
frcr |= SAI_XFRCR_FSPOL | SAI_XFRCR_FSDEF;
break;
case SND_SOC_DAIFMT_DSP_A:
+ cr1 |= SAI_XCR1_CKSTR;
frcr |= SAI_XFRCR_FSPOL | SAI_XFRCR_FSOFF;
break;
case SND_SOC_DAIFMT_DSP_B:
+ cr1 |= SAI_XCR1_CKSTR;
frcr |= SAI_XFRCR_FSPOL;
break;
default:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] iommu: Always fill in gather when unmapping
From: Jon Hunter @ 2026-04-08 8:42 UTC (permalink / raw)
To: Jason Gunthorpe, Robin Murphy
Cc: Alexandre Ghiti, AngeloGioacchino Del Regno, Albert Ou, asahi,
Baolin Wang, iommu, Janne Grunau, Jernej Skrabec, Joerg Roedel,
Jean-Philippe Brucker, linux-arm-kernel, linux-mediatek,
linux-riscv, linux-sunxi, Matthias Brugger, Neal Gompa,
Orson Zhai, Palmer Dabbelt, Paul Walmsley, Samuel Holland,
Sven Peter, virtualization, Chen-Yu Tsai, Will Deacon, Yong Wu,
Chunyan Zhang, Lu Baolu, Janusz Krzysztofik, Joerg Roedel,
patches, Samiullah Khawaja, stable, Vasant Hegde,
linux-tegra@vger.kernel.org
In-Reply-To: <20260402225121.GI310919@nvidia.com>
Hi Robin, Jason,
On 02/04/2026 23:51, Jason Gunthorpe wrote:
> On Thu, Apr 02, 2026 at 07:11:13PM +0100, Robin Murphy wrote:
>>>> @@ -2714,6 +2714,10 @@ static size_t __iommu_unmap(struct iommu_domain *domain,
>>>> pr_debug("unmapped: iova 0x%lx size 0x%zx\n",
>>>> iova, unmapped_page);
>>>> + /* If the driver itself isn't using the gather, mark it used */
>>>> + if (iotlb_gather->end <= iotlb_gather->start)
>>>> + iommu_iotlb_gather_add_range(&iotlb_gather, iova, unmapped_page);
>>>
>>> The gathers can be joined across unmaps and now we are inviting subtly
>>> ill-formed gathers as only the first unmap will get included.
>
>>> We do have error cases where the gather is legitimately empty, and
>>> this would squash that, it probably needs to check unmapped_page for 0
>>> too, at least.
>>
>> Maybe try looking at the rest of the code around these lines...
>
> Okay, well lets do this one, do you want to send it since it is your
> idea?
Any update on this? Boot is still broken on a couple of our boards.
Thanks
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 2/3] KVM: arm64: vgic: Allow userspace to set IIDR revision 1
From: Woodhouse, David @ 2026-04-08 8:39 UTC (permalink / raw)
To: maz@kernel.org
Cc: kvm@vger.kernel.org, shuah@kernel.org, yuzenghui@huawei.com,
joey.gouly@arm.com, linux-kernel@vger.kernel.org,
catalin.marinas@arm.com, nathan@kernel.org, pbonzini@redhat.com,
kvmarm@lists.linux.dev, arnd@arndb.de, kees@kernel.org,
will@kernel.org, suzuki.poulose@arm.com, oupton@kernel.org,
rananta@google.com, linux-arm-kernel@lists.infradead.org,
linux-kselftest@vger.kernel.org, eric.auger@redhat.com
In-Reply-To: <87wlyhc2g4.wl-maz@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2128 bytes --]
On Wed, 2026-04-08 at 08:54 +0100, Marc Zyngier wrote:
> On Tue, 07 Apr 2026 21:27:03 +0100,
> David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > From: David Woodhouse <dwmw@amazon.co.uk>
> >
> > Allow userspace to select GICD_IIDR revision 1, which restores the
> > original pre-d53c2c29ae0d ("KVM: arm/arm64: vgic: Allow configuration
> > of interrupt groups") behaviour where interrupt groups are not
> > guest-configurable.
>
> I'm a bit surprised by this.
>
> Either your guest knows that the group registers are not writable and
> already deals with the buggy behaviour by not configuring the groups
> (or configuring them in a way that matches what the implementation
> does). Or it configures them differently and totally fails to handle
> the interrupts as they are delivered using the wrong exception type,
> if at all.
>
> I'd expect that your guests fall in the former category and not the
> latter, as we'd be discussing a very different problem. And my vague
> recollection of this issue is that we had established that as long as
> the reset values were unchanged, there was no harm in letting things
> rip.
What if the guest boots under a new host kernel and finds the group
registers are writable, and then is live migrated to an old host kernel
on which they are not?
What about hibernation, if the *boot* kernel in the guest configures
the groups, but then transfers control back to the resumed guest kernel
which had not?
> So what is this *really* fixing?
I look at that question the other way round.
KVM has an established procedure for allowing userspace to control
guest-visible changes, using the IIDR. First the host kernel which
*supports* the change is rolled out, and only then does the VMM start
to enable it for new launches.
Even if we can address the questions above, and even if we can convince
ourselves that those are the *only* questions to ask... why not follow
the normal, safe, procedure? Especially given that there is already an
IIDR value which corresponds to it.
We don't *have* to YOLO it... and I don't want to :)
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5964 bytes --]
[-- Attachment #2.1: Type: text/plain, Size: 215 bytes --]
Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.
[-- Attachment #2.2: Type: text/html, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-08 8:40 UTC (permalink / raw)
To: Frank Li
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <adYRuAU5ueEKHK5l@lizhi-Precision-Tower-5810>
On Wed, Apr 08, 2026 at 04:28:40AM -0400, Frank Li wrote:
> On Wed, Apr 08, 2026 at 04:08:24PM +0800, Liu Ying wrote:
>> On Wed, Apr 08, 2026 at 03:58:59AM -0400, Frank Li wrote:
>>> On Wed, Apr 08, 2026 at 02:02:54PM +0800, Liu Ying wrote:
>>>> Hi Frank,
>>>>
>>>> On Tue, Apr 07, 2026 at 05:55:29AM -0400, Frank Li wrote:
>>>>> On Tue, Apr 07, 2026 at 05:15:31PM +0800, Liu Ying wrote:
>>>>>> Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB.
>>>>>>
>>>>>> The panel connects with the QSB board through an adapter board[1]
>>>>>> designed by NXP.
>>>>>>
>>>>>> Link: https://www.nxp.com/design/design-center/development-boards-and-designs/parallel-lcd-display:TM050RDH03-41 [1]
>>>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>>>>> ---
>>>>>> arch/arm64/boot/dts/freescale/Makefile | 2 +
>>>>>> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi | 110 +++++++++++++++++++++
>>>>>> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso | 106 +-------------------
>>>>>
>>>>> Can you add some description about raname in commit message?
>>>>
>>>> I'll add some description about the file copy in commit message.
>>>>
>>>>> Use -C option to create patch.
>>>>
>>>> Will do.
>>>>
>>>>>
>>>>> ...
>>>>>> diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
>>>>>> new file mode 100644
>>>>>> index 000000000000..c233797ec28c
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
>>>>>> @@ -0,0 +1,14 @@
>>>>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>>>>> +/*
>>>>>> + * Copyright 2026 NXP
>>>>>> + */
>>>>>> +
>>>>>> +#include <dt-bindings/gpio/gpio.h>
>>>>>> +#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
>>>>>> +
>>>>>> +&{/} {
>>>>>> + panel {
>>>>>> + compatible = "tianma,tm050rdh03";
>>>>>> + enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
>>>>>> + };
>>>>>> +};
>>>>>
>>>>> Is it possible to appply this overlay file and kd50g21-40nt-a1 overlay file
>>>>>
>>>>> to imx93-9x9-qsb.dtb, so needn't create dtsi.
>>>>
>>>> I'm sorry, I don't get your question here.
>>>> Anyway, the DT overlays are needed, because the 40-pin EXP/PRI interface on
>>>> the i.MX93 9x9 QSB board can not only connect to a DPI panel adapter board
>>>> but also to an audio hat[2], and maybe more. The newly introduced .dtsi
>>>> file just aims to avoid duplicated code.
>>>
>>> My means apply two overlay files to dtb
>>>
>>> imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo imx93-9x9-qsb-tianma-tm050rdh03.dtbo
This ...
>>>
>>> In imx93-9x9-qsb-tianma-tm050rdh03.dtbo, only include
>>> &{/} {
>>> panel {
>>> compatible = "tianma,tm050rdh03";
>>> enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
>>> };
>>> };
>>
>> If an user wants to use imx93-9x9-qsb.dtb and the DT overlay blob
>> imx93-9x9-qsb-tianma-tm050rdh03.dtbo to enable the tianma,tm050rdh03
>> DPI panel, then it won't work unless the user also apply
>> imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo, right?
>>
>>>
>
> Yes, imx93-9x9-qsb-tianma-tm050rdh03.dtb already created, which already
> applied both overlay file.
.... indicates that imx93-9x9-qsb-tianma-tm050rdh03.dtb is generated by
applying both imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo and
imx93-9x9-qsb-tianma-tm050rdh03.dtbo to imx93-9x9-qsb.dtb.
While, imx93-9x9-qsb-tianma-tm050rdh03.dtbo(a DT overlay blob) just contains
the panel node, which means that an user __cannot_ enable the tianma,tm050rdh03
DPI panel by only applying it to imx93-9x9-qsb.dtb, unless the user also
applies imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo. That's why the .dtsi
file is needed.
>
> can the same board be use for imx91 or other evk boards?
Yes, both tianma,tm050rdh03 and ontat,kd50g21-40nt-a1 DPI panels can be
connected to i.MX91/93 11x11 EVK and 9x9 QSB boards.
>
> Frank
>
>>> Frank
>>>>
>>>> [2] https://www.nxp.com/design/design-center/development-boards-and-designs/mx93aud-hat-audio-board:MX93AUD-HAT
>>>>
>>>>>
>>>>> Frank
>>>>>>
>>>>>> ---
>>>>>> base-commit: 816f193dd0d95246f208590924dd962b192def78
>>>>>> change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
>>>>>>
>>>>>> Best regards,
>>>>>> --
>>>>>> Liu Ying <victor.liu@nxp.com>
>>>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Liu Ying
>>
>> --
>> Regards,
>> Liu Ying
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v3] tpm: i2c: atmel: fix block comment formatting
From: Jarkko Sakkinen @ 2026-04-08 8:38 UTC (permalink / raw)
To: Ethan Luna
Cc: peterhuewe, jgg, nicolas.ferre, claudiu.beznea, linux-integrity,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260324154354.6268-1-trunixcodes@zohomail.com>
On Tue, Mar 24, 2026 at 08:39:49AM -0700, Ethan Luna wrote:
> Multiple block comments in tpm_i2c_atmel.c placed the closing '*/' on the
> same line as the comment text. This violates the kernel's preferred
> comment style, which requires the closing delimiter to appear on its
> line.
>
> Fix the formatting to improve readability and resolve checkpatch
> warnings.
>
> Signed-off-by: Ethan Luna <trunixcodes@zohomail.com>
> ---
>
> V1 -> V2: Fixed block comment formatting consistently across all multi-line comments
> V2 -> V3: Fixed trailing whitespaces consistently across all multi-line comments
>
> v1: https://lore.kernel.org/all/20260322193112.27010-1-trunixcodes@zohomail.com/
> v2: https://lore.kernel.org/all/20260323134200.7766-1-trunixcodes@zohomail.com/
>
> drivers/char/tpm/tpm_i2c_atmel.c | 34 +++++++++++++++++++++-----------
> 1 file changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
> index 4f229656a8e2..9fd73049821f 100644
> --- a/drivers/char/tpm/tpm_i2c_atmel.c
> +++ b/drivers/char/tpm/tpm_i2c_atmel.c
> @@ -31,9 +31,11 @@
>
> struct priv_data {
> size_t len;
> - /* This is the amount we read on the first try. 25 was chosen to fit a
> + /*
> + * This is the amount we read on the first try. 25 was chosen to fit a
> * fair number of read responses in the buffer so a 2nd retry can be
> - * avoided in small message cases. */
> + * avoided in small message cases.
> + */
> u8 buffer[sizeof(struct tpm_header) + 25];
> };
>
> @@ -58,7 +60,9 @@ static int i2c_atmel_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
> if (status < 0)
> return status;
>
> - /* The upper layer does not support incomplete sends. */
> + /*
> + * The upper layer does not support incomplete sends.
> + */
> if (status != len)
> return -E2BIG;
>
> @@ -76,9 +80,11 @@ static int i2c_atmel_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> if (priv->len == 0)
> return -EIO;
>
> - /* Get the message size from the message header, if we didn't get the
> + /*
> + * Get the message size from the message header, if we didn't get the
> * whole message in read_status then we need to re-read the
> - * message. */
> + * message.
> + */
> expected_len = be32_to_cpu(hdr->length);
> if (expected_len > count)
> return -ENOMEM;
> @@ -111,15 +117,19 @@ static u8 i2c_atmel_read_status(struct tpm_chip *chip)
> struct i2c_client *client = to_i2c_client(chip->dev.parent);
> int rc;
>
> - /* The TPM fails the I2C read until it is ready, so we do the entire
> + /*
> + * The TPM fails the I2C read until it is ready, so we do the entire
> * transfer here and buffer it locally. This way the common code can
> - * properly handle the timeouts. */
> + * properly handle the timeouts.
> + */
> priv->len = 0;
> memset(priv->buffer, 0, sizeof(priv->buffer));
>
>
> - /* Once the TPM has completed the command the command remains readable
> - * until another command is issued. */
> + /*
> + * Once the TPM has completed the command the command remains readable
> + * until another command is issued.
> + */
> rc = i2c_master_recv(client, priv->buffer, sizeof(priv->buffer));
> dev_dbg(&chip->dev,
> "%s: sts=%d", __func__, rc);
> @@ -172,9 +182,11 @@ static int i2c_atmel_probe(struct i2c_client *client)
>
> dev_set_drvdata(&chip->dev, priv);
>
> - /* There is no known way to probe for this device, and all version
> + /*
> + * There is no known way to probe for this device, and all version
> * information seems to be read via TPM commands. Thus we rely on the
> - * TPM startup process in the common code to detect the device. */
> + * TPM startup process in the common code to detect the device.
> + */
>
> return tpm_chip_register(chip);
> }
> --
> 2.53.0
>
Thank you.
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Applied.
BR, Jarkko
^ permalink raw reply
* RE: [PATCH v4 net-next 09/14] net: dsa: add NETC switch tag support
From: Wei Fang @ 2026-04-08 8:35 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011736.1795610-1-kuba@kernel.org>
> > diff --git a/net/dsa/tag_netc.c b/net/dsa/tag_netc.c
> > new file mode 100644
> > index 000000000000..addd41f7f1b6
> > --- /dev/null
> > +++ b/net/dsa/tag_netc.c
> [ ... ]
> > +static void *netc_fill_common_tp_tag(struct sk_buff *skb,
> > + struct net_device *ndev,
> > + u8 subtype, int tag_len)
> > +{
> > + struct dsa_port *dp = dsa_user_to_port(ndev);
> > + u16 queue = skb_get_queue_mapping(skb);
> > + u8 ipv = netdev_txq_to_tc(ndev, queue);
>
> What happens here if the interface doesn't have traffic classes configured?
netdev_txq_to_tc() will return 0 if not TC configured, I mean ndev->num_tc is
0.
>
> By default, netdev_txq_to_tc() returns -1. Because ipv is an unsigned 8-bit
> integer, this casts to 255.
Okay, this is a potential bug when we add TC_SETUP_QDISC_MQPRIO
support. I will fix it.
>
> When this is later passed to FIELD_PREP(NETC_TAG_IPV, ipv) in
> netc_fill_common_tag(), the macro blindly masks the variable, silently
> forcing the IPV field to 7 (the maximum priority) for all default,
> unconfigured traffic. Valid TC values greater than 7 would also be silently
> truncated.
>
> Does this code bypass the intended QoS mechanisms?
No, configure IPV to send packets according to the expected TC.
>
> > + void *tag;
> > +
> > + skb_push(skb, tag_len);
> > + dsa_alloc_etype_header(skb, tag_len);
> > +
> > + tag = dsa_etype_header_pos_tx(skb);
> > + memset(tag + NETC_TAG_CMN_LEN, 0, tag_len - NETC_TAG_CMN_LEN);
> > + netc_fill_common_tag(tag, NETC_TAG_TO_PORT, subtype,
> > + dp->ds->index, dp->index, ipv);
>
> Will this break communication for standard single-switch setups?
>
> The driver passes dp->ds->index as the hardware switch ID here, which
> defaults to 0 for the first switch in a DSA tree. However, on the receive
> path, frames stamped with switch ID 0 are rejected.
>
> If the physical switch hardware uses an ID greater than 0, frames will fail
> the lookup in dsa_conduit_find_user() on receive because the software index
> is 0.
We added the 'dsa,member' property to the netc switch DT-binding doc, specifying
that the 'member' (switch index) value cannot be 0. Furthermore, the netc switch
driver also checks the switch index to ensure it is not 0. Therefore, the software index
and hardware index are equal.
>
> > +
> > + return tag;
> > +}
> [ ... ]
> > +static struct sk_buff *netc_rcv(struct sk_buff *skb,
> > + struct net_device *ndev)
> > +{
> > + struct netc_tag_cmn *tag_cmn;
> > + int tag_len, sw_id, port;
> [ ... ]
> > + if (tag_cmn->qos & NETC_TAG_QV)
> > + skb->priority = FIELD_GET(NETC_TAG_IPV, tag_cmn->qos);
> > +
> > + sw_id = NETC_TAG_SWITCH & tag_cmn->switch_port;
>
> This isn't a bug, but is there a reason to use a raw bitwise AND for sw_id
> instead of using FIELD_GET(NETC_TAG_SWITCH, ...) to match how the port
> field is extracted just below this?
I think either is fine, the final result is the same. I just wrote it this way for
convenience during implementation.
^ permalink raw reply
* RE: [PATCH V11 04/12] PCI: imx6: Add support for parsing the reset property in new Root Port binding
From: Sherry Sun @ 2026-04-08 8:34 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <7ewnbwdo5qtasbxj4uel6a6uthczq2l6udbvoqqkwm776lvseb@v54ri2gknwxn>
> On Tue, Apr 07, 2026 at 06:41:46PM +0800, Sherry Sun wrote:
> > The current DT binding for pci-imx6 specifies the 'reset-gpios'
> > property in the host bridge node. However, the PERST# signal logically
> > belongs to individual Root Ports rather than the host bridge itself.
> > This becomes important when supporting PCIe KeyE connector and PCI
> > power control framework for pci-imx6 driver, which requires properties
> > to be specified in Root Port nodes.
> >
> > Add support for parsing 'reset-gpios' from Root Port child nodes using
> > the common helper pci_host_common_parse_ports(), and update the reset
> > GPIO handling to use the parsed port list from bridge->ports. To
> > maintain DT backwards compatibility, fallback to the legacy method of
> > parsing the host bridge node if the reset property is not present in
> > the Root Port node.
> >
> > Since now the reset GPIO is obtained with GPIOD_ASIS flag, it may be
> > in input mode, using gpiod_direction_output() instead of
> > gpiod_set_value_cansleep() to ensure the reset GPIO is properly
> > configured as output before setting its value.
> >
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/dwc/pci-imx6.c | 75
> > +++++++++++++++++++++------
> > 1 file changed, 60 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index d99da7e42590..dd8f9c0fcec4 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -34,6 +34,7 @@
> > #include <linux/pm_runtime.h>
> >
> > #include "../../pci.h"
> > +#include "../pci-host-common.h"
> > #include "pcie-designware.h"
> >
> > #define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
> > @@ -152,7 +153,6 @@ struct imx_lut_data {
> >
> > struct imx_pcie {
> > struct dw_pcie *pci;
> > - struct gpio_desc *reset_gpiod;
> > struct clk_bulk_data *clks;
> > int num_clks;
> > bool supports_clkreq;
> > @@ -1224,6 +1224,32 @@ static void imx_pcie_disable_device(struct
> pci_host_bridge *bridge,
> > imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev)); }
> >
> > +static int imx_pcie_parse_legacy_binding(struct imx_pcie *pcie) {
> > + struct device *dev = pcie->pci->dev;
> > + struct pci_host_bridge *bridge = pcie->pci->pp.bridge;
> > + struct pci_host_port *port;
> > + struct gpio_desc *reset;
> > +
> > + reset = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
> > + if (IS_ERR(reset))
> > + return PTR_ERR(reset);
> > +
> > + if (!reset)
> > + return 0;
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + port->reset = reset;
> > + INIT_LIST_HEAD(&port->list);
> > + list_add_tail(&port->list, &bridge->ports);
> > +
> > + return devm_add_action_or_reset(dev,
> pci_host_common_delete_ports,
> > + &bridge->ports);
> > +}
> > +
> > static void imx_pcie_vpcie_aux_disable(void *data) {
> > struct regulator *vpcie_aux = data;
> > @@ -1233,13 +1259,22 @@ static void imx_pcie_vpcie_aux_disable(void
> > *data)
> >
> > static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool
> > assert) {
> > - if (assert) {
> > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 1);
> > - } else {
> > - if (imx_pcie->reset_gpiod) {
> > - msleep(PCIE_T_PVPERL_MS);
> > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 0);
> > - msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > + struct dw_pcie *pci = imx_pcie->pci;
> > + struct pci_host_bridge *bridge = pci->pp.bridge;
> > + struct pci_host_port *port;
> > +
> > + if (!bridge)
> > + return;
> > +
> > + list_for_each_entry(port, &bridge->ports, list) {
> > + if (assert) {
> > + gpiod_direction_output(port->reset, 1);
> > + } else {
> > + if (port->reset) {
> > + msleep(PCIE_T_PVPERL_MS);
> > + gpiod_direction_output(port->reset, 0);
> > + msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > + }
>
> Sashiko flagged this loop:
>
> ```
> Does this loop multiply the initialization delays?
> If a controller has multiple Root Ports, the msleep calls will run sequentially
> for each port, linearly increasing the delay. Could we optimize this by
> asserting all reset GPIOs, waiting the pre-delay once, de-asserting all GPIOs,
> and waiting the post-delay once for the entire bus?
> ```
>
> Maybe you should do:
>
> if (!list_empty(&bridge->ports) && !assert)
> msleep(PCIE_T_PVPERL_MS);
>
> list_for_each_entry(port, &bridge->ports, list) {
> ...
> gpiod_direction_output(port->reset, 0);
> ...
> }
>
> if (!list_empty(&bridge->ports) && !assert)
> msleep(PCIE_RESET_CONFIG_WAIT_MS);
>
Hi Mani, I think the code below looks clearer, is that ok for you?
if (assert) {
list_for_each_entry(port, &bridge->ports, list)
gpiod_direction_output(port->reset, 1);
} else {
if (list_empty(&bridge->ports))
return;
msleep(PCIE_T_PVPERL_MS);
list_for_each_entry(port, &bridge->ports, list)
gpiod_direction_output(port->reset, 0);
msleep(PCIE_RESET_CONFIG_WAIT_MS);
}
> And then this:
>
> ```
> Also, since this function is called from imx_pcie_resume_noirq, which
> executes with hardware interrupts disabled, does the use of msleep here
> trigger a 'sleeping while atomic' bug?
> ```
>
> This is a valid concern. You should use mdelay(). But I'd recommend switching
> to IRQ enabled callback, resume() instead. There is no complelling reason to
> use resume_noirq() in this driver and adding delays in noirq() callbacks is not
> recommended as it may increase the overall system resume time.
>
> I will submit a separate series to convert dw_pcie_resume_noirq() and its
> callers to IRQ enabled callbacks since this dw_pcie_resume_noirq() could
> potentially cause delay up to 1sec.
Yes, this is not a new bug introduced by this patch. I agree we should covert the
convert dw_pcie_resume_noirq() and the caller to IRQ enabled callbacks to fix
this in a separate patch series.
For now, should I leave it as is, or switch to mdelay in this patch?
>
> > }
> > }
> > }
> > @@ -1249,8 +1284,25 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > struct device *dev = pci->dev;
> > struct imx_pcie *imx_pcie = to_imx_pcie(pci);
> > + struct pci_host_bridge *bridge = pp->bridge;
> > int ret;
> >
> > + if (bridge && list_empty(&bridge->ports)) {
> > + /* Parse Root Port nodes if present */
> > + ret = pci_host_common_parse_ports(dev, bridge);
> > + if (ret) {
> > + if (ret != -ENOENT) {
> > + dev_err(dev, "Failed to parse Root Port
> nodes: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + /* Fallback to legacy binding for DT backwards
> compatibility */
> > + ret = imx_pcie_parse_legacy_binding(imx_pcie);
>
> This is also flagged by Sashiko:
>
> ```
> Could this error handling corrupt the port state and trigger an invalid legacy
> fallback?
>
> If a device tree defines multiple Root Ports and one lacks the optional reset
> GPIO, pci_host_common_parse_ports returns -ENOENT. This causes the code
> to fall back to imx_pcie_parse_legacy_binding.
>
> Since the already-parsed child ports remain in bridge->ports without rollback,
> the legacy host bridge GPIO will be appended alongside them.
> Valid child nodes are skipped, and both child and legacy GPIOs will be toggled
> simultaneously.
> ```
>
> You should try to cleanup Root Port resources if
> pci_host_common_parse_ports() fails with -ENOENT.
Sure, I will call pci_host_common_delete_ports() to clean up any partially parsed
Root Port resources before falling back to legacy binding.
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Frank Li @ 2026-04-08 8:28 UTC (permalink / raw)
To: Liu Ying
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <f5cd5da8-566d-4dff-b712-3d48927f97eb@nxp.com>
On Wed, Apr 08, 2026 at 04:08:24PM +0800, Liu Ying wrote:
> On Wed, Apr 08, 2026 at 03:58:59AM -0400, Frank Li wrote:
> > On Wed, Apr 08, 2026 at 02:02:54PM +0800, Liu Ying wrote:
> >> Hi Frank,
> >>
> >> On Tue, Apr 07, 2026 at 05:55:29AM -0400, Frank Li wrote:
> >>> On Tue, Apr 07, 2026 at 05:15:31PM +0800, Liu Ying wrote:
> >>>> Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB.
> >>>>
> >>>> The panel connects with the QSB board through an adapter board[1]
> >>>> designed by NXP.
> >>>>
> >>>> Link: https://www.nxp.com/design/design-center/development-boards-and-designs/parallel-lcd-display:TM050RDH03-41 [1]
> >>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >>>> ---
> >>>> arch/arm64/boot/dts/freescale/Makefile | 2 +
> >>>> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi | 110 +++++++++++++++++++++
> >>>> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso | 106 +-------------------
> >>>
> >>> Can you add some description about raname in commit message?
> >>
> >> I'll add some description about the file copy in commit message.
> >>
> >>> Use -C option to create patch.
> >>
> >> Will do.
> >>
> >>>
> >>> ...
> >>>> diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
> >>>> new file mode 100644
> >>>> index 000000000000..c233797ec28c
> >>>> --- /dev/null
> >>>> +++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
> >>>> @@ -0,0 +1,14 @@
> >>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >>>> +/*
> >>>> + * Copyright 2026 NXP
> >>>> + */
> >>>> +
> >>>> +#include <dt-bindings/gpio/gpio.h>
> >>>> +#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
> >>>> +
> >>>> +&{/} {
> >>>> + panel {
> >>>> + compatible = "tianma,tm050rdh03";
> >>>> + enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
> >>>> + };
> >>>> +};
> >>>
> >>> Is it possible to appply this overlay file and kd50g21-40nt-a1 overlay file
> >>>
> >>> to imx93-9x9-qsb.dtb, so needn't create dtsi.
> >>
> >> I'm sorry, I don't get your question here.
> >> Anyway, the DT overlays are needed, because the 40-pin EXP/PRI interface on
> >> the i.MX93 9x9 QSB board can not only connect to a DPI panel adapter board
> >> but also to an audio hat[2], and maybe more. The newly introduced .dtsi
> >> file just aims to avoid duplicated code.
> >
> > My means apply two overlay files to dtb
> >
> > imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo imx93-9x9-qsb-tianma-tm050rdh03.dtbo
> >
> > In imx93-9x9-qsb-tianma-tm050rdh03.dtbo, only include
> > &{/} {
> > panel {
> > compatible = "tianma,tm050rdh03";
> > enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
> > };
> > };
>
> If an user wants to use imx93-9x9-qsb.dtb and the DT overlay blob
> imx93-9x9-qsb-tianma-tm050rdh03.dtbo to enable the tianma,tm050rdh03
> DPI panel, then it won't work unless the user also apply
> imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo, right?
>
> >
Yes, imx93-9x9-qsb-tianma-tm050rdh03.dtb already created, which already
applied both overlay file.
can the same board be use for imx91 or other evk boards?
Frank
> > Frank
> >>
> >> [2] https://www.nxp.com/design/design-center/development-boards-and-designs/mx93aud-hat-audio-board:MX93AUD-HAT
> >>
> >>>
> >>> Frank
> >>>>
> >>>> ---
> >>>> base-commit: 816f193dd0d95246f208590924dd962b192def78
> >>>> change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
> >>>>
> >>>> Best regards,
> >>>> --
> >>>> Liu Ying <victor.liu@nxp.com>
> >>>>
> >>
> >> --
> >> Regards,
> >> Liu Ying
>
> --
> Regards,
> Liu Ying
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] Add the missing mpll3 clock and clock controller nodes
From: Jerome Brunet @ 2026-04-08 8:20 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Martin Blumenstingl, Stephen Boyd,
Michael Turquette, robh+dt, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jian Hu
Cc: devicetree, linux-clk, linux-amlogic, linux-kernel,
linux-arm-kernel, Ronald Claveau, Ferass El Hafidi
In-Reply-To: <20260326092645.1053261-1-jian.hu@amlogic.com>
Applied to clk-meson (clk-meson-next), thanks!
[1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
https://github.com/BayLibre/clk-meson/commit/6d6be1cca2c9
[2/3] dt-bindings: clock: amlogic: t7: Add missing mpll3 parent clock
https://github.com/BayLibre/clk-meson/commit/87edca62c4f5
Best regards,
--
Jerome
^ permalink raw reply
* [PATCH] firmware: raspberrypi: Change dependency to ARCH_BCM2835 and COMPILE_TEST
From: Chen-Yu Tsai @ 2026-04-08 8:11 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list
Cc: Chen-Yu Tsai, linux-rpi-kernel, linux-arm-kernel, linux-kernel
The Raspberry Pi firmware driver has no compile dependencies on the
BCM2835 mailbox driver. It's just a indirect runtime dependency: the
driver only works on a Raspberry Pi.
Change the dependency from BCM2835_MBOX to ARCH_BCM2835. Also allow
compile tests. This allows drivers that have build time dependencies
on this firmware driver to be compile tested as well.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/firmware/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index bbd2155d8483..f99d27c1f6a4 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -114,7 +114,7 @@ config ISCSI_IBFT
config RASPBERRYPI_FIRMWARE
tristate "Raspberry Pi Firmware Driver"
- depends on BCM2835_MBOX
+ depends on ARCH_BCM2835 || COMPILE_TEST
help
This option enables support for communicating with the firmware on the
Raspberry Pi.
--
2.53.0.1213.gd9a14994de-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