* cleanup the RAID6 P/Q library v3
From: Christoph Hellwig @ 2026-05-18 5:12 UTC (permalink / raw)
To: Andrew Morton
Cc: Catalin Marinas, Will Deacon, Ard Biesheuvel, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Herbert Xu, Dan Williams,
Chris Mason, David Sterba, Arnd Bergmann, Song Liu, Yu Kuai,
Li Nan, linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
Hi all,
this series cleans up the RAID6 P/Q library to match the recent updates
to the RAID 5 XOR library and other CRC/crypto libraries. This includes
providing properly documented external interfaces, hiding the internals,
using static_call instead of indirect calls and turning the user space
test suite into an in-kernel kunit test which is also extended to
improve coverage.
Note that this changes registration so that non-priority algorithms are
not registered, which greatly helps with the benchmark time at boot time.
I'd like to encourage all architecture maintainers to see if they can
further optimized this by registering as few as possible algorithms when
there is a clear benefit in optimized or more unrolled implementations.
This series sits on top of the "cleanup the RAID5 XOR library v3" series.
A git tree is also available here:
git://git.infradead.org/users/hch/misc.git lib-raid6
Gitweb:
https://git.infradead.org/?p=users/hch/misc.git;a=shortlog;h=refs/heads/lib-raid6
Changes since v2:
- merge two patches that should have been one
- split out enforcing the 4-device minimum into a well-documented patch
explaining the rationale
- drop the btrfs patch to restrict the number of devices again
- fix them module description for the kunit test
- add -I $(src) to fix out of srctree builds for architectures with
headers in the architecture-specific directories
- always add the least optimized/unrolled algorithms first to keep the
existing no-benchmark behavior
- drop the delayed benchmarking for now to avoid corner cases
- improve a few commit messages
Changes since v1:
- fix arm64 objdir != srcdir builds
- call the kunit module raid6_kunit.ko from the beginning
- update MAINTAINERS
- don't require preemptible context and apply the same restrictions as
the merged version of the XOR API
- fix the arm64 default in Kconfig
- pick the last registered (and presumably most optimized) algorithm when
benchmarking is disabled
- port over the randomization fixes from the XOR series
- misc other kunit cleanups
- require at least 4 devices for RAID6 to skip broken special cases
Diffstat:
b/Documentation/crypto/async-tx-api.rst | 4
b/MAINTAINERS | 2
b/crypto/async_tx/async_pq.c | 9
b/crypto/async_tx/async_raid6_recov.c | 9
b/drivers/dma/bcm-sba-raid.c | 1
b/drivers/md/raid5.c | 4
b/fs/btrfs/raid56.c | 8
b/include/linux/raid/pq.h | 216 ------------
b/include/linux/raid/pq_tables.h | 19 +
b/lib/Kconfig | 11
b/lib/Makefile | 1
b/lib/raid/Kconfig | 33 +
b/lib/raid/Makefile | 2
b/lib/raid/raid6/Makefile | 128 +++++++
b/lib/raid/raid6/algos.c | 377 ++++++++++++++++++++++
b/lib/raid/raid6/algos.h | 41 ++
b/lib/raid/raid6/arm/neon.c | 23 -
b/lib/raid/raid6/arm/neon.uc | 2
b/lib/raid/raid6/arm/pq_arch.h | 21 +
b/lib/raid/raid6/arm/recov_neon.c | 27 -
b/lib/raid/raid6/arm/recov_neon_inner.c | 2
b/lib/raid/raid6/arm64/pq_arch.h | 1
b/lib/raid/raid6/int.uc | 10
b/lib/raid/raid6/loongarch/loongarch_simd.c | 31 -
b/lib/raid/raid6/loongarch/pq_arch.h | 23 +
b/lib/raid/raid6/loongarch/recov_loongarch_simd.c | 39 --
b/lib/raid/raid6/mktables.c | 28 -
b/lib/raid/raid6/powerpc/altivec.uc | 32 -
b/lib/raid/raid6/powerpc/pq_arch.h | 32 +
b/lib/raid/raid6/powerpc/vpermxor.uc | 29 -
b/lib/raid/raid6/recov.c | 62 ---
b/lib/raid/raid6/riscv/pq_arch.h | 21 +
b/lib/raid/raid6/riscv/recov_rvv.c | 14
b/lib/raid/raid6/riscv/rvv.h | 26 -
b/lib/raid/raid6/s390/pq_arch.h | 15
b/lib/raid/raid6/s390/recov_s390xc.c | 14
b/lib/raid/raid6/s390/s390vx.uc | 15
b/lib/raid/raid6/tests/Makefile | 3
b/lib/raid/raid6/tests/raid6_kunit.c | 321 ++++++++++++++++++
b/lib/raid/raid6/x86/avx2.c | 47 --
b/lib/raid/raid6/x86/avx512.c | 57 +--
b/lib/raid/raid6/x86/mmx.c | 39 --
b/lib/raid/raid6/x86/pq_arch.h | 96 +++++
b/lib/raid/raid6/x86/recov_avx2.c | 22 -
b/lib/raid/raid6/x86/recov_avx512.c | 26 -
b/lib/raid/raid6/x86/recov_ssse3.c | 23 -
b/lib/raid/raid6/x86/sse1.c | 49 --
b/lib/raid/raid6/x86/sse2.c | 47 --
lib/raid6/Makefile | 83 ----
lib/raid6/algos.c | 291 ----------------
lib/raid6/loongarch.h | 38 --
lib/raid6/test/.gitignore | 3
lib/raid6/test/Makefile | 156 ---------
lib/raid6/test/test.c | 152 --------
lib/raid6/x86.h | 75 ----
55 files changed, 1349 insertions(+), 1511 deletions(-)
^ permalink raw reply
* Re: [PATCH] ARM: dts: aspeed: anacapa: add JTAG CPLD TRST pin to SGPIO map
From: Andrew Jeffery @ 2026-05-18 5:12 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Colin Huang
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
colin.huang2
In-Reply-To: <20260511-add-jtag-trst-pin-v1-1-b0be2f7b2da5@gmail.com>
On Mon, 11 May 2026 17:47:56 +0800, Colin Huang wrote:
> Add JTAG_CPLD_TRST_R_N to the sgpiom0 pin name table on
> Facebook Anacapa BMC.
>
> This exposes the CPLD JTAG TRST signal through SGPIO,
> allowing proper JTAG reset control during debug.
>
>
> [...]
Thanks, I've applied this to the BMC tree.
--
Andrew Jeffery <andrew@codeconstruct.com.au>
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: Christoph Hellwig @ 2026-05-18 5:12 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Christoph Hellwig, kreijack, David Sterba, Andrew Morton,
Catalin Marinas, Will Deacon, Ard Biesheuvel, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <34C16854-1065-4542-8836-DDED58EC1844@zytor.com>
On Fri, May 15, 2026 at 12:59:34PM -0700, H. Peter Anvin wrote:
> I don't think this is a good idea. Error out; it is the btrfs maintainers' job to ensure user data isn't lost.
>
> The RAID-6 code has *never* supported only 3 units, and if it ever worked for *any* of the implementations it was purely by accident. Speaking as the original author I should know; this was deliberate as in some cases the degenerate case (3) would have required extra trays in the code to no user benefit.
>
> I would not be surprised if the kernel crashed or corrupted the page cache in that case.
It does, that's why I wanted to exclude it. Anyway, for the about to be
resent version I'll drop this btrfs patch over the stated objection and
will otherwise not change anything. This means the (IMHO hypothetical)
users of this configuration will get a WARN_ON_ONCE triggered, but
otherwise keep working (or rather not working) as before.
^ permalink raw reply
* Re: [PATCH v4 0/3] ARM: dts: aspeed-g6: add AST2600 I3C nodes and bindings
From: Andrew Jeffery @ 2026-05-18 5:02 UTC (permalink / raw)
To: Dawid Glazik, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, linux-aspeed
Cc: devicetree, linux-arm-kernel, linux-kernel, maciej.lawniczak
In-Reply-To: <15956b70-c6c2-4e3d-8f15-471a274d6e2d@linux.intel.com>
Hi Dawid,
On Mon, 2026-05-11 at 16:14 +0200, Dawid Glazik wrote:
> On 4/24/2026 10:20 PM, Dawid Glazik wrote:
> > This series reworks and resubmits AST2600 I3C DTS updates that were
> > originally posted in 2024, but stalled without further upstream
> > progress.[1] The series was rebased onto the current tree and merge
> > conflicts were resolved.
> >
> > The patches first move I2C controller nodes under the APB simple-bus
> > for layout consistency, then document aspeed,ast2600-i3c-global in
> > the syscon binding, and finally add AST2600 I3C controller nodes in
> > aspeed-g6.dtsi.
> >
> > Jeremy agreed in a separate email thread that I can continue this
> > series under my authorship.
> >
> > Link: https://lore.kernel.org/all/9d8c03d742fa9767f30e23d75ddf0baf4296c88e.1714647917.git.jk@codeconstruct.com.au/
> >
> > Dawid Glazik (3):
> > ARM: dts: aspeed-g6: move i2c controllers directly into apb node
> > dt-bindings: mfd: syscon: add aspeed,ast2600-i3c-global compatible
> > ARM: dts: aspeed-g6: Add nodes for i3c controllers
> >
> > .../devicetree/bindings/mfd/syscon.yaml | 2 +
> > arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 543 ++++++++++--------
> > 2 files changed, 318 insertions(+), 227 deletions(-)
> >
> >
> > base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
>
> Hi all,
>
> Gentle ping for this series:
> https://lore.kernel.org/all/cover.1777058942.git.dawid.glazik@linux.intel.com/#t
>
> I received Reviewed-by from Krzysztof Kozlowski (thank you).
> Could I please get feedback/ack from maintainers on the remaining parts,
> especially ASPEED DTS?
>
> If preferred, I can respin/rebase the series.
>
Sorry for the delay.
Given Krzysztof's R-b tag for patch 2 I've applied 3 (along with 1) to
the BMC tree. Patch 2 should be picked up by Lee through the MFD tree.
Cheers,
Andrew
^ permalink raw reply
* Re: [PATCH v1] virt: arm-cca-guest: use raw variant of smp_processor_id() in arm_cca_report_new()
From: Gavin Shan @ 2026-05-18 4:28 UTC (permalink / raw)
To: Kohei Enju, Catalin Marinas, Will Deacon
Cc: Sami Mujawar, Steven Price, Suzuki K Poulose, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260518033157.1865498-1-enju.kohei@fujitsu.com>
On 5/18/26 1:31 PM, Kohei Enju wrote:
> With CONFIG_DEBUG_PREEMPT=y, smp_processor_id() becomes an alias of
> debug_smp_processor_id(). This debug function complains when certain
> conditions that ensure CPU ID stability are not met, specifically when
> it's called from a preemptible context.
>
> In arm_cca_report_new(), which runs in a preemptible context,
> smp_processor_id() triggers a splat [0] due to this.
>
> However, the CPU ID obtained here is used as the target CPU for
> smp_call_function_single() to designate a specific CPU for subsequent
> operations, not to assert that the current thread will continue to
> execute on the same CPU. Therefore, snapshotting the CPU ID itself is
> correct, and thus there's no actual harm except for the splat.
>
> Use raw_smp_processor_id() instead, to directly retrieve the current CPU
> ID without the debug checks, avoiding the unnecessary warning message
> while preserving the correct functional behavior.
>
> [0]
> BUG: using smp_processor_id() in preemptible [00000000] code: cca-workload-at/134
> caller is debug_smp_processor_id+0x20/0x2c
> CPU: 0 UID: 0 PID: 134 Comm: cca-workload-at Not tainted 7.0.0-rc1-gc74a64d12073 #1 PREEMPT
> Hardware name: linux,dummy-virt (DT)
> Call trace:
> [...]
> check_preemption_disabled+0xf8/0x100
> debug_smp_processor_id+0x20/0x2c
> arm_cca_report_new+0x54/0x230
> tsm_report_read+0x184/0x260
> tsm_report_outblob_read+0x18/0x38
> configfs_bin_read_iter+0xf4/0x1dc
> vfs_read+0x230/0x31c
> [...]
>
> Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms")
> Signed-off-by: Kohei Enju <enju.kohei@fujitsu.com>
> ---
> drivers/virt/coco/arm-cca-guest/arm-cca-guest.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [RFC V2 00/14] arm64/mm: Enable 128 bit page table entries
From: Anshuman Khandual @ 2026-05-18 4:20 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: linux-arm-kernel, Catalin Marinas, Will Deacon, Ryan Roberts,
Mark Rutland, Andrew Morton, David Hildenbrand, Mike Rapoport,
Linu Cherian, Usama Arif, linux-kernel, linux-mm
In-Reply-To: <agRF7FXwCvp4Ec3h@lucifer>
On 13/05/26 3:09 PM, Lorenzo Stoakes wrote:
> -cc my previous kernel address
>
> Hi Anshuman,
>
> Sorry to be a pain, but I'm using ljs@kernel.org now for my kernel mail, so
> I am at risk of missing stuff sent to my @oracle.com address (I changed
> things around to make managing the... rather large quantities of mail I get
> a bit easier :)
>
> Hence I missed this previously, can you send future revisions to
> ljs@kernel.org? Thanks!
Sure, will do.
>
> Cheers, Lorenzo
>
> On Wed, May 13, 2026 at 10:15:33AM +0530, Anshuman Khandual wrote:
>> FEAT_D128 is a new arm architecture feature adding support for VMSAv9-128
>> translation system. FEAT_D128 is an optional feature from ARMV9.3 onwards.
>> So with this feature arm64 platforms could have two different translation
>> systems, VMSAv8-64 and VMSAv9-128 could selectively be enabled.
>>
>> FEAT_D128 adds 128 bit page table entries, thus supporting larger physical
>> and virtual address range while also expanding available room for more MMU
>> management feature bits both for HW and SW.
>>
>> This series has been split into two parts. Generic MM changes followed by
>> arm64 platform changes, finally enabling D128 with a new config ARM64_D128.
>>
>> READ_ONCE() on page table entries get routed via level specific pxdp_get()
>> helpers which platforms could then override when required. These accessors
>> on arm64 platform help in ensuring page table accesses are performed in an
>> atomic manner while reading 128 bit page table entries.
>>
>> All ARM64_VA_BITS and ARM64_PA_BITS combinations for all page sizes are now
>> supported both on D64 and D128 translation regimes. Although new 56 bits VA
>> space is not yet supported. Similarly FEAT_D128 skip level is not supported
>> currently.
>>
>> Basic page table geometry has also been changed with D128 as there are fewer
>> entries per level. Please refer to the following table for leaf entry sizes.
>>
>> D64 D128
>> ------------------------------------------------
>> | PAGE_SIZE | PMD | PUD | PMD | PUD |
>> -----------------------------|-----------------|
>> | 4K | 2M | 1G | 1M | 256M |
>> | 16K | 32M | 64G | 16M | 16G |
>> | 64K | 512M | 4T | 256M | 1T |
>> ------------------------------------------------
>>
>> D64 D128
>> --------------------------------------------------------------------
>> | PAGE_SIZE | CONT_PTE | CONT_PMD | CONT_PTE | CONT_PMD |
>> --------------------------|------------|-------------|--------------
>> | 4K | 64K | 32M | 64K | 16M |
>> | 16K | 2M | 1G | 1M | 256M |
>> | 64K | 2M | 16G | 1M | 16G |
>> --------------------------------------------------------------------
>>
>> From arm64 kernel features perspective KVM, KASAN and UNMAP_KERNEL_AT_EL0
>> are currently not supported as well.
>>
>> This series applies on v7.1-rc3 and there are no apparent problems while
>> running MM kselftests with and without CONFIG_ARM64_D128. Besides this has
>> been built tested on other platform such as x86, powerpc, riscv, arm and
>> s390 etc.
>>
>> Changes in RFC V2:
>>
>> - Dropped some patches that were merged upstream and rebased on v7.1-rc3
>> - Moved pxdval_t definition inside generic page table header per Mike
>> - Restored print format in __print_bad_page_map_pgtable() per Usama
>> - Renamed __PRIpte as __PRIpxx per David
>> - Dropped _once from pgprot_[read|write]() callbacks per Mike
>> - Moved back all helpers back from arch/arm64/mm/mmu.c into the header
>> - Renamed all ptdesc_ instances as pxxval_ instead
>> - Moved arm64 pgtable header READ_ONCE() replacements later in the series
>> - Updated commit message for the 5-level fixmap change per David
>> - Updated ARM64_CONT_[PTE|PMD]_SHIFT both for 16K and 64K base pages
>> - Added abstraction for tlbi_op
>> - Adopted TLBIP implementation to recent TLB flush changes
>> - Updated all commit messages as required and suggested
>>
>> Changes in RFC V1:
>>
>> https://lore.kernel.org/linux-arm-kernel/20260224051153.3150613-2-anshuman.khandual@arm.com/
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: David Hildenbrand <david@kernel.org>
>> Cc: Mike Rapoport <rppt@kernel.org>
>> Cc: Linu Cherian <linu.cherian@arm.com>
>> Cc: Usama Arif <usama.arif@linux.dev>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-mm@kvack.org
>>
>> Anshuman Khandual (13):
>> mm: Abstract printing of pxd_val()
>> mm: Add read-write accessors for vm_page_prot
>> arm64/mm: Convert READ_ONCE() as pmdp_get() while accessing PMD
>> arm64/mm: Convert READ_ONCE() as pudp_get() while accessing PUD
>> arm64/mm: Convert READ_ONCE() as p4dp_get() while accessing P4D
>> arm64/mm: Convert READ_ONCE() as pgdp_get() while accessing PGD
>> arm64/mm: Route all pgtable reads via pxxval_get()
>> arm64/mm: Route all pgtable writes via pxxval_set()
>> arm64/mm: Route all pgtable atomics to central helpers
>> arm64/mm: Abstract printing of pxd_val()
>> arm64/mm: Override read-write accessors for vm_page_prot
>> arm64/mm: Enable fixmap with 5 level page table
>> arm64/mm: Add initial support for FEAT_D128 page tables
>>
>> Linu Cherian (1):
>> arm64/mm: Add an abstraction level for tlbi_op
>>
>> arch/arm64/Kconfig | 51 +++++++-
>> arch/arm64/Makefile | 4 +
>> arch/arm64/include/asm/assembler.h | 4 +-
>> arch/arm64/include/asm/el2_setup.h | 9 ++
>> arch/arm64/include/asm/pgtable-hwdef.h | 137 ++++++++++++++++++++
>> arch/arm64/include/asm/pgtable-prot.h | 18 ++-
>> arch/arm64/include/asm/pgtable-types.h | 12 ++
>> arch/arm64/include/asm/pgtable.h | 169 ++++++++++++++++++++-----
>> arch/arm64/include/asm/smp.h | 1 +
>> arch/arm64/include/asm/tlbflush.h | 138 ++++++++++++++------
>> arch/arm64/kernel/head.S | 12 ++
>> arch/arm64/mm/fault.c | 20 +--
>> arch/arm64/mm/fixmap.c | 24 +++-
>> arch/arm64/mm/hugetlbpage.c | 10 +-
>> arch/arm64/mm/kasan_init.c | 14 +-
>> arch/arm64/mm/mmu.c | 65 +++++-----
>> arch/arm64/mm/pageattr.c | 8 +-
>> arch/arm64/mm/proc.S | 25 +++-
>> arch/arm64/mm/trans_pgd.c | 14 +-
>> include/linux/pgtable.h | 25 ++++
>> mm/huge_memory.c | 4 +-
>> mm/memory.c | 25 ++--
>> mm/migrate.c | 2 +-
>> mm/mmap.c | 2 +-
>> 24 files changed, 624 insertions(+), 169 deletions(-)
>>
>> --
>> 2.43.0
>>
^ permalink raw reply
* [PATCH] Input: mtk-pmic-keys - use of_device_get_match_data()
From: Rosen Penev @ 2026-05-18 4:20 UTC (permalink / raw)
To: linux-input
Cc: Dmitry Torokhov, Matthias Brugger, AngeloGioacchino Del Regno,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
Use of_device_get_match_data() to fetch the PMIC key register data directly instead of open-coding an of_match_device() lookup.
This also lets the driver drop the of_device.h include.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/input/keyboard/mtk-pmic-keys.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
index c78d9f6d97c4..fd684ac16938 100644
--- a/drivers/input/keyboard/mtk-pmic-keys.c
+++ b/drivers/input/keyboard/mtk-pmic-keys.c
@@ -16,7 +16,6 @@
#include <linux/mfd/mt6397/core.h>
#include <linux/mfd/mt6397/registers.h>
#include <linux/module.h>
-#include <linux/of_device.h>
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
@@ -333,8 +332,6 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
struct mtk_pmic_keys *keys;
const struct mtk_pmic_regs *mtk_pmic_regs;
struct input_dev *input_dev;
- const struct of_device_id *of_id =
- of_match_device(of_mtk_pmic_keys_match_tbl, &pdev->dev);
keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
if (!keys)
@@ -342,7 +339,7 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
keys->dev = &pdev->dev;
keys->regmap = pmic_chip->regmap;
- mtk_pmic_regs = of_id->data;
+ mtk_pmic_regs = of_device_get_match_data(&pdev->dev);
keys->input_dev = input_dev = devm_input_allocate_device(keys->dev);
if (!input_dev) {
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] ARM: PCI: expand single-line pci_common_init() wrapper function
From: Ethan Nelson-Moore @ 2026-05-18 4:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-arm-kernel, linux-kernel, Russell King,
Sebastian Hesselbarth, Gregory Clement
In-Reply-To: <b3c8c216-d8e3-4ee9-b4bc-1080f73592dc@lunn.ch>
Hi, Andrew,
On Sun, May 17, 2026 at 8:42 PM Andrew Lunn <andrew@lunn.ch> wrote:
> Nobody seems to call pci_common_init_dev() without passing NULL. So i
> think it makes more sense to rename pci_common_init_dev() to
> pci_common_init() and drop struct device *parent parameter. You then
> only need to change pci.h and bios32.c.
I considered that, but decided against it because it would prevent the
code from easily being updated to pass a parent parameter in the
future. However, given the age of the affected platforms, that is
unlikely to happen, so your approach might make more sense. What do
you think?
Ethan
^ permalink raw reply
* RE: Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Chancel Liu @ 2026-05-18 4:18 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, festevam@gmail.com,
mturquette@baylibre.com, sboyd@kernel.org, kernel@pengutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org
In-Reply-To: <20260515-resourceful-singing-roadrunner-ce25ec@quoll>
> > +description:
> > + The NXP I/O connector represents a physically present I/O connector
> > +on the
> > + base board. It acts as a nexus that exposes a constrained set of
> > +I/O
> > + resources, such as GPIOs, clocks, PWMs and interrupts, through
> > +fixed
> > + electrical wiring. All actual hardware providers reside on the base board.
> > + The connector node only defines index-based mappings to those
> providers.
> > +
> > +properties:
> > + compatible:
> > + const: fsl,io-connector
>
> Everything is IO. Everything is connector, so your compatible does not match
> requirements from writing bindings.
>
Yes, this compatible is too generic. I will rename the compatible to
fsl,aud-io-connector.
> > +
> > + gpio-controller: true
> > +
> > + '#gpio-cells':
> > + const: 2
> > +
> > + gpio-map:
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
>
> You do not need to redefine the types. You need constraints, though.
>
OK. I will add proper constraints.
> > +
> > + gpio-map-mask:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > + gpio-map-pass-thru:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > + '#clock-cells':
> > + const: 1
> > +
> > + clock-map:
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +
> > + clock-map-mask:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > + clock-map-pass-thru:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
>
> I do not see these defined anywhere. I also checked cover letter for
> references for pulls to dtschema.
>
Nexus nodes are already in the device-tree specification：
https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
For reference, current kernel has supported it:
* Nexus OF support:
commit bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a nexus node")
* GPIO adoption:
commit c11e6f0f04db ("gpio: Support gpio nexus dt bindings")
* PWM adoption:
commit e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings")
Clock adoption is ongoing:
https://lore.kernel.org/all/20260327-schneider-v7-0-rc1-crypto-v1-10-5e6ff7853994@bootlin.com/
> > +
> > + pwm-map:
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +
> > + pwm-map-mask:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > + pwm-map-pass-thru:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > + '#address-cells':
> > + const: 0
> > +
> > + interrupt-controller: true
> > +
> > + "#interrupt-cells":
>
> Use consistent quotes.
>
I will fix it in next revision.
> > + const: 2
> > +
> > + interrupt-map: true
> > +
> > + interrupt-map-mask: true
> > +
> > +required:
> > + - compatible
>
> You need to require the properties. You have a FIXED connector, so it has
> fixed set of features.
>
> Best regards,
> Krzysztof
I will make gpio related properties required because they are mandatory
for DT. Clock and interrupt mappings are board/configuration dependent
so I prefer to use dependentRequired when they are present.
Regards,
Chancel Liu
^ permalink raw reply
* Re: [PATCH v2 9/9] iommu/arm-smmu-v3: Directly encode TLBI commands
From: Nicolin Chen @ 2026-05-18 3:52 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <9-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:48PM -0300, Jason Gunthorpe wrote:
> TLBI is more complicated than all the other commands because the
> invalidation loop builds a template command from the struct
> arm_smmu_inv which is then expanded into many TLBI commands for the
> invalidation.
>
> Reviewed-by: Mostafa Saleh <smostafa@google.com>
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* Re: [PATCH] ARM: PCI: expand single-line pci_common_init() wrapper function
From: Andrew Lunn @ 2026-05-18 3:42 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-kernel, Russell King,
Sebastian Hesselbarth, Gregory Clement
In-Reply-To: <20260517235916.57178-1-enelsonmoore@gmail.com>
On Sun, May 17, 2026 at 04:59:11PM -0700, Ethan Nelson-Moore wrote:
> pci_common_init() is a compatibility wrapper that simply calls
> pci_common_init_dev() with an additional NULL argument. The comment
> above it implies that it should be replaced by pci_common_init_dev(),
> but that has never happened - there are no callers of
> pci_common_init_dev() in the kernel. Make the PCI code more
> straightforward by updating all uses of pci_common_init() to instead
> call pci_common_init_dev() with a NULL first argument and removing
> pci_common_init().
Nobody seems to call pci_common_init_dev() without passing NULL. So i
think it makes more sense to rename pci_common_init_dev() to
pci_common_init() and drop struct device *parent parameter. You then
only need to change pci.h and bios32.c.
Andrew
^ permalink raw reply
* [PATCH v3 2/2] ARM: dts: aspeed: Add ASRock Rack B650D4U BMC
From: Prasanth Kumar Padarthi @ 2026-05-18 3:34 UTC (permalink / raw)
To: joel, andrew, robh, krzk+dt, conor+dt
Cc: andrew+netdev, devicetree, linux-aspeed, linux-arm-kernel,
Prasanth Kumar Padarthi
In-Reply-To: <20260518033440.17569-1-prasanth.padarthi10@gmail.com>
Add initial device tree support for the ASRock Rack B650D4U BMC.
The B650D4U is a server motherboard utilizing the ASPEED AST2600
SoC for management.
Signed-off-by: Prasanth Kumar Padarthi <prasanth.padarthi10@gmail.com>
---
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../dts/aspeed/aspeed-bmc-asrock-b650d4u.dts | 71 +++++++++++++++++++
2 files changed, 72 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index c4f064e4b..124d4f8f8 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-asrock-romed8hm3.dtb \
aspeed-bmc-asrock-spc621d8hm3.dtb \
aspeed-bmc-asrock-x570d4u.dtb \
+ aspeed-bmc-asrock-b650d4u.dtb \
aspeed-bmc-asus-x4tf.dtb \
aspeed-bmc-bytedance-g220a.dtb \
aspeed-bmc-delta-ahe50dc.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
new file mode 100644
index 000000000..daa8b25e3
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "aspeed-g6.dtsi"
+
+/ {
+ model = "ASRock Rack B650D4U BMC";
+ compatible = "asrock,b650d4u-bmc", "aspeed,ast2600";
+
+ aliases {
+ serial4 = &uart5;
+ };
+
+ chosen {
+ stdout-path = "serial4:115200n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000>;
+ };
+};
+
+/* SPI Flash Management */
+&fmc {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc";
+ };
+};
+
+/* I2C Bus for FRU/EEPROM Storage */
+&i2c7 {
+ status = "okay";
+ eeprom@57 {
+ compatible = "atmel,24c02";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+};
+
+&mac0 {
+ status = "okay";
+ phy-mode = "rgmii-rxid";
+ phy-handle = <ðphy0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii1_default &pinctrl_mdio1_default>;
+};
+
+/* Dedicated management LAN via on-board discrete PHY */
+&mdio0 {
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
+/* BMC Console UART */
+&uart5 {
+ status = "okay";
+};
+
+/* System Watchdog */
+&wdt1 {
+ status = "okay";
+ aspeed,reset-type = "soc";
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: arm: aspeed: Add ASRock Rack B650D4U
From: Prasanth Kumar Padarthi @ 2026-05-18 3:34 UTC (permalink / raw)
To: joel, andrew, robh, krzk+dt, conor+dt
Cc: andrew+netdev, devicetree, linux-aspeed, linux-arm-kernel,
Prasanth Kumar Padarthi
In-Reply-To: <20260518033440.17569-1-prasanth.padarthi10@gmail.com>
Add the compatible string for the ASRock Rack B650D4U BMC,
which is an AST2600-based server motherboard.
Signed-off-by: Prasanth Kumar Padarthi <prasanth.padarthi10@gmail.com>
---
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index 2f92b8ab0..656397850 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -77,6 +77,7 @@ properties:
- ampere,mtmitchell-bmc
- aspeed,ast2600-evb
- aspeed,ast2600-evb-a1
+ - asrock,b650d4u-bmc
- asus,x4tf-bmc
- facebook,bletchley-bmc
- facebook,catalina-bmc
--
2.47.3
^ permalink raw reply related
* [PATCH v3 0/2] Add ASRock Rack B650D4U BMC
From: Prasanth Kumar Padarthi @ 2026-05-18 3:34 UTC (permalink / raw)
To: joel, andrew, robh, krzk+dt, conor+dt
Cc: andrew+netdev, devicetree, linux-aspeed, linux-arm-kernel,
Prasanth Kumar Padarthi
Add initial devicetree support for the ASRock Rack B650D4U BMC,
an ASPEED AST2600-based server management controller.
Changes in v3:
- Reorder board DTS nodes alphabetically by label.
- Clarify that the management LAN PHY is an on-board discrete PHY.
- Keep MAC0 phy-mode as "rgmii-rxid" based on the extracted vendor DTB.
- Keep flash layout unspecified until it can be validated on hardware.
Changes in v2:
- Add MAC0 dedicated management LAN description with MDIO PHY at address 0.
Prasanth Kumar Padarthi (2):
dt-bindings: arm: aspeed: Add ASRock Rack B650D4U
ARM: dts: aspeed: Add ASRock Rack B650D4U BMC
.../bindings/arm/aspeed/aspeed.yaml | 1 +
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../dts/aspeed/aspeed-bmc-asrock-b650d4u.dts | 71 +++++++++++++++++++
3 files changed, 73 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
--
2.47.3
^ permalink raw reply
* [PATCH v1] virt: arm-cca-guest: use raw variant of smp_processor_id() in arm_cca_report_new()
From: Kohei Enju @ 2026-05-18 3:31 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Sami Mujawar, Gavin Shan, Steven Price, Suzuki K Poulose,
linux-arm-kernel, linux-kernel, Kohei Enju
With CONFIG_DEBUG_PREEMPT=y, smp_processor_id() becomes an alias of
debug_smp_processor_id(). This debug function complains when certain
conditions that ensure CPU ID stability are not met, specifically when
it's called from a preemptible context.
In arm_cca_report_new(), which runs in a preemptible context,
smp_processor_id() triggers a splat [0] due to this.
However, the CPU ID obtained here is used as the target CPU for
smp_call_function_single() to designate a specific CPU for subsequent
operations, not to assert that the current thread will continue to
execute on the same CPU. Therefore, snapshotting the CPU ID itself is
correct, and thus there's no actual harm except for the splat.
Use raw_smp_processor_id() instead, to directly retrieve the current CPU
ID without the debug checks, avoiding the unnecessary warning message
while preserving the correct functional behavior.
[0]
BUG: using smp_processor_id() in preemptible [00000000] code: cca-workload-at/134
caller is debug_smp_processor_id+0x20/0x2c
CPU: 0 UID: 0 PID: 134 Comm: cca-workload-at Not tainted 7.0.0-rc1-gc74a64d12073 #1 PREEMPT
Hardware name: linux,dummy-virt (DT)
Call trace:
[...]
check_preemption_disabled+0xf8/0x100
debug_smp_processor_id+0x20/0x2c
arm_cca_report_new+0x54/0x230
tsm_report_read+0x184/0x260
tsm_report_outblob_read+0x18/0x38
configfs_bin_read_iter+0xf4/0x1dc
vfs_read+0x230/0x31c
[...]
Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms")
Signed-off-by: Kohei Enju <enju.kohei@fujitsu.com>
---
drivers/virt/coco/arm-cca-guest/arm-cca-guest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
index 0c9ea24a200c..2d450caee3e4 100644
--- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
+++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
@@ -108,7 +108,7 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
* allocate outblob based on the returned value from the 'init'
* call and that cannot be done in an atomic context.
*/
- cpu = smp_processor_id();
+ cpu = raw_smp_processor_id();
info.challenge = desc->inblob;
info.challenge_size = desc->inblob_len;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Chen-Yu Tsai @ 2026-05-18 3:30 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: Andre Przywara, linux-sunxi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jernej Skrabec, Samuel Holland, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <14a7e289ff5ffed8fcd6dcb9b2e8455a1b2c9420.camel@gmail.com>
On Mon, May 18, 2026 at 4:37 AM Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
>
> Hi Andre,
>
> thanks for the quick feedback!
>
> On Mon, 2026-05-11 at 13:44 +0200, Andre Przywara wrote:
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> > > @@ -0,0 +1,162 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > +/*
> > > + * Copyright (c) 2025 Arm Ltd.
> >
> > Please put your own copyright here, even if that has been largely copied
> > from an existing file.
> >
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include "sun50i-a100.dtsi"
> > > +#include "sun50i-a100-cpu-opp.dtsi"
> > > +
> > > +/{
> > > + compatible = "baijie,helper-a133-core",
> > > + "allwinner,sun50i-a100";
> > > +
> > > + aliases {
> > > + serial1 = &uart1; /* BT module */
> >
> > Do we really need an alias for the BT UART? And is the BT module
> > supported already? Then please add a child node to the UART node.
>
> That's the only thing I can do currently regarding BT: stabilize the
> serial enumeration, because UART1 cannot be used for anything else
> except BT module, because this is soldered inside "core" module.
> We can avoid different tty enumeration, should the support for
> BT be implemented in the future...
>
> > Isn't the WiFi/BT module on the SoM? Then please mention and enable MMC1
> > here. Provide the child node for the WiFi chip, even if there is no
> > upstream support in the kernel for it yet.
>
> So both the above BT and the WiFi is AW869A/AIC8800 combo chip, which
> has neither upstream driver, nor [upstream] DT bindings. Even github
> driver for AIC8800 doesn't seem to use DT, therefore it looks quite
> pointless to me at this point to specify anything in the DT for the
> chip which doesn't have the bindings idea even theoretically.
>
> Nothing in the current DT shall block any future work on the AW869A
> support though and the above "aliases" entry shall even guarantee
> unchanged serial enumeration shall such support arise.
>
> > > +®_aldo1 {
> >
> > What is aldo1 used for, actually? I don't see this referenced anywhere.
> > I guess the kernel turns that off after booting?
> > If you have access to the schematic, please check that. If that's for
> > some peripheral not yet supported, please note the user anyway, ideally
> > by an explaining regulator-name, or by a comment. Also if it's used for
> > any of the required SoC VDD pins. See the Liontron .dts for comparison.
> >
> > > + regulator-always-on;
> ^^^^^^^^^^^^^^^^^^^
> I suppose it's not being switcdhed of because of the above.
> It's used for both PLL supply for the whole SoC + as analog voltage reference
> for LRADC (the buttons you've noticed on the board are connected to
> this ADC via a resistor ladder).
>
> >
> > > +®_aldo2 {
> > > + regulator-always-on;
> >
> > For always-on regulators we definitely need an explanation. Does the
> > board stop booting if you remove this line?
> > Maybe it's for DRAM? Can you say what voltage it is, either from the
> > reset default, or set by the bootloader?
>
> Thanks for the hint! I'll put proper voltages into all regulators +
> comment all the always-on regulators.
Please also give them proper names. If you have the schematics, then use
the names from that; otherwise just make up names matching their use.
> >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
> > > new file mode 100644
> > > index 000000000000..ccbca5d0a40c
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
>
> > And you should provide a top level 5V regulator here, to be the root of
> > the regulator tree. Look at reg_vcc5v in the Liontron .dts.
>
> It doesn't look to me as if Liontron had reg_vcc5v as its 5V "root" regulator.
> It seems to be only used for reg_usb1_vbus, while HelperBoard A133 doesn't
> have USB power control. The second issue with Helper/Core split is that
> all PMIC story is inside Core board which has 5V input rail, while HelperBoard
> around it has indeed 12V->5V DCDC regulator (similar to Liontron), but
> putting it in the DT would introduce wierd dependency of the core to the
> HelperBoard which carries it. Do you think it would make sense?
In that case I would probably put a 5v "fake root" regulator in the core
dtsi. And in combined dts, I'd then add the 12v "real root", and use that
as the supply for the 5v fake root.
Does that make sense?
ChenYu
> > So from the pictures I found online it looks like there is an USB-C port
> > labelled "OTG", so can you please add an &usbotg reference here and
> > describe that port.
>
> Nice catch! I've missed the fact usbphy 0 has to be in peripheral mode,
> not host mode. Will rework!
>
> > > +&usbphy {
> >
> > Are the two USB ports always powered?
> >
> > And anyway, I see a *dual* USB-A socket on the pictures online, in
> > addition to the USB-OTG port. So where does the third USB come from? The
> > A133 only supports one host USB port plus the one OTG port. So is there
> > an USB hub chip on the board?
>
> There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
> two USB-A ports are always powered from the board's 12V->5V DCDC, no USB
> load switches.
> >
>
> --
> Alexander Sverdlin.
^ permalink raw reply
* Re: [PATCH v2 8/9] iommu/arm-smmu-v3: Directly encode CMDQ_OP_SYNC
From: Nicolin Chen @ 2026-05-18 3:30 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <8-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:47PM -0300, Jason Gunthorpe wrote:
> Change the flow so the caller controls the CS field and remove the
> weird u64p_replace_bits() thing to override it.
>
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
> Reviewed-by: Mostafa Saleh <smostafa@google.com>
> Tested-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* Re: [PATCH v2 7/9] iommu/arm-smmu-v3: Directly encode CMDQ_OP_ATC_INV
From: Nicolin Chen @ 2026-05-18 3:27 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <7-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:46PM -0300, Jason Gunthorpe wrote:
> Add a new command make function and convert all the places using
> ATC_INV.
>
> Split out full invalidation to directly make the cmd instead of
> overloading size=0 to mean full invalidation.
>
> In section "3.9.1 ATS Interface" of F.b the specification says:
>
> When the SMMU returns an ATS Translation Completion for a request that
> had a PASID, the Global bit of the Translation Completion Data Entry
> must be zero.
>
> Even though it faithfully forwards the G bit through to the ATS
> invalidation command there is no way to create G mappings so there is
> never any need to send a G invalidation. Thus don't expose global in the
> new helpers and leave CMDQ_ATC_0_GLOBAL unused.
>
> Reviewed-by: Mostafa Saleh <smostafa@google.com>
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
With a nit ..
> -static void
> -arm_smmu_atc_inv_to_cmd(int ssid, unsigned long iova, size_t size,
> - struct arm_smmu_cmdq_ent *cmd)
> +static struct arm_smmu_cmd
> +arm_smmu_atc_inv_to_cmd(u32 sid, int ssid, unsigned long iova, size_t size)
> {
> size_t log2_span;
> size_t span_mask;
> @@ -2395,17 +2386,6 @@ arm_smmu_atc_inv_to_cmd(int ssid, unsigned long iova, size_t size,
> * This has the unpleasant side-effect of invalidating all PASID-tagged
> * ATC entries within the address range.
> */
> - *cmd = (struct arm_smmu_cmdq_ent) {
> - .opcode = CMDQ_OP_ATC_INV,
> - .substream_valid = (ssid != IOMMU_NO_PASID),
> - .atc.ssid = ssid,
> - };
> -
> - if (!size) {
> - cmd->atc.size = ATC_INV_SIZE_ALL;
> - return;
> - }
.. should !size jump to arm_smmu_make_cmd_atc_inv_all()?
Or maybe add a note to disallow this function being used with !size
and WARN_ON? The function name itself doesn't sound very restricted
though.
Nicolin
^ permalink raw reply
* RE: [PATCH v4 2/7] PCI: cadence: Add post-link delay for LGA and j721e glue driver
From: Manikandan Karunakaran Pillai @ 2026-05-18 3:17 UTC (permalink / raw)
To: Hans Zhang, bhelgaas@google.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, vigneshr@ti.com,
jingoohan1@gmail.com, thomas.petazzoni@bootlin.com,
ryder.lee@mediatek.com, claudiu.beznea.uj@bp.renesas.com
Cc: robh@kernel.org, s-vadapalli@ti.com, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, claudiu.beznea@tuxon.dev,
linux-mediatek@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <e7143078-0c0a-4c15-a192-081f2a5a5ff8@163.com>
>>>>>
>>>>> #include "pcie-cadence.h"
>>>>> #include "pcie-cadence-host-common.h"
>>>>> +#include "../pci-host-common.h"
>>>>>
>>>>> #define LINK_RETRAIN_TIMEOUT HZ
>>>>>
>>>>> @@ -115,6 +116,9 @@ int cdns_pcie_host_start_link(struct cdns_pcie_rc
>>> *rc,
>>>>> if (!ret && rc->quirk_retrain_flag)
>>>>> ret = cdns_pcie_retrain(pcie, pcie_link_up);
>>>>>
>>>>> + if (!ret)
>>>>> + pci_host_common_link_train_delay(pcie->max_link_speed);
>>>>> +
>>>>> return ret;
>>>>> }
>>>>> EXPORT_SYMBOL_GPL(cdns_pcie_host_start_link);
>>>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>>> b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>>> index 0bc9e6e90e0e..058e4e619654 100644
>>>>> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>>> @@ -13,6 +13,7 @@
>>>>>
>>>>> #include "pcie-cadence.h"
>>>>> #include "pcie-cadence-host-common.h"
>>>>> +#include "../../pci.h"
>>>>>
>>>>> static u8 bar_aperture_mask[] = {
>>>>> [RP_BAR0] = 0x1F,
>>>>> @@ -397,6 +398,9 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
>>>>> rc->device_id = 0xffff;
>>>>> of_property_read_u32(np, "device-id", &rc->device_id);
>>>>>
>>>>> + if (pcie->max_link_speed < 1)
>>>>> + pcie->max_link_speed = of_pci_get_max_link_speed(np);
>>>>> +
>>>> Why is the conditional if required here as during cdns_pcie_host_setup(),
>the
>>> value of
>>>> max_link_speed is expected to be '0', unless specifically initialized by the
>>> platform code separately.
>>>>
>>>> What happens if the max_link_speed is not defined in the corresponding
>dts
>>> ? Would not the -EINVAL returned from the function create issues ?
>>>
>>> Hi Manikandan,
>>>
>>> Please see:
>>>
>>> https://urldefense.com/v3/__https://github.com/torvalds/linux/blob/v7.1-
>>> rc4/drivers/pci/controller/dwc/pcie-
>>>
>designware.c*L191__;Iw!!EHscmS1ygiU1lA!EDHVakD3QN0gGza3V1__qzHgDG9
>>> RZlq7LzC5AFsYLV2i5FcoveNFsjWORRgRdHCAmOI-LizY5cJvGIWBOFJG$
>>>
>>>
>>> Best regards,
>>> Hans
>>>
>> That is how Designware has implemented it but that does not answer my
>query. Becos both these implementations do
>> not take care of the error returned, and it could well be the case for many of
>the current implementations.
>
>Hi Manikandan,
>
>If "max-link-speed" is not defined in the DT, then:
>
>of_pci_get_max_link_speed
> of_property_read_u32
> of_property_read_u32_array
> of_property_read_variable_u32_array
> return -EINVAL;
>
>
>For patch 0001, no actions will be executed. I wonder if this answers
>your question?
>
Yes, got it. Thanks Hans.
>Best regards,
>Hans
>
>
>>
>>>>
>>>>> pcie->reg_base = devm_platform_ioremap_resource_byname(pdev,
>>>>> "reg");
>>>>> if (IS_ERR(pcie->reg_base)) {
>>>>> dev_err(dev, "missing \"reg\"\n");
>>>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h
>>>>> b/drivers/pci/controller/cadence/pcie-cadence.h
>>>>> index 574e9cf4d003..042a4c49bb9a 100644
>>>>> --- a/drivers/pci/controller/cadence/pcie-cadence.h
>>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
>>>>> @@ -86,6 +86,7 @@ struct cdns_plat_pcie_of_data {
>>>>> * @ops: Platform-specific ops to control various inputs from Cadence
>PCIe
>>>>> * wrapper
>>>>> * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
>>>>> + * @max_link_speed: Maximum supported link speed
>>>>> */
>>>>> struct cdns_pcie {
>>>>> void __iomem *reg_base;
>>>>> @@ -98,6 +99,7 @@ struct cdns_pcie {
>>>>> struct device_link **link;
>>>>> const struct cdns_pcie_ops *ops;
>>>>> const struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
>>>>> + int max_link_speed;
>>>>> };
>>>>>
>>>>> /**
>>>>> --
>>>>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH v2 6/9] iommu/arm-smmu-v3: Directly encode simple commands
From: Nicolin Chen @ 2026-05-18 3:15 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Jonathan Hunter, Joerg Roedel, linux-arm-kernel,
linux-tegra, Robin Murphy, Thierry Reding, Krishna Reddy,
Will Deacon, David Matlack, Pasha Tatashin, patches,
Pranjal Shrivastava, Samiullah Khawaja, Mostafa Saleh
In-Reply-To: <6-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com>
On Wed, May 13, 2026 at 08:57:45PM -0300, Jason Gunthorpe wrote:
> Add make functions to build commands for
>
> CMDQ_OP_TLBI_EL2_ALL
> CMDQ_OP_TLBI_NSNH_ALL
> CMDQ_OP_CFGI_ALL
> CMDQ_OP_PREFETCH_CFG
> CMDQ_OP_CFGI_STE
> CMDQ_OP_CFGI_CD
> CMDQ_OP_RESUME
> CMDQ_OP_PRI_RESP
>
> Convert all of these call sites to use the make function instead of
> going through arm_smmu_cmdq_build_cmd(). Use a #define so the general
> pattern is always:
>
> arm_smmu_cmdq_issue_cmd(smmu, arm_smmu_make_cmd_XX(..));
>
> Add arm_smmu_cmdq_batch_add_cmd() which takes struct arm_smmu_cmd
> directly to match the new flow.
>
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
> Reviewed-by: Mostafa Saleh <smostafa@google.com>
> Tested-by: Pranjal Shrivastava <praan@google.com>
> Tested-by: Mostafa Saleh <smostafa@google.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
> +static inline struct arm_smmu_cmd arm_smmu_make_cmd_cfgi_all(void)
> +{
> + struct arm_smmu_cmd cmd = arm_smmu_make_cmd_op(CMDQ_OP_CFGI_ALL);
> +
> + cmd.data[1] |= FIELD_PREP(CMDQ_CFGI_1_RANGE, 31);
Optional, might retain the note:
/* Cover the entire SID range */
^ permalink raw reply
* Re: [PATCH v2 2/2] pwm: meson: Add support for Amlogic S7
From: Xianwei Zhao @ 2026-05-18 3:05 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiner Kallweit,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pwm, devicetree, linux-kernel, linux-arm-kernel,
linux-amlogic
In-Reply-To: <agn2Yp3mzI7DcsyN@monoceros>
Hi Uwe,
Thanks for your review.
On 2026/5/18 01:12, Uwe Kleine-König wrote:
> Subject:
> Re: [PATCH v2 2/2] pwm: meson: Add support for Amlogic S7
> From:
> Uwe Kleine-König <ukleinek@kernel.org>
> Date:
> 2026/5/18 01:12
>
> To:
> xianwei.zhao@amlogic.com
> CC:
> Rob Herring <robh@kernel.org>, Krzysztof Kozlowski <krzk+dt@kernel.org>,
> Conor Dooley <conor+dt@kernel.org>, Heiner Kallweit
> <hkallweit1@gmail.com>, Neil Armstrong <neil.armstrong@linaro.org>,
> Kevin Hilman <khilman@baylibre.com>, Jerome Brunet
> <jbrunet@baylibre.com>, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com>, linux-pwm@vger.kernel.org,
> devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
> linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org
>
>
>
> Hello,
>
> On Thu, Apr 02, 2026 at 02:40:16AM +0000, Xianwei Zhao via B4 Relay wrote:
>> From: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>
>> Add support for Amlogic S7 PWM. Amlogic S7 different from the
>> previous SoCs, a controller includes one pwm, at the same time,
>> the controller has only one input clock source.
>>
>> Signed-off-by: Xianwei Zhao<xianwei.zhao@amlogic.com>
>> ---
>> drivers/pwm/pwm-meson.c | 32 +++++++++++++++++++++++++++++---
>> 1 file changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
>> index 8c6bf3d49753..7a43c42ef3d6 100644
>> --- a/drivers/pwm/pwm-meson.c
>> +++ b/drivers/pwm/pwm-meson.c
>> @@ -113,6 +113,7 @@ struct meson_pwm_data {
>> int (*channels_init)(struct pwm_chip *chip);
>> bool has_constant;
>> bool has_polarity;
>> + bool single_pwm;
> Conceptually I'd prefer a `npwm` field here. That doesn't take more
> space in memory and simplifies the logic a bit. (At the cost of having
> to adapt all already existing meson_pwm_data instances, but that's fine
> in my book.)
>
I will use npwm(u8 type) instead of single_pwm.
>> };
>>
>> struct meson_pwm {
>> @@ -503,6 +504,18 @@ static void meson_pwm_s4_put_clk(void *data)
>> clk_put(clk);
>> }
>>
>> +static int meson_pwm_init_channels_s7(struct pwm_chip *chip)
>> +{
>> + struct device *dev = pwmchip_parent(chip);
>> + struct meson_pwm *meson = to_meson_pwm(chip);
>> +
>> + meson->channels[0].clk = devm_clk_get(dev, NULL);
>> + if (IS_ERR(meson->channels[0].clk))
>> + return dev_err_probe(dev, PTR_ERR(meson->channels[0].clk),
>> + "Failed to get clk\n");
>> + return 0;
>> +}
>> +
>> static int meson_pwm_init_channels_s4(struct pwm_chip *chip)
>> {
>> struct device *dev = pwmchip_parent(chip);
>> @@ -592,6 +605,13 @@ static const struct meson_pwm_data pwm_s4_data = {
>> .has_polarity = true,
>> };
>>
>> +static const struct meson_pwm_data pwm_s7_data = {
>> + .channels_init = meson_pwm_init_channels_s7,
>> + .has_constant = true,
>> + .has_polarity = true,
>> + .single_pwm = true,
>> +};
>> +
>> static const struct of_device_id meson_pwm_matches[] = {
>> {
>> .compatible = "amlogic,meson8-pwm-v2",
>> @@ -642,6 +662,10 @@ static const struct of_device_id meson_pwm_matches[] = {
>> .compatible = "amlogic,meson-s4-pwm",
>> .data = &pwm_s4_data
>> },
>> + {
>> + .compatible = "amlogic,s7-pwm",
>> + .data = &pwm_s7_data
>> + },
>> {},
> If you touch that array in the next revision, please make this line:
>
> { }
>
> (I.e. add a space and drop the comma.)
>
Will do.
> Best regards
> Uwe
^ permalink raw reply
* Re: [PATCH v4 2/7] PCI: cadence: Add post-link delay for LGA and j721e glue driver
From: Hans Zhang @ 2026-05-18 3:03 UTC (permalink / raw)
To: Manikandan Karunakaran Pillai, bhelgaas@google.com,
lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
vigneshr@ti.com, jingoohan1@gmail.com,
thomas.petazzoni@bootlin.com, ryder.lee@mediatek.com,
claudiu.beznea.uj@bp.renesas.com
Cc: robh@kernel.org, s-vadapalli@ti.com, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, claudiu.beznea@tuxon.dev,
linux-mediatek@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DM6PR07MB6716CC48016E6D44EC5FCAB3A2032@DM6PR07MB6716.namprd07.prod.outlook.com>
On 5/18/26 10:38, Manikandan Karunakaran Pillai wrote:
>
>
>> EXTERNAL MAIL
>>
>>
>>
>>
>> On 5/18/26 10:12, Manikandan Karunakaran Pillai wrote:
>>>
>>>
>>>> EXTERNAL MAIL
>>>>
>>>>
>>>> The Cadence LGA (Legacy Architecture IP) PCIe host controller currently
>>>> lacks the mandatory 100 ms delay after link training completes for speeds
>>>>> 5.0 GT/s, as required by PCIe r6.0 sec 6.6.1.
>>>>
>>>> Add a 'max_link_speed' field to struct cdns_pcie. In the common host
>>>> layer function cdns_pcie_host_start_link(), after the link has been
>>>> successfully established, call pci_host_common_link_train_delay() to
>>>> insert the required delay.
>>>>
>>>> For the j721e glue driver, set cdns_pcie.max_link_speed from the existing
>>>> link speed logic. For other LGA-based glue drivers (sky1, sg2042), the
>>>> common LGA host setup (pcie-cadence-host.c) provides a fallback reading
>>>> of the device tree property "max-link-speed" when available. This ensures
>>>> that the delay is not missed on those platforms once they enable the
>>>> property.
>>>>
>>>> Signed-off-by: Hans Zhang <18255117159@163.com>
>>>> ---
>>>> drivers/pci/controller/cadence/pci-j721e.c | 1 +
>>>> drivers/pci/controller/cadence/pcie-cadence-host-common.c | 4 ++++
>>>> drivers/pci/controller/cadence/pcie-cadence-host.c | 4 ++++
>>>> drivers/pci/controller/cadence/pcie-cadence.h | 2 ++
>>>> 4 files changed, 11 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/controller/cadence/pci-j721e.c
>>>> b/drivers/pci/controller/cadence/pci-j721e.c
>>>> index bfdfe98d5aba..ae916e7b1927 100644
>>>> --- a/drivers/pci/controller/cadence/pci-j721e.c
>>>> +++ b/drivers/pci/controller/cadence/pci-j721e.c
>>>> @@ -206,6 +206,7 @@ static int j721e_pcie_set_link_speed(struct
>> j721e_pcie
>>>> *pcie,
>>>> (pcie_get_link_speed(link_speed) == PCI_SPEED_UNKNOWN))
>>>> link_speed = 2;
>>>>
>>>> + pcie->cdns_pcie->max_link_speed = link_speed;
>>>> val = link_speed - 1;
>>>> ret = regmap_update_bits(syscon, offset, GENERATION_SEL_MASK,
>>>> val);
>>>> if (ret)
>>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> index 2b0211870f02..18e4b6c760b5 100644
>>>> --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> @@ -14,6 +14,7 @@
>>>>
>>>> #include "pcie-cadence.h"
>>>> #include "pcie-cadence-host-common.h"
>>>> +#include "../pci-host-common.h"
>>>>
>>>> #define LINK_RETRAIN_TIMEOUT HZ
>>>>
>>>> @@ -115,6 +116,9 @@ int cdns_pcie_host_start_link(struct cdns_pcie_rc
>> *rc,
>>>> if (!ret && rc->quirk_retrain_flag)
>>>> ret = cdns_pcie_retrain(pcie, pcie_link_up);
>>>>
>>>> + if (!ret)
>>>> + pci_host_common_link_train_delay(pcie->max_link_speed);
>>>> +
>>>> return ret;
>>>> }
>>>> EXPORT_SYMBOL_GPL(cdns_pcie_host_start_link);
>>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>> b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>> index 0bc9e6e90e0e..058e4e619654 100644
>>>> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>>> @@ -13,6 +13,7 @@
>>>>
>>>> #include "pcie-cadence.h"
>>>> #include "pcie-cadence-host-common.h"
>>>> +#include "../../pci.h"
>>>>
>>>> static u8 bar_aperture_mask[] = {
>>>> [RP_BAR0] = 0x1F,
>>>> @@ -397,6 +398,9 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
>>>> rc->device_id = 0xffff;
>>>> of_property_read_u32(np, "device-id", &rc->device_id);
>>>>
>>>> + if (pcie->max_link_speed < 1)
>>>> + pcie->max_link_speed = of_pci_get_max_link_speed(np);
>>>> +
>>> Why is the conditional if required here as during cdns_pcie_host_setup(), the
>> value of
>>> max_link_speed is expected to be '0', unless specifically initialized by the
>> platform code separately.
>>>
>>> What happens if the max_link_speed is not defined in the corresponding dts
>> ? Would not the -EINVAL returned from the function create issues ?
>>
>> Hi Manikandan,
>>
>> Please see:
>>
>> https://urldefense.com/v3/__https://github.com/torvalds/linux/blob/v7.1-
>> rc4/drivers/pci/controller/dwc/pcie-
>> designware.c*L191__;Iw!!EHscmS1ygiU1lA!EDHVakD3QN0gGza3V1__qzHgDG9
>> RZlq7LzC5AFsYLV2i5FcoveNFsjWORRgRdHCAmOI-LizY5cJvGIWBOFJG$
>>
>>
>> Best regards,
>> Hans
>>
> That is how Designware has implemented it but that does not answer my query. Becos both these implementations do
> not take care of the error returned, and it could well be the case for many of the current implementations.
Hi Manikandan,
If "max-link-speed" is not defined in the DT, then:
of_pci_get_max_link_speed
of_property_read_u32
of_property_read_u32_array
of_property_read_variable_u32_array
return -EINVAL;
For patch 0001, no actions will be executed. I wonder if this answers
your question?
Best regards,
Hans
>
>>>
>>>> pcie->reg_base = devm_platform_ioremap_resource_byname(pdev,
>>>> "reg");
>>>> if (IS_ERR(pcie->reg_base)) {
>>>> dev_err(dev, "missing \"reg\"\n");
>>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h
>>>> b/drivers/pci/controller/cadence/pcie-cadence.h
>>>> index 574e9cf4d003..042a4c49bb9a 100644
>>>> --- a/drivers/pci/controller/cadence/pcie-cadence.h
>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
>>>> @@ -86,6 +86,7 @@ struct cdns_plat_pcie_of_data {
>>>> * @ops: Platform-specific ops to control various inputs from Cadence PCIe
>>>> * wrapper
>>>> * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
>>>> + * @max_link_speed: Maximum supported link speed
>>>> */
>>>> struct cdns_pcie {
>>>> void __iomem *reg_base;
>>>> @@ -98,6 +99,7 @@ struct cdns_pcie {
>>>> struct device_link **link;
>>>> const struct cdns_pcie_ops *ops;
>>>> const struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
>>>> + int max_link_speed;
>>>> };
>>>>
>>>> /**
>>>> --
>>>> 2.43.0
>
^ permalink raw reply
* [PATCH v4 2/2] arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
From: Joseph Guo @ 2026-05-18 2:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, xinyu.chen,
qijian.guo, justin.jiang, Joseph Guo
In-Reply-To: <20260518-imx95_frdm_pro-v4-0-975346555a9b@nxp.com>
NXP i.MX95 19x19 FRDM PRO is cost-effective with extensive
expansion capabilities based on the i.MX95 19x19 SoC.
It is designed for AI and robotic situation.
Difference with i.MX95 15x15 FRDM:
- Use i.MX95 19x19 package
- Support 2 KEY-M M.2 PCIE
- 10G ETH interface
- Secure Element interface
Add device tree for this board. Including:
- LPUART1 and LPUART5
- NETC
- USB
- 2 M-Key M.2 PCIe
- uSDHC1, uSDHC2 and uSDHC3
- FlexCAN1 and FlexCAN3 (CAN1 is reserved by M7)
- LPI2C3, LPI2C4 and their child nodes
- Watchdog3
- SAI, MQS, MICFIL
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
Changes in v2:
- Run dt-format to reformat the node order
- Change compatible of mqs to audio-graph-card2
- Add imx95-19x19-frdm-pro in Makefile
Changes in v3:
- Change status of CAN1 to reserved
- Remove unused pinctrl
- Explain difference with i.MX95 15x15 FRDM in message
Changes in v4:
- Correct underscores in node names
- Correct 'silent-gpio' of can_phy to GPIO_ACTIVE_HIGH
- Fix typo in pinctrl_pcal6416
- Change 'reg_ext_12v' to 'reg_exp_12v'
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx95-19x19-frdm-pro.dts | 1021 ++++++++++++++++++++
2 files changed, 1022 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index a6fe56bb93aa12040d184aa576623951515a8469..af22a5aa3e96fa24ebf2766a98fea4d0948c50f4 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -462,6 +462,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-frdm-pro.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-frdm-pro.dts
new file mode 100644
index 0000000000000000000000000000000000000000..b87a26b0d7fcf5790a8cb616833c6f27d633bca0
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-frdm-pro.dts
@@ -0,0 +1,1021 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/usb/pd.h>
+#include "imx95.dtsi"
+
+#define FALLING_EDGE 1
+#define RISING_EDGE 2
+
+#define BRD_SM_CTRL_SD3_WAKE 0x8000 /*!< PCAL6408A-0 */
+#define BRD_SM_CTRL_PCIE1_WAKE 0x8001 /*!< PCAL6408A-4 */
+#define BRD_SM_CTRL_BT_WAKE 0x8002 /*!< PCAL6408A-5 */
+#define BRD_SM_CTRL_PCIE2_WAKE 0x8003 /*!< PCAL6408A-6 */
+#define BRD_SM_CTRL_BUTTON 0x8004 /*!< PCAL6408A-7 */
+
+/ {
+ model = "NXP FRDM-IMX95-PRO";
+ compatible = "fsl,imx95-19x19-frdm-pro", "fsl,imx95";
+
+ aliases {
+ ethernet0 = &enetc_port0;
+ ethernet1 = &enetc_port1;
+ gpio0 = &gpio1;
+ gpio1 = &gpio2;
+ gpio2 = &gpio3;
+ gpio3 = &gpio4;
+ gpio4 = &gpio5;
+ i2c0 = &lpi2c1;
+ i2c1 = &lpi2c2;
+ i2c2 = &lpi2c3;
+ i2c3 = &lpi2c4;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ serial0 = &lpuart1;
+ serial4 = &lpuart5;
+ };
+
+ bt_sco_codec: bt-sco-codec {
+ compatible = "linux,bt-sco";
+ #sound-dai-cells = <1>;
+ };
+
+ flexcan1_phy: can-phy0 {
+ compatible = "nxp,tja1057";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ silent-gpios = <&i2c4_gpio_expander_22 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ flexcan3_phy: can-phy2 {
+ compatible = "nxp,tja1057";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ silent-gpios = <&i2c4_gpio_expander_22 13 GPIO_ACTIVE_HIGH>;
+ };
+
+ chosen {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ stdout-path = &lpuart1;
+ };
+
+ reg_vref_1v8: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "+V1.8_SW";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "+V3.3_SW";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+
+ reg_dcdc_3v3: regulator-dcdc-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "DCDC_3V3";
+ regulator-always-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ vin-supply = <®_dcdc_5v>;
+ gpio = <&i2c4_gpio_expander_22 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_dcdc_5v: regulator-dcdc-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "DCDC_5V";
+ regulator-always-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ gpio = <&i2c4_gpio_expander_22 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_exp_1v8: regulator-exp-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "EXP_1V8";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ gpio = <&i2c4_gpio_expander_22 10 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_exp_3v3: regulator-exp-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "EXP_3V3";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ vin-supply = <®_dcdc_3v3>;
+ gpio = <&i2c4_gpio_expander_22 6 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_exp_5v: regulator-exp-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "EXP_5V";
+ regulator-always-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ vin-supply = <®_dcdc_5v>;
+ gpio = <&i2c4_gpio_expander_22 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_exp_12v: regulator-exp-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "VCCEXP_12V";
+ regulator-always-on;
+ regulator-max-microvolt = <12000000>;
+ regulator-min-microvolt = <12000000>;
+ gpio = <&i2c4_gpio_expander_22 17 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_m2_mkey_1_pwr: regulator-m2-mkey-1-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "M.2-power-mkey-1";
+ regulator-always-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&i2c3_gpio_expander_20 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_m2_mkey_2_pwr: regulator-m2-mkey-2-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "M.2-power-mkey-2";
+ regulator-always-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&i2c3_gpio_expander_20 6 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_m2_ekey_pwr: regulator-m2-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "M.2-power-ekey";
+ regulator-always-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&i2c4_gpio_expander_22 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_SD2_3V3";
+ off-on-delay-us = <12000>;
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usdhc3_vmmc: regulator-usdhc3 {
+ compatible = "regulator-fixed";
+ regulator-name = "WLAN_EN";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ vin-supply = <®_m2_ekey_pwr>;
+ gpio = <&i2c4_gpio_expander_22 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ /*
+ * IW612 wifi chip needs more delay than other wifi chips to complete
+ * the host interface initialization after power up, otherwise the
+ * internal state of IW612 may be unstable, resulting in the failure of
+ * the SDIO3.0 switch voltage.
+ */
+ startup-delay-us = <20000>;
+ };
+
+ reg_usb_vbus: regulator-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "USB_VBUS";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ gpio = <&i2c4_gpio_expander_22 0 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ ranges;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ linux_cma: linux,cma {
+ compatible = "shared-dma-pool";
+ alloc-ranges = <0 0x80000000 0 0x7F000000>;
+ reusable;
+ size = <0 0x3c000000>;
+ linux,cma-default;
+ };
+ };
+
+ sound-bt-sco {
+ compatible = "simple-audio-card";
+ simple-audio-card,bitclock-inversion;
+ simple-audio-card,bitclock-master = <&btcpu>;
+ simple-audio-card,format = "dsp_a";
+ simple-audio-card,frame-master = <&btcpu>;
+ simple-audio-card,name = "bt-sco-audio";
+
+ simple-audio-card,codec {
+ sound-dai = <&bt_sco_codec 1>;
+ };
+
+ btcpu: simple-audio-card,cpu {
+ dai-tdm-slot-num = <2>;
+ dai-tdm-slot-width = <16>;
+ sound-dai = <&sai5>;
+ };
+ };
+
+ sound-micfil {
+ compatible = "fsl,imx-audio-card";
+ model = "micfil-audio";
+
+ pri-dai-link {
+ format = "i2s";
+ link-name = "micfil hifi";
+
+ cpu {
+ sound-dai = <&micfil>;
+ };
+ };
+ };
+
+ sound-mqs {
+ compatible = "audio-graph-card2";
+ links = <&sai1_port1>;
+ label = "mqs-audio";
+ };
+
+ usdhc3_pwrseq: usdhc3-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&i2c4_gpio_expander_22 9 GPIO_ACTIVE_LOW>;
+ };
+
+ memory@80000000 {
+ reg = <0x0 0x80000000 0 0x80000000>;
+ device_type = "memory";
+ };
+};
+
+&adc1 {
+ vref-supply = <®_vref_1v8>;
+ status = "okay";
+};
+
+&enetc_port0 {
+ phy-handle = <ðphy0>;
+ phy-mode = "rgmii-id";
+ pinctrl-0 = <&pinctrl_enetc0>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&enetc_port1 {
+ phy-handle = <ðphy1>;
+ phy-mode = "rgmii-id";
+ pinctrl-0 = <&pinctrl_enetc1>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&flexcan1 {
+ phys = <&flexcan1_phy>;
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ pinctrl-names = "default";
+ status = "reserved";
+};
+
+&flexcan3 {
+ phys = <&flexcan3_phy>;
+ pinctrl-0 = <&pinctrl_flexcan3>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&lpi2c3 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c3>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ i2c3_gpio_expander_20: i2c3-gpio-expander@20 {
+ compatible = "nxp,pcal6416";
+ reg = <0x20>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio5>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ pinctrl-0 = <&pinctrl_pcal6416>;
+ pinctrl-names = "default";
+ };
+
+ ptn5110: tcpc@50 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x50>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&pinctrl_ptn5110>;
+ pinctrl-names = "default";
+
+ typec_con: connector {
+ compatible = "usb-c-connector";
+ data-role = "dual";
+ label = "USB-C";
+ op-sink-microwatt = <0>;
+ power-role = "dual";
+ self-powered;
+ sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "sink";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec_con_hs: endpoint {
+ remote-endpoint = <&usb3_data_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ typec_con_ss: endpoint {
+ remote-endpoint = <&usb3_data_ss>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&lpi2c4 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c4>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ i2c4_gpio_expander_22: i2c4-gpio-expander@22 {
+ compatible = "nxp,pcal6524";
+ reg = <0x22>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-line-names = "USB2 Power Enable",
+ "DCDC5V Enable",
+ "",
+ "SE Enable",
+ "",
+ "EXP 5V Enable",
+ "EXP 3V3 Enable",
+ "WIFI Power Enable",
+ "M2 DIS1 B",
+ "WIFI SD3 Reset",
+ "EXP 1V8 Enable",
+ "CAN1 Standby",
+ "M2 DIS2",
+ "CAN2 Standby",
+ "ETH 10G IO4",
+ "ETH 10G IO3",
+ "SPI3/GPIO select",
+ "EXP 12V Enable",
+ "DCDC 3V3 Enable",
+ "PCIE1 Reset",
+ "",
+ "ETH 10G CLK Enable",
+ "LVDS to HDMI converter IT6263 reset",
+ "";
+
+ /* When high, select lpspi; When low, select gpio. */
+ lpspi-gpio-sel-hog {
+ gpios = <16 GPIO_ACTIVE_HIGH>;
+ gpio-hog;
+ output-high;
+ };
+ };
+};
+
+&lpuart1 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&lpuart5 {
+ /* BT */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
+&micfil {
+ assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX95_CLK_PDM>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>,
+ <3612672000>, <393216000>,
+ <361267200>, <49152000>;
+ #sound-dai-cells = <0>;
+ pinctrl-0 = <&pinctrl_pdm>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&mqs1 {
+ clocks = <&scmi_clk IMX95_CLK_SAI1>;
+ clock-names = "mclk";
+ pinctrl-0 = <&pinctrl_mqs1>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ mqs1_port: port {
+ mqs1_ep: endpoint {
+ dai-format = "left_j";
+ remote-endpoint = <&sai1_port1_ep>;
+ };
+ };
+};
+
+&netc_blk_ctrl {
+ status = "okay";
+};
+
+&netc_emdio {
+ pinctrl-0 = <&pinctrl_emdio>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ ethphy0: ethernet-phy@1 {
+ reg = <1>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ reset-gpios = <&i2c3_gpio_expander_20 1 GPIO_ACTIVE_LOW>;
+ };
+
+ ethphy1: ethernet-phy@2 {
+ reg = <2>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ reset-gpios = <&i2c3_gpio_expander_20 2 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&netc_timer {
+ status = "okay";
+};
+
+&netcmix_blk_ctrl {
+ status = "okay";
+};
+
+&pcie0 {
+ pinctrl-0 = <&pinctrl_pcie0>;
+ pinctrl-names = "default";
+ reset-gpio = <&i2c4_gpio_expander_22 19 GPIO_ACTIVE_LOW>;
+ vpcie-supply = <®_m2_mkey_1_pwr>;
+ status = "okay";
+};
+
+&pcie1 {
+ pinctrl-0 = <&pinctrl_pcie1>;
+ pinctrl-names = "default";
+ reset-gpio = <&i2c3_gpio_expander_20 9 GPIO_ACTIVE_LOW>;
+ vpcie-supply = <®_m2_mkey_2_pwr>;
+ status = "okay";
+};
+
+&sai1 {
+ clocks = <&scmi_clk IMX95_CLK_BUSAON>, <&dummy>,
+ <&scmi_clk IMX95_CLK_SAI1>, <&dummy>,
+ <&dummy>, <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>;
+ clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k";
+ assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX95_CLK_SAI1>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>,
+ <3612672000>, <393216000>,
+ <361267200>, <24576000>;
+ #sound-dai-cells = <0>;
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* leave unconnected - no RX in the context of MQS */
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ };
+ };
+
+ sai1_port1: port@1 {
+ reg = <1>;
+ mclk-fs = <512>;
+
+ sai1_port1_ep: endpoint {
+ dai-format = "left_j";
+ system-clock-direction-out;
+ bitclock-master;
+ frame-master;
+ remote-endpoint = <&mqs1_ep>;
+ };
+ };
+ };
+};
+
+&sai5 {
+ assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX95_CLK_SAI5>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>,
+ <3612672000>, <393216000>,
+ <361267200>, <12288000>;
+ #sound-dai-cells = <0>;
+ pinctrl-0 = <&pinctrl_sai5>;
+ pinctrl-names = "default";
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
+&scmi_iomuxc {
+ pinctrl-0 = <&pinctrl_hog>;
+ pinctrl-names = "default";
+
+ pinctrl_emdio: emdiogrp {
+ fsl,pins = <
+ IMX95_PAD_ENET2_MDC__NETCMIX_TOP_NETC_MDC 0x50e
+ IMX95_PAD_ENET2_MDIO__NETCMIX_TOP_NETC_MDIO 0x90e
+ >;
+ };
+
+ pinctrl_enetc0: enetc0grp {
+ fsl,pins = <
+ IMX95_PAD_ENET1_TD3__NETCMIX_TOP_ETH0_RGMII_TD3 0x50e
+ IMX95_PAD_ENET1_TD2__NETCMIX_TOP_ETH0_RGMII_TD2 0x50e
+ IMX95_PAD_ENET1_TD1__NETCMIX_TOP_ETH0_RGMII_TD1 0x50e
+ IMX95_PAD_ENET1_TD0__NETCMIX_TOP_ETH0_RGMII_TD0 0x50e
+ IMX95_PAD_ENET1_TX_CTL__NETCMIX_TOP_ETH0_RGMII_TX_CTL 0x57e
+ IMX95_PAD_ENET1_TXC__NETCMIX_TOP_ETH0_RGMII_TX_CLK 0x58e
+ IMX95_PAD_ENET1_RX_CTL__NETCMIX_TOP_ETH0_RGMII_RX_CTL 0x57e
+ IMX95_PAD_ENET1_RXC__NETCMIX_TOP_ETH0_RGMII_RX_CLK 0x58e
+ IMX95_PAD_ENET1_RD0__NETCMIX_TOP_ETH0_RGMII_RD0 0x57e
+ IMX95_PAD_ENET1_RD1__NETCMIX_TOP_ETH0_RGMII_RD1 0x57e
+ IMX95_PAD_ENET1_RD2__NETCMIX_TOP_ETH0_RGMII_RD2 0x57e
+ IMX95_PAD_ENET1_RD3__NETCMIX_TOP_ETH0_RGMII_RD3 0x57e
+ >;
+ };
+
+ pinctrl_enetc1: enetc1grp {
+ fsl,pins = <
+ IMX95_PAD_ENET2_TD3__NETCMIX_TOP_ETH1_RGMII_TD3 0x50e
+ IMX95_PAD_ENET2_TD2__NETCMIX_TOP_ETH1_RGMII_TD2 0x50e
+ IMX95_PAD_ENET2_TD1__NETCMIX_TOP_ETH1_RGMII_TD1 0x50e
+ IMX95_PAD_ENET2_TD0__NETCMIX_TOP_ETH1_RGMII_TD0 0x50e
+ IMX95_PAD_ENET2_TX_CTL__NETCMIX_TOP_ETH1_RGMII_TX_CTL 0x57e
+ IMX95_PAD_ENET2_TXC__NETCMIX_TOP_ETH1_RGMII_TX_CLK 0x58e
+ IMX95_PAD_ENET2_RX_CTL__NETCMIX_TOP_ETH1_RGMII_RX_CTL 0x57e
+ IMX95_PAD_ENET2_RXC__NETCMIX_TOP_ETH1_RGMII_RX_CLK 0x58e
+ IMX95_PAD_ENET2_RD0__NETCMIX_TOP_ETH1_RGMII_RD0 0x57e
+ IMX95_PAD_ENET2_RD1__NETCMIX_TOP_ETH1_RGMII_RD1 0x57e
+ IMX95_PAD_ENET2_RD2__NETCMIX_TOP_ETH1_RGMII_RD2 0x57e
+ IMX95_PAD_ENET2_RD3__NETCMIX_TOP_ETH1_RGMII_RD3 0x57e
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ IMX95_PAD_SAI1_TXD0__AONMIX_TOP_CAN1_TX 0x39e
+ IMX95_PAD_SAI1_TXC__AONMIX_TOP_CAN1_RX 0x39e
+ >;
+ };
+
+ pinctrl_flexcan3: flexcan3grp {
+ fsl,pins = <
+ IMX95_PAD_CCM_CLKO3__CAN3_TX 0x39e
+ IMX95_PAD_CCM_CLKO4__CAN3_RX 0x39e
+ >;
+ };
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ IMX95_PAD_XSPI1_SS1_B__GPIO5_IO_BIT11 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ IMX95_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
+ IMX95_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c4: lpi2c4grp {
+ fsl,pins = <
+ IMX95_PAD_GPIO_IO30__LPI2C4_SDA 0x40000b9e
+ IMX95_PAD_GPIO_IO31__LPI2C4_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_mqs1: mqs1grp {
+ fsl,pins = <
+ IMX95_PAD_SAI1_TXFS__AONMIX_TOP_MQS1_LEFT 0x31e
+ IMX95_PAD_SAI1_RXD0__AONMIX_TOP_MQS1_RIGHT 0x31e
+ >;
+ };
+
+ pinctrl_pcal6416: pcal6416grp {
+ fsl,pins = <
+ IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14 0x31e
+ >;
+ };
+
+ pinctrl_pcie0: pcie0grp {
+ fsl,pins = <
+ IMX95_PAD_GPIO_IO32__HSIOMIX_TOP_PCIE1_CLKREQ_B 0x4000031e
+ >;
+ };
+
+ pinctrl_pcie1: pcie1grp {
+ fsl,pins = <
+ IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x4000031e
+ >;
+ };
+
+ pinctrl_pdm: pdmgrp {
+ fsl,pins = <
+ IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e
+ IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e
+ >;
+ };
+
+ pinctrl_ptn5110: ptn5110grp {
+ fsl,pins = <
+ IMX95_PAD_XSPI1_DQS__GPIO5_IO_BIT8 0x31e
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7 0x31e
+ >;
+ };
+
+ pinctrl_sai5: sai5grp {
+ fsl,pins = <
+ IMX95_PAD_XSPI1_DATA7__SAI5_RX_DATA_BIT0 0x31e
+ IMX95_PAD_XSPI1_DATA6__SAI5_TX_BCLK 0x31e
+ IMX95_PAD_XSPI1_DATA5__SAI5_TX_SYNC 0x31e
+ IMX95_PAD_XSPI1_DATA4__SAI5_TX_DATA_BIT0 0x31e
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX 0x31e
+ IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ IMX95_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e
+ IMX95_PAD_DAP_TDI__LPUART5_RX 0x31e
+ IMX95_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e
+ IMX95_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e
+ IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e
+ IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e
+ IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e
+ IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e
+ IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e
+ IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e
+ IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e
+ IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e
+ IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e
+ IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e
+ IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e
+ IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e
+ IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e
+ IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e
+ IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e
+ IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e
+ IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e
+ IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e
+ IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e
+ IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD1_CLK__USDHC1_CLK 0x15fe
+ IMX95_PAD_SD1_CMD__USDHC1_CMD 0x13fe
+ IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x13fe
+ IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x13fe
+ IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x13fe
+ IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x13fe
+ IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x13fe
+ IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x13fe
+ IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x13fe
+ IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x13fe
+ IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x31e
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ IMX95_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ IMX95_PAD_SD2_CMD__USDHC2_CMD 0x138e
+ IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e
+ IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e
+ IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e
+ IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e
+ IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ IMX95_PAD_SD2_CMD__USDHC2_CMD 0x138e
+ IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e
+ IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e
+ IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e
+ IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e
+ IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ IMX95_PAD_SD2_CMD__USDHC2_CMD 0x138e
+ IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e
+ IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e
+ IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e
+ IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e
+ IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e
+ IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e
+ IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e
+ IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e
+ IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e
+ IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e
+ IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e
+ IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e
+ IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e
+ IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e
+ IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ IMX95_PAD_SD3_CLK__USDHC3_CLK 0x15fe
+ IMX95_PAD_SD3_CMD__USDHC3_CMD 0x13fe
+ IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x13fe
+ IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x13fe
+ IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x13fe
+ IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x13fe
+ >;
+ };
+};
+
+&scmi_misc {
+ nxp,ctrl-ids = <BRD_SM_CTRL_SD3_WAKE FALLING_EDGE
+ BRD_SM_CTRL_PCIE1_WAKE FALLING_EDGE
+ BRD_SM_CTRL_BT_WAKE FALLING_EDGE
+ BRD_SM_CTRL_PCIE2_WAKE FALLING_EDGE
+ BRD_SM_CTRL_BUTTON FALLING_EDGE>;
+};
+
+&thermal_zones {
+ pf09-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 2>;
+
+ trips {
+ pf09_alert: trip0 {
+ hysteresis = <2000>;
+ temperature = <140000>;
+ type = "passive";
+ };
+
+ pf09_crit: trip1 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ pf53arm-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 4>;
+
+ cooling-maps {
+ map0 {
+ cooling-device = <&A55_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ trip = <&pf5301_alert>;
+ };
+ };
+
+ trips {
+ pf5301_alert: trip0 {
+ hysteresis = <2000>;
+ temperature = <140000>;
+ type = "passive";
+ };
+
+ pf5301_crit: trip1 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ pf53soc-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 3>;
+
+ trips {
+ pf5302_alert: trip0 {
+ hysteresis = <2000>;
+ temperature = <140000>;
+ type = "passive";
+ };
+
+ pf5302_crit: trip1 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+};
+
+&usb2 {
+ disable-over-current;
+ dr_mode = "host";
+ vbus-supply = <®_usb_vbus>;
+ status = "okay";
+};
+
+&usb3 {
+ status = "okay";
+};
+
+&usb3_dwc3 {
+ adp-disable;
+ dr_mode = "otg";
+ hnp-disable;
+ role-switch-default-mode = "peripheral";
+ srp-disable;
+ usb-role-switch;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
+ status = "okay";
+
+ port {
+ usb3_data_hs: endpoint {
+ remote-endpoint = <&typec_con_hs>;
+ };
+ };
+};
+
+&usb3_phy {
+ orientation-switch;
+ fsl,phy-pcs-tx-deemph-3p5db-attenuation-db = <17>;
+ fsl,phy-pcs-tx-swing-full-percent = <100>;
+ fsl,phy-tx-preemp-amp-tune-microamp = <600>;
+ fsl,phy-tx-vboost-level-microvolt = <1156>;
+ fsl,phy-tx-vref-tune-percent = <100>;
+ status = "okay";
+
+ port {
+ usb3_data_ss: endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+};
+
+&usdhc1 {
+ bus-width = <8>;
+ non-removable;
+ no-sd;
+ no-sdio;
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ pinctrl-3 = <&pinctrl_usdhc1>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ status = "okay";
+};
+
+&usdhc2 {
+ bus-width = <4>;
+ cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-3 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ vmmc-supply = <®_usdhc2_vmmc>;
+ status = "okay";
+};
+
+&usdhc3 {
+ bus-width = <4>;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&usdhc3_pwrseq>;
+ non-removable;
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ pinctrl-3 = <&pinctrl_usdhc3>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ vmmc-supply = <®_usdhc3_vmmc>;
+ wakeup-source;
+ status = "okay";
+};
+
+&wdog3 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: arm: fsl: Add i.MX95 19x19 FRDM PRO board
From: Joseph Guo @ 2026-05-18 2:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, xinyu.chen,
qijian.guo, justin.jiang, Joseph Guo, Daniel Baluta, Conor Dooley
In-Reply-To: <20260518-imx95_frdm_pro-v4-0-975346555a9b@nxp.com>
Add the i.MX95 19x19 FRDM PRO board in the binding document.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index f5d3c08369b92987b2cb01e36c26f9f72937f557..9f50b4bf67bc2c0b0e11b1ae615151aa4d5f0d09 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1485,6 +1485,7 @@ properties:
- fsl,imx95-15x15-evk # i.MX95 15x15 EVK Board
- fsl,imx95-15x15-frdm # i.MX95 15x15 FRDM Board
- fsl,imx95-19x19-evk # i.MX95 19x19 EVK Board
+ - fsl,imx95-19x19-frdm-pro # i.MX95 19x19 FRDM PRO Board
- toradex,verdin-imx95-19x19-evk # i.MX95 Verdin Evaluation Kit (EVK)
- const: fsl,imx95
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/2] Add NXP FRDM-IMX95-PRO board support
From: Joseph Guo @ 2026-05-18 2:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, xinyu.chen,
qijian.guo, justin.jiang, Joseph Guo, Daniel Baluta, Conor Dooley
This patchset add Devicetree support for NXP FRDM-IMX95-PRO
development board based on i.MX95 19x19 SoC.
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
Changes in v4:
- Correct underscores in node names
- Correct 'silent-gpio' of can_phy to GPIO_ACTIVE_HIGH
- Fix typo in pinctrl_pcal6416
- Link to v3: https://lore.kernel.org/r/20260509-imx95_frdm_pro-v3-0-96290b471396@nxp.com
Changes in v3:
- Change status of CAN1 to reserved
- Remove unused pinctrl
- Explain difference with i.MX95 15x15 FRDM in message
- Link to v2: https://lore.kernel.org/r/20260428-imx95_frdm_pro-v2-0-434240b652f4@nxp.com
Changes in v2:
- Run dt-format to reformat the node order
- Change compatible of mqs to audio-graph-card2
- Add imx95-19x19-frdm-pro in Makefile
- Link to v1: https://lore.kernel.org/r/20260318-imx95_frdm_pro-v1-0-8c00e59f0b1b@nxp.com
---
Joseph Guo (2):
dt-bindings: arm: fsl: Add i.MX95 19x19 FRDM PRO board
arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx95-19x19-frdm-pro.dts | 1021 ++++++++++++++++++++
3 files changed, 1023 insertions(+)
---
base-commit: 7109a2155340cc7b21f27e832ece6df03592f2e8
change-id: 20260311-imx95_frdm_pro-7a8d03b50982
Best regards,
--
Joseph Guo <qijian.guo@nxp.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox