* [PATCH v15 0/3] of: parsing of multi #{iommu,msi}-cells in maps
From: Vijayanand Jitta @ 2026-05-20 8:02 UTC (permalink / raw)
To: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia
Cc: linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Vijayanand Jitta, Charan Teja Kalla
So far our parsing of {iommu,msi}-map properties has always blindly
assumed that the output specifiers will always have exactly 1 cell.
This typically does happen to be the case, but is not actually enforced
(and the PCI msi-map binding even explicitly states support for 0 or 1
cells) - as a result we've now ended up with dodgy DTs out in the field
which depend on this behaviour to map a 1-cell specifier for a 2-cell
provider, despite that being bogus per the bindings themselves.
Since there is some potential use[1] in being able to map at least
single input IDs to multi-cell output specifiers (and properly support
0-cell outputs as well), add support for properly parsing and using the
target nodes' #cells values, albeit with the unfortunate complication of
still having to work around expectations of the old behaviour too.
-- Robin.
Unlike single #{}-cell, it is complex to establish a linear relation
between input 'id' and output specifier for multi-cell properties, thus
it is always expected that len never going to be > 1.
These changes have been tested on QEMU for the arm64 architecture.
Since, this would also need update in dt-schema, raised PR[2] for the
same.
[1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/
[2] PR for iommu-map dtschema: https://github.com/devicetree-org/dt-schema/pull/184
V15:
Address Sashiko AI review comments on v14:
Patch 2:
- [Critical] pci-imx6: pass &msi_filter (not NULL) to of_map_msi_id()
so that of_map_id() returns -ENODEV when msi-map is absent, preventing
the '!err_m && !msi_spec.np' path from incorrectly returning -EINVAL
- [High] of_map_id(): explicitly set arg->np = NULL before any bypass
path so callers can safely call of_node_put(arg->np) on all return paths
- [Medium] of_msi_xlate(): pass msi_np directly to of_map_msi_id() and
of_check_msi_parent() (removing the local_np/np indirection), and use
'break' (not 'continue') when msi_spec.np is NULL so that msi-parent
bindings are still checked when msi-map is present but has no match
- Guard 'id_out = msi_spec.args[0]' with 'args_count > 0' in
of_msi_xlate() to correctly handle 0-cell MSI output specifiers
- Use of_node_get() + unconditional of_node_put() in of_msi_xlate()
for clearer reference ownership
Patch 3:
- [Critical] of_map_id(): add 'cells > MAX_PHANDLE_ARGS' check before
using cells as an array index to prevent stack buffer overflow
- [High] of_map_id(): the MAX_PHANDLE_ARGS bound on cells also prevents
integer overflow in the '3 + cells' length check
- [High] of_map_id(): fix misleading bad-map workaround message from
"assuming extra cell of 0" to "treating as 1-cell output" to accurately
describe the actual behavior
- [Medium] of_msi_xlate(): guard 'id_out = msi_spec.args[0]' with
'args_count > 0' to preserve id_in for 0-cell MSI output specifiers
Link to v14:
https://patch.msgid.link/20260424-parse_iommu_cells-v14-0-fd02f11b6c38@oss.qualcomm.com
V14:
- Updated Patch 2 ("of: Factor arguments passed to of_map_id() into a struct") to
fix below two issues in of_msi_xlate() that were introduced by the API refactoring:
1) The refactoring changed of_map_id()'s dual-purpose **target parameter to
an explicit filter_np parameter. In of_msi_xlate(), this caused
of_map_msi_id() to return 0 (pass-through) instead of -ENODEV when a node
has no msi-map, terminating the device hierarchy walk prematurely before
reaching the root complex node that has the msi-map. This broke MSI
allocation for PCIe endpoint devices (e.g., wcn7850 Wi-Fi on ARM64).
2) Additionally, fsl_mc_get_msi_id() passes msi_np == NULL to of_msi_xlate(),
which would dereference NULL with the new API.
Link to v13:
https://patch.msgid.link/20260408-parse_iommu_cells-v13-0-fa921e92661b@oss.qualcomm.com
V13:
- Fix bad_map handling in of_map_id(): 'cells' is re-initialized to 0
on each loop iteration, so the !bad_map guard was insufficient, cells
stayed 0 for all entries after the first. Fix by explicitly setting
cells=1 when bad_map is true on every iteration.
- Collected Acked-by from Frank Li.
Link to v12:
https://patch.msgid.link/20260331-parse_iommu_cells-v12-0-decfd305eea9@oss.qualcomm.com
V12:
- Call of_node_put() unconditionally in imx_pcie_add_lut_by_rid()
thereby addressing comments from Bjorn Helgaas.
Link to v11:
https://lore.kernel.org/r/20260325-parse_iommu_cells-v11-0-1fefa5c0e82c@oss.qualcomm.com
V11:
- Added explicit filter_np parameter to of_map_id() and of_map_msi_id()
per Dmitry Baryshkov's review feedback, making the filter explicit
instead of overloading arg->np as both input filter and output parameter.
- Removed of_node_put() from inside of_map_id(), making the caller responsible
for reference management. Updated of_msi_xlate() to properly handle reference counting.
- Collected ACKed by tags, and fixed minor typos.
Link to v10:
https://lore.kernel.org/r/20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com
V10:
- Move of_map_iommu_id()/of_map_msi_id() from include/linux/of.h to
drivers/of/base.c as out-of-line helpers per feedback from Marc Zyngier
and Rob Herring.
- Add kernel-doc to document both helpers for discoverability and
usage clarity.
- Fix of_map_msi_id() wrapper and all its callers (cdx_msi.c,
irq-gic-its-msi-parent.c, drivers/of/irq.c) to correctly use the new
struct of_phandle_args-based API with proper of_node_put() handling
as per feeback from Dmitry.
Link to v9:
https://lore.kernel.org/r/20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com
V9:
- Updated TO/CC list based on feedback to include all relevant
maintainers.
- No functional changes to the patches themselves.
Link to V8:
https://lore.kernel.org/all/20260226074245.3098486-1-vijayanand.jitta@oss.qualcomm.com/
V8:
- Removed mentions of of_map_args from commit message to match code.
Link to V7:
https://lore.kernel.org/all/20260210101157.2145113-1-vijayanand.jitta@oss.qualcomm.com/
V7:
- Removed of_map_id_args structure and replaced it with
of_phandle_args as suggested by Dmitry.
Link to V6:
https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
V6:
- Fixed build error reported by kernel test bot.
Link to V5:
https://lore.kernel.org/all/20260118181125.1436036-1-vijayanand.jitta@oss.qualcomm.com/
V5:
- Fixed Build Warnings.
- Raised PR for iommu-map dtschema: https://github.com/devicetree-org/dt-schema/pull/184
Link to V4:
https://lore.kernel.org/all/20251231114257.2382820-1-vijayanand.jitta@oss.qualcomm.com/
V4:
- Added Reviewed-by tag.
- Resolved warnings reported by kernel test bot, minor code
reorganization.
Link to V3:
https://lore.kernel.org/all/20251221213602.2413124-1-vijayanand.jitta@oss.qualcomm.com/
V3:
- Added Reviewed-by tag.
- Updated of_map_id_args struct as a wrapper to of_phandle_args and
added comment description as suggested by Rob Herring.
Link to V2:
https://lore.kernel.org/all/20251204095530.8627-1-vijayanand.jitta@oss.qualcomm.com/
V2:
- Incorporated the patches from Robin that does the clean implementation.
- Dropped the patches the were adding multi-map support from this series
as suggested.
V1:
https://lore.kernel.org/all/cover.1762235099.git.charan.kalla@oss.qualcomm.com/
RFC:
https://lore.kernel.org/all/20250928171718.436440-1-charan.kalla@oss.qualcomm.com/#r
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
---
To: Nipun Gupta <nipun.gupta@amd.com>
To: Nikhil Agarwal <nikhil.agarwal@amd.com>
To: Joerg Roedel <joro@8bytes.org>
To: Will Deacon <will@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Marc Zyngier <maz@kernel.org>
To: Thomas Gleixner <tglx@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Saravana Kannan <saravanak@kernel.org>
To: Richard Zhu <hongxing.zhu@nxp.com>
To: Lucas Stach <l.stach@pengutronix.de>
To: Krzysztof Wilczyński <kwilczynski@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>
To: Frank Li <Frank.Li@nxp.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
To: Pengutronix Kernel Team <kernel@pengutronix.de>
To: Fabio Estevam <festevam@gmail.com>
To: Juergen Gross <jgross@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>
To: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: iommu@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: xen-devel@lists.xenproject.org
---
To: Nipun Gupta <nipun.gupta@amd.com>
To: Nikhil Agarwal <nikhil.agarwal@amd.com>
To: Joerg Roedel <joro@8bytes.org>
To: Will Deacon <will@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Marc Zyngier <maz@kernel.org>
To: Thomas Gleixner <tglx@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Saravana Kannan <saravanak@kernel.org>
To: Richard Zhu <hongxing.zhu@nxp.com>
To: Lucas Stach <l.stach@pengutronix.de>
To: Krzysztof Wilczyński <kwilczynski@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>
To: Frank Li <Frank.Li@nxp.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
To: Pengutronix Kernel Team <kernel@pengutronix.de>
To: Fabio Estevam <festevam@gmail.com>
To: Juergen Gross <jgross@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>
To: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: iommu@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: xen-devel@lists.xenproject.org
---
Charan Teja Kalla (1):
of: Factor arguments passed to of_map_id() into a struct
Robin Murphy (2):
of: Add convenience wrappers for of_map_id()
of: Respect #{iommu,msi}-cells in maps
drivers/cdx/cdx_msi.c | 10 +-
drivers/iommu/of_iommu.c | 6 +-
drivers/irqchip/irq-gic-its-msi-parent.c | 10 +-
drivers/of/base.c | 227 +++++++++++++++++++++++++------
drivers/of/irq.c | 25 +++-
drivers/pci/controller/dwc/pci-imx6.c | 55 ++++----
drivers/pci/controller/pcie-apple.c | 6 +-
drivers/xen/grant-dma-ops.c | 5 +-
include/linux/of.h | 32 ++++-
9 files changed, 277 insertions(+), 99 deletions(-)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260301-parse_iommu_cells-1c33768aebba
Best regards,
--
Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 6/7] mm/vmalloc: align vm_area so vmap() can batch mappings
From: Barry Song @ 2026-05-20 7:55 UTC (permalink / raw)
To: Uladzislau Rezki
Cc: Wen Jiang, linux-mm, linux-arm-kernel, catalin.marinas, will,
akpm, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <ag1jhrWivbasi8Jq@milan>
On Wed, May 20, 2026 at 3:37 PM Uladzislau Rezki <urezki@gmail.com> wrote:
>
> On Thu, May 14, 2026 at 05:41:07PM +0800, Wen Jiang wrote:
> > From: "Barry Song (Xiaomi)" <baohua@kernel.org>
> >
> > Try to align the vmap virtual address to PMD_SHIFT or a
> > larger PTE mapping size hinted by the architecture, so
> > contiguous pages can be batch-mapped when setting PMD or
> > PTE entries.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> > Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > ---
> > mm/vmalloc.c | 31 ++++++++++++++++++++++++++++++-
> > 1 file changed, 30 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index c30a7673e..b3389c8f1 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3591,6 +3591,35 @@ static int __vmap_huge(unsigned long addr, unsigned long end,
> > return err;
> > }
> >
> > +static struct vm_struct *get_aligned_vm_area(unsigned long size, unsigned long flags)
> > +{
> > + unsigned int shift = (size >= PMD_SIZE) ? PMD_SHIFT :
> > + arch_vmap_pte_supported_shift(size);
> > + struct vm_struct *vm_area = NULL;
> > +
> > + /*
> > + * Try to allocate an aligned vm_area so contiguous pages can be
> > + * mapped in batches.
> > + */
> > + while (1) {
> > + unsigned long align = 1UL << shift;
> > +
> > + vm_area = __get_vm_area_node(size, align, PAGE_SHIFT, flags,
> > + VMALLOC_START, VMALLOC_END,
> > + NUMA_NO_NODE, GFP_KERNEL,
> > + __builtin_return_address(0));
> > + if (vm_area || shift <= PAGE_SHIFT)
> > + goto out;
> > + if (shift == PMD_SHIFT)
> > + shift = arch_vmap_pte_supported_shift(size);
> > + else if (shift > PAGE_SHIFT)
> > + shift = PAGE_SHIFT;
> > + }
> > +
> > +out:
> > + return vm_area;
> > +}
> > +
> IMO, we should get rid of this while(1) loop. It looks like you need to
> handle just few cases. 3?
Hi Uladzislau,
I don’t quite understand what you mean — are you suggesting
calling __get_vm_area_node() three times? We try 2MB first,
then 64KB, and finally 4KB. If 2MB succeeds, there is no
reason to try 64KB. Likewise, if 64KB succeeds, there is no
need to fall back to 4KB.
>
>
> shift min value is PAGE_SHIFT, could you please clarify when it can be less?
I guess this should be changed to "==" ?
Thanks
Barry
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-20 7:50 UTC (permalink / raw)
To: Barry Song
Cc: Suren Baghdasaryan, Matthew Wilcox, akpm, linux-mm, david, liam,
vbabka, rppt, mhocko, jack, pfalcato, wanglian, chentao,
lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng,
nphamcs, bhe, youngjun.park, linux-arm-kernel, linux-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAGsJ_4zxyZP_xkFCGWfLyXkqomrX6DNqyMVirk=aggtwB1zExw@mail.gmail.com>
On Wed, May 20, 2026 at 05:18:52AM +0800, Barry Song wrote:
> On Tue, May 19, 2026 at 8:53 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
> >
> > > >
> > > > I think we either need to fix `fork()`, or keep the current
> > > > behavior of dropping the VMA lock before performing I/O.
> > >
> > > I see. So, this problem arises from the fact that we are changing the
> > > pagefaults requiring I/O operation to hold VMA lock...
> > > And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> > > is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> > > anonymous and COW VMAs only while holding mmap_write_lock, preventing
> > > any VMA modification. On the surface, that looks ok to me but I might
> > > be missing some corner cases. If nobody sees any obvious issues, I
> > > think it's worth a try.
> >
> > Not sure if you noticed but I did raise concerns ;)
> >
> > I wonder if you've confused the fault path and fork here, as I think Barry has
> > been a little unclear on that.
>
> I think I’ve been absolutely clear :-)
On this point sure, I would argue less so around the fork stuff but I responded
on that specifically elsewhere so let's keep things moving :>)
> We should either stick to the current behavior - drop
> the VMA lock before doing I/O, or change fork() so that it
> does not wait on vma_start_write().
Again, as I said elsewhere, I think there might be a 3rd way possibly. It's a
big mistake to assume that there are only specific solutions to problems in the
kernel then to present a false dichotomy.
We absolutely hear you on this being a problem and it WILL be addressed one way
or another.
Of the two approaches, as I said elsewhere, I prefer what you've done in this
series to anything touching fork.
But give me time to look through the series please (I'd also suggest RFC'ing
when it's something kinda fundamental that might generate converastion, makes
life a bit easier on the review side :)
>
> Before per-VMA locks, page faults dropped mmap_lock before
> doing I/O. After per-VMA locks, page faults dropped the
> VMA lock before doing I/O. In both cases, fork() would not
> wait for I/O in the page-fault path.
>
> Now you guys are suggesting performing I/O while holding
> the VMA lock, which means fork() must wait for that I/O to
> complete. Since an application can have more than 1000
> VMAs, and I/O can be stalled for an unpredictable amount
> of time in the bio/request queue or filesystem GC, fork()
> could end up blocked on multiple VMAs while taking
> vma_start_write() for each of them.
>
> As a result, fork() could hold mmap_lock for a very, very,
> very long time. fork() itself would become extremely slow,
> and any other task needing mmap_lock would also be blocked
> behind it.
Yep aware, we spoke in Zagreb about this, and on this thread, we know :)
>
> >
> > What's being suggested in this thread is to fundamentally change fork behaviour
> > so it's different from the entire history of the kernel (or - presumably - at
> > least recent history :) and permit concurrent page faults to occur on a forking
> > process.
> >
> > I absolutely object to this for being pretty crazy. I mean I'm not sure we
> > really want to be simultaneously modifying page tables while invoking
> > copy_page_range()? No?
>
> If you object to touching fork(), can you at least accept
> keeping the existing behavior of dropping the VMA lock
> before doing I/O? If you object to both approaches, then I
> really do not know how we can continue :-)
Again as per above, let's not impose a false dichtomy, let's take our time, and
specifically - please give me time to read through the series and think about
this.
>
> Thanks
> Barry
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH v2 1/3] crypto: atmel-sha204a - Drop of_device_id data
From: Ard Biesheuvel @ 2026-05-20 7:49 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub), Thorsten Blum,
Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <d0fc3069860f9e31122c1af635a1114dd2c443cf.1779260113.git.u.kleine-koenig@baylibre.com>
On Wed, 20 May 2026, at 09:01, Uwe Kleine-König (The Capable Hub) wrote:
> The driver binds to i2c devices only and thus in the absence of an
> assignment for .data in the of_device_id array i2c_get_match_data()
> falls back to .driver_data from the i2c_device_id array. So only provide
> &atsha204_quality once to reduce duplication.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> drivers/crypto/atmel-sha204a.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> index 6e6ac4770416..f17e1f6af1a3 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -208,8 +208,8 @@ static void atmel_sha204a_remove(struct i2c_client *client)
> }
>
> static const struct of_device_id atmel_sha204a_dt_ids[] = {
> - { .compatible = "atmel,atsha204", .data = &atsha204_quality },
> - { .compatible = "atmel,atsha204a", },
> + { .compatible = "atmel,atsha204" },
> + { .compatible = "atmel,atsha204a" },
> { }
> };
> MODULE_DEVICE_TABLE(of, atmel_sha204a_dt_ids);
Just trying to figure out how this is supposed to work:
i2c_get_match_data()
data = device_get_match_data(&client->dev);
... returns NULL ...
if (!data) {
match = i2c_match_id(driver->id_table, client);
... compares client->name with { "atsha204", "atsha204a" }
So we will be relying on client->name having been set to either
"atsha204" or "atsha204a" on the DT probe path before
i2c_match_data() is called, but I am struggling to see where
that might happen.
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: arm: fsl: add TQMa8MPxS board
From: Alexander Stein @ 2026-05-20 7:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Paul Gerber, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc, Alexander Stein, Conor Dooley
From: Paul Gerber <paul.gerber@tq-group.com>
TQMa8MPxS is a SOM family using NXP i.MX8MP CPU family.
MB-SMARC-2 is an evaluation mainbord for this SOM
The SOM needs a mainboard, therefore we provide two compatibles here:
"tq,imx8mp-<SOM>" for the module and
"tq,imx8mp-<SOM>-<SBC>"
Signed-off-by: Paul Gerber <paul.gerber@tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes in v2:
* Added Conor's a-b
Documentation/devicetree/bindings/arm/fsl.yaml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 4d167cf392830..67437c8d669dd 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1310,6 +1310,18 @@ properties:
- const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
- const: fsl,imx8mp
+ - description:
+ TQMa8MPxS is a series of SOM featuring NXP i.MX8MP system-on-chip
+ variants. It has the SMARC-2.0 form factor and is designed to be
+ placed on different carrier boards. All CPU variants use the same
+ device tree hence only one compatible is needed. MB-SMARC-2 is a
+ carrier reference design.
+ items:
+ - enum:
+ - tq,imx8mp-tqma8mpqs-mb-smarc-2 # TQ-Systems GmbH i.MX8MP TQMa8MPQS SOM on MB-SMARC-2
+ - const: tq,imx8mp-tqma8mpqs # TQ-Systems GmbH i.MX8MP TQMa8MPQS SOM
+ - const: fsl,imx8mp
+
- description: Variscite VAR-SOM-MX8M Plus based boards
items:
- const: variscite,var-som-mx8mp-symphony
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP
From: Alexander Stein @ 2026-05-20 7:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Paul Gerber, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc, Alexander Stein
In-Reply-To: <20260520074754.1631543-1-alexander.stein@ew.tq-group.com>
From: Paul Gerber <paul.gerber@tq-group.com>
This adds support for TQMa8MPQS module on MB-SMARC-2 board.
Signed-off-by: Paul Gerber <paul.gerber@tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v2:
* Do not enable DSI-DP bridge (yet). Needs additional patches
* Already source disp1 (DSI) clock from audio pll
will be required once DSI and LVDS are enabled at the same time
* Move 'maximum-speed' property to correct node (dwc3 core)
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts | 378 ++++++
.../boot/dts/freescale/imx8mp-tqma8mpqs.dtsi | 1177 +++++++++++++++++
3 files changed, 1556 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index af0df42324aa4..8164dfc200ede 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -326,6 +326,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-jutouch-jt101tm023.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mpxl.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2.dtb
imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10-dtbs += imx8mp-tx8p-ml81-moduline-display-106.dtb \
imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts
new file mode 100644
index 0000000000000..360a0253a3c02
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts
@@ -0,0 +1,378 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Paul Gerber
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>
+#include "imx8mp-tqma8mpqs.dtsi"
+
+/ {
+ model = "TQ-Systems i.MX8MPlus TQMa8MPxS on MB-SMARC-2";
+ compatible = "tq,imx8mp-tqma8mpqs-mb-smarc-2", "tq,imx8mp-tqma8mpqs", "fsl,imx8mp";
+ chassis-type = "embedded";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+
+ aliases {
+ ethernet0 = &eqos;
+ ethernet1 = &fec;
+ mmc0 = &usdhc3;
+ mmc1 = &usdhc2;
+ rtc0 = &pcf85063;
+ rtc1 = &snvs_rtc;
+ spi0 = &flexspi;
+ spi1 = &ecspi1;
+ spi2 = &ecspi2;
+ spi3 = &ecspi3;
+ };
+
+ backlight_lvds0: backlight-lvds0 {
+ compatible = "pwm-backlight";
+ pwms = <&pwm3 0 100000 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = <&expander0 0 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_12v0>;
+ status = "disabled";
+ };
+
+ backlight_lvds1: backlight-lvds1 {
+ compatible = "pwm-backlight";
+ pwms = <&pwm2 0 100000 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = <&expander0 2 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_12v0>;
+ status = "disabled";
+ };
+
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "X6";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
+ panel_lvds0: panel-lvds0 {
+ /*
+ * Display is not fixed, so compatible has to be added from
+ * DT overlay
+ */
+ backlight = <&backlight_lvds0>;
+ power-supply = <®_lvds0>;
+ status = "disabled";
+
+ port {
+ panel_in_lvds0: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+ };
+
+ panel_lvds1: panel-lvds1 {
+ /*
+ * Display is not fixed, so compatible has to be added from
+ * DT overlay
+ */
+ backlight = <&backlight_lvds1>;
+ power-supply = <®_lvds1>;
+ status = "disabled";
+
+ port {
+ panel_in_lvds1: endpoint {
+ remote-endpoint = <&ldb_lvds_ch1>;
+ };
+ };
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_12v0: regulator-12v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "12V0";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_lvds0: regulator-lvds0 {
+ compatible = "regulator-fixed";
+ regulator-name = "LCD0_VDD_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&expander0 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_lvds1: regulator-lvds1 {
+ compatible = "regulator-fixed";
+ regulator-name = "LCD1_VDD_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&expander0 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* global autoconfigured region for contiguous allocations */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0 0x38000000>;
+ alloc-ranges = <0 0x40000000 0 0x78000000>;
+ linux,cma-default;
+ };
+ };
+
+ sound {
+ compatible = "fsl,imx-audio-tlv320aic32x4";
+ model = "tqm-tlv320aic32";
+ audio-asrc = <&easrc>;
+ audio-cpu = <&sai5>;
+ audio-codec = <&tlv320aic3x04>;
+ audio-routing =
+ "IN3_L", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "IN1_L", "Line In Jack",
+ "IN1_R", "Line In Jack",
+ "Line Out Jack", "LOL",
+ "Line Out Jack", "LOR";
+ };
+
+ usb-connector {
+ compatible = "gpio-usb-b-connector", "usb-b-connector";
+ type = "micro";
+ label = "X4";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbcon0>;
+ id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+
+ port {
+ usb_dr_connector: endpoint {
+ remote-endpoint = <&usb3_dwc>;
+ };
+ };
+ };
+};
+
+&easrc {
+ status = "okay";
+};
+
+&ecspi1 {
+ status = "okay";
+};
+
+&eqos {
+ status = "okay";
+};
+
+ðphy0 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+ };
+};
+
+ðphy3 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+ };
+};
+
+&fec {
+ status = "okay";
+};
+
+&flexcan1 {
+ xceiver-supply = <®_3v3>;
+ status = "okay";
+};
+
+&flexcan2 {
+ xceiver-supply = <®_3v3>;
+ status = "okay";
+};
+
+&hdmi_pvi {
+ status = "okay";
+};
+
+&hdmi_tx {
+ status = "okay";
+
+ ports {
+ port@1 {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
+
+&hdmi_tx_phy {
+ status = "okay";
+};
+
+&i2c1 {
+ tlv320aic3x04: audio-codec@18 {
+ compatible = "ti,tlv320aic32x4";
+ reg = <0x18>;
+ clock-names = "mclk";
+ clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_MCLK1>;
+ iov-supply = <®_1v8>;
+ ldoin-supply = <®_3v3>;
+ };
+
+ eeprom2: eeprom@57 {
+ compatible = "atmel,24c32";
+ reg = <0x57>;
+ pagesize = <32>;
+ vcc-supply = <®_3v3>;
+ };
+};
+
+&ldb_lvds_ch0 {
+ remote-endpoint = <&panel_in_lvds0>;
+};
+
+&ldb_lvds_ch1 {
+ remote-endpoint = <&panel_in_lvds1>;
+};
+
+&lcdif1 {
+ status = "okay";
+};
+
+&lcdif3 {
+ status = "okay";
+};
+
+&pcie_phy {
+ fsl,clkreq-unsupported;
+ status = "okay";
+};
+
+&pcie {
+ status = "okay";
+};
+
+®_usdhc2_vmmc {
+ startup-delay-us = <100>;
+ off-on-delay-us = <200000>;
+ status = "okay";
+};
+
+®_usdhc2_vqmmc {
+ status = "okay";
+};
+
+&sai3 {
+ status = "okay";
+};
+
+&sai5 {
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&usb3_0 {
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ status = "okay";
+
+ port {
+ usb3_dwc: endpoint {
+ remote-endpoint = <&usb_dr_connector>;
+ };
+ };
+};
+
+&usdhc2 {
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ no-mmc;
+ no-sdio;
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
new file mode 100644
index 0000000000000..9576152657405
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
@@ -0,0 +1,1177 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Paul Gerber
+ */
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include "imx8mp.dtsi"
+
+/ {
+ model = "TQ-Systems i.MX8MPlus TQMa8MPxS";
+ compatible = "tq,imx8mp-tqma8mpqs", "fsl,imx8mp";
+
+ clk_dp: clk-dp {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+
+ clk_xtal25: clk-xtal25 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x0 0x40000000 0 0x80000000>;
+ };
+
+ reg_5v0: regulator-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_5V0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ regulator-name = "SDIO_PWR_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ status = "disabled";
+ };
+
+ reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc {
+ compatible = "regulator-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vqmmc>;
+ regulator-name = "V_SD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x1>,
+ <3300000 0x0>;
+ vin-supply = <&ldo5>;
+ status = "disabled";
+ };
+};
+
+&A53_0 {
+ cpu-supply = <&buck2>;
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>, <&gpio5 12 GPIO_ACTIVE_LOW>;
+};
+
+/* GBE0 */
+&eqos {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ snps,force_thresh_dma_mode;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos_phy>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ reset-gpios = <&expander0 6 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ enet-phy-lane-no-swap;
+ interrupt-parent = <&gpio2>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ ethphy3: ethernet-phy@3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec_phy>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <3>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ reset-gpios = <&expander0 7 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ enet-phy-lane-no-swap;
+ interrupt-parent = <&gpio2>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <5>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ };
+
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x4>;
+ };
+
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x8>;
+ };
+
+ queue4 {
+ snps,dcb-algorithm;
+ snps,priority = <0xf0>;
+ };
+ };
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <5>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ snps,map-to-dma-channel = <0>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ snps,map-to-dma-channel = <1>;
+ };
+
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x4>;
+ snps,map-to-dma-channel = <2>;
+ };
+
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x8>;
+ snps,map-to-dma-channel = <3>;
+ };
+
+ queue4 {
+ snps,dcb-algorithm;
+ snps,priority = <0xf0>;
+ snps,map-to-dma-channel = <4>;
+ };
+ };
+};
+
+/* GBE1 */
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy3>;
+ fsl,magic-packet;
+};
+
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+};
+
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+};
+
+&flexspi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexspi0>;
+ status = "okay";
+
+ flash0: flash@0 {
+ reg = <0>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <66666666>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ vcc-supply = <&buck5>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
+};
+
+&gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio1>;
+
+ gpio-line-names = "SLEEP", "BATLOW#", "", "LID",
+ "", "GPIO10", "CHARGING#", "CHG_PRSNT#",
+ "PMIC_IRQ#", "ESPI_CS1_ALERT#", "USB1_OTG_ID", "USB2_OTG_ID",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+
+ pmic_irq_hog: pmic-irq-hog {
+ gpio-hog;
+ gpios = <8 0>;
+ input;
+ line-name = "PMIC_IRQ#";
+ };
+};
+
+&gpio2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hoggpio2>;
+
+ gpio-line-names = "", "", "", "",
+ "", "", "", "",
+ "", "", "PERST#", "PEWAKE#",
+ "SDIO_CD#", "", "", "",
+ "", "", "", "SDIO_PWR_EN",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+
+ enet0-int-hog {
+ gpio-hog;
+ gpios = <0 0>;
+ input;
+ line-name = "ENET0_INT#";
+ };
+
+ enet1-int-hog {
+ gpio-hog;
+ gpios = <1 0>;
+ input;
+ line-name = "ENET_INT#";
+ };
+
+ perst-hog {
+ gpio-hog;
+ gpios = <10 0>;
+ output-high;
+ line-name = "PERST#";
+ };
+
+ pewake-hog {
+ gpio-hog;
+ gpios = <11 0>;
+ input;
+ line-name = "PEWAKE#";
+ };
+};
+
+&gpio3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio3>;
+
+ gpio-line-names = "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "GPIO4",
+ "GPIO3", "", "", "",
+ "", "", "", "",
+ "TEMP_EVENT#", "", "", "";
+
+ temp-event--hog {
+ gpio-hog;
+ gpios = <28 0>;
+ input;
+ line-name = "TEMP_EVENT#";
+ };
+};
+
+&gpio4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio4>, <&pinctrl_sdp>, <&pinctrl_espi_rst>;
+
+ gpio-line-names = "RTC_INT#", "GPIO8", "", "",
+ "GPIO9", "ESPI_RST#", "", "",
+ "", "", "", "",
+ "", "", "GBE0_SDP_DIR", "",
+ "GPIO7", "", "", "",
+ "", "", "", "",
+ "", "GPIO0", "GPIO1", "",
+ "GPIO2", "GPIO6", "", "";
+
+ rtc-int-hog {
+ gpio-hog;
+ gpios = <0 0>;
+ input;
+ line-name = "RTC_INT#";
+ };
+
+ espi-reset-hog {
+ gpio-hog;
+ gpios = <5 0>;
+ output-high;
+ line-name = "ESPI_RST#";
+ };
+};
+
+&gpio5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio5>;
+
+ gpio-line-names = "", "", "", "",
+ "", "GPIO5", "", "",
+ "", "", "GPIO12", "GPIO11",
+ "", "GPIO13", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+
+ dp-hpd-int-hog {
+ gpio-hog;
+ gpios = <21 0>;
+ input;
+ line-name = "DP_HPD_INT";
+ };
+};
+
+&hdmi_tx {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+};
+
+&i2c1 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ pinctrl-1 = <&pinctrl_i2c1_gpio>;
+ scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ eeprom0: eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ pagesize = <32>;
+ read-only;
+ vcc-supply = <&buck5>;
+ };
+
+ pcf85063: rtc@51 {
+ compatible = "nxp,pcf85063a";
+ reg = <0x51>;
+ quartz-load-femtofarads = <7000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcf85063>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ eeprom1: eeprom@54 {
+ compatible = "atmel,24c64";
+ reg = <0x54>;
+ pagesize = <32>;
+ vcc-supply = <&buck5>;
+ };
+
+ /* protectable identification memory (part of M24C64-D @50) */
+ eeprom@58 {
+ compatible = "atmel,24c64d-wl";
+ reg = <0x58>;
+ size = <32>;
+ pagesize = <32>;
+ vcc-supply = <&buck5>;
+ };
+
+ /* protectable identification memory (part of M24C64-D @54) */
+ eeprom@5c {
+ compatible = "atmel,24c64d-wl";
+ reg = <0x5c>;
+ size = <32>;
+ pagesize = <32>;
+ vcc-supply = <&buck5>;
+ };
+
+ pcieclk: clock-generator@6a {
+ compatible = "renesas,9fgv0241";
+ reg = <0x6a>;
+ clocks = <&clk_xtal25>;
+ #clock-cells = <1>;
+ };
+
+ imu@6b {
+ compatible = "st,ism330dhcx";
+ reg = <0x6b>;
+ vdd-supply = <&buck4>;
+ vddio-supply = <&buck4>;
+ };
+};
+
+&i2c2 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ pinctrl-1 = <&pinctrl_i2c2_gpio>;
+ scl-gpios = <&gpio5 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pmic: pmic@25 {
+ reg = <0x25>;
+ compatible = "nxp,pca9450c";
+
+ /* PMIC PCA9450 PMIC_nINT GPIO1_IO08 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ /* V_0V85_SOC: 0.85 .. 0.95 */
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <950000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ /* VDD_ARM */
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ nxp,dvs-run-voltage = <950000>;
+ nxp,dvs-standby-voltage = <850000>;
+ regulator-ramp-delay = <3125>;
+ };
+
+ /* VCC3V3 -> VMMC, ... must not be changed */
+ buck4: BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V8 -> VQMMC, SPI-NOR, ... must not be changed */
+ buck5: BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V1 -> RAM, ... must not be changed */
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V8_SNVS */
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V8_ANA */
+ ldo3: LDO3 {
+ regulator-name = "LDO3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* unused */
+ ldo4: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ /* VCC SD IO - switched using SD2 VSELECT */
+ ldo5: LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+ };
+
+ tmp1075: temperature-sensor@4a {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tmp1075>;
+ compatible = "ti,tmp1075";
+ reg = <0x4a>;
+ vs-supply = <&buck4>;
+ };
+
+ expander0: gpio@73 {
+ compatible = "nxp,pca9538";
+ reg = <0x73>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ vcc-supply = <&buck5>;
+ gpio-line-names = "LCD0_BKLT_EN", "LCD0_VDD_EN",
+ "LCD1_BKLT_EN", "LCD1_VDD_EN",
+ "DP_BRIDGE_EN", "HUB_RST#",
+ "ENET0_RESET#", "ENET1_RESET#";
+ };
+};
+
+&i2c3 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ pinctrl-1 = <&pinctrl_i2c3_gpio>;
+ scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ dp_bridge: dp-bridge@f {
+ compatible = "toshiba,tc9595", "toshiba,tc358767";
+ reg = <0xf>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tc9595>;
+ clock-names = "ref";
+ clocks = <&clk_dp>;
+ reset-gpios = <&expander0 4 GPIO_ACTIVE_HIGH>;
+ toshiba,hpd-pin = <0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ endpoint {
+ toshiba,pre-emphasis = /bits/ 8 <1 1>;
+ };
+ };
+ };
+ };
+};
+
+&i2c4 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ pinctrl-1 = <&pinctrl_i2c4_gpio>;
+ scl-gpios = <&gpio2 4 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 5 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+&i2c6 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c6>;
+ pinctrl-1 = <&pinctrl_i2c6_gpio>;
+ scl-gpios = <&gpio2 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+// Change parent clock of disp1 pixel clock to audio_pll2
+&media_blk_ctrl {
+ assigned-clocks = <&clk IMX8MP_CLK_MEDIA_AXI>,
+ <&clk IMX8MP_CLK_MEDIA_APB>,
+ <&clk IMX8MP_CLK_MEDIA_DISP1_PIX>,
+ <&clk IMX8MP_CLK_MEDIA_DISP2_PIX>,
+ <&clk IMX8MP_CLK_MEDIA_ISP>,
+ <&clk IMX8MP_VIDEO_PLL1>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
+ <&clk IMX8MP_SYS_PLL1_800M>,
+ <&clk IMX8MP_AUDIO_PLL2_OUT>,
+ <&clk IMX8MP_VIDEO_PLL1_OUT>,
+ <&clk IMX8MP_SYS_PLL2_500M>;
+};
+
+&mipi_dsi {
+ samsung,burst-clock-frequency = <1000000000>;
+ samsung,esc-clock-frequency = <10000000>;
+
+ ports {
+ port@1 {
+ reg = <1>;
+
+ dsi_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+ };
+};
+
+&pcie_phy {
+ fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+ clock-names = "ref";
+ clocks = <&pcieclk 0>;
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie>;
+ clocks = <&clk IMX8MP_CLK_HSIO_ROOT>,
+ <&clk IMX8MP_CLK_HSIO_AXI>,
+ <&clk IMX8MP_CLK_PCIE_ROOT>;
+ clock-names = "pcie", "pcie_bus", "pcie_aux";
+ assigned-clocks = <&clk IMX8MP_CLK_PCIE_AUX>;
+ assigned-clock-rates = <10000000>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_50M>;
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>;
+};
+
+&sai3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai3>;
+ assigned-clocks = <&clk IMX8MP_CLK_SAI3>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12288000>;
+};
+
+&sai5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai5>;
+ assigned-clocks = <&clk IMX8MP_CLK_SAI5>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12288000>;
+ fsl,sai-mclk-direction-output;
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ assigned-clocks = <&clk IMX8MP_CLK_UART1>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+ uart-has-rtscts;
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ assigned-clocks = <&clk IMX8MP_CLK_UART2>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+ uart-has-rtscts;
+};
+
+&uart3 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ assigned-clocks = <&clk IMX8MP_CLK_UART4>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+};
+
+&usb3_phy0 {
+ vbus-supply = <®_5v0>;
+ status = "okay";
+};
+
+&usb3_phy1 {
+ vbus-supply = <®_5v0>;
+ status = "okay";
+};
+
+&usb3_0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb0>;
+ fsl,over-current-active-low;
+};
+
+&usb3_1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb1>;
+ fsl,over-current-active-low;
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ /* dual role is implemented, but not a full featured OTG */
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ dr_mode = "otg";
+ usb-role-switch;
+ role-switch-default-mode = "peripheral";
+ /* SMARC-2 USB0 interface only supports USB 2.0 signals */
+ maximum-speed = "high-speed";
+};
+
+&usb_dwc3_1 {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ hub_2_0: hub@1 {
+ compatible = "usb451,8142";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&expander0 5 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_3v3>;
+ };
+
+ hub_3_0: hub@2 {
+ compatible = "usb451,8140";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&expander0 5 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_3v3>;
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ bus-width = <4>;
+ vqmmc-supply = <®_usdhc2_vqmmc>;
+ /* NOTE: CD / WP and VMMC support depends on mainboard */
+};
+
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ no-sdio;
+ no-sd;
+ vmmc-supply = <&buck4>;
+ vqmmc-supply = <&buck5>;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI2_MISO__GPIO5_IO12 0x1c0>;
+ };
+
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC 0x40000044>,
+ <MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO 0x40000044>,
+ <MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0 0x90>,
+ <MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1 0x90>,
+ <MX8MP_IOMUXC_ENET_RD2__ENET_QOS_RGMII_RD2 0x90>,
+ <MX8MP_IOMUXC_ENET_RD3__ENET_QOS_RGMII_RD3 0x90>,
+ <MX8MP_IOMUXC_ENET_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x90>,
+ <MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x90>,
+ <MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0 0x12>,
+ <MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1 0x12>,
+ <MX8MP_IOMUXC_ENET_TD2__ENET_QOS_RGMII_TD2 0x12>,
+ <MX8MP_IOMUXC_ENET_TD3__ENET_QOS_RGMII_TD3 0x12>,
+ <MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x12>,
+ <MX8MP_IOMUXC_ENET_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x14>;
+ };
+
+ pinctrl_eqos_event: eqosevtgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI2_MCLK__ENET_QOS_1588_EVENT3_IN 0x100>,
+ <MX8MP_IOMUXC_SAI2_TXFS__ENET_QOS_1588_EVENT3_OUT 0x1c0>;
+ };
+
+ pinctrl_eqos_phy: eqosphygrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_CLK__GPIO2_IO00 0x1c0>;
+ };
+
+ pinctrl_espi_rst: espirstgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXD3__GPIO4_IO05 0x144>;
+ };
+
+ pinctrl_fec: fecgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXD4__ENET1_RGMII_RD0 0x90>,
+ <MX8MP_IOMUXC_SAI1_RXD5__ENET1_RGMII_RD1 0x90>,
+ <MX8MP_IOMUXC_SAI1_RXD6__ENET1_RGMII_RD2 0x90>,
+ <MX8MP_IOMUXC_SAI1_RXD7__ENET1_RGMII_RD3 0x90>,
+ <MX8MP_IOMUXC_SAI1_TXC__ENET1_RGMII_RXC 0x90>,
+ <MX8MP_IOMUXC_SAI1_TXFS__ENET1_RGMII_RX_CTL 0x90>,
+ <MX8MP_IOMUXC_SAI1_TXD0__ENET1_RGMII_TD0 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD1__ENET1_RGMII_TD1 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD2__ENET1_RGMII_TD2 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD3__ENET1_RGMII_TD3 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD4__ENET1_RGMII_TX_CTL 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD5__ENET1_RGMII_TXC 0x14>;
+ };
+
+ pinctrl_fec_event: fecevtgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXD1__ENET1_1588_EVENT1_OUT 0x100>,
+ <MX8MP_IOMUXC_SAI1_RXD0__ENET1_1588_EVENT1_IN 0x1c0>;
+ };
+
+ pinctrl_fec_phy: fecphygrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_CMD__GPIO2_IO01 0x1c0>;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI5_RXD1__CAN1_TX 0x150>,
+ <MX8MP_IOMUXC_SAI5_RXD2__CAN1_RX 0x150>;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI5_RXD3__CAN2_TX 0x150>,
+ <MX8MP_IOMUXC_SAI5_MCLK__CAN2_RX 0x150>;
+ };
+
+ pinctrl_flexspi0: flexspi0grp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_ALE__FLEXSPI_A_SCLK 0x142>,
+ <MX8MP_IOMUXC_NAND_CE0_B__FLEXSPI_A_SS0_B 0x82>,
+ <MX8MP_IOMUXC_NAND_DQS__FLEXSPI_A_DQS 0x40000010>,
+ <MX8MP_IOMUXC_NAND_DATA00__FLEXSPI_A_DATA00 0x82>,
+ <MX8MP_IOMUXC_NAND_DATA01__FLEXSPI_A_DATA01 0x82>,
+ <MX8MP_IOMUXC_NAND_DATA02__FLEXSPI_A_DATA02 0x82>,
+ <MX8MP_IOMUXC_NAND_DATA03__FLEXSPI_A_DATA03 0x82>;
+ };
+
+ pinctrl_sdp: gbegrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_TXD6__GPIO4_IO18 0x10>,
+ <MX8MP_IOMUXC_SAI1_TXD7__GPIO4_IO19 0x10>;
+ };
+
+ pinctrl_gpio1: gpio1grp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO00__GPIO1_IO00 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO01__GPIO1_IO01 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO05__GPIO1_IO05 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO06__GPIO1_IO06 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO07__GPIO1_IO07 0x80>,
+ <MX8MP_IOMUXC_GPIO1_IO09__GPIO1_IO09 0x80>;
+ };
+
+ pinctrl_gpio3: gpio3grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI5_RXFS__GPIO3_IO19 0x10>,
+ <MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20 0x10>;
+ };
+
+ pinctrl_gpio4: gpio4grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXC__GPIO4_IO01 0x10>,
+ <MX8MP_IOMUXC_SAI1_RXD2__GPIO4_IO04 0x10>,
+ <MX8MP_IOMUXC_SAI1_RXD3__GPIO4_IO05 0x10>,
+ <MX8MP_IOMUXC_SAI1_MCLK__GPIO4_IO20 0x10>,
+ <MX8MP_IOMUXC_SAI2_TXC__GPIO4_IO25 0x10>,
+ <MX8MP_IOMUXC_SAI2_TXD0__GPIO4_IO26 0x10>,
+ <MX8MP_IOMUXC_SAI3_RXFS__GPIO4_IO28 0x10>,
+ <MX8MP_IOMUXC_SAI3_RXC__GPIO4_IO29 0x10>;
+ };
+
+ pinctrl_gpio5: gpio5grp {
+ fsl,pins = <MX8MP_IOMUXC_SPDIF_EXT_CLK__GPIO5_IO05 0x10>,
+ <MX8MP_IOMUXC_ECSPI2_SCLK__GPIO5_IO10 0x10>,
+ <MX8MP_IOMUXC_ECSPI2_MOSI__GPIO5_IO11 0x10>,
+ <MX8MP_IOMUXC_ECSPI2_SS0__GPIO5_IO13 0x10>;
+ };
+
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x400001c2>,
+ <MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x400001c2>,
+ <MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0x40000010>;
+ };
+
+ pinctrl_hoggpio2: hoggpio2grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_STROBE__GPIO2_IO11 0x140>;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c1_gpio: i2c1-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C1_SCL__GPIO5_IO14 0x400001e2>,
+ <MX8MP_IOMUXC_I2C1_SDA__GPIO5_IO15 0x400001e2>;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c2_gpio: i2c2-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C2_SCL__GPIO5_IO16 0x400001e2>,
+ <MX8MP_IOMUXC_I2C2_SDA__GPIO5_IO17 0x400001e2>;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c3_gpio: i2c3-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C3_SCL__GPIO5_IO18 0x400001e2>,
+ <MX8MP_IOMUXC_I2C3_SDA__GPIO5_IO19 0x400001e2>;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA2__I2C4_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA3__I2C4_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c4_gpio: i2c4-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA2__GPIO2_IO04 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA3__GPIO2_IO05 0x400001e2>;
+ };
+
+ pinctrl_i2c6: i2c6grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA0__I2C6_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA1__I2C6_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c6_gpio: i2c6-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA0__GPIO2_IO02 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA1__GPIO2_IO03 0x400001e2>;
+ };
+
+ pinctrl_pcf85063: pcf85063grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXFS__GPIO4_IO00 0x80>;
+ };
+
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C4_SCL__PCIE_CLKREQ_B 0x60>,
+ <MX8MP_IOMUXC_SD1_RESET_B__GPIO2_IO10 0x94>;
+ };
+
+ pinctrl_pmic: pmicirqgrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO08__GPIO1_IO08 0x1c0>;
+ };
+
+ pinctrl_pwm2: pwm2grp {
+ fsl,pins = <MX8MP_IOMUXC_SPDIF_RX__PWM2_OUT 0x14>;
+ };
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <MX8MP_IOMUXC_SPDIF_TX__PWM3_OUT 0x14>;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x10>;
+ };
+
+ pinctrl_reg_usdhc2_vqmmc: regusdhc2vqmmcgrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO04__GPIO1_IO04 0xc0>;
+ };
+
+ pinctrl_sai3: sai3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI3_RXD__AUDIOMIX_SAI3_RX_DATA00 0x94
+ MX8MP_IOMUXC_SAI3_TXD__AUDIOMIX_SAI3_TX_DATA00 0x94
+ MX8MP_IOMUXC_SAI3_TXFS__AUDIOMIX_SAI3_TX_SYNC 0x94
+ MX8MP_IOMUXC_SAI3_TXC__AUDIOMIX_SAI3_TX_BCLK 0x94
+ >;
+ };
+
+ pinctrl_sai5: sai5grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI3_MCLK__AUDIOMIX_SAI5_MCLK 0x94
+ MX8MP_IOMUXC_SAI5_RXD0__AUDIOMIX_SAI5_RX_DATA00 0x94
+ MX8MP_IOMUXC_SAI2_RXD0__AUDIOMIX_SAI5_TX_DATA00 0x94
+ MX8MP_IOMUXC_SAI2_RXFS__AUDIOMIX_SAI5_TX_SYNC 0x94
+ MX8MP_IOMUXC_SAI2_RXC__AUDIOMIX_SAI5_TX_BCLK 0x94
+ >;
+ };
+
+ pinctrl_tc9595: tc9595grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C4_SDA__GPIO5_IO21 0x10>;
+ };
+
+ pinctrl_tmp1075: tmp1075grp {
+ fsl,pins = <MX8MP_IOMUXC_HDMI_CEC__GPIO3_IO28 0x140>;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x140>,
+ <MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x140>,
+ <MX8MP_IOMUXC_UART3_RXD__UART1_DCE_CTS 0x140>,
+ <MX8MP_IOMUXC_UART3_TXD__UART1_DCE_RTS 0x140>;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x140>,
+ <MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x140>,
+ <MX8MP_IOMUXC_SD1_DATA4__UART2_DCE_RTS 0x140>,
+ <MX8MP_IOMUXC_SD1_DATA5__UART2_DCE_CTS 0x140>;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA6__UART3_DCE_TX 0x140>,
+ <MX8MP_IOMUXC_SD1_DATA7__UART3_DCE_RX 0x140>;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <MX8MP_IOMUXC_UART4_RXD__UART4_DCE_RX 0x140>,
+ <MX8MP_IOMUXC_UART4_TXD__UART4_DCE_TX 0x140>;
+ };
+
+ pinctrl_usb0: usb0grp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO13__USB1_OTG_OC 0x1c0>,
+ <MX8MP_IOMUXC_GPIO1_IO12__USB1_OTG_PWR 0x1c0>;
+ };
+
+ pinctrl_usb1: usb1grp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO15__USB2_OTG_OC 0x1c0>,
+ <MX8MP_IOMUXC_GPIO1_IO14__USB2_OTG_PWR 0x1c0>;
+ };
+
+ pinctrl_usbcon0: usb0congrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO10__GPIO1_IO10 0x1c0>;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x192>,
+ <MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d2>;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x194>,
+ <MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4>;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x194>,
+ <MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4>;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CD_B__GPIO2_IO12 0x1c0>,
+ <MX8MP_IOMUXC_SD2_WP__GPIO2_IO20 0x1c0>;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194>,
+ <MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4>,
+ <MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x84>,
+ <MX8MP_IOMUXC_NAND_READY_B__USDHC3_RESET_B 0x84>;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194>,
+ <MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4>,
+ <MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x84>,
+ <MX8MP_IOMUXC_NAND_READY_B__USDHC3_RESET_B 0x84>;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194>,
+ <MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4>,
+ <MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x84>,
+ <MX8MP_IOMUXC_NAND_READY_B__USDHC3_RESET_B 0x84>;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO02__WDOG1_WDOG_B 0x1c4>;
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 10/10] clk: amlogic: Add A9 AO clock controller driver
From: Jian Hu @ 2026-05-20 7:37 UTC (permalink / raw)
To: Jerome Brunet, Jian Hu via B4 Relay
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Xianwei Zhao, Kevin Hilman,
Martin Blumenstingl, linux-kernel, linux-clk, devicetree,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1j33zu6jnl.fsf@starbuckisacylon.baylibre.com>
On 5/15/2026 12:27 AM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>
>> From: Jian Hu <jian.hu@amlogic.com>
>>
>> Add the Always-on clock controller driver for the Amlogic A9 SoC family.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> drivers/clk/meson/Makefile | 2 +-
>> drivers/clk/meson/a9-aoclk.c | 494 +++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 495 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>> index 2b5b67b14efc..91af609ce815 100644
>> --- a/drivers/clk/meson/Makefile
>> +++ b/drivers/clk/meson/Makefile
>> @@ -20,7 +20,7 @@ obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
>> obj-$(CONFIG_COMMON_CLK_A1_PLL) += a1-pll.o
>> obj-$(CONFIG_COMMON_CLK_A1_PERIPHERALS) += a1-peripherals.o
>> obj-$(CONFIG_COMMON_CLK_A9_PLL) += a9-pll.o
>> -obj-$(CONFIG_COMMON_CLK_A9_PERIPHERALS) += a9-peripherals.o
>> +obj-$(CONFIG_COMMON_CLK_A9_PERIPHERALS) += a9-peripherals.o a9-aoclk.o
>> obj-$(CONFIG_COMMON_CLK_C3_PLL) += c3-pll.o
>> obj-$(CONFIG_COMMON_CLK_C3_PERIPHERALS) += c3-peripherals.o
>> obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o
>> diff --git a/drivers/clk/meson/a9-aoclk.c b/drivers/clk/meson/a9-aoclk.c
>> new file mode 100644
>> index 000000000000..3c42eaf585d2
>> --- /dev/null
>> +++ b/drivers/clk/meson/a9-aoclk.c
>> @@ -0,0 +1,494 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
>> +/*
>> + * Copyright (C) 2026 Amlogic, Inc. All rights reserved
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/platform_device.h>
>> +#include <dt-bindings/clock/amlogic,a9-aoclkc.h>
>> +#include "clk-regmap.h"
>> +#include "clk-dualdiv.h"
>> +#include "meson-clkc-utils.h"
>> +
>> +#define AO_OSCIN_CTRL 0x00
>> +#define AO_SYS_CLK0 0x04
>> +#define AO_PWM_CLK_A_CTRL 0x1c
>> +#define AO_PWM_CLK_B_CTRL 0x20
>> +#define AO_PWM_CLK_C_CTRL 0x24
>> +#define AO_PWM_CLK_D_CTRL 0x28
>> +#define AO_PWM_CLK_E_CTRL 0x2c
>> +#define AO_PWM_CLK_F_CTRL 0x30
>> +#define AO_PWM_CLK_G_CTRL 0x34
>> +#define AO_CEC_CTRL0 0x38
>> +#define AO_CEC_CTRL1 0x3c
>> +#define AO_RTC_BY_OSCIN_CTRL0 0x50
>> +#define AO_RTC_BY_OSCIN_CTRL1 0x54
>> +
>> +#define A9_COMP_SEL(_name, _reg, _shift, _mask, _pdata) \
>> + MESON_COMP_SEL(a9_, _name, _reg, _shift, _mask, _pdata, NULL, 0, 0)
> a9_ao_ ?
>
Ok, I will replace it with the prefix a9_ao_
[...]
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH] arm64: Add user and kernel page-fault tracepoints
From: Leo Yan @ 2026-05-20 7:36 UTC (permalink / raw)
To: Justinien Bouron
Cc: Mark Rutland, Gunnar Kudrjavets, Ryan Roberts, Quentin Perret,
Catalin Marinas, Kevin Brodsky, linux-kernel, David Hildenbrand,
Lorenzo Stoakes, Will Deacon, linux-arm-kernel
In-Reply-To: <20260520045524.75670-1-jbouron@amazon.com>
On Tue, May 19, 2026 at 09:55:24PM -0700, Justinien Bouron wrote:
[...]
> @@ -606,6 +609,11 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
> int si_code;
> int pkey = -1;
>
> + if (user_mode(regs))
> + trace_page_fault_user(addr, regs, esr);
> + else
> + trace_page_fault_kernel(addr, regs, esr);
Based on the discussion [1], Arm64 has already supported perf sw event
for page-faults:
perf record -e page-faults ...
Seems there have a plan to consolidate perf event and tracepoints but I
have no idea how it is going. I would leave this to maintainers.
> +
> if (kprobe_page_fault(regs, esr))
> return 0;
tracepoints should be after kprobe_page_fault(), as explained [2] by Mark.
Thanks,
Leo
[1] https://lore.kernel.org/all/20250520140453.GA18711@willie-the-truck/
[2] https://lore.kernel.org/all/aCtZfiU8bgkSAgLh@J2N7QTR9R3/
^ permalink raw reply
* Re: [PATCH 07/10] clk: amlogic: Support POWER_OF_TWO for PLL pre-divider
From: Jerome Brunet @ 2026-05-20 7:35 UTC (permalink / raw)
To: Jian Hu
Cc: Jian Hu via B4 Relay, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Xianwei Zhao, Kevin Hilman, Martin Blumenstingl, linux-kernel,
linux-clk, devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <8d89b669-e72e-4663-9596-999a12922d32@amlogic.com>
On mer. 20 mai 2026 at 13:47, Jian Hu <jian.hu@amlogic.com> wrote:
> On 5/14/2026 11:11 PM, Jerome Brunet wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>>
>>> From: Jian Hu <jian.hu@amlogic.com>
>>>
>>> The A9 PLL pre-divider uses a division factor of 2^n to ensure a clock
>>> duty cycle of 50% after predivision.
>>>
>>> Add flag 'CLK_MESON_PLL_N_POWER_OF_TWO' to indicate that the PLL
>>> pre-divider division factor is 2^n.
>> I understand what you are doing here but I have to ask why this can't be
>> implemented with independent dividers that already supports power of 2 ?
>
>
> If we use independent dividers, the n member would have to be removed from
> meson_clk_pll_data.
>
> However, n is referenced 35 times in clk-pll.c, which means we would need
> to modify all
> related logic across the file. This would be a relatively large
> change.
Yes
>
>
> Moreover, for all Amlogic chips, the n divider is an indispensable part of
> the DCO clock.
There is hardly a justification here
> The difference between SoC generations is as follows:
> Previous SoCs PLL: n = 1, 2, 3, 4... (linear divider)
> A9 SoC PLL: n = 2^0, 2^1, 2^2, 2^3, 2^4... (power-of-two
> divider)
Yes that was fairly obvious
>
> Therefore, splitting out the n divider from the DCO clock might not be a
> good design choice.
I'm not sure I agree and you've only stated your point of view without
providing any technical justification here.
From the datasheets of the different SoC we have, the documented
limitation is always the DCO output rate range. Nothing related to n (or
m, or the mult-range for that matter). This is a legacy problem, we
started with monolithic driver and slowly simplified it.
As far as I can see now, reworking the PLL driver to be a simple
multiplier driver with range output rate constraint could actually be
simpler than the current code. I would also make simpler to accomodate
differences such as the one presented here.
Unless you can provide technical reasons why going in this direction
would be incorrect, that's where I'd prefer to go.
>
> [...]
>
> Best regards,
>
> Jian
--
Jerome
^ permalink raw reply
* [PATCH] dt-bindings: arm-smmu: qcom: Constrain clocks for Hawi SoC
From: Mukesh Ojha @ 2026-05-20 7:34 UTC (permalink / raw)
To: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robin Murphy
Cc: Robin Murphy, linux-arm-kernel, iommu, devicetree, linux-kernel,
Mukesh Ojha
The Hawi SoC has two SMMU instances with different clock requirements.
The Adreno GPU SMMU uses the qcom,adreno-smmu fallback and requires a
single HLOS vote clock, matching the pattern already established for
Glymur and SM8750. The Application Processor SMMU (APSS) uses the
qcom,smmu-500 fallback and has no controllable clocks.
Add qcom,hawi-smmu-500 to the single-clock constraint block for the
Adreno GPU SMMU and to the no-clocks constraint block for the APSS SMMU,
following the pattern how it is done for other SoCs.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
This patch is on based on arm/smmu/bindings branch here in
https://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux.git
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 25fd3efa2420..e413564ce55d 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -570,6 +570,7 @@ allOf:
items:
- enum:
- qcom,glymur-smmu-500
+ - qcom,hawi-smmu-500
- qcom,sm8750-smmu-500
- const: qcom,adreno-smmu
- const: qcom,smmu-500
@@ -616,6 +617,7 @@ allOf:
- enum:
- qcom,eliza-smmu-500
- qcom,glymur-smmu-500
+ - qcom,hawi-smmu-500
- qcom,kaanapali-smmu-500
- qcom,milos-smmu-500
- qcom,qcs615-smmu-500
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 08/10] clk: amlogic: Add A9 PLL clock controller driver
From: Jian Hu @ 2026-05-20 7:33 UTC (permalink / raw)
To: Jerome Brunet, Jian Hu via B4 Relay
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Xianwei Zhao, Kevin Hilman,
Martin Blumenstingl, linux-kernel, linux-clk, devicetree,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1jh5oa6kcm.fsf@starbuckisacylon.baylibre.com>
On 5/15/2026 12:12 AM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>
>> From: Jian Hu <jian.hu@amlogic.com>
>>
>> Add the PLL clock controller driver for the Amlogic A9 SoC family.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
[...]
>> +
>> +/*
>> + * Compared with previous SoC PLLs, the A9 PLL input path has an inherent
>> + * 2-divider. The N pre-divider follows the same calculation rule as OD,
>> + * where the pre-divider ratio equals 2^N.
>> + *
>> + * A9 PLL is composed as follows:
>> + *
>> + * PLL
>> + * +---------------------------------+
>> + * | |
>> + * | +--+ |
>> + * in/2 >>---[ /2^N ]-->| | +-----+ |
>> + * | | |------| DCO |----->> out
>> + * | +--------->| | +--v--+ |
>> + * | | +--+ | |
>> + * | | | |
>> + * | +--[ *(M + (F/Fmax) ]<--+ |
>> + * | |
>> + * +---------------------------------+
>> + *
>> + * out = in / 2 * (m + frac / frac_max) / 2^n
>> + */
>> +
>> +static struct clk_fixed_factor a9_gp0_in_div2_div = {
>> + .mult = 1,
>> + .div = 2,
>> + .hw.init = &(struct clk_init_data){
>> + .name = "gp0_in_div2_div",
>> + .ops = &clk_fixed_factor_ops,
>> + .parent_data = &(const struct clk_parent_data) {
>> + .fw_name = "in0",
>> + },
>> + .num_parents = 1,
>> + },
>> +};
>> +
>> +static struct clk_regmap a9_gp0_in_div2 = {
>> + .data = &(struct clk_regmap_gate_data) {
>> + .offset = GP0PLL_CTRL0,
>> + .bit_idx = 27,
>> + },
>> + .hw.init = &(struct clk_init_data) {
>> + .name = "gp0_in_div2",
>> + .ops = &clk_regmap_gate_ops,
>> + .parent_hws = (const struct clk_hw *[]) {
>> + &a9_gp0_in_div2_div.hw
>> + },
>> + .num_parents = 1,
>> + },
>> +};
> When document something, be sure it matches what you are doing
> afterward. It is confusing otherwise. Your comments above clearly miss
> this gate.
>
> A fixed 2 divider followed by a power of 2 divider ? Is it actually how
> the HW works or your modelisation power of 2 that's shifted by 1,
> mapping :
> * 0 -> 2
> * 1 -> 4
> * etc ...
>
> ?
Sorry for missing the gate in PLL block diagram, above block diagram
focuses on mathematical formulas.
A9 PLL is composed as follows in fact, M and frac have a 0.5 weight factor:
PLL
+-----------------------------------------------------+
| |
| +--+ |
in >>---[ /N ]--> | | +-----+ |
| | |---------------------| DCO | |----->> out
| +--------->| | +--v--+ |
| | +--+ | |
| | | |
| +--[ *(M + (F/Fmax) ] * 0.5 + Enable<--+ |
| |
+-----------------------------------------------------+
out = in * (M + frac / frac_max) * 0.5 / N
If we ignore frac and set N = 1, it simplifies to:
out = in * M * 0.5
This can be rewritten as:
out = (in / 2) * M
The 0.5 weight is hardware-controlled:
For GP0/HIFI PLL: controlled by CTRL0 bit27 (gate)
For MCLK PLL: enabled by default, no gate bit
To model this in the clock tree, we add:
A fixed /2 divider after input clock to represent the 0.5 weight
A gate clock to represent the enable control
The resulting structure is:
input --> fixed div2 --> gate--> dco
I would appreciate your guidance If this is not appropriate.
>> +
>> +/* The output frequency range of the A9 PLL_DCO is 1.4 GHz to 2.8 GHz. */
>> +static const struct pll_mult_range a9_pll_mult_range = {
>> + .min = 117,
>> + .max = 233,
>> +};
> If PLL restriction is actually the DCO output rate, and only the reason
> to keep the pre-devider in the range above, I would definitely welcome a
> rework to express the constraints properly and split the pre-divider out.
>
>> +
>> +static const struct reg_sequence a9_gp0_pll_init_regs[] = {
>> + { .reg = GP0PLL_CTRL0, .def = 0x00010000 },
>> + { .reg = GP0PLL_CTRL1, .def = 0x11480000 },
>> + { .reg = GP0PLL_CTRL2, .def = 0x1219b010 },
>> + { .reg = GP0PLL_CTRL3, .def = 0x00008010 }
>> +};
>> +
>> +static struct clk_regmap a9_gp0_pll_dco = {
>> + .data = &(struct meson_clk_pll_data) {
>> + .en = {
>> + .reg_off = GP0PLL_CTRL0,
>> + .shift = 28,
>> + .width = 1,
>> + },
>> + .m = {
>> + .reg_off = GP0PLL_CTRL0,
>> + .shift = 0,
>> + .width = 9,
>> + },
>> + .n = {
>> + .reg_off = GP0PLL_CTRL0,
>> + .shift = 12,
>> + .width = 3,
>> + },
>> + .frac = {
>> + .reg_off = GP0PLL_CTRL1,
>> + .shift = 0,
>> + .width = 17,
>> + },
>> + .l = {
>> + .reg_off = GP0PLL_CTRL0,
>> + .shift = 31,
>> + .width = 1,
>> + },
>> + .rst = {
>> + .reg_off = GP0PLL_CTRL0,
>> + .shift = 29,
>> + .width = 1,
>> + },
>> + .l_detect = {
>> + .reg_off = GP0PLL_CTRL0,
>> + .shift = 30,
>> + .width = 1,
>> + },
>> + .range = &a9_pll_mult_range,
>> + .init_regs = a9_gp0_pll_init_regs,
>> + .init_count = ARRAY_SIZE(a9_gp0_pll_init_regs),
>> + .flags = CLK_MESON_PLL_RST_ACTIVE_LOW |
>> + CLK_MESON_PLL_N_POWER_OF_TWO |
>> + CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH,
>> + },
>> + .hw.init = &(struct clk_init_data) {
>> + .name = "gp0_pll_dco",
>> + .ops = &meson_clk_pll_ops,
>> + .parent_hws = (const struct clk_hw *[]) {
>> + &a9_gp0_in_div2.hw
>> + },
>> + .num_parents = 1,
>> + },
>> +};
>> +
>> +/* For gp0, hifi and mclk pll, the maximum value of od is 4. */
>> +static const struct clk_div_table a9_pll_od_table[] = {
>> + { 0, 1 },
>> + { 1, 2 },
>> + { 2, 4 },
>> + { 3, 8 },
>> + { 4, 16 },
>> + { /* sentinel */ }
>> +};
>> +
>> +static struct clk_regmap a9_gp0_pll = {
>> + .data = &(struct clk_regmap_div_data) {
>> + .offset = GP0PLL_CTRL0,
>> + .shift = 20,
>> + .width = 3,
>> + .table = a9_pll_od_table,
>> + },
>> + .hw.init = &(struct clk_init_data) {
>> + .name = "gp0_pll",
>> + .ops = &clk_regmap_divider_ops,
>> + .parent_hws = (const struct clk_hw *[]) {
>> + &a9_gp0_pll_dco.hw
>> + },
>> + .num_parents = 1,
>> + .flags = CLK_SET_RATE_PARENT,
>> + },
>> +};
>> +
>> +static struct clk_fixed_factor a9_hifi0_in_div2_div = {
>> + .mult = 1,
>> + .div = 2,
>> + .hw.init = &(struct clk_init_data){
>> + .name = "hifi0_in_div2_div",
>> + .ops = &clk_fixed_factor_ops,
>> + .parent_data = &(const struct clk_parent_data) {
>> + .fw_name = "in0",
>> + },
>> + .num_parents = 1,
>> + },
>> +};
>> +
>> +static struct clk_regmap a9_hifi0_in_div2 = {
>> + .data = &(struct clk_regmap_gate_data) {
>> + .offset = HIFIPLL_CTRL0,
>> + .bit_idx = 27,
>> + },
>> + .hw.init = &(struct clk_init_data) {
>> + .name = "hifi0_in_div2",
>> + .ops = &clk_regmap_gate_ops,
>> + .parent_hws = (const struct clk_hw *[]) {
>> + &a9_hifi0_in_div2_div.hw
>> + },
>> + .num_parents = 1,
>> + },
>> +};
>> +
>> +static const struct reg_sequence a9_hifi0_pll_init_regs[] = {
>> + { .reg = HIFIPLL_CTRL0, .def = 0x00010000 },
>> + { .reg = HIFIPLL_CTRL1, .def = 0x11480000 },
>> + { .reg = HIFIPLL_CTRL2, .def = 0x1219b010 },
>> + { .reg = HIFIPLL_CTRL3, .def = 0x00008010 }
>> +};
> It look like GP0 and HIFI PLL are exactly the same IP, you've even
> documented it as such. Yet all the code is duplicated. That's not OK.
>
> I understand that way we statically declared the clocks so far pushed
> you in that direction. That's something I'd like to fix properly
> someday.
>
> In the meantime, you could at least duplicate the memory at runtime to
> avoid copy/pasting the code. A minor change to clkc utils as suggested
> at the end of this message could help you do so.
>
> Same probably applies to mclks.
You're right, the GP0 and HIFI PLLs are indeed the same IP, differing
only by frac_max:
GP0: frac_max = 2^17
HIFI: frac_max = 100000
Each clock requires its own clk_regmap and clk_hw structure, though the
data in
clk_regmap can be shared between HIFI0 and HIFI1.
I have tried duplicating HIFI1's clock structure from HIFI0 at runtime.
Most members of clk_init_data (except parent_hws / parent_data) can be
easily copied.
However, I have a question regarding dynamic parent assignment:
For example:
Clock B is created dynamically, and its parent is clock A (also created
dynamically).
How should I properly assign this parent relationship?
Furthermore, how to handle more complex parent configurations dynamically?
For example:
Clock D has three parents: C, B, A (in an irregular order).
I would appreciate your guidance on how to handle these dynamic clock
relationships properly.
>
>
[...]
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH v2 6/7] mm/vmalloc: align vm_area so vmap() can batch mappings
From: Uladzislau Rezki @ 2026-05-20 7:32 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <20260514094108.2016201-7-jiangwen6@xiaomi.com>
On Thu, May 14, 2026 at 05:41:07PM +0800, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua@kernel.org>
>
> Try to align the vmap virtual address to PMD_SHIFT or a
> larger PTE mapping size hinted by the architecture, so
> contiguous pages can be batch-mapped when setting PMD or
> PTE entries.
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> mm/vmalloc.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index c30a7673e..b3389c8f1 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3591,6 +3591,35 @@ static int __vmap_huge(unsigned long addr, unsigned long end,
> return err;
> }
>
> +static struct vm_struct *get_aligned_vm_area(unsigned long size, unsigned long flags)
> +{
> + unsigned int shift = (size >= PMD_SIZE) ? PMD_SHIFT :
> + arch_vmap_pte_supported_shift(size);
> + struct vm_struct *vm_area = NULL;
> +
> + /*
> + * Try to allocate an aligned vm_area so contiguous pages can be
> + * mapped in batches.
> + */
> + while (1) {
> + unsigned long align = 1UL << shift;
> +
> + vm_area = __get_vm_area_node(size, align, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL,
> + __builtin_return_address(0));
> + if (vm_area || shift <= PAGE_SHIFT)
> + goto out;
> + if (shift == PMD_SHIFT)
> + shift = arch_vmap_pte_supported_shift(size);
> + else if (shift > PAGE_SHIFT)
> + shift = PAGE_SHIFT;
> + }
> +
> +out:
> + return vm_area;
> +}
> +
IMO, we should get rid of this while(1) loop. It looks like you need to
handle just few cases. 3?
shift min value is PAGE_SHIFT, could you please clarify when it can be less?
--
Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH v3 0/5] KVM: arm64: nv: Implement nested stage-2 reverse map
From: Itaru Kitayama @ 2026-05-20 7:31 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon
In-Reply-To: <20260510145338.322962-1-weilin.chang@arm.com>
Hi Wei Lin,
On Sun, May 10, 2026 at 03:53:33PM +0100, Wei-Lin Chang wrote:
> Hi,
>
> This is v3 of optimizing the shadow s2 mmu unmapping during MMU
> notifiers.
>
> Two new preparatory patches are added, one reduces a hole in kvm_s2_mmu
> and another refactors the code a bit during s2 faults. Other changes are
> listed below.
>
> * Changes from v2 [1]:
>
> - Removed "polluted" teminology.
>
> - Use xa_{mk, to}_value() when storing and retriving values from maple
> trees.
>
> - Avoid using the 63rd bit in maple tree values so that xa_{mk, to}_value()
> does not lose us a bit.
>
> - Added reverse map removal during TLBI handling.
>
> - Other suggested refactorings.
>
> Thanks!
With this series applied on the recent kvmarm/fixes (minor local modification),
your v3 hello_nested runs fine on all three page granules; without this 16KB
kernel can't handle stage 2 unmapping paths. I tested using the latest QEMU only
so wonder how you're testing.
Thanks,
Itaru.
>
> [1]: https://lore.kernel.org/kvmarm/20260411125024.3735989-1-weilin.chang@arm.com/
>
> Wei-Lin Chang (5):
> KVM: arm64: Use a variable for the canonical GPA in kvm_s2_fault_map()
> KVM: arm64: Move shadow_pt_debugfs_dentry to reduce holes in
> kvm_s2_mmu
> KVM: arm64: nv: Avoid full shadow s2 unmap
> KVM: arm64: nv: Remove reverse map entries during TLBI handling
> KVM: arm64: nv: Create nested IPA direct map to speed up reverse map
> removal
>
> arch/arm64/include/asm/kvm_host.h | 17 +-
> arch/arm64/include/asm/kvm_nested.h | 6 +
> arch/arm64/kvm/mmu.c | 43 +++--
> arch/arm64/kvm/nested.c | 238 +++++++++++++++++++++++++++-
> arch/arm64/kvm/sys_regs.c | 3 +
> 5 files changed, 290 insertions(+), 17 deletions(-)
>
> --
> 2.43.0
>
^ permalink raw reply
* [GIT PULL] KVM/arm64 fixes for 7.1, take #3
From: Marc Zyngier @ 2026-05-20 7:25 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Michael Bommarito, Vincent Donnefort, Will Deacon, Yuan Yao,
Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, kvmarm, linux-arm-kernel, kvm
Paolo,
Here's the next set of KVM/arm64 fixes for 7.1. Continuing the trend,
we have two AI-fuelled fixes, both of which are stable candidates.
Additionally, a minor tidying-up of the hypervisor tracing descriptor
validation.
Please pull,
M.
The following changes since commit effc0a39b8e0f30670fe24f51e44329d4324e566:
KVM: arm64: Pre-check vcpu memcache for host->guest donate (2026-05-07 14:12:42 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.1-3
for you to fetch changes up to 1702da76e017ae0fbe1a92b07bc332972c293e89:
KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc (2026-05-20 08:08:37 +0100)
----------------------------------------------------------------
KVM/arm64 fixes for 7.1, take #3
- Fix ITS EventID sanitisation when restoring an interrupt translation
table.
- Fix PPI memory leak when failing to initialise a vcpu.
- Correctly return an error when the validation of a hypervisor trace
descriptor fails, and limit this validation to protected mode only.
----------------------------------------------------------------
Michael Bommarito (2):
KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits
KVM: arm64: vgic: Free private_irqs when init fails after allocation
Vincent Donnefort (1):
KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc
arch/arm64/kvm/arm.c | 4 +++-
arch/arm64/kvm/hyp/nvhe/trace.c | 9 +++++++--
arch/arm64/kvm/vgic/vgic-its.c | 4 ++++
3 files changed, 14 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH 05/10] clk: amlogic: PLL l_detect signal supports active-high configuration
From: Jerome Brunet @ 2026-05-20 7:24 UTC (permalink / raw)
To: Jian Hu
Cc: Jian Hu via B4 Relay, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Xianwei Zhao, Kevin Hilman, Martin Blumenstingl, linux-kernel,
linux-clk, devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <d023303e-e785-4b60-85cd-c83cc3f890e4@amlogic.com>
On mer. 20 mai 2026 at 11:25, Jian Hu <jian.hu@amlogic.com> wrote:
> On 5/14/2026 11:13 PM, Jerome Brunet wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>>
>>> From: Jian Hu <jian.hu@amlogic.com>
>>>
>>> l_detect controls the enable/disable of the PLL lock-detect module.
>>>
>>> For A9, the l_detect signal is active-high:
>>> 0 -> Disable lock-detect module;
>>> 1 -> Enable lock-detect module.
>>>
>>> Here, a flag CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH is added to handle cases
>>> like A9, where the signal is active-high.
>>>
>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>> ---
>>> drivers/clk/meson/clk-pll.c | 9 +++++++--
>>> drivers/clk/meson/clk-pll.h | 2 ++
>>> 2 files changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
>>> index 1ea6579a760f..5a0bd75f85a9 100644
>>> --- a/drivers/clk/meson/clk-pll.c
>>> +++ b/drivers/clk/meson/clk-pll.c
>>> @@ -388,8 +388,13 @@ static int meson_clk_pll_enable(struct clk_hw *hw)
>>> }
>>>
>>> if (MESON_PARM_APPLICABLE(&pll->l_detect)) {
>>> - meson_parm_write(clk->map, &pll->l_detect, 1);
>>> - meson_parm_write(clk->map, &pll->l_detect, 0);
>>> + if (pll->flags & CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH) {
>>> + meson_parm_write(clk->map, &pll->l_detect, 0);
>>> + meson_parm_write(clk->map, &pll->l_detect, 1);
>>> + } else {
>>> + meson_parm_write(clk->map, &pll->l_detect, 1);
>>> + meson_parm_write(clk->map, &pll->l_detect, 0);
>>> + }
>> I'm not a fan of this code duplication.
>> Use the introduced CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH to compute the
>> first value, then flip the bit.
>
>
> Ok, I will update this in the next version.
>
> Here is the updated code:
>
> if (MESON_PARM_APPLICABLE(&pll->l_detect)) {
> meson_parm_write(clk->map, &pll->l_detect,
> !(pll->flags &
> CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH));
> meson_parm_write(clk->map, &pll->l_detect,
> !!(pll->flags &
> CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH));
Please use a variable. Make it clean
> }
>
>>> }
>>>
>>> if (meson_clk_pll_wait_lock(hw))
>>> diff --git a/drivers/clk/meson/clk-pll.h b/drivers/clk/meson/clk-pll.h
>>> index 949157fb7bf5..97b7c70376a3 100644
>>> --- a/drivers/clk/meson/clk-pll.h
>>> +++ b/drivers/clk/meson/clk-pll.h
>>> @@ -29,6 +29,8 @@ struct pll_mult_range {
>>>
>>> #define CLK_MESON_PLL_ROUND_CLOSEST BIT(0)
>>> #define CLK_MESON_PLL_NOINIT_ENABLED BIT(1)
>>> +/* l_detect signal is active-high */
>>> +#define CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH BIT(2)
>>>
>>> struct meson_clk_pll_data {
>>> struct parm en;
>> --
>> Jerome
>
> Best regards,
>
> Jian
--
Jerome
^ permalink raw reply
* Re: [PATCH v4 11/24] iommu: Add iommu_report_device_broken() to quarantine a broken device
From: Nicolin Chen @ 2026-05-20 7:20 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, Kevin Tian, linux-arm-kernel, iommu, linux-kernel,
linux-acpi, linux-pci, vsethi, Shuai Xue
In-Reply-To: <20260520003023.GR3602937@nvidia.com>
On Tue, May 19, 2026 at 09:30:23PM -0300, Jason Gunthorpe wrote:
> On Tue, May 19, 2026 at 05:21:36PM -0700, Nicolin Chen wrote:
> > On Tue, May 19, 2026 at 08:02:04PM -0300, Jason Gunthorpe wrote:
> > > > OK. So you are suggesting a quarantine at the driver-level only:
> > > >
> > > > 1. Driver detects ATC_INV timeout during an invalidation.
> > > > 2. Driver retries the commands to identify the master.
> > >
> > > I might argue to push even this out to a followup series given it is
> > > complex and I suspect it becomes much simpler after the batch
> > > removal...
> >
> > I see you suggest to treat the entire batch as ATS-broken. Just to
> > confirm: without per-SID retry, that might falsely block a healthy
> > device in the ATC batch, right? The driver now batches all ATC_INV
> > commands via arm_smmu_invs_end_batch().
>
> Yes, it is not good, but a giant complex series is not reviewable. So
> I'd start with trashing all the devices, then come with a narrowing.
I can take that path for now and leave a FIXME.
Another option is to not batch multiple devices, until we support
retry (which shouldn't be hard to add since we've already done the
coding)?
> > > > 5. Driver sets master->ats_broken to fence concurrent attach:
> > > > arm_smmu_write_ste() and arm_smmu_ats_supported().
> > >
> > > Not sure this is needed, if we race some attach then the attach will
> > > re-set EATS, get another timeout and clear EATS. Doesn't seem worth
> > > trying to optimize for.
> >
> > I didn't see that coming. master->ats_enabled && state->ats_enabled
> > in the commit() for a concurrent attachment would issue an ATC that
> > may timeout again to re-start the step 1.
> >
> > And since arm_smmu_atc_inv_master() doesn't use domain->invs, it is
> > not affected by INV_TYPE_ATS_BROKEN. So, ATC_INV can continue to be
> > issued in this case.
> >
> > Ah, I feel that we are walking in the mine field where every single
> > step could be a kaboom. But your insight is clearly a safe pathway.
>
> We cannot eliminate parallel ATS invalidation. Two threads could be
> concurrently processing the invs list. So it has handle it, the driver
> is going to have to tolerate a number of redundant error events.
OK. That sounds like we still need a flag or locking so that at
least pci_disable_ats() would not be called again. I will see
what I can do.
> > > We do need to push a pci error event (didn't see that in this series)
> > > so the driver can catch it and start the FLR process. I suppose that
> > > will still need to bounce through a workqueue, and once you have that
> > > it can also set the blocked domain prior to calling out to the driver.
> >
> > In the specific case that I am trying to tackle with this series, I
> > do see AER error prints from the device already but there is no FLR
> > process.
>
> It depends on the driver, mlx5 has a FLR RAS flow for instance.
I assume a driver like that would trigger FLR flow on its own?
> A driver with a device that can blow up ATS should implement the FLR
> flow if it wants automatic RAS. It requires driver co-ordination.
Or FLR via sysfs, which I have been doing...
> But I wasn't thinking we can rely on existing AER events here, yes
> probably there will be AERs associated with the device exploding so
> badly it cannot do ATS, but also maybe not..
So, should I put the AER injection on hold for a future work? To
be honest, I am still not very clear how AER injection could help
here; or is it for a case where ATC times out while device isn't
aware of any AER fault?
> This is also a problem if we shoot healthy devices as the first stage,
> there will not be an AER from heathly..
>
> So I guess we need to decide which is better to tackle, the dedicated
> event or the single invalidation sequence..
I feel it safer to not break healthy devices. Otherwise, would a
nesting parent invalidation falsely block all devices, if one of
them times out?
Thanks
Nicolin
^ permalink raw reply
* [PATCH v8] arm64: dts: imx95: Correct PCIe outbound address space configuration
From: Richard Zhu @ 2026-05-20 7:22 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, frank.li, s.hauer, festevam
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel,
Richard Zhu
Fix the PCIe outbound memory ranges for both pcie0 and pcie1
controllers on i.MX95.
The memory window size was incorrectly set to 256MB during initial
bring-up, but the hardware supports up to 4GB of outbound address space
per controller.
Additionally, the ECAM region cannot be mapped as I/O space. Use a
memory-mapped region for I/O space instead, and relocate the 1MB I/O
region to immediately follow the memory region at offset 0xf0000000
within each window.
Update the outbound address space layout per controller as follows:
- 3.5GB 64-bit prefetchable memory
- 256MB 32-bit non-prefetchable memory
- 1MB I/O
Fixes: 3b1d5deb29ff ("arm64: dts: imx95: add pcie[0,1] and pcie-ep[0,1] support")
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx95.dtsi | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
---
Changes in v8:
- Keep low address free, set the 32-bit non-prefetchable memory regioin
starting at 0xe0000000. Since PCI address 0x0 might break inbound DMA.
Changes in v7:
- Map the large outbound window into 64-bit PCI address, to eliminates both
the inbound DMA routing conflict and the IOVA exhaustion problem.
Changes in v6:
- Set the PCI I/O bus address starting at 0x0000_0000, while keeping the
CPU-side mapping at 0x9_f000_0000.
Changes in v5:
- Expand the outbound address space from 256MB to 3840MB, starting at the
base of each controller's assigned CPU address range.
- Use a memory region to map the I/O space.
Changes in v4:
Update the flag from 0x82000000 to 0x83000000 to declare a 64-bit PCI space.
Changes in v3:
Update the commit message, and set the region size to the max
hardware-supported memory space 4G.
Changes in v2:
Add the Fixes tag, and rebase to latest imx/dt64 branch.
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index adcc0e1d3696..60bf0932c6f7 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1939,8 +1939,9 @@ pcie0: pcie@4c300000 {
<0 0x4c360000 0 0x10000>,
<0 0x4c340000 0 0x4000>;
reg-names = "dbi", "config", "atu", "app";
- ranges = <0x81000000 0x0 0x00000000 0x0 0x6ff00000 0 0x00100000>,
- <0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000>;
+ ranges = <0x43000000 0x9 0x00000000 0x9 0x00000000 0x0 0xe0000000>,
+ <0x82000000 0x0 0xe0000000 0x9 0xe0000000 0x0 0x10000000>,
+ <0x81000000 0x0 0x00000000 0x9 0xf0000000 0x0 0x00100000>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -2014,8 +2015,9 @@ pcie1: pcie@4c380000 {
<0 0x4c3e0000 0 0x10000>,
<0 0x4c3c0000 0 0x4000>;
reg-names = "dbi", "config", "atu", "app";
- ranges = <0x81000000 0 0x00000000 0x8 0x8ff00000 0 0x00100000>,
- <0x82000000 0 0x10000000 0xa 0x10000000 0 0x10000000>;
+ ranges = <0x43000000 0xa 0x00000000 0xa 0x00000000 0x0 0xe0000000>,
+ <0x82000000 0x0 0xe0000000 0xa 0xe0000000 0x0 0x10000000>,
+ <0x81000000 0x0 0x00000000 0xa 0xf0000000 0x0 0x00100000>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
--
2.37.1
^ permalink raw reply related
* Re: [PATCH v2 0/7] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Uladzislau Rezki @ 2026-05-20 7:15 UTC (permalink / raw)
To: Andrew Morton
Cc: Wen Jiang, linux-mm, linux-arm-kernel, catalin.marinas, will,
urezki, baohua, Xueyuan.chen21, dev.jain, rppt, david,
ryan.roberts, anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <20260519131738.11a78ba88e1be28ba5cb26eb@linux-foundation.org>
On Tue, May 19, 2026 at 01:17:38PM -0700, Andrew Morton wrote:
> On Thu, 14 May 2026 17:41:01 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
>
> > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > is physically fully or partially contiguous.
> >
> > ...
> >
> > On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> > the performance CPUfreq policy enabled, benchmark results:
> >
> > * ioremap(1 MB): 1.35× faster (3407 ns -> 2526 ns)
> > * vmalloc(1 MB) mapping time (excluding allocation) with
> > VM_ALLOW_HUGE_VMAP: 1.42× faster (5.00 us -> 3.53us)
> > * vmap(100MB) with order-8 pages: 8.3× faster (1235 us -> 149 us)
>
> Nice.
>
> AI review found a bunch of things to ask about:
> https://sashiko.dev/#/patchset/20260514094108.2016201-1-jiangwen6@xiaomi.com
>
> It doesn't appear that you'll be getting any more review on this
> series, so please check the above questions and resend?
>
Actually i keep an eye on it and i have done some stability testing.
So, just need some time. Fixing AI sounds good.
--
Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc
From: Marc Zyngier @ 2026-05-20 7:17 UTC (permalink / raw)
To: joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will,
Oliver Upton, Vincent Donnefort
Cc: linux-arm-kernel, kvmarm, kernel-team
In-Reply-To: <20260514162624.3477857-1-vdonnefort@google.com>
On Thu, 14 May 2026 17:26:24 +0100, Vincent Donnefort wrote:
> pKVM must validate the host-provided tracing buffer descriptor.
> However, if an error is found, the hypervisor would just return 0 to the
> host. Fix the return value on validation failure.
>
> While at it, rename the function to hyp_trace_desc_is_valid() and skip
> validation for the nVHE mode as we trust host-provided data in that
> case.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc
commit: 1702da76e017ae0fbe1a92b07bc332972c293e89
Cheers,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: vgic: free private_irqs when init fails after allocation
From: Marc Zyngier @ 2026-05-20 7:17 UTC (permalink / raw)
To: Oliver Upton, Michael Bommarito
Cc: Yao Yuan, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260519135042.2219239-1-michael.bommarito@gmail.com>
On Tue, 19 May 2026 09:50:42 -0400, Michael Bommarito wrote:
> Companion to commit 250f25367b58 ("KVM: arm64: Tear down vGIC on
> failed vCPU creation"), which added the missing kvm_vgic_vcpu_destroy()
> call to the kvm_share_hyp() failure path in kvm_arch_vcpu_create(). The
> kvm_vgic_vcpu_init() failure path immediately above it has the same
> shape and still needs the same cleanup.
>
> Call kvm_vgic_vcpu_destroy() when kvm_vgic_vcpu_init() fails so private
> IRQs allocated before a redistributor iodev registration failure are
> released before the failed vCPU is freed.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: vgic: free private_irqs when init fails after allocation
commit: f19c354dbd457759dfcf1195ab4bdba2bb568323
Cheers,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: vgic-its: reject restored DTE with out-of-range num_eventid_bits
From: Marc Zyngier @ 2026-05-20 7:17 UTC (permalink / raw)
To: Oliver Upton, Michael Bommarito
Cc: Yao Yuan, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm,
linux-kernel
In-Reply-To: <20260519132519.2142458-1-michael.bommarito@gmail.com>
On Tue, 19 May 2026 09:25:19 -0400, Michael Bommarito wrote:
> Userspace can restore an ITS Device Table Entry whose Size field encodes
> more EventID bits than the virtual ITS supports. The live MAPD path
> rejects that state, but vgic_its_restore_dte() accepts it and stores the
> out-of-range value in dev->num_eventid_bits.
>
> Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before
> allocating the device. This mirrors the MAPD check and prevents the
> restored state from reaching vgic_its_restore_itt(), where the unchecked
> value can be converted into an oversized scan_its_table() range.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: vgic-its: reject restored DTE with out-of-range num_eventid_bits
commit: 9ce754ed8e7ab4e3999767ce1505f85c449ccb07
Cheers,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Krzysztof Kozlowski @ 2026-05-20 7:08 UTC (permalink / raw)
To: Chancel Liu (OSS), Chancel Liu
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: <AM9PR04MB8353B563519EBC1AD6C5BFE1E3012@AM9PR04MB8353.eurprd04.prod.outlook.com>
On 20/05/2026 07:02, Chancel Liu (OSS) wrote:
>>>>>>> +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.
>>>>
>>>> aud is not much better. Which boards have it? What's the pinout?
>> What's
>>>> standard? Is it described anywhere? If so, provide reference to
>> spec/docs.
>>>>
>>>
>>> This is not an industry standard electrical interface. This connector
>>
>> Then if you do not have standard, then you have board specific layouts
>> thus you need board-specific compatibles. You can use fallbacks. Generic
>> fallback could work, but both io-connector and aud-io-connector are just
>> too generic. Every connector is "connector" and "io", thus absolutely
>> anything can be "io-connector". "aud" improves it only a bit, thus
>> honestly I would go with board specific fallback as well.
>>
>
> How about board specific + common fallback compatible like this:
> compatible:
> items:
> - enum:
> - fsl,imx95-19x19-evk-aud-io-connector
> - fsl,imx952-evk-aud-io-connector
> - const: fsl,imx-aud-io-connector
> Since the daughter board is named “IMX-AUD-IO” in publicly available
I don't think it is named like that.
git grep -i imx-aud-io
> documentation, common compatible clearly indicates that this connector
> is intended for that.
>
> Also, I want to talk about the topic of generic connector. It's a common
> design that daughter board is connected to base board through a
> connector. This connector more often acts as a nexus that exposes a
> constrained subset of GPIO, clock, PWM and interrupt resources to the
> daughter board. Can we document this kind of connector as a generic
> binding?
So this binding is the connector between carrier and some addon? Then
you don't get a compatible for that at all, because it is not necessary,
not useful and NEVER used. Do you see socket LGA "connector" bindings? No.
Best regards,
Krzysztof
^ permalink raw reply
* [PACTH v2] i2c: imx: mark I2C adapter when hardware is powered down
From: Carlos Song (OSS) @ 2026-05-20 7:09 UTC (permalink / raw)
To: o.rempel, kernel, andi.shyti, Frank.Li, s.hauer, festevam,
carlos.song, haibo.chen
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
From: Carlos Song <carlos.song@nxp.com>
Mark the I2C adapter as suspended during system suspend to block further
transfers, and resume it on system resume. This prevents potential hangs
when the hardware is powered down but clients still attempt I2C transfers.
Fixes: 358025ac091e ("i2c: imx: make controller available until system suspend_noirq() and from resume_noirq()")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
Change for v2:
- Call i2c_mark_adapter_suspended() before pm_runtime_force_suspend()
to prevent potential deadlock if a transfer is active during suspend.
- Roll back with i2c_mark_adapter_resumed() if pm_runtime_force_suspend()
fails.
---
drivers/i2c/busses/i2c-imx.c | 34 ++++++++++++++++++++++++++++++++--
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index a208fefd3c3b..cf6e1333b084 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1913,6 +1913,36 @@ static int i2c_imx_runtime_resume(struct device *dev)
return ret;
}
+static int __maybe_unused i2c_imx_suspend_noirq(struct device *dev)
+{
+ struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
+ int ret;
+
+ i2c_mark_adapter_suspended(&i2c_imx->adapter);
+
+ ret = pm_runtime_force_suspend(dev);
+ if (ret) {
+ i2c_mark_adapter_resumed(&i2c_imx->adapter);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __maybe_unused i2c_imx_resume_noirq(struct device *dev)
+{
+ struct imx_i2c_struct *i2c_imx = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_force_resume(dev);
+ if (ret)
+ return ret;
+
+ i2c_mark_adapter_resumed(&i2c_imx->adapter);
+
+ return 0;
+}
+
static int i2c_imx_suspend(struct device *dev)
{
/*
@@ -1946,8 +1976,8 @@ static int i2c_imx_resume(struct device *dev)
}
static const struct dev_pm_ops i2c_imx_pm_ops = {
- NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
- pm_runtime_force_resume)
+ NOIRQ_SYSTEM_SLEEP_PM_OPS(i2c_imx_suspend_noirq,
+ i2c_imx_resume_noirq)
SYSTEM_SLEEP_PM_OPS(i2c_imx_suspend, i2c_imx_resume)
RUNTIME_PM_OPS(i2c_imx_runtime_suspend, i2c_imx_runtime_resume, NULL)
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v7 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-05-20 7:05 UTC (permalink / raw)
To: Kevin Hilman
Cc: Andreas Kemnade, Bartosz Golaszewski, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Janusz Krzysztofik,
Tony Lindgren, Russell King, Dmitry Torokhov, Arnd Bergmann,
driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Aaro Koskinen
In-Reply-To: <agYB3-T9yz9-hdr4@darkstar.musicnaut.iki.fi>
On Thu, May 14, 2026 at 7:10 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>
> Hi,
>
> On Wed, May 13, 2026 at 02:59:26PM +0200, Andreas Kemnade wrote:
> > On Mon, 11 May 2026 15:34:39 +0200
> > Bartosz Golaszewski <brgl@kernel.org> wrote:
> > > > This converts Nokia 770 to using real firmware node lookup for GPIOs by
> > > > attaching the software nodes describing GPIO controllers to their target
> > > > devices.
> > > >
> > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > >
> > > Hi!
> > >
> > > Gentle ping, can this be queued now for v7.2?
> > >
> > So any objections from your side, Aaro?
>
> It's fine.
>
> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
>
> A.
Kevin,
I think you offered to queue these patches before, can you take them for v7.2?
Thanks,
Bartosz
^ permalink raw reply
* [PATCH v2 3/3] crypto: atmel-ecc - Use named initializers for struct i2c_device_id
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-20 7:01 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: Ard Biesheuvel, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1779260113.git.u.kleine-koenig@baylibre.com>
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
This patch doesn't modify the compiled array, only its representation in
source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/crypto/atmel-ecc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index 9660f6426a84..0ca02995a1de 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -376,8 +376,8 @@ static const struct of_device_id atmel_ecc_dt_ids[] = {
MODULE_DEVICE_TABLE(of, atmel_ecc_dt_ids);
static const struct i2c_device_id atmel_ecc_id[] = {
- { "atecc508a" },
- { "atecc608b" },
+ { .name = "atecc508a" },
+ { .name = "atecc608b" },
{ }
};
MODULE_DEVICE_TABLE(i2c, atmel_ecc_id);
--
2.47.3
^ 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