* [GIT PULL] SoC fixes for 7.2
From: Arnd Bergmann @ 2026-07-17 15:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-arm-kernel, soc
The following changes since commit 8cdeaa50eae8dad34885515f62559ee83e7e8dda:
Linux 7.2-rc2 (2026-07-05 14:44:06 -1000)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-fixes-7.2-1
for you to fetch changes up to 3d9855d114f0955d590420f5670152c1099c1638:
Merge tag 'renesas-fixes-for-v7.2-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/fixes (2026-07-16 15:59:57 +0200)
----------------------------------------------------------------
SoC fixes for 7.2
There are only three devicetree fixes this time: one critical memory
corruption fix for Renesas and three minor corrections for Tegra.
The MAINTAINERS file is updated for a new maintainer of the CIX platform
and two address changes.
The rest is all driver fixes, mostly firmware:
- multiple runtime issues in ARM SCMI and FF-A firmware code, dealing
with error handling for corner cases in firmware.
- multiple fixes for reset drivers, dealing with individual platform
specific mistakes and more error handling
- minor build and runtime fixes for the Tegra SoC drivers
----------------------------------------------------------------
Akhil R (1):
arm64: tegra: Remove fallback compatible for GPCDMA
Arnd Bergmann (8):
soc/tegra: pmc: fix #ifdef block in header
Merge tag 'reset-fixes-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/pza/linux into arm/fixes
Merge tag 'tegra-for-7.2-pmc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes
Merge tag 'tegra-for-7.2-soc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes
Merge tag 'tegra-for-7.2-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes
Merge tag 'tee-update-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into arm/fixes
Merge tag 'scmi-ffa-fixes-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Merge tag 'renesas-fixes-for-v7.2-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/fixes
Breno Leitao (1):
soc/tegra: fuse: Fix spurious straps warning on SMCCC platforms
Christophe JAILLET (1):
drm/tegra: Fix a strange error handling path
Gary Yang (1):
MAINTAINERS: Update maintainer and git tree for CIX SoC
Geert Uytterhoeven (1):
firmware: arm_scmi: Grammar s/may needed/may be needed/
Jens Wiklander (1):
MAINTAINERS: .mailmap: update Jens Wiklander's email address
Marek Vasut (1):
arm64: dts: renesas: ironhide: Describe inline ECC carveouts
Pushpendra Singh (1):
firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context
Robby Cai (1):
reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ
Seth Forshee (1):
firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits
Steve Dunnagan (1):
firmware: arm_scmi: Use 64-bit division for clock rate rounding
Sudeep Holla (1):
Merge branches 'for-next/scmi/fixes' and 'for-next/ffa/fixes'
Sumit Gupta (2):
arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234
arm64: tegra: Fix CPU1 node unit-address on Tegra264
Tanmay Kathpalia (1):
dt-bindings: reset: altr: add COMBOPHY_RESET for Agilex5
Unnathi Chalicheemala (1):
firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()
Uwe Kleine-König (The Capable Hub) (1):
ARM: Don't let ARMv5 platforms select USE_OF
Yixun Lan (2):
reset: spacemit: k3: fix USB2 ahb reset
MAINTAINERS: Update SpacemiT SoC git tree repository
Zhao Dongdong (1):
reset: sunxi: fix memory region leak on ioremap failure
.mailmap | 1 +
MAINTAINERS | 12 +++----
arch/arm/mach-ixp4xx/Kconfig | 1 -
arch/arm/mach-pxa/Kconfig | 3 --
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 24 ++++++-------
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 4 +--
arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts | 41 +++++++++++++++++++++++
drivers/firmware/arm_ffa/driver.c | 29 +++++++++++-----
drivers/firmware/arm_scmi/Kconfig | 4 +--
drivers/firmware/arm_scmi/clock.c | 11 +++---
drivers/firmware/arm_scmi/notify.c | 6 ++--
drivers/gpu/drm/tegra/sor.c | 6 ++--
drivers/reset/reset-imx7.c | 6 ++++
drivers/reset/reset-sunxi.c | 4 ++-
drivers/reset/spacemit/reset-spacemit-k3.c | 2 +-
drivers/soc/tegra/fuse/tegra-apbmisc.c | 2 +-
include/dt-bindings/reset/altr,rst-mgr-s10.h | 2 +-
include/soc/tegra/pmc.h | 5 ++-
18 files changed, 113 insertions(+), 50 deletions(-)
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx91-9x9-qsb: add CAN support overlay file
From: Frank.Li @ 2026-07-17 15:37 UTC (permalink / raw)
To: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, haibo.chen
Cc: Frank Li, imx, linux-arm-kernel, devicetree, linux-kernel,
Haibo Chen
In-Reply-To: <20260710-dts-imx91-can1-v1-1-c78c9c378e8d@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Fri, 10 Jul 2026 18:12:20 +0800, haibo.chen@oss.nxp.com wrote:
> On the i.MX91 9x9 QSB, CAN1 and MICFIL share pins. A TMUX1574RSVR
> analog mux controls the routing: when SEL is driven high, CAN1 is
> selected; when SEL is driven low, MICFIL is selected. By default,
> SEL is kept low.
>
> To enable CAN1, SEL must be driven high. This is done via the can_fun
> function defined in the pinctrl-gpiomux node. CAN1 uses the
> TJA1057GT/3 PHY.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: imx91-9x9-qsb: add CAN support overlay file
commit: 356894c37aa1f8ab430cef5d69176123b0ec98b3
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 0/7] Add reset support to MT6589 wdt and remove fallback compatibles
From: Akari Tsuyukusa @ 2026-07-17 15:38 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Philipp Zabel
Cc: open list:WATCHDOG DEVICE DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, Roman Vivchar
In-Reply-To: <20260716161923.266315-1-akkun11.open@gmail.com>
On Fri, Jul 17, 2026 at 1:19 AM Akari Tsuyukusa <akkun11.open@gmail.com> wrote:
>
> This series adds TOPRGU reset controller support to the MT6589 watchdog
> and removes the use of "mediatek,mt6589-wdt" as the fallback compatible
> from many other MediaTek SoCs.
>
> Many SoCs have been using "mediatek,mt6589-wdt" as the fallback.
> However, they are not compatible with the MT6589's reset register.
>
> To add reset support to MT6589 wdt and resolve this problem safely,
> the series proceeds step by step:
Better patch series is available
Link: https://lore.kernel.org/linux-mediatek/20260717151134.678839-1-l.scorcia@gmail.com/T/#t
I'm withdrawing this series.
Best regards,
Akari
^ permalink raw reply
* RE: [PATCH v3 3/7] gpio: regmap: Add gpio_regmap_operation and write-enable support
From: Yu-Chun Lin [林祐君] @ 2026-07-17 15:38 UTC (permalink / raw)
To: Andy Shevchenko, Michael Walle
Cc: Michael.Hennerich@analog.com, afaerber@suse.com, andy@kernel.org,
brgl@kernel.org, conor+dt@kernel.org,
CY_Huang[黃鉦晏], devicetree@vger.kernel.org,
dlechner@baylibre.com, James Tai [戴志峰],
jic23@kernel.org, krzk+dt@kernel.org, lars@metafoo.de,
linus.walleij@linaro.org, linusw@kernel.org,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-realtek-soc@lists.infradead.org,
mathieu.dubois-briand@bootlin.com, nuno.sa@analog.com,
robh@kernel.org, Stanley Chang[昌育德],
TY_Chang[張子逸], wbg@kernel.org
In-Reply-To: <alkbVkB5KNNR7ffN@ashevche-desk.local>
Hi,
>
> On Thu, Jul 16, 2026 at 12:55:37PM +0200, Michael Walle wrote:
> > On Thu Jul 16, 2026 at 11:40 AM CEST, Andy Shevchenko wrote:
> > > On Thu, Jul 16, 2026 at 11:08:55AM +0200, Michael Walle wrote:
> > >> On Thu Jul 16, 2026 at 10:27 AM CEST, Andy Shevchenko wrote:
> > >> > On Thu, Jul 16, 2026 at 02:26:14PM +0800, Yu-Chun Lin wrote:
>
> ...
>
> > >> > From the above list I tend to the approach 2, but this might
> > >> > require to have GPIO regmap level of locking. I'm a bit lost in
> > >> > the context, though. I assume we need a fresh start, id est issue
> > >> > a v6 with approach 2 or 3 in place and summarize the choices in
> > >> > the cover letter, so we can understand what has been considered.
> > >>
> > >> I don't really like approach 3. You'd need to check if the regs of
> > >> both xlate calls are the same. With the sample code above, you
> > >> silently drop the first xlate'd reg.
> > >
> > > If I rank the proposals, the worst is #1, the best is #2.
> > >
> > >> And honestly, it really seems like a one-off. What controllers, are
> > >> there that need a write enable bit. The real problem seems to be
> > >> the assumption that we operate on just one bit. IOW we either set
> > >> mask or don't set mask in gpio_regmap_set().
> > >
> > > Yes, we should KISS.
> >
> > But IMHO #2 and #3 are not KISS. Approach 2 is just a way of adding
> > some kind of pre op to a gpio set. Just tying it to a write enable
> > feature. That kinda bothers me. It might also be useful for other
> > things, too. So don't tie it to just write enable. And who is doing a
> > write disable if it's not self clearing for example. Probably Some
> > kind of post op :)
> >
> > Approach 3 is a way to change the value of the written value - in a
> > restricted way, as is is just doing a OR with both values.
> >
> > Also approach 2 might not even work if the hardware requires the write
> > enable bit set in the *same* write as the gpio set bit. Thus, we might
> > need both anyway in the future.
> >
> > >> For a more generic solution, we should be able to control the
> > >> written value. We could add another .value_xlate().
> > >
> > > Maybe not now?
> >
> > But if not now, then when? I wouldn't add the write enable feature and
> > later a more generic solution which also covers the write enable
> > feature.
>
> Taking into account how it's done in HW, I think the whole approach can be
> folded to just a boolean flag (or a simply bit shift) in the config.
> Wouldn't it work?
>
To respect Michael's perspective on keeping WREN-specific code out of the
framework, I think adding a value_xlate callback in the config is a cleaner
approach. It allows us to wrap this hardware quirk within the callback and let
the consumer driver handle it entirely.
To ensure it is truly generic, I will not introduce any WREN-specific operation
flags. Instead, value_xlate will reuse the gpio_regmap_operation enum
(e.g., GPIO_REGMAP_OP_SET, GPIO_REGMAP_OP_SET_DIR).
Best Regards,
Yu-Chun
> > > As per IPs, Synopsys IPs (not exactly GPIO) likes to have that kind
> > > of "protection". So, from HW perspective it's kinda pattern, and it
> > > might be possible to see more IPs (including GPIO) that follow it in
> > > some cases.
>
> --
> With Best Regards,
> Andy Shevchenko
>
^ permalink raw reply
* Re: [PATCH v9 2/4] clk: cix: add sky1 audss clock controller
From: Brian Masney @ 2026-07-17 14:30 UTC (permalink / raw)
To: Joakim Zhang
Cc: mturquette@baylibre.com, sboyd@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <SEYPR06MB6226BD151ABBB192AEC53BA482C62@SEYPR06MB6226.apcprd06.prod.outlook.com>
On Fri, Jul 17, 2026 at 09:47:28AM +0000, Joakim Zhang wrote:
> > -----Original Message-----
> > > +static void sky1_audss_clk_remove(struct platform_device *pdev) {
> > > + struct device *dev = &pdev->dev;
> > > +
> > > + if (!pm_runtime_status_suspended(dev))
> > > + pm_runtime_force_suspend(dev);
> > > +
> > > + pm_runtime_disable(dev);
> >
> > I am fairly certain that remove() is called before the devm handlers are
> > invoked. The clocks will be shutdown, but there's a window where they are still
> > visible to consumers. I think you should use
> > devm_add_action_or_reset() so that the cleanup is called in the expected order.
> Agreed. remove() runs before devres_release_all(), so force_suspend() tears down the hardware while the OF clock provider is still visible. I'll move the runtime PM cleanup into a devm_add_action_or_reset() registered before the clocks/provider, and drop it from remove().
I don't know which email client you are using but you should fix your
client so that the text in your response wraps at 80 characters. Also
add a newline between what you are quoting and your response since it
also makes things much nicer to read in the archive.
Brian
^ permalink raw reply
* Re: [PATCH v4 5/6] KVM: arm64: Add HDBSS fault handling and buffer flush
From: Leonardo Bras @ 2026-07-17 15:44 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, will, yuzenghui,
wangzhou1, yangjinqian1, caijian11, liuyonglong, yezhenyu2,
yubihong, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-kernel, seiden, suzuki.poulose
In-Reply-To: <3fb4b33e-4618-4523-b140-955e15fd9a8c@huawei.com>
On Fri, Jul 17, 2026 at 02:51:12PM +0800, Tian Zheng wrote:
>
> On 7/14/2026 10:19 PM, Leonardo Bras wrote:
> > On Tue, Jul 14, 2026 at 09:27:15PM +0800, Tian Zheng wrote:
> > > On 7/14/2026 6:50 PM, Leonardo Bras wrote:
> > > > On Tue, Jul 14, 2026 at 03:38:39PM +0800, Tian Zheng wrote:
> > > > > On 7/13/2026 10:06 PM, Leonardo Bras wrote:
> > > > > > On Thu, Jul 09, 2026 at 06:40:25PM +0800, Tian Zheng wrote:
> > > > > > > From: eillon <yezhenyu2@huawei.com>
> > > > > > >
> > > > > > > Add HDBSS fault handling for buffer full, external abort, and general
> > > > > > > protection fault (GPF) events. When the HDBSS buffer becomes full,
> > > > > > > the hardware traps to EL2 with an HDBSSF event, which is handled by
> > > > > > > setting a flush request.
> > > > > > >
> > > > > > > Add kvm_flush_hdbss_buffer() to consume HDBSS buffer entries and
> > > > > > > propagate dirty information into the userspace-visible dirty bitmap.
> > > > > > > Flush is triggered on vcpu_put, check_vcpu_requests, and
> > > > > > > sync_dirty_log.
> > > > > > >
> > > > > > > Add esr_iss2_is_hdbssf() helper for HDBSS fault detection in guest
> > > > > > > abort handling.
> > > > > > >
> > > > > > > Signed-off-by: Eillon <yezhenyu2@huawei.com>
> > > > > > > Signed-off-by: Tian Zheng <zhengtian10@huawei.com>
> > > > > > > ---
> > > > > > > arch/arm64/include/asm/esr.h | 5 +++
> > > > > > > arch/arm64/include/asm/kvm_dirty_bit.h | 11 +++++
> > > > > > > arch/arm64/include/asm/kvm_host.h | 1 +
> > > > > > > arch/arm64/kvm/arm.c | 14 ++++++
> > > > > > > arch/arm64/kvm/dirty_bit.c | 62 ++++++++++++++++++++++++++
> > > > > > > arch/arm64/kvm/mmu.c | 4 ++
> > > > > > > 6 files changed, 97 insertions(+)
> > > > > > >
> > > > > > > diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> > > > > > > index 81c17320a588..2e6b679b5908 100644
> > > > > > > --- a/arch/arm64/include/asm/esr.h
> > > > > > > +++ b/arch/arm64/include/asm/esr.h
> > > > > > > @@ -437,6 +437,11 @@
> > > > > > > #ifndef __ASSEMBLER__
> > > > > > > #include <asm/types.h>
> > > > > > >
> > > > > > > +static inline bool esr_iss2_is_hdbssf(unsigned long esr)
> > > > > > > +{
> > > > > > > + return ESR_ELx_ISS2(esr) & ESR_ELx_HDBSSF;
> > > > > > This will return a long, which will be casted as bool.
> > > > > > In general, what I see in the kernel is something like:
> > > > > >
> > > > > > return !!(ESR_ELx_ISS2(esr) & ESR_ELx_HDBSSF)
> > > > > ok!
> > > > >
> > > > >
> > > > > > > +}
> > > > > > > +
> > > > > > > static inline unsigned long esr_brk_comment(unsigned long esr)
> > > > > > > {
> > > > > > > return esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
> > > > > > > diff --git a/arch/arm64/include/asm/kvm_dirty_bit.h b/arch/arm64/include/asm/kvm_dirty_bit.h
> > > > > > > index 84b12f0a10af..4b28000e972f 100644
> > > > > > > --- a/arch/arm64/include/asm/kvm_dirty_bit.h
> > > > > > > +++ b/arch/arm64/include/asm/kvm_dirty_bit.h
> > > > > > > @@ -10,7 +10,18 @@
> > > > > > > #include <asm/kvm_pgtable.h>
> > > > > > > #include <asm/sysreg.h>
> > > > > > >
> > > > > > > +/* HDBSS entry field definitions */
> > > > > > > +#define HDBSS_ENTRY_VALID BIT(0)
> > > > > > > +#define HDBSS_ENTRY_TTWL_SHIFT (1)
> > > > > > > +#define HDBSS_ENTRY_TTWL_MASK (GENMASK(3, 1))
> > > > > > > +#define HDBSS_ENTRY_TTWL(x) \
> > > > > > > + (((x) << HDBSS_ENTRY_TTWL_SHIFT) & HDBSS_ENTRY_TTWL_MASK)
> > > > > > > +#define HDBSS_ENTRY_TTWL_RESV HDBSS_ENTRY_TTWL(-4)
> > > > > > > +#define HDBSS_ENTRY_IPA GENMASK_ULL(55, 12)
> > > > > > > +
> > > > > > > int kvm_arm_vcpu_alloc_hdbss(struct kvm_vcpu *vcpu, unsigned int order);
> > > > > > > void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu);
> > > > > > > +void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu);
> > > > > > > +int kvm_handle_hdbss_fault(struct kvm_vcpu *vcpu);
> > > > > > >
> > > > > > > #endif /* __ARM64_KVM_DIRTY_BIT_H__ */
> > > > > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > > > > > index c41ec6d9c45a..cecfb884a64f 100644
> > > > > > > --- a/arch/arm64/include/asm/kvm_host.h
> > > > > > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > > > > > @@ -55,6 +55,7 @@
> > > > > > > #define KVM_REQ_GUEST_HYP_IRQ_PENDING KVM_ARCH_REQ(9)
> > > > > > > #define KVM_REQ_MAP_L1_VNCR_EL2 KVM_ARCH_REQ(10)
> > > > > > > #define KVM_REQ_VGIC_PROCESS_UPDATE KVM_ARCH_REQ(11)
> > > > > > > +#define KVM_REQ_FLUSH_HDBSS KVM_ARCH_REQ(12)
> > > > > > >
> > > > > > > #define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \
> > > > > > > KVM_DIRTY_LOG_INITIALLY_SET)
> > > > > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > > > > index bf6688245d83..566953a4e23a 100644
> > > > > > > --- a/arch/arm64/kvm/arm.c
> > > > > > > +++ b/arch/arm64/kvm/arm.c
> > > > > > > @@ -755,6 +755,9 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
> > > > > > > kvm_vcpu_put_hw_mmu(vcpu);
> > > > > > > kvm_arm_vmid_clear_active();
> > > > > > >
> > > > > > > + if (vcpu->kvm->arch.enable_hdbss)
> > > > > > > + kvm_flush_hdbss_buffer(vcpu);
> > > > > > > +
> > > > > > > vcpu_clear_on_unsupported_cpu(vcpu);
> > > > > > > vcpu->cpu = -1;
> > > > > > > }
> > > > > > > @@ -1157,6 +1160,9 @@ static int check_vcpu_requests(struct kvm_vcpu *vcpu)
> > > > > > > if (kvm_dirty_ring_check_request(vcpu))
> > > > > > > return 0;
> > > > > > >
> > > > > > > + if (kvm_check_request(KVM_REQ_FLUSH_HDBSS, vcpu))
> > > > > > > + kvm_flush_hdbss_buffer(vcpu);
> > > > > > > +
> > > > > > > check_nested_vcpu_requests(vcpu);
> > > > > > > }
> > > > > > >
> > > > > > > @@ -1971,7 +1977,15 @@ long kvm_arch_vcpu_unlocked_ioctl(struct file *filp, unsigned int ioctl,
> > > > > > >
> > > > > > > void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
> > > > > > > {
> > > > > > > + /*
> > > > > > > + * Flush all CPUs' dirty log buffers to the dirty_bitmap. Called
> > > > > > > + * before reporting dirty_bitmap to userspace. Send a request with
> > > > > > > + * KVM_REQUEST_WAIT to flush buffer synchronously.
> > > > > > > + */
> > > > > > > + if (!kvm->arch.enable_hdbss)
> > > > > > > + return;
> > > > > > >
> > > > > > > + kvm_make_all_cpus_request(kvm, KVM_REQ_FLUSH_HDBSS | KVM_REQUEST_WAIT);
> > > > > > > }
> > > > > > >
> > > > > > > static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
> > > > > > > diff --git a/arch/arm64/kvm/dirty_bit.c b/arch/arm64/kvm/dirty_bit.c
> > > > > > > index 6c7a6ef66b5a..002366337637 100644
> > > > > > > --- a/arch/arm64/kvm/dirty_bit.c
> > > > > > > +++ b/arch/arm64/kvm/dirty_bit.c
> > > > > > > @@ -50,3 +50,65 @@ void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu)
> > > > > > >
> > > > > > > vcpu->arch.hdbss.hdbssbr_el2 = 0;
> > > > > > > }
> > > > > > > +
> > > > > > > +void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu)
> > > > > > > +{
> > > > > > > + int idx, curr_idx;
> > > > > > > + u64 *hdbss_buf;
> > > > > > > + struct kvm *kvm = vcpu->kvm;
> > > > > > > +
> > > > > > > + if (!kvm->arch.enable_hdbss)
> > > > > > > + return;
> > > > > > > +
> > > > > > > + curr_idx = HDBSSPROD_IDX(read_sysreg_s(SYS_HDBSSPROD_EL2));
> > > > > > > +
> > > > > > > + /* Do nothing if HDBSS buffer is empty or br_el2 is NULL */
> > > > > > > + if (curr_idx == 0 || vcpu->arch.hdbss.hdbssbr_el2 == 0)
> > > > > > > + return;
> > > > > > > +
> > > > > > > + hdbss_buf = page_address(phys_to_page(vcpu->arch.hdbss.base_phys));
> > > > > > > + if (!hdbss_buf)
> > > > > > > + return;
> > > > > > > +
> > > > > > > + guard(write_lock_irqsave)(&vcpu->kvm->mmu_lock);
> > > > > > > + for (idx = 0; idx < curr_idx; idx++) {
> > > > > > > + u64 gpa;
> > > > > > > +
> > > > > > > + gpa = hdbss_buf[idx];
> > > > > > > + if (!(gpa & HDBSS_ENTRY_VALID))
> > > > > > > + continue;
> > > > > > > +
> > > > > > > + gpa &= HDBSS_ENTRY_IPA;
> > > > > > > + kvm_vcpu_mark_page_dirty(vcpu, gpa >> PAGE_SHIFT);
> > > > > > You mention that it does not support dirty-ring, but above function will
> > > > > > mark the page as dirty in the dirty-ring :/
> > > > > >
> > > > > In kvm_arm_enable_hdbss_global(), we explicitly check and reject HDBSS
> > > > > enablement if dirty-ring is active:
> > > > >
> > > > > ```
> > > > > if (kvm->dirty_ring_size)
> > > > > return 0;
> > > > > ```
> > > > >
> > > > > So when kvm_flush_hdbss_buffer() runs (which requires enable_hdbss = true),
> > > > > we know for certain that
> > > > >
> > > > > kvm->dirty_ring_size == 0. Therefore, kvm_vcpu_mark_page_dirty() will always
> > > > > take the dirty_bitmap path,
> > > > >
> > > > > never the dirty-ring path.
> > > > >
> > > > > That said, I'll add a comment in kvm_flush_hdbss_buffer() before dirty ring
> > > > > mode is supported, to make this explicit:
> > > > >
> > > > > ```
> > > > > /*
> > > > > * HDBSS is mutually exclusive with dirty-ring mode (see
> > > > > * kvm_arm_enable_hdbss_global()), so kvm_vcpu_mark_page_dirty()
> > > > > * will update the dirty_bitmap, not the dirty-ring.
> > > > > */
> > > > > ```
> > > > >
> > > > Got it :)
> > > >
> > > > Out of curiosity: which issues have you found on supporting dirty-ring at
> > > > this point?
> > > >
> > > > Thanks!
> > > > Leo
> > >
> > > I haven't looked deeply into dirty-ring yet — my main concern is that if
> > > both the dirty
> > >
> > > ring and HDBSS buffer fill up, the flush path might get blocked or
> > > complicated.
> > >
> > > For now, I'm planning to match the HDBSS buffer size to the dirty ring size
> > > in v5 and test it.
> > >
> > > Ideally, the two buffers would be the same size, and the entire dirty
> > > tracking path would use
> > >
> > Ah, I see the point.
> >
> > IIRC, when dirty-ring gets full, the kernel returns to userspace with
> > run->exit_reason == KVM_EXIT_DIRTY_RING_FULL, which will warn the VMM to
> > drain the dirty-ring, and that makes space for us draining HDBSS to the
> > dirty-ring again.
> >
> > The best way to achieve that, as I remember, is to always drain
> > HDBSS as much as possible at guest_exitting. That will make more space to
> > newer HDBSS entries, and we can get userspace to drain the dirty-ring
> > earlier.
> >
> > I would say to even make HDBSS buffer half (entries) the dirty-ring. Then
> > we can generally fully drain to the dirty-ring and even report ring full
> > if the ring is above a given threshold percentage full.
> > > HDBSS exclusively — no fallback to the legacy dirty bitmap path. If that
> > > works, I think this approach should be fine.
> > >
> > > Let me know if you have any insights on dirty ring's full-buffer behavior —
> > > that would be helpful.
> > >
> > >
> > Will do!
> >
> > Thanks!
> > Leo
>
>
> Thanks for the insights — reusing PML's reservation mechanism makes sense.
>
> I think we can*keep the HDBSS buffer at 512 entries* (matching
I recommend using a PAGESIZE (512 in 4k, but bigger in other sizes)
> PML_LOG_NR_ENTRIES)
>
> for now, and *not expose any ioctl for userspace to configure it*. Since the
> kernel
>
> auto-enables HDBSS, a userspace size knob would be confusing.
>
Humm, I am in favor of letting the user change it according to it's
workload. Why would that be confusing?
(Having a default size is useful just for enabling it to work without any
change in current VMs)
>
> The reservation logic would be:
>
> - Implement kvm_cpu_dirty_log_size() on arm64 to return the HDBSS buffer
> entry
>
> count (512, or 0 if HDBSS is not enabled)
Why a get to log_size? does userspace need to know it's using HDBSS?
Just a set should do, as VMMs can just try to set a value, and if it fails
(IOCTL does not exist, or invalid value), then it can just go forward.
>
> - Reuse kvm_dirty_ring_get_rsvd_entries() to reserve space for one full
> flush:
>
> KVM_DIRTY_RING_RSVD_ENTRIES + hdbss_entries
>
> - So soft_limit = dirty_ring_size - (KVM_DIRTY_RING_RSVD_ENTRIES +
> hdbss_entries),
>
> guaranteeing a full flush always fits
>
> kvm_flush_hdbss_buffer() at guest_exit pushes via mark_page_dirty_in_slot()
> ->
>
I think I get the point here: since we can have sw dirtying as well as
HDBSS tracking, we may get to the point that we don't have enough space to
flush hdbss -> dirty-ring, right?
> kvm_dirty_ring_push() -> kvm_dirty_ring_soft_full, which triggers
>
> KVM_EXIT_DIRTY_RING_FULL when needed.
>
> If soft_limit is hit, KVM_REQ_DIRTY_RING_FULL is set and the next vcpu_run
> exits
>
> to userspace for QEMU to drain the ring.
So the software dirtying routine would be affected by the soft limit, but
HADBSS exit would not. It means the dirty-ring would be effectively smaller
than specified if we are having mostly sw dirtying.
Did I get that right?
>
> *One more thing: *when userspace sets the dirty ring size via
>
> KVM_VM_IOCTL_ENABLE_DIRTY_LOG_RING, we already enforce that
>
> size >= kvm_dirty_ring_get_rsvd_entries(kvm) * sizeof(struct kvm_dirty_gfn)
>
> or size < PAGE_SIZE. With HDBSS, kvm_dirty_ring_get_rsvd_entries() will
> include the
>
> HDBSS entries via kvm_cpu_dirty_log_size(), so the same check will
> automatically guarantee
>
> the ring is large enough to accommodate the HDBSS buffer. No additional
> validation is needed.
>
An alternative is moving the remaining array entries to the beginning of
the array, and setting the registers accordingly. The tradeoff is an
overhead here vs having the full size of the array available later.
Thanks!
Leo
^ permalink raw reply
* Re: [RFC PATCH v1 1/8] misc/arm-cla: Add driver skeleton and documentation
From: Ryan Roberts @ 2026-07-17 15:44 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
Mark Rutland, Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet
Cc: linux-kernel, linux-arm-kernel, dri-devel, linux-doc
In-Reply-To: <1e561b1a-2c87-4a23-b4da-126b333de8ba@app.fastmail.com>
Hi Arnd,
Thanks for all your fast feedback!...
On 17/07/2026 14:49, Arnd Bergmann wrote:
> On Fri, Jul 17, 2026, at 12:47, Ryan Roberts wrote:
>> From: Jean-Philippe Brucker <jpb@kernel.org>
>>
>> Add the initial Kconfig and build-system plumbing for the Arm Core Local
>> Accelerator driver.
>>
>> Introduce the common driver header and register definitions used by
>> later CLA support. The definitions cover the CLA MMIO frame, launch
>> response and status fields, standard accelerator registers, launch
>> opcodes, error codes and memory translation context state.
>>
>> Add documentation describing the CLA programming model, its CPU-local
>> MMIO access rules, userspace assignment model, domain grouping and
>> expected boot state.
>
> I have a few more questions here. Most of the description and
> the design decisions make perfect sense to me, but there are
> a few things I don't understand from your current document.
>
>> +The CLA supports up to 8 attached accelerators, which are accessed by
>> +programming the CLA's MMIO registers. Operations are launched to an
>> accelerator
>> +and are polled for completion. CLA does not raise interrupts.
>> +
>> + CPU CLA Accel
>> + |--- write DATA[7:0] -->| |
>> + |--- write LAUNCH ----->|---- launch ---->|
>> + |<--- poll LRESP -------| |
>> + | | |
>> + |<--- poll STATUS ------|<--- complete ---|
>> +
>> +Each operation can take a 512-bit payload in the DATA registers. After handling
>> +a LAUNCH write, CLA indicates the launch status in the LRESP register. A further
>> +operation can only be launched after LRESP indicates completion of the previous
>> +launch.
>
> This sounds a lot like st64bv or st64bv0, passing an 8-word payload and returning
> a single word per accelerator operation with shared addressing.
We're actually passing 9 words here; 8 DATA words plus the LAUNCH word. CLA
supports only 64 bit aligned and sized accesses (other accesses are RAZ/WI) so
they have to be written as 9x64bit stores. Then poll using 64bit loads.
>
> Why are there now two interfaces to do the same thing?
Good question. This is how the HW operates.
>
> Can a user process use st64bv to do the four steps in a
> single instruction?
No, unfortunately not.
>
>> +Some operations continue to run asynchronously on the accelerator after launch
>> +completion. In this case progress is tracked by polling the STATUS register.
>> +When the CLA updates the STATUS register, it also raises an event which will
>> +wake an in-progress WFE (wait for event) instruction on the local CPU.
>
> The asynchronous interface seems very confusing.
>
> How are page faults from the SVA master resolved during an
> asynchronous operation?
The STATUS register has a fault bit; the poller notices, reads fault info from
accelerator registers and takes actions to resolve the fault (which in practice
means access from user space on CPU and fault into the kernel to handle).
>
> Can a CPU start multiple asynchronous operations concurrently?
Yes; STATUS indicates READY while it can accept more asynchronous operations
("comamnds").
>
> Do these continue to run if the starting process is scheduled out
> and another process also tries to use CLA?
Yes; the driver manages assignment of a CLA to a process context completely
separately from the thread scheduler's decisions about which threads run on
which CPUs and when. If another process is scheduled onto the CPU and it
attempts to access it's VA for the CLA, it will fault into the driver's handler
and be put to sleep until the driver decides to reassign the CLA.
>
>> +Faults during address translation are reported by the accelerator in its
>> +registers and in STATUS. While polling for work completion, software fixes up
>> +the faults and notifies the accelerator with RESOLVE operations.
>
> I would like to understand the faulting part better. Which instruction
> specifically causes the fault, is that the poll STATUS read?
I'm not sure what you mean by "Which instruction specifically causes the fault".
A fault occurs within the accelerator if it tries to access a virtual address
that is not mapped by the page table or if the permissions of the mapping are
not sufficient, etc... The fact that the accelerator has faulted is reported to
the SW that is polling the accelerator's STATUS register within user space. That
SW is expected to trigger fault handling by the usual kernel mechanisms by
accessing the VA. Then it issues a RESOLVE operation to tell the accelerator it
can continue.
>
>> +Inter-Accelerator Communication
>> +-------------------------------
>> +
>> +On some platforms, multiple accelerators, each attached to a separate CLA within
>> +a cluster, are also directly connected to each other via a shared bus to
>> +accelerate cooperation between accelerators. The accelerators sharing a bus
>> +cannot be isolated from each other. When collaborative operations are launched
>> +on each of the participating accelerators, they synchronize over the bus,
>> +stalling until all are ready.
>
> Could you give an example what this model might be good for?
I can't currently share that information. I expect you might be able to have a
good guess though :)
>
> Does this mean a user may have to start one operation on each CPU
> from a thread of the same process in order to get a result efficiently
> across a shared accelerator?
Yes, correct. User space threads don't need to be precisesly synchronized
because multiple operations can be queued.
>
> I assume this will become clearer once you can show an example userspace
> application that uses this type of accelerator.
Yes indeed. As I said, Arm plans to open source a user space driver, but there
is no commitment on dates yet.
>
>> +Intended SW Usage Model
>> +=======================
>> +
>> +CLA is designed for its PL0 MMIO frame to be mapped into user space and for user
>> +space to directly launch accelerator operations and poll for completion. It has
>> +been observed that for some use cases, the operation execution time is small and
>> +a trip through the kernel would consume a significant amount of the CPU budget
>> +for preparing the next operation leading to a significant reduction in bandwidth
>> +through the accelerator.
>
> Do you have any plans for in-kernel usage of the accelerators?
> I would assume that for things like cryptographic features, these
> make sense to be exposed to the kernel itself.
As per cover letter: "the initial (and currently only) target is a compute
engine". There are not any plans for crypto accelerators (or other things like
that). So haven't been considering this as something the kernel would want to
use directly.
(Sorry I'm being vague - I'm sure you appreciate I'm limited on what I can say
around the use cases for now).
>
>> +User space software is expected to create a thread to drive each CLA it is
>> +using, and for each thread to be pinned to the CLA's local CPU.
>
> What happens if multiple processes have the same chardev open and
> each mmap() that, e.g. after a fork()? Does each process see its
> own virtual instance of the accelerator and interact with it through
> the same physical MMIO register range but its own process address space,
> or do you have to rely on the registers being mapped only into a
> single mm_struct to prevent a process from messing with another process
> data?
The driver maintains a cla_ctx for each {file description, mm_struct} pair. So
in this case, even though the file description is shared between the parent and
child processes, they still have distinct mm_structs so still have separate
contexts allowing the driver to virtualize access correctly.
>
>> +Saving and restoring the internal state of the accelerator is an optional
>> +feature. Current platforms only support it when the accelerator is idle, so
>> +preempting an accelerator causes work cancellation. Software must carefully
>> +consider how to balance forward-progress guarantees with preemption
>> latency.
>
> I'm not sure I understand this point. Do you mean any async operation
> that was started on an accelerator may fail due to preemption, so user
> space must be able to restart it?
Yes, at it's simplest. But it gets a bit complicated if you introduce the idea
of a priority to each cla_ctx. If a high priority context needs the HW
periodically and preempts a low priority context, if we just abort the low
priority work on preemption, it may never make forward progress. We've been
considering a grace period where the kernel will wait for the accelerators to
complete their current work (up to a certain timeout) before reassigning them to
the incomming context. But none of that is part of this RFC - I think that's
discussion that can come later once we have the basic shape of everything agreed.
Thanks,
Ryan
>
> Arnd
^ permalink raw reply
* [PATCH v4] media: rkvdec: fix clk reference leak on unbind
From: Francesco Saverio Pavone @ 2026-07-17 15:45 UTC (permalink / raw)
To: jonas, detlev.casanova, nicolas.dufresne, hverkuil, mchehab
Cc: ezequiel, heiko, linux-media, linux-rockchip, linux-arm-kernel,
linux-kernel
From: Jonas Karlman <jonas@kwiboo.se>
remove() calls pm_runtime_disable() before
pm_runtime_dont_use_autosuspend(), so the second call can never suspend
the device: it reaches rpm_idle(), which returns -EACCES once PM runtime
is disabled. The probe error path has had the two the other way round
since the driver was merged.
This shows up when the device is unbound while the 100ms autosuspend
window is still open, which is what an rmmod right after a decode does.
device_release_driver() calls pm_runtime_put_sync() before .remove(),
and rpm_idle() adds RPM_AUTO on its own, so that put only arms the
autosuspend timer. pm_runtime_disable() then cancels the timer, and
pm_runtime_reinit() relabels the device suspended without calling the
driver back. The clk_bulk reference taken by rkvdec_runtime_resume() is
never dropped, and a later probe does not reclaim it, so every such
unbind leaks one enable count.
Drop autosuspend first, so the callback still runs and releases the
clocks.
The PM calls also have to move ahead of rkvdec_v4l2_cleanup() rather
than just swap with each other. rkvdec_runtime_suspend() looks its state
up with dev_get_drvdata(), and v4l2_device_unregister() clears it:
struct rkvdec_dev has v4l2_device as its first member, so
&rkvdec->v4l2_dev and rkvdec are the same address and the check in
v4l2_device_disconnect() matches. That is harmless today because
pm_runtime_disable() suppresses the callback, but once the callback can
run, a suspend after the V4L2 teardown dereferences NULL. Swapping only
the two PM calls oopses on every unbind.
Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
[fsp: wrote the commit message; the diff is unchanged]
Tested-by: Francesco Saverio Pavone <pavone.lawyer@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Francesco Saverio Pavone <pavone.lawyer@gmail.com>
---
Changes in v4:
- No functional change. Resent as its own thread (no In-Reply-To on v2),
per Nicolas's note that a new version should be its own thread for
patchwork tracking. Same diff and same commit message as v3.
Changes in v3:
- Rewrote the commit message, and dropped the VP9 claim from v1 and v2.
Those said this fixed a VP9 inter-prediction bug on RK3588, green chroma
from the second ALTREF frame onward. The bug is real, but this is not
what fixes it, and I should have established that before sending v1.
What happened: I took this patch out of chewitt's tree along with two
others and tested the three as a batch. The green is fixed by "media:
rkvdec: implement reset controls" from Alex Bee, which adds the
reset_control handling that recovers the VDPU381 after a transient error
(COLMV_REF_ERR_STA and friends) instead of leaving it dirty for the next
inter frame. Randy Li's PMU idle export goes with it. This patch was the
third one in that batch and got the credit.
Retested this week on the same Rock 5B+ with an unpatched driver: a VP9
Profile 0 1080p clip with alt-ref frames decodes byte-identical to the
libvpx reference, across five rmmod/insmod cycles and after an unbind
inside the autosuspend window. The green does not come back, because the
reset_control work is in the tree I test on. Sorry for the review and the
testing you spent on that basis.
- Worth flagging separately: mainline rkvdec has no reset_control support
at all, so the VDPU381 is never recovered after a transient error. That
is a real gap, it is just not this patch. I can write it up properly if
that is useful.
- The diff is unchanged from v1 and v2. It is Jonas's 2020 commit verbatim,
and his original one-line subject already described exactly what it does.
The wrong story was mine, not his.
- The subject changed with the message: "media: rkvdec: fix PM runtime
teardown ordering in remove" in v1 and v2, "media: rkvdec: fix clk
reference leak on unbind" here, since that is what it actually fixes.
- What is left is measured. With a dev_info() at the top of
rkvdec_runtime_suspend(), autosuspend_delay raised to 60s to take the
timer out of the race, and unbind driven through sysfs:
unpatched: 0 suspend callbacks, aclk_rkvdec0 enable_count 1 -> 2
patched: 1 suspend callback, enable_count 1 -> 1
The leak survives rmmod and accumulates one per unbind. With
autosuspend_delay=0 both orders suspend once, which is the control: the
difference only exists inside the window.
- Fixes: was wrong in v1 and v2. ff8c5622f9f7 has the two pm_runtime calls
as context and only added iommu_domain_free(). cd33c830448b added remove()
with the reversed order, and the probe error path with the right one, so
the tag points there now.
- Dropped Cc: stable. A clk reference leaked on unbind is not backport
material, and the tag was only there for the VP9 claim.
- Dropped your Reviewed-by and Tested-by from v2: they were given for a fix
to something else.
- Not included, happy to send as follow-ups: clearing empty_domain after
iommu_domain_free(), and hoisting the unregisters to the top of remove()
as you suggested on v2.
Tested on a Radxa Rock 5B+ (RK3588) on a 7.1 tree where the six calls in
rkvdec_v4l2_cleanup() are open-coded; the executed sequence is the one this
patch produces. VP9 decode stays byte-identical to libvpx, and five
rmmod/insmod cycles leave dmesg clean.
Link to v1: https://lore.kernel.org/all/20260518105413.42147-1-pavone.lawyer@gmail.com/
Link to v2: https://lore.kernel.org/all/20260518145414.64514-1-pavone.lawyer@gmail.com/
Link to v3: https://lore.kernel.org/all/20260717150440.77079-1-pavone.lawyer@gmail.com/
drivers/media/platform/rockchip/rkvdec/rkvdec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.c b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
index 1d1e9bfef8e9..0ec3fca9cccc 100644
--- a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
@@ -1869,12 +1869,13 @@ static void rkvdec_remove(struct platform_device *pdev)
cancel_delayed_work_sync(&rkvdec->watchdog_work);
- rkvdec_v4l2_cleanup(rkvdec);
- pm_runtime_disable(&pdev->dev);
pm_runtime_dont_use_autosuspend(&pdev->dev);
if (rkvdec->empty_domain)
iommu_domain_free(rkvdec->empty_domain);
+
+ pm_runtime_disable(&pdev->dev);
+ rkvdec_v4l2_cleanup(rkvdec);
}
#ifdef CONFIG_PM
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3] media: rkvdec: fix clk reference leak on unbind
From: Francesco Saverio Pavone @ 2026-07-17 15:47 UTC (permalink / raw)
To: nicolas.dufresne, jonas, detlev.casanova, hverkuil, mchehab
Cc: ezequiel, heiko, linux-media, linux-rockchip, linux-arm-kernel,
linux-kernel
In-Reply-To: <6c3081fed130534ac0d5cf83c7658bb13e0bfc7b.camel@collabora.com>
Thanks, makes sense. Resent as its own thread as v4:
https://lore.kernel.org/linux-media/20260717154505.83935-1-pavone.lawyer@gmail.com/
— Sav
^ permalink raw reply
* Re: [PATCH v2] soc: ti: knav_qmss: remove debugfs file on teardown
From: Nishanth Menon @ 2026-07-17 15:47 UTC (permalink / raw)
To: Santosh Shilimkar, Pengpeng Hou
Cc: Nishanth Menon, Sandeep Nair, linux-arm-kernel, linux-kernel
In-Reply-To: <20260706144706.96313-1-pengpeng@iscas.ac.cn>
Hi Pengpeng Hou,
On Mon, 06 Jul 2026 22:47:06 +0800, Pengpeng Hou wrote:
> knav_queue_probe() creates the global qmss debugfs file whose show
> callback reads the global knav_qdev state. knav_queue_remove() tears
> down the queue manager resources but leaves the debugfs file published.
>
> Save the debugfs dentry in struct knav_device and remove it during
> teardown before the resources used by the show callback are released.
> While touching the debugfs_create_file() call, spell the unchanged read-
> only file mode as 0444.
>
> [...]
I have applied the following to branch ti-drivers-soc-next on [1].
Thank you!
[1/1] soc: ti: knav_qmss: remove debugfs file on teardown
commit: 3c817862759913097f11467ed4ed2bbf974dabaf
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH 0/2] ARM: dts: ls: cleanup fpga related CHECK_DTBS warning
From: Frank.Li @ 2026-07-17 15:48 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Frank.Li
Cc: Frank Li, devicetree, linux-kernel, linux-arm-kernel, imx,
Ioana Ciornei, vladimir.oltean
In-Reply-To: <20260708-ls-fpga-v1-0-06c8a099b2a5@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Wed, 08 Jul 2026 14:55:12 -0400, Frank.Li@oss.nxp.com wrote:
> Cleanup oneboard fpga related CHECK_DTBS warning.
Applied, thanks!
[1/2] dt-bindings: fsl,fpga-qixis: Add fsl,ls1021aqds-fpga compatible string
commit: 092d1fad3b2c224e465e4ecc5d7a17f3da3cf1a8
[2/2] ARM: dts: ls1021a-qds: add compatible string "fsl,ls1021aqds-fpga" for on boards FPGA chip
commit: 28228f9ea570a94e1873adda5ee284134af28cd6
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v4 6/6] KVM: arm64: Add auto HDBSS enable/disable on dirty logging change
From: Leonardo Bras @ 2026-07-17 15:50 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, will, yuzenghui,
wangzhou1, yangjinqian1, caijian11, liuyonglong, yezhenyu2,
yubihong, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-kernel, seiden, suzuki.poulose
In-Reply-To: <02713422-0b1f-45c4-a93d-2fc7de2a0b84@huawei.com>
On Fri, Jul 17, 2026 at 03:23:24PM +0800, Tian Zheng wrote:
>
>
> On 7/14/2026 7:16 PM, Leonardo Bras wrote:
> > On Tue, Jul 14, 2026 at 04:58:37PM +0800, Tian Zheng wrote:
> > >
> > > On 7/13/2026 10:50 PM, Leonardo Bras wrote:
> > > > On Thu, Jul 09, 2026 at 06:40:26PM +0800, Tian Zheng wrote:
> > > > > From: eillon <yezhenyu2@huawei.com>
> > > > >
> > > > > HDBSS buffers store per-page dirty state after the stage-2 page tables
> > > > > have been split down to page granularity (chunk_size == PAGE_SIZE).
> > > > chunk_size != PAGE_SIZE now, but that should change as well :)
> > >
> > >
> > > Thanks, I'll clarify the comment in v5.
> >
> > By the discussion we are having in the HACDBS patchset, I think we can't
> > assume the pages are split in the future. :\
> >
>
> Agreed.
>
> > >
> > >
> > > >
> > > > > When chunk_size == 0 the kernel may lazily skip splitting block mappings,
> > > > > leaving the page table coarser than what HDBSS expects. Therefore,
> > > > > enabling HDBSS requires disabling lazy split so that all block mappings
> > > > > are eagerly broken down before the buffer starts recording.
> > > > (See cover letter reply)
> > > >
> > > > > Add VM-level HDBSS enable/disable support. When dirty logging is
> > > > > enabled on any memslot, HDBSS is automatically enabled. When dirty
> > > > > logging is disabled on all memslots, HDBSS is automatically disabled.
> > > > >
> > > > > This includes:
> > > > > - kvm_arm_enable_hdbss_global() to enable HDBSS for all vCPUs
> > > > > - kvm_arm_disable_hdbss_global() to disable and free HDBSS buffers
> > > > > - kvm_arm_hdbss_on_dirty_logging_change() for auto enable/disable
> > > > > - kvm_arch_destroy_vm() cleanup path
> > > > > - kvm_arch_commit_memory_region() integration
> > > > >
> > > > > Signed-off-by: Eillon <yezhenyu2@huawei.com>
> > > > > Signed-off-by: Tian Zheng <zhengtian10@huawei.com>
> > > > > ---
> > > > > arch/arm64/include/asm/kvm_dirty_bit.h | 2 +
> > > > > arch/arm64/kvm/arm.c | 8 ++
> > > > > arch/arm64/kvm/dirty_bit.c | 105 +++++++++++++++++++++++++
> > > > > arch/arm64/kvm/mmu.c | 3 +
> > > > > 4 files changed, 118 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/include/asm/kvm_dirty_bit.h b/arch/arm64/include/asm/kvm_dirty_bit.h
> > > > > index 4b28000e972f..a4cda8cdab24 100644
> > > > > --- a/arch/arm64/include/asm/kvm_dirty_bit.h
> > > > > +++ b/arch/arm64/include/asm/kvm_dirty_bit.h
> > > > > @@ -23,5 +23,7 @@ int kvm_arm_vcpu_alloc_hdbss(struct kvm_vcpu *vcpu, unsigned int order);
> > > > > void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu);
> > > > > void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu);
> > > > > int kvm_handle_hdbss_fault(struct kvm_vcpu *vcpu);
> > > > > +void kvm_arm_hdbss_on_dirty_logging_change(struct kvm *kvm, int nr_memslots_logging);
> > > > > +void kvm_arm_disable_hdbss_global(struct kvm *kvm);
> > > > >
> > > > > #endif /* __ARM64_KVM_DIRTY_BIT_H__ */
> > > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > > index 566953a4e23a..536d94799ba8 100644
> > > > > --- a/arch/arm64/kvm/arm.c
> > > > > +++ b/arch/arm64/kvm/arm.c
> > > > > @@ -317,6 +317,14 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> > > > > if (is_protected_kvm_enabled())
> > > > > pkvm_destroy_hyp_vm(kvm);
> > > > >
> > > > > + /*
> > > > > + * Userspace may destroy the VM without disabling dirty logging,
> > > > > + * so the auto-disable path is never reached. Force disable HDBSS
> > > > > + * here to ensure vCPU buffers are freed and prevent memory leaks.
> > > > > + */
> > > > > + if (kvm->arch.enable_hdbss)
> > > > > + kvm_arm_disable_hdbss_global(kvm);
> > > > > +
> > > > > kvm_uninit_stage2_mmu(kvm);
> > > > > kvm_destroy_mpidr_data(kvm);
> > > > >
> > > > > diff --git a/arch/arm64/kvm/dirty_bit.c b/arch/arm64/kvm/dirty_bit.c
> > > > > index 002366337637..c5bf866c23ef 100644
> > > > > --- a/arch/arm64/kvm/dirty_bit.c
> > > > > +++ b/arch/arm64/kvm/dirty_bit.c
> > > > > @@ -112,3 +112,108 @@ int kvm_handle_hdbss_fault(struct kvm_vcpu *vcpu)
> > > > > return -EFAULT;
> > > > > }
> > > > > }
> > > > > +
> > > > > +static unsigned int hdbss_auto_select_order(struct kvm *kvm)
> > > > > +{
> > > > > + unsigned long npages = 0;
> > > > > + struct kvm_memory_slot *memslot;
> > > > > + int bkt;
> > > > > +
> > > > > + kvm_for_each_memslot(memslot, bkt, kvm_memslots(kvm))
> > > > > + npages += memslot->npages;
> > > > > +
> > > > > + if (npages <= 16384)
> > > > > + return 0;
> > > > > + else if (npages <= 262144)
> > > > > + return 3;
> > > > > + else if (npages <= 4194304)
> > > > > + return 6;
> > > > > + else
> > > > > + return 9;
> > > > > +}
> > > > IIUC you are counting the amount of pages the VM has, and based on that
> > > > allocating a size for the HDBSS buffer.
> > > >
> > > > A few notes here:
> > > > - It's not really nice to use magic numbers around like this. If you
> > > > actually want to use it, then use stuff like SZ_16K, SZ_256K, SZ_4M and
> > > > so on.
> > > > - You are returning magic numbers as well, why is it 0, 3, 6, or 9 here?
> > > > It only makes sense if the person is reading HDBSSBR_EL2 documentation,
> > > > which should not be necessary at this point. That's one reason I
> > > > recommended to using sizes. If that was really the best way to use it,
> > > > I would recommend using the defines that we get from sysreg, and you
> > > > actually used before to set the maximum order on a previous patch.
> > > > - Also, if you can return only valid values here, why do you check against
> > > > the maximum value in that previous patch?
> > > > - Also, are you using some undisclosed rule here? On 'order 0' the
> > > > meanining is 4KB, which translate to 512 HDBSS entries. Why are you using
> > > > it for any value under 16K? Same for 3-32KB-4kEntries you use for under
> > > > 256K pages (and so on). If you are assuming a logical rule such as
> > > > 'N pages would be ok with N/32 entries' it has to be described here at
> > > > least.
> > > > - Not sure VM size is the best way of doing that, since it will depend
> > > > more on the dirtying rate than the actual size, and most VMs would just
> > > > use the biggest size (4M x 4K pages is just 16GB). For instance with
> > > > dirty_ring we can use the dirty_ring.size as a better option.
> > > > (I know this is a hard one to estimate when using dirty-bitmap, though)
> > >
> > >
> > > I'll replace the magic numbers and also add a comment in the next version
> > > explaining
> > >
> > > the mapping between the thresholds and the order values.
> > >
> > >
> > > On auto-choosing the size: VM memory size is a simple starting point, but I
> > > agree it's
> > >
> > > not ideal. For dirty-ring mode we could use dirty_ring_size as a reference;
> > > for dirty-bitmap
> > >
> > > mode there's no equivalent, so I don't have a good answer yet. I'd really
> > > appreciate any
> > >
> > > suggestions from the community on a better idea for the dirty-bitmap case.
> >
> > I am thinking that we could use a default value (say 1 PAGESIZE/vcpu) and
> > add an ioctl to optionally increase this value. This way we don't require
> > a new interface to benefit from HDBSS, but allow users to tune it.
> >
>
> That makes sense. I think we can use a default value (e.g., 1 page per
> vCPU), but I'd prefer not to expose any ioctl for userspace to configure
> it. Since the kernel auto-enables HDBSS, a userspace size knob would be
> confusing — similar to what I mentioned in the discussion at [1].
>
> [1] https://lore.kernel.org/linux-arm-kernel/3fb4b33e-4618-4523-b140-955e15fd9a8c@huawei.com/
>
You can reply either there or here, but why do you think it will be
confusing?
> > >
> > > Also, since we automatically enable HDBSS in the kernel, the check against
> > > HDBSS_MAX_ORDER is redundant. I'll remove it.
> > >
> > >
> > > > > +
> > > > > +/*
> > > > > + * Enable HDBSS for all vCPUs in the VM.
> > > > > + *
> > > > > + * Called from kvm_arm_hdbss_on_dirty_logging_change() which is invoked
> > > > > + * by kvm_arch_commit_memory_region() under kvm->slots_lock.
> > > > > + *
> > > > > + * If buffer allocation fails, HDBSS remains disabled and dirty tracking
> > > > > + * falls back to the traditional software-based approach (PTE write-protect
> > > > > + * + software dirty marking). This does not affect correctness; dirty
> > > > > + * logging remains functional without HDBSS.
> > > > > + */
> > > > > +static int kvm_arm_enable_hdbss_global(struct kvm *kvm)
> > > > > +{
> > > > > + int err;
> > > > > + unsigned long i;
> > > > > + unsigned int order;
> > > > > + struct kvm_vcpu *vcpu;
> > > > > +
> > > > > + if (!system_supports_hdbss())
> > > > > + return 0;
> > > > > +
> > > > > + if (kvm->dirty_ring_size) /* Don't support HDBSS in dirty ring mode */
> > > > > + return 0;
> > > > > +
> > > > > + if (kvm->arch.enable_hdbss) /* Already On */
> > > > > + return 0;
> > > > > +
> > > > > + /* Turn it on */
> > > > > + order = hdbss_auto_select_order(kvm);
> > > > > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > > > > + err = kvm_arm_vcpu_alloc_hdbss(vcpu, order);
> > > > > + if (err)
> > > > > + goto error_alloc;
> > > > > + }
> > > > > +
> > > > > + kvm->arch.enable_hdbss = true;
> > > > > + kvm->arch.mmu.vtcr |= VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA;
> > > > > +
> > > > > + /*
> > > > > + * We should kick vcpus out of guest mode here to load new
> > > > > + * vtcr value to vtcr_el2 register when re-enter guest mode.
> > > > > + */
> > > > > + kvm_for_each_vcpu(i, vcpu, kvm)
> > > > > + kvm_vcpu_kick(vcpu);
> > > > > +
> > > > > + return 0;
> > > > > +
> > > > > +error_alloc:
> > > > > + kvm_for_each_vcpu(i, vcpu, kvm)
> > > > > + if (vcpu->arch.hdbss.base_phys)
> > > > > + kvm_arm_vcpu_free_hdbss(vcpu);
> > > > > +
> > > > > + pr_warn_once("kvm: failed to allocate HDBSS buffers (order=%u), "
> > > > > + "falling back to software dirty tracking\n", order);
> > > > > + return -ENOMEM;
> > > > > +}
> > > > > +
> > > > > +void kvm_arm_disable_hdbss_global(struct kvm *kvm)
> > > > > +{
> > > > > + unsigned long i;
> > > > > + struct kvm_vcpu *vcpu;
> > > > > +
> > > > > + if (!kvm->arch.enable_hdbss) /* Already Off */
> > > > > + return;
> > > > > +
> > > > > + /* Turn it off */
> > > > > + kvm->arch.mmu.vtcr &= ~(VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA);
> > > > > +
> > > > > + kvm_for_each_vcpu(i, vcpu, kvm)
> > > > > + kvm_arm_vcpu_free_hdbss(vcpu);
> > > > > +
> > > > > + kvm->arch.enable_hdbss = false;
> > > > > +}
> > > > > +
> > > > Okay, say the user requested it to be disabled, you change the global vtcr,
> > > > then free the hdbss on every vcpu.
> > > >
> > > > But the vcpus are still running, and since they will only disable this when
> > > > they go out of the guest, then in again, HDBSS will still be running,
> > > > right?
> > > >
> > > > If some page gets dirty in the between, would not the HDBSS try to write to
> > > > the already loaded buffer adress, and write to memory that have already
> > > > been freed here?
> > > >
> > >
> > > You're right — this is a race condition. I'll fix this in v5 by clearing
> > > VTCR_EL2_HDBSS from
> > >
> > > kvm->arch.mmu.vtcr first, then kicking all vCPUs to force them to exit guest
> > > mode and reload the config.
> > >
> > > Once all vCPUs are out of guest mode, it will be safe to free the HDBSS
> > > buffers.
> > >
> >
> > That would be safer, indeed.
> > >
> > > > > +void kvm_arm_hdbss_on_dirty_logging_change(struct kvm *kvm, int nr_memslots_logging)
> > > > > +{
> > > > > + /*
> > > > > + * Called from kvm_arch_commit_memory_region() under kvm->slots_lock.
> > > > > + * All state transitions are serialized by slots_lock.
> > > > > + */
> > > > > + if (nr_memslots_logging > 0 && !kvm->arch.enable_hdbss)
> > > > > + kvm_arm_enable_hdbss_global(kvm);
> > > > > + else if (nr_memslots_logging == 0 && kvm->arch.enable_hdbss)
> > > > > + kvm_arm_disable_hdbss_global(kvm);
> > > > > +}
> > > > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > > > index 949fb895add6..484f48dae000 100644
> > > > > --- a/arch/arm64/kvm/mmu.c
> > > > > +++ b/arch/arm64/kvm/mmu.c
> > > > > @@ -2588,6 +2588,9 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
> > > > > {
> > > > > bool log_dirty_pages = new && new->flags & KVM_MEM_LOG_DIRTY_PAGES;
> > > > >
> > > > > + kvm_arm_hdbss_on_dirty_logging_change(kvm,
> > > > > + atomic_read(&kvm->nr_memslots_dirty_logging));
> > > > > +
> > > > > /*
> > > > > * At this point memslot has been committed and there is an
> > > > > * allocated dirty_bitmap[], dirty pages will be tracked while the
> > > > > --
> > > > > 2.33.0
> > > > >
> > > > Okay, reading the above I remembered something really complicated:
> > > > We can't really enable HDBSS partially if we start with DBM set for all
> > > > pages. Once we enable HDBSS wit will track changes for all memslots.
> > > >
> > > > The only way to enable it partially would be to set DBM during the
> > > > dirty-bit tracking, which I recall being complicated for some reasons.
> > > >
> > > > Well, we have to think about the overall strategy before a next version.
> > > >
> > > > Thanks!
> > > > Leo
> > >
> > >
> > > Yes, I did consider this when I switched to global DBM injection in v4.
> > > There are
> > >
> > > indeed some scenarios that are harder to control:
> > >
> > >
> > >
> > > Firstly, for lazy split, if we add the DBM tag lazily during live migration
> > > dirty tracking (like v3 did),
> > >
> > > the first write to each page would trap. That trap serves two purposes: it
> > > gives us a chance to split
> > >
> > > hugepages on demand (lazy split), and it ensures the DBM addition happens at
> > > a safer, more controlled point.
> >
> > It also allows us to do the dirty-tracking by slot, which is not possible
> > with the v4 approach.
> >
>
> I think the per-memslot tracking capability is not a critical
> requirement. As I mentioned in my earlier reply [1], we can follow the
> same approach as PML on x86 — filtering at flush time works just fine.
>
> [1] https://lore.kernel.org/linux-arm-kernel/a240e7a6-cd22-4fe4-a01d-472c95cc65e4@huawei.com/
>
Yeah, filtering before flushing to dirty_log/ring works fine.
I don't expect a lot of untracked pages to pop here, anyway, as they would
be required to not be faulted before dirty_tracking starts.
> > >
> > > However, because v4 enables HDBSS and DBM upfront, we lose that initial
> > > trap. That's exactly why we
> > >
> > > now rely on your eager hugepage splitting patch as a mandatory dependency.
> > >
> >
> > Correct.
> >
> > >
> > >
> > > Secondly, I'm also concerned about whether global DBM injection could
> > > accidentally mark pages
> > >
> > > that shouldn't be tracked — for example, pages with special mappings.
> >
> > Well, if we want to not track those pages, we have just to make sure we can
> > detect them and not mark them with the DBM bit.
> >
> > > If
> > > that's possible, then the
> > >
> > > lazy approach (only adding DBM on the first write fault) would be safer
> > > because it only touches pages
> > >
> > > that are actually written to.
> > >
> > >
> > >
> > > So I'd like to ask: is avoiding the first-trap overhead worth the potential
> > > risks of global DBM injection?
> > >
> > > Or do you think the lazy approach is actually safer overall? I'd appreciate
> > > your thoughts on this trade-off.
> > >
> >
> > Well, even though performance is important, the decision to set DBM bits
> > for all writtable pages at their mapping time was not driven by
> > performance, but instead by an issue with setting DBM while the VCPUs were
> > running. I have to rework what that was, and check if that is still an
> > issue, before we can even discuss what to do next :(
> >
> > But the fact that the 'eager DBM setting' makes dirty-bit tracking start
> > global, instead of per-memslot, is something we have to consider as well.
> >
> >
> > Thanks!
> > Leo
>
>
> That makes sense. I think global eager DBM is workable.
I think it will be good with Oliver's suggestion of changing the
sw-dirtying encoding for the PTE.
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH v4 6/6] KVM: arm64: Add auto HDBSS enable/disable on dirty logging change
From: Leonardo Bras @ 2026-07-17 15:53 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, will, yuzenghui,
wangzhou1, yangjinqian1, caijian11, liuyonglong, yezhenyu2,
yubihong, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-kernel, seiden, suzuki.poulose
In-Reply-To: <a240e7a6-cd22-4fe4-a01d-472c95cc65e4@huawei.com>
On Thu, Jul 16, 2026 at 03:15:38PM +0800, Tian Zheng wrote:
>
> On 7/13/2026 10:50 PM, Leonardo Bras wrote:
> > On Thu, Jul 09, 2026 at 06:40:26PM +0800, Tian Zheng wrote:
> > > From: eillon <yezhenyu2@huawei.com>
> > >
> > > HDBSS buffers store per-page dirty state after the stage-2 page tables
> > > have been split down to page granularity (chunk_size == PAGE_SIZE).
> > chunk_size != PAGE_SIZE now, but that should change as well :)
> >
> > > When chunk_size == 0 the kernel may lazily skip splitting block mappings,
> > > leaving the page table coarser than what HDBSS expects. Therefore,
> > > enabling HDBSS requires disabling lazy split so that all block mappings
> > > are eagerly broken down before the buffer starts recording.
> > (See cover letter reply)
> >
> > > Add VM-level HDBSS enable/disable support. When dirty logging is
> > > enabled on any memslot, HDBSS is automatically enabled. When dirty
> > > logging is disabled on all memslots, HDBSS is automatically disabled.
> > >
> > > This includes:
> > > - kvm_arm_enable_hdbss_global() to enable HDBSS for all vCPUs
> > > - kvm_arm_disable_hdbss_global() to disable and free HDBSS buffers
> > > - kvm_arm_hdbss_on_dirty_logging_change() for auto enable/disable
> > > - kvm_arch_destroy_vm() cleanup path
> > > - kvm_arch_commit_memory_region() integration
> > >
> > > Signed-off-by: Eillon <yezhenyu2@huawei.com>
> > > Signed-off-by: Tian Zheng <zhengtian10@huawei.com>
> > > ---
> > > arch/arm64/include/asm/kvm_dirty_bit.h | 2 +
> > > arch/arm64/kvm/arm.c | 8 ++
> > > arch/arm64/kvm/dirty_bit.c | 105 +++++++++++++++++++++++++
> > > arch/arm64/kvm/mmu.c | 3 +
> > > 4 files changed, 118 insertions(+)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_dirty_bit.h b/arch/arm64/include/asm/kvm_dirty_bit.h
> > > index 4b28000e972f..a4cda8cdab24 100644
> > > --- a/arch/arm64/include/asm/kvm_dirty_bit.h
> > > +++ b/arch/arm64/include/asm/kvm_dirty_bit.h
> > > @@ -23,5 +23,7 @@ int kvm_arm_vcpu_alloc_hdbss(struct kvm_vcpu *vcpu, unsigned int order);
> > > void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu);
> > > void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu);
> > > int kvm_handle_hdbss_fault(struct kvm_vcpu *vcpu);
> > > +void kvm_arm_hdbss_on_dirty_logging_change(struct kvm *kvm, int nr_memslots_logging);
> > > +void kvm_arm_disable_hdbss_global(struct kvm *kvm);
> > >
> > > #endif /* __ARM64_KVM_DIRTY_BIT_H__ */
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index 566953a4e23a..536d94799ba8 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -317,6 +317,14 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> > > if (is_protected_kvm_enabled())
> > > pkvm_destroy_hyp_vm(kvm);
> > >
> > > + /*
> > > + * Userspace may destroy the VM without disabling dirty logging,
> > > + * so the auto-disable path is never reached. Force disable HDBSS
> > > + * here to ensure vCPU buffers are freed and prevent memory leaks.
> > > + */
> > > + if (kvm->arch.enable_hdbss)
> > > + kvm_arm_disable_hdbss_global(kvm);
> > > +
> > > kvm_uninit_stage2_mmu(kvm);
> > > kvm_destroy_mpidr_data(kvm);
> > >
> > > diff --git a/arch/arm64/kvm/dirty_bit.c b/arch/arm64/kvm/dirty_bit.c
> > > index 002366337637..c5bf866c23ef 100644
> > > --- a/arch/arm64/kvm/dirty_bit.c
> > > +++ b/arch/arm64/kvm/dirty_bit.c
> > > @@ -112,3 +112,108 @@ int kvm_handle_hdbss_fault(struct kvm_vcpu *vcpu)
> > > return -EFAULT;
> > > }
> > > }
> > > +
> > > +static unsigned int hdbss_auto_select_order(struct kvm *kvm)
> > > +{
> > > + unsigned long npages = 0;
> > > + struct kvm_memory_slot *memslot;
> > > + int bkt;
> > > +
> > > + kvm_for_each_memslot(memslot, bkt, kvm_memslots(kvm))
> > > + npages += memslot->npages;
> > > +
> > > + if (npages <= 16384)
> > > + return 0;
> > > + else if (npages <= 262144)
> > > + return 3;
> > > + else if (npages <= 4194304)
> > > + return 6;
> > > + else
> > > + return 9;
> > > +}
> > IIUC you are counting the amount of pages the VM has, and based on that
> > allocating a size for the HDBSS buffer.
> >
> > A few notes here:
> > - It's not really nice to use magic numbers around like this. If you
> > actually want to use it, then use stuff like SZ_16K, SZ_256K, SZ_4M and
> > so on.
> > - You are returning magic numbers as well, why is it 0, 3, 6, or 9 here?
> > It only makes sense if the person is reading HDBSSBR_EL2 documentation,
> > which should not be necessary at this point. That's one reason I
> > recommended to using sizes. If that was really the best way to use it,
> > I would recommend using the defines that we get from sysreg, and you
> > actually used before to set the maximum order on a previous patch.
> > - Also, if you can return only valid values here, why do you check against
> > the maximum value in that previous patch?
> > - Also, are you using some undisclosed rule here? On 'order 0' the
> > meanining is 4KB, which translate to 512 HDBSS entries. Why are you using
> > it for any value under 16K? Same for 3-32KB-4kEntries you use for under
> > 256K pages (and so on). If you are assuming a logical rule such as
> > 'N pages would be ok with N/32 entries' it has to be described here at
> > least.
> > - Not sure VM size is the best way of doing that, since it will depend
> > more on the dirtying rate than the actual size, and most VMs would just
> > use the biggest size (4M x 4K pages is just 16GB). For instance with
> > dirty_ring we can use the dirty_ring.size as a better option.
> > (I know this is a hard one to estimate when using dirty-bitmap, though)
> >
> > > +
> > > +/*
> > > + * Enable HDBSS for all vCPUs in the VM.
> > > + *
> > > + * Called from kvm_arm_hdbss_on_dirty_logging_change() which is invoked
> > > + * by kvm_arch_commit_memory_region() under kvm->slots_lock.
> > > + *
> > > + * If buffer allocation fails, HDBSS remains disabled and dirty tracking
> > > + * falls back to the traditional software-based approach (PTE write-protect
> > > + * + software dirty marking). This does not affect correctness; dirty
> > > + * logging remains functional without HDBSS.
> > > + */
> > > +static int kvm_arm_enable_hdbss_global(struct kvm *kvm)
> > > +{
> > > + int err;
> > > + unsigned long i;
> > > + unsigned int order;
> > > + struct kvm_vcpu *vcpu;
> > > +
> > > + if (!system_supports_hdbss())
> > > + return 0;
> > > +
> > > + if (kvm->dirty_ring_size) /* Don't support HDBSS in dirty ring mode */
> > > + return 0;
> > > +
> > > + if (kvm->arch.enable_hdbss) /* Already On */
> > > + return 0;
> > > +
> > > + /* Turn it on */
> > > + order = hdbss_auto_select_order(kvm);
> > > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > > + err = kvm_arm_vcpu_alloc_hdbss(vcpu, order);
> > > + if (err)
> > > + goto error_alloc;
> > > + }
> > > +
> > > + kvm->arch.enable_hdbss = true;
> > > + kvm->arch.mmu.vtcr |= VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA;
> > > +
> > > + /*
> > > + * We should kick vcpus out of guest mode here to load new
> > > + * vtcr value to vtcr_el2 register when re-enter guest mode.
> > > + */
> > > + kvm_for_each_vcpu(i, vcpu, kvm)
> > > + kvm_vcpu_kick(vcpu);
> > > +
> > > + return 0;
> > > +
> > > +error_alloc:
> > > + kvm_for_each_vcpu(i, vcpu, kvm)
> > > + if (vcpu->arch.hdbss.base_phys)
> > > + kvm_arm_vcpu_free_hdbss(vcpu);
> > > +
> > > + pr_warn_once("kvm: failed to allocate HDBSS buffers (order=%u), "
> > > + "falling back to software dirty tracking\n", order);
> > > + return -ENOMEM;
> > > +}
> > > +
> > > +void kvm_arm_disable_hdbss_global(struct kvm *kvm)
> > > +{
> > > + unsigned long i;
> > > + struct kvm_vcpu *vcpu;
> > > +
> > > + if (!kvm->arch.enable_hdbss) /* Already Off */
> > > + return;
> > > +
> > > + /* Turn it off */
> > > + kvm->arch.mmu.vtcr &= ~(VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA);
> > > +
> > > + kvm_for_each_vcpu(i, vcpu, kvm)
> > > + kvm_arm_vcpu_free_hdbss(vcpu);
> > > +
> > > + kvm->arch.enable_hdbss = false;
> > > +}
> > > +
> > Okay, say the user requested it to be disabled, you change the global vtcr,
> > then free the hdbss on every vcpu.
> >
> > But the vcpus are still running, and since they will only disable this when
> > they go out of the guest, then in again, HDBSS will still be running,
> > right?
> >
> > If some page gets dirty in the between, would not the HDBSS try to write to
> > the already loaded buffer adress, and write to memory that have already
> > been freed here?
> >
> >
> > > +void kvm_arm_hdbss_on_dirty_logging_change(struct kvm *kvm, int nr_memslots_logging)
> > > +{
> > > + /*
> > > + * Called from kvm_arch_commit_memory_region() under kvm->slots_lock.
> > > + * All state transitions are serialized by slots_lock.
> > > + */
> > > + if (nr_memslots_logging > 0 && !kvm->arch.enable_hdbss)
> > > + kvm_arm_enable_hdbss_global(kvm);
> > > + else if (nr_memslots_logging == 0 && kvm->arch.enable_hdbss)
> > > + kvm_arm_disable_hdbss_global(kvm);
> > > +}
> > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > index 949fb895add6..484f48dae000 100644
> > > --- a/arch/arm64/kvm/mmu.c
> > > +++ b/arch/arm64/kvm/mmu.c
> > > @@ -2588,6 +2588,9 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
> > > {
> > > bool log_dirty_pages = new && new->flags & KVM_MEM_LOG_DIRTY_PAGES;
> > >
> > > + kvm_arm_hdbss_on_dirty_logging_change(kvm,
> > > + atomic_read(&kvm->nr_memslots_dirty_logging));
> > > +
> > > /*
> > > * At this point memslot has been committed and there is an
> > > * allocated dirty_bitmap[], dirty pages will be tracked while the
> > > --
> > > 2.33.0
> > >
> > Okay, reading the above I remembered something really complicated:
> > We can't really enable HDBSS partially if we start with DBM set for all
> > pages. Once we enable HDBSS wit will track changes for all memslots.
> >
> > The only way to enable it partially would be to set DBM during the
> > dirty-bit tracking, which I recall being complicated for some reasons.
> >
> > Well, we have to think about the overall strategy before a next version.
> >
> > Thanks!
> > Leo
>
>
> Hi, Leo
>
>
> One thing just clicked for me: we don't actually need per-memslot DBM
> control.
Yeah, I mentioned it here:
https://lore.kernel.org/linux-arm-kernel/alZI1rwmeYJHUFut@LeoBrasDK/
>
>
>
> PML on x86 works the same way — D bit set on all writable SPTEs
> unconditionally,
>
> buffer records everything. The filtering happens in software at flush time:
>
> vmx_flush_pml_buffer() -> kvm_vcpu_mark_page_dirty() ->
> mark_page_dirty_in_slot(),
>
> where kvm_slot_dirty_track_enabled() discards non-tracked memslots.
>
>
> Our HDBSS does exactly the same: global DBM, buffer records all writes,
>
> kvm_flush_hdbss_buffer() -> mark_page_dirty_in_slot() filters at flush time.
>
> So I'm questioning the premise — why should HDBSS be held to a different
> standard
>
> than PML? If overhead becomes a real problem, we can revisit per-memslot
> later.
>
> For v5, I think global DBM is fine.
>
> So, I think we just need to focus on how to correctly handle DBM for huge
> pages.
>
>
^ permalink raw reply
* Re: [PATCH v3 00/11] arm64: dts: describe the Lynx 10G and 28G SerDes blocks for Layerscape SoCs
From: Frank Li @ 2026-07-17 15:53 UTC (permalink / raw)
To: Ioana Ciornei
Cc: Frank.Li, robh, krzk+dt, conor+dt, devicetree, vladimir.oltean,
linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
On Fri, Jul 17, 2026 at 03:06:24PM +0300, Ioana Ciornei wrote:
> This patch set adds the device tree nodes for the Lynx10G SerDes blocks
> found on the LS1028A, LS1046A, LS1088A and LS2088A SoCs.
>
> The first 5 patches slowly change the LX2160A DTS support to a new
> structure which does not use any delete-node or delete-property
> directives. This is a direct result of the discussion with Frank in the
> v2 of this set:
> https://lore.kernel.org/all/akwAmzAbtg0Ejey0@SMW015318/
>
> Patches 5 and 6 transition the LX2160A and LX2162 SoC dtsi to use the
> device-specific Lynx28G SerDes compatible while the remainder of the set
> adds the SerDes block descriptions for the LS1028A, LS1046A, LS2088A and
> LS1088A SoCs.
>
> Changes in v3:
> - Changes how the LX216XA based SoC dtsi files are structured.
> - Split the enabling of serdes_1 into a separate patch
> - Split the LX2162A changes to another patch
> - Move the status property to be the last for serdes_3
> - Move the changes to the new fsl-lx2160a-serdes.dtsi file
Overall look good, let wait for some days for other reviewers.
Frank
>
> Changes in v2:
> - Enable serdes_1 on all board DTs that has consumers for it.
> - Use the proper name for serdes_3 in fsl-lx2162a.dtsi.
> - Remove paragraph from commit message which mentioned some consumer
> changes that are no longer needed nor part of the commit.
> - Change the size of the SerDes region to 0x2000
>
> Ioana Ciornei (8):
> arm64: dts: lx2160a: explicitly enable serdes_1 node
> arm64: dts: lx2160a: extract the PCIe nodes into a separate dtsi
> arm64: dts: lx2160a: extract the SerDes nodes into a separate dtsi
> arm64: dts: lx2160a: extract the PCIe from LX2160A Rev2 into a
> separate file
> arm64: dts: lx2160a: split the dtsi to avoid delete-property
> arm64: dts: lx2160a: transition to device-specific SerDes compatible
> strings
> arm64: dts: lx2162a: transition to device-specific SerDes compatible
> strings
> arm64: dts: ls1088a: describe the Lynx 10G SerDes blocks
>
> Vladimir Oltean (3):
> arm64: dts: ls1028a: describe the Lynx 10G SerDes
> arm64: dts: ls1046a: describe the Lynx 10G SerDes blocks
> arm64: dts: ls208xa: describe the Lynx 10G SerDes blocks
>
> .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 29 ++
> .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 60 ++++
> .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 58 ++++
> .../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 98 +++++++
> .../dts/freescale/fsl-lx2160a-bluebox3.dts | 2 +-
> .../dts/freescale/fsl-lx2160a-clearfog-cx.dts | 2 +-
> .../freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 +
> .../dts/freescale/fsl-lx2160a-half-twins.dts | 4 +
> .../dts/freescale/fsl-lx2160a-honeycomb.dts | 2 +-
> .../dts/freescale/fsl-lx2160a-pcie-mbvl.dtsi | 176 ++++++++++++
> .../boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 +
> .../boot/dts/freescale/fsl-lx2160a-rev1.dtsi | 9 +
> .../boot/dts/freescale/fsl-lx2160a-rev2.dtsi | 188 +------------
> .../dts/freescale/fsl-lx2160a-serdes.dtsi | 167 ++++++++++++
> .../dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi | 2 +-
> .../dts/freescale/fsl-lx2162a-clearfog.dts | 6 +-
> .../boot/dts/freescale/fsl-lx2162a-qds.dts | 2 +-
> .../dts/freescale/fsl-lx2162a-serdes.dtsi | 86 ++++++
> .../arm64/boot/dts/freescale/fsl-lx2162a.dtsi | 9 +
> .../{fsl-lx2160a.dtsi => fsl-lx216x.dtsi} | 181 ------------
> .../dts/freescale/fsl-lx216xa-pcie-gen3.dtsi | 257 ++++++++++++++++++
> 21 files changed, 974 insertions(+), 372 deletions(-)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-pcie-mbvl.dtsi
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-rev1.dtsi
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-serdes.dtsi
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a-serdes.dtsi
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
> rename arch/arm64/boot/dts/freescale/{fsl-lx2160a.dtsi => fsl-lx216x.dtsi} (86%)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx216xa-pcie-gen3.dtsi
>
> --
> 2.25.1
>
>
^ permalink raw reply
* Re: [GIT PULL] SoC fixes for 7.2
From: pr-tracker-bot @ 2026-07-17 15:58 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linus Torvalds, linux-kernel, linux-arm-kernel, soc
In-Reply-To: <69fe5d78-221f-4825-a2a5-fd78f62f3628@app.fastmail.com>
The pull request you sent on Fri, 17 Jul 2026 17:36:41 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-fixes-7.2-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/111e7b23e5b05e2298f2e1a4d2a632bee4dde8b0
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v3] coresight: Fix scheduling while atomic in coresight_cpu_pm_notify()
From: Leo Yan @ 2026-07-17 15:58 UTC (permalink / raw)
To: Mohamed Ayman
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
moderated list:ARM/CORESIGHT FRAMEWORK AND DRIVERS,
moderated list:ARM/CORESIGHT FRAMEWORK AND DRIVERS, open list,
open list:Real-time Linux (PREEMPT_RT):Keyword:PREEMPT_RT
In-Reply-To: <20260716214155.2049564-1-mohamedaymanworkspace@gmail.com>
On Fri, Jul 17, 2026 at 12:41:54AM +0300, Mohamed Ayman wrote:
[...]
> static struct coresight_path *coresight_cpu_get_active_path(enum cs_mode mode)
> {
> struct coresight_device *source;
> - bool is_active = false;
> + struct coresight_path *path = NULL;
>
> - source = coresight_get_percpu_source_ref(smp_processor_id());
> - if (!source)
> - return NULL;
> -
> - if (coresight_get_mode(source) & mode)
> - is_active = true;
> + guard(raw_spinlock_irqsave)(&coresight_dev_lock);
>
> - coresight_put_percpu_source_ref(source);
> + source = per_cpu(csdev_source, smp_processor_id());
> + if (source && (coresight_get_mode(source) & mode))
> + path = source->path;
I agree the get_device()/put_device() pair in
coresight_cpu_get_active_path() is not a good fit for CPU PM notifier,
because the put_device() can become the final put while IRQ is disabled.
However, my understanding is this patch might cause UAF issue that the
existing code is intended to prevent.
The raw spinlock (coresight_dev_lock) serializes access to the per-CPU
csdev_source pointer. It does not guarantee the lifetime of the source
or its _parent_ device. coresight_unregister() is not only reached from
module unload; it can also be called when a driver is unbind, for
example DT overlay removal or device hotplug/unplug.
This is why the UAF issue Sashiko mentioned in patch 03 of [1]. A built
CoreSight path currently grabs references for the path components, which
keeps module alive, but that is not the same as preventing the parent
device/driver from being unbound and tearing down CoreSight device data
while an active session still has raw pointers.
There are also similar race window before the path is built: for
example etm_setup_aux() has to look up source/sink state before
coresight_build_path() establishes the path, so it might access
released source/sink data if device is unbound.
I think a proper fix needs a clearer lifetime model for an active
session. E.g., we could consider to call device_link_add() to prevent
device unbind / unregister, and unlink device when the session is
finished. Once that is in place, the CPU PM notifier can safely use the
active path without get_device()/put_device() pair anymore.
Hope this is clear and makes sense.
Thanks,
Leo
[1] https://sashiko.dev/#/patchset/20260405-arm_coresight_path_power_management_improvement-v10-0-13e94754a8be%40arm.com
^ permalink raw reply
* Re: [PATCH 1/3] perf: Remove redundant dev_err()/dev_err_probe()
From: Frank Li @ 2026-07-17 16:00 UTC (permalink / raw)
To: Pan Chuang
Cc: Shuai Xue, Will Deacon, Mark Rutland, Frank Li, Xu Yang,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ji Sheng Teoh, Khuong Dinh,
moderated list:ARM PMU PROFILING AND DEBUGGING,
open list:ARM PMU PROFILING AND DEBUGGING, open list,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:ARM/QUALCOMM MAILING LIST
In-Reply-To: <20260717103123.34887-2-panchuang@vivo.com>
On Fri, Jul 17, 2026 at 06:31:17PM +0800, Pan Chuang wrote:
> Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
> devm_request_*_irq()"), devm_request_irq() automatically logs
> detailed error messages on failure. Remove the now-redundant
> driver-specific dev_err() and dev_err_probe() calls.
>
> Signed-off-by: Pan Chuang <panchuang@vivo.com>
> ---
> drivers/perf/alibaba_uncore_drw_pmu.c | 5 +----
> drivers/perf/fsl_imx8_ddr_perf.c | 4 +---
> drivers/perf/fsl_imx9_ddr_perf.c | 4 +---
for imx part
Acked-by: Frank Li <Frank.Li@kernel.org>
^ permalink raw reply
* Re: [PATCH] drm/mediatek: mtk_dsi: enable hs clock during pre-enable
From: Gary Bisson @ 2026-07-17 16:06 UTC (permalink / raw)
To: Esben Haabendal
Cc: AngeloGioacchino Del Regno, Chun-Kuang Hu, Philipp Zabel,
David Airlie, Simona Vetter, Matthias Brugger, dri-devel,
linux-mediatek, linux-kernel, linux-arm-kernel, Adam Thiede,
Thorsten Leemhuis
In-Reply-To: <87h5m0mkca.fsf@geanix.com>
Hi Angelo & Esteban,
On Wed, Jul 15, 2026 at 03:52:05PM +0200, Esben Haabendal wrote:
> "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>
> writes:
>
> > On 7/15/26 15:36, Gary Bisson wrote:
> >> Hi,
> >>
> >> On Wed, Jul 15, 2026 at 03:25:11PM +0200, AngeloGioacchino Del Regno wrote:
> >>> On 7/15/26 14:53, Esben Haabendal wrote:
> >>>> Gary Bisson <bisson.gary@gmail.com> writes:
> >>>>
> >>>>> Some bridges, such as the TI SN65DSI83, require the HS clock to be
> >>>>> running in order to lock its PLL during its own pre-enable function.
> >>>>>
> >>>>> Without this change, the bridge gives the following error:
> >>>>> sn65dsi83 14-002c: failed to lock PLL, ret=-110
> >>>>> sn65dsi83 14-002c: Unexpected link status 0x01
> >>>>> sn65dsi83 14-002c: reset the pipe
> >>>>>
> >>>>> Move the necessary functions from enable to pre-enable.
> >>>>>
> >>>>> Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
> >>>>
> >>>> Hi
> >>>>
> >>>> I have run into the same problem, but in combination with another
> >>>> pipeline. I am seeing same problem with an i.MX8 using the nwl-dsi
> >>>> bridge and the dcss driver.
> >>>>
> >>>> I have submitted a fix that adresses the problem in the ti-sn65dsi83
> >>>> driver instead. With a bit of luck, it can replace the fix proposed in
> >>>> this thread.
> >>>>
> >>>> See https://lore.kernel.org/all/20260711-ti-sn65dsi83-fixes-v1-2-d85eb5342b98@geanix.com/
> >>
> >> Thanks, just tried it on 7.2-rc3 with my patch reverted and confirm that
> >> it works too. My assumption was that the SN65DSI83 was locking the PLL
> >> earlier for some specific reason and therefore was reluctant to change
> >> it.
> >>
> >>>> /Esben
> >>>
> >>> That clarifies a lot of things.
> >>>
> >>> The patch on mtk_dsi shall be reverted then.
> >>
> >> Angelo, do you want me to offer the revert patch? Should I wait to see
> >> how the other thread goes?
> >>
> >
> > Gary, yes please, send a revert and make sure to explain the reason why
> > we're reverting this in the commit description :-)
>
> Maybe test if my fix actually solves the problem with the mtk_dsi driver
> also ;)
As mentioned in the other thread, your patch works but it might break
the init sequence recommended by the bridge datasheet.
Moreover, the drm_bridge.c doc [1] does mention that the clock lane
should be initialized during pre_enable. If we agree on this assumption
I believe my patch should not be reverted.
Maybe Adam's bridge driver must be patched instead, just like the
nwl-dsi driver should be updated to follow the drm recommendation.
Let me know your thoughts.
Regards,
Gary
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_bridge.c#n169
^ permalink raw reply
* Re: [RFC PATCH v1 1/8] misc/arm-cla: Add driver skeleton and documentation
From: Arnd Bergmann @ 2026-07-17 16:10 UTC (permalink / raw)
To: Ryan Roberts, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
Mark Rutland, Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet
Cc: linux-kernel, linux-arm-kernel, dri-devel, linux-doc
In-Reply-To: <5f82ee6b-d106-4ae1-9b2c-5a817e3e43b9@arm.com>
On Fri, Jul 17, 2026, at 17:44, Ryan Roberts wrote:
> On 17/07/2026 14:49, Arnd Bergmann wrote:
>> On Fri, Jul 17, 2026, at 12:47, Ryan Roberts wrote:
>> This sounds a lot like st64bv or st64bv0, passing an 8-word payload and returning
>> a single word per accelerator operation with shared addressing.
>
> We're actually passing 9 words here; 8 DATA words plus the LAUNCH word. CLA
> supports only 64 bit aligned and sized accesses (other accesses are RAZ/WI) so
> they have to be written as 9x64bit stores. Then poll using 64bit loads.
>
>>
>> Why are there now two interfaces to do the same thing?
>
> Good question. This is how the HW operates.
>
>>
>> Can a user process use st64bv to do the four steps in a
>> single instruction?
>
> No, unfortunately not.
>
Ok
>> Can a CPU start multiple asynchronous operations concurrently?
>
> Yes; STATUS indicates READY while it can accept more asynchronous operations
> ("comamnds").
How does userspace know which operations have already completed
then? (not worried about this bit, just trying to understand)
>> Do these continue to run if the starting process is scheduled out
>> and another process also tries to use CLA?
>
> Yes; the driver manages assignment of a CLA to a process context completely
> separately from the thread scheduler's decisions about which threads run on
> which CPUs and when. If another process is scheduled onto the CPU and it
> attempts to access it's VA for the CLA, it will fault into the driver's handler
> and be put to sleep until the driver decides to reassign the CLA.
This part does sound dangerous, not in the sense that I think it's
fundamentally broken, but in the complexity it adds.
I wonder if it's feasible to simplify this by always canceling
any ongoing CLA operations during switch_mm():
Is there an upper bound on how long a single operation can take,
or a guarantee that an operation at least provides a partial result
in hardware?
From your earlier descriptions, it sounds like the CPU is usually
assumed to wait for completion with WFE anyway, so from the
scheduler's perspective, the thread is active while waiting for
the accelerator to complete a job (even if from hardware side
the CPU is powered down during WFE).
If this is how it generally operates, and the accelerator jobs
are usually fast, forcing the CLA TTBR0 to be the same as the
CPU TTBR0 would avoid the entire problem of unmapping the registers
on context switch, but instead let this hook into the same place
as the corresponding iommu_mm_data switch on x86, which seems
to handle this more nicely.
> I'm not sure what you mean by "Which instruction specifically causes the fault".
> A fault occurs within the accelerator if it tries to access a virtual address
> that is not mapped by the page table or if the permissions of the mapping are
> not sufficient, etc... The fact that the accelerator has faulted is reported to
> the SW that is polling the accelerator's STATUS register within user space. That
> SW is expected to trigger fault handling by the usual kernel mechanisms by
> accessing the VA. Then it issues a RESOLVE operation to tell the accelerator it
> can continue.
Got it now. I had assumed that the page fault is delivered asynchronously
to the kernel without user space getting involved. In this case, I think
the interface is actually cleaner, though it does add a little bit
of overhead for userspace having to decipher the status.
>>> +User space software is expected to create a thread to drive each CLA it is
>>> +using, and for each thread to be pinned to the CLA's local CPU.
>>
>> What happens if multiple processes have the same chardev open and
>> each mmap() that, e.g. after a fork()? Does each process see its
>> own virtual instance of the accelerator and interact with it through
>> the same physical MMIO register range but its own process address space,
>> or do you have to rely on the registers being mapped only into a
>> single mm_struct to prevent a process from messing with another process
>> data?
>
> The driver maintains a cla_ctx for each {file description, mm_struct} pair. So
> in this case, even though the file description is shared between the parent and
> child processes, they still have distinct mm_structs so still have separate
> contexts allowing the driver to virtualize access correctly.
Ok, got it.
Arnd
^ permalink raw reply
* Re: [PATCH v3] coresight: Fix scheduling while atomic in coresight_cpu_pm_notify()
From: Sebastian Andrzej Siewior @ 2026-07-17 16:12 UTC (permalink / raw)
To: Leo Yan
Cc: Mohamed Ayman, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Clark Williams, Steven Rostedt,
moderated list:ARM/CORESIGHT FRAMEWORK AND DRIVERS,
moderated list:ARM/CORESIGHT FRAMEWORK AND DRIVERS, open list,
open list:Real-time Linux (PREEMPT_RT):Keyword:PREEMPT_RT
In-Reply-To: <20260717155848.GB3998092@e132581.arm.com>
On 2026-07-17 16:58:48 [+0100], Leo Yan wrote:
> > static struct coresight_path *coresight_cpu_get_active_path(enum cs_mode mode)
> > {
> > struct coresight_device *source;
> > - bool is_active = false;
> > + struct coresight_path *path = NULL;
> >
> > - source = coresight_get_percpu_source_ref(smp_processor_id());
> > - if (!source)
> > - return NULL;
> > -
> > - if (coresight_get_mode(source) & mode)
> > - is_active = true;
> > + guard(raw_spinlock_irqsave)(&coresight_dev_lock);
> >
> > - coresight_put_percpu_source_ref(source);
> > + source = per_cpu(csdev_source, smp_processor_id());
> > + if (source && (coresight_get_mode(source) & mode))
> > + path = source->path;
>
> I agree the get_device()/put_device() pair in
> coresight_cpu_get_active_path() is not a good fit for CPU PM notifier,
> because the put_device() can become the final put while IRQ is disabled.
>
> However, my understanding is this patch might cause UAF issue that the
> existing code is intended to prevent.
>
> The raw spinlock (coresight_dev_lock) serializes access to the per-CPU
> csdev_source pointer. It does not guarantee the lifetime of the source
> or its _parent_ device. coresight_unregister() is not only reached from
> module unload; it can also be called when a driver is unbind, for
> example DT overlay removal or device hotplug/unplug.
But doesn't coresight_unregister() block on the coresight_dev_lock here?
> This is why the UAF issue Sashiko mentioned in patch 03 of [1]. A built
> CoreSight path currently grabs references for the path components, which
> keeps module alive, but that is not the same as preventing the parent
> device/driver from being unbound and tearing down CoreSight device data
> while an active session still has raw pointers.
>
> There are also similar race window before the path is built: for
> example etm_setup_aux() has to look up source/sink state before
> coresight_build_path() establishes the path, so it might access
> released source/sink data if device is unbound.
>
> I think a proper fix needs a clearer lifetime model for an active
> session. E.g., we could consider to call device_link_add() to prevent
> device unbind / unregister, and unlink device when the session is
> finished. Once that is in place, the CPU PM notifier can safely use the
> active path without get_device()/put_device() pair anymore.
Right. I am also not sure about lifetime of coresight_device::path.
> Hope this is clear and makes sense.
>
> Thanks,
> Leo
Sebastian
^ permalink raw reply
* Re: [PATCH v2 3/4] perf/arm_cspmu: Improve sub-module error reporting
From: Robin Murphy @ 2026-07-17 16:16 UTC (permalink / raw)
To: Jonathan Cameron
Cc: will, mark.rutland, catalin.marinas, ilkka, bwicaksono,
linux-acpi, linux-arm-kernel, linux-perf-users
In-Reply-To: <20260716171213.000026c7@oss.qualcomm.com>
On 17/07/2026 1:12 am, Jonathan Cameron wrote:
> On Thu, 16 Jul 2026 15:56:36 +0100
> Robin Murphy <robin.murphy@arm.com> wrote:
>
>> When waiting for a sub-module to register, we return a bare
>> -EPROBE_DEFER that ends up showing the end user:
>>
>> platform arm-cs-arch-pmu.1: deferred probe pending (no reason)
>>
>> wherein it's not necessarily clear that they might need to take some
>> action to ensure the appropriate module is available to load. Let's use
>> dev_err_probe() here so we can show exactly what we're waiting for.
>>
>> Similarly, in the case where something's gone horribly wrong with an
>> already-registered module, we can use dev_WARN() to standardise the
>> device/driver attribution rather than just open-coding "arm_cspmu".
>>
>> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> Hi Robin,
>
> Maybe sprinkle some cleanup.h magic and use a guard(mutex)() and direct
> returns. Simplifies this function that you are touching anyway.
>
> Looking more broadly it'd either take a scoped_guard() or some refactoring
> if you want to go that way cross the file.
Heh, feel free to try some cosmetic refactoring if you fancy - for
starters, "if (!match) return 0" would save a whole needless level of
indentation here - but this patch is purely about a functional
improvement to the user-visible logging. I'd rather not tangle that up
in subjective non-functional changes.
(And to be brutally honest I'm not much of a fan of the cleanup.h stuff
anyway - maybe for complex nested resource acquisition, but it's not
like there are any gotos here, so for the sake of ~3 lines I'd
personally rather have locking that looks like locking...)
Thanks,
Robin.
>
> Jonathan
>
>>
>> ---
>> v2: No change
>> ---
>> drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
>> index 8c2dda17d73e..caad9a36651d 100644
>> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
>> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
>> @@ -437,13 +437,15 @@ static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
>> if (ret)
>> module_put(match->module);
>> } else {
>> - WARN(1, "arm_cspmu failed to get module: %s\n",
>> + dev_WARN(cspmu->dev, "Failed to get module: %s\n",
>> match->module_name);
>> ret = -EINVAL;
>> }
>> } else {
>> request_module_nowait(match->module_name);
>> - ret = -EPROBE_DEFER;
>> + ret = dev_err_probe(cspmu->dev, -EPROBE_DEFER,
>> + "Waiting for module %s to load\n",
>> + match->module_name);
>> }
>>
>> mutex_unlock(&arm_cspmu_lock);
>
^ permalink raw reply
* Re: [RFC PATCH v1 8/8] misc/arm-cla: Add userspace interface
From: Ryan Roberts @ 2026-07-17 16:21 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
Mark Rutland, Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet
Cc: linux-kernel, linux-arm-kernel, dri-devel, linux-doc
In-Reply-To: <59d0c4d5-af53-410d-9bf8-8dd2ba17f697@app.fastmail.com>
On 17/07/2026 16:31, Arnd Bergmann wrote:
> On Fri, Jul 17, 2026, at 16:35, Ryan Roberts wrote:
>> On 17/07/2026 13:54, Arnd Bergmann wrote:
>>> On Fri, Jul 17, 2026, at 12:47, Ryan Roberts wrote:
>>>> Expose CLA devices through a character device so userspace can enumerate
>>>> the available hardware and map accelerator register frames.
>>>>
>>>> Define version 1 of the CLA UAPI with a GET_PARAM ioctl. Report device
>>>> topology, CPU affinity, domain membership, mmap offsets, architecture
>>>> version and attached accelerator masks, together with the IIDR, DEVARCH
>>>> and REVIDR of each accelerator.
>>>>
>>>> CLA registers can only be read from the CPU local to the device, while
>>>> enumeration may occur on any CPU. Validate the supported CLA
>>>> architecture version during device setup and cache the CLA and
>>>> accelerator identification registers for later ioctl queries.
>>>
>>> This interface looks very raw at the moment, I expect this will have
>>> one or more larger redesigns.
>>
>> Are you referring to the overall UABI or specifically to the ioctl interface
>> here? I could imagine the ioctl interface evolving before we get this merged
>> (although it is based on similar patterns used by some DRM and accel drivers -
>> it's intended to be easily extensible while existing params remain stable).
>>
>> The aspect where the CLA MMIO is directly mapped into user space is an aspect we
>> are keen to keep though since it has significant performance implications if we
>> need to redirect through the kernel.
>
> I see no problem with having a per-accelerator VM area for MMIO
> operations mapped to userspace, this is obviously part of all
> designs like this one that sneak custom coprocessor instructions
> in by disguising them as MMIO.
>
> My concern is about how userspace gets to that mapping, both
> the chardev itself, but also the ioctls.
OK thanks for the clarification.
>
>>> Most importantly, a single character device to expose an arbitrary
>>> number of underlying hardware features is an inherently flawed security
>>> model. If any specific accelerator is ever found to have a
>>> major vulnerability, that would mean administrators will have to
>>> disable all of them by default.
>>
>> Note that we are exposing MMIO per CLA, not per accelerator. So preventing
>> access to a single CLA would prevent access to all accelerators attached to it.
>> There is a per-accelerator availability masking control that the kernel can use
>> to disable access to selected accelerators though, which might help with the
>> vulnerability example.
>>
>> The rationale for choosing a single device file was driven by performance: At
>> domain reassignment time, we need to unmap and invalidate the TLB entries for
>> all the devices in the domain from the out-going process's address space. By
>> having all the devices in a single file and all devices within the same domain
>> adjacent, they can all be mapped to a single VMA, meaning the driver can use a
>> single call to the existing zap_special_vma_range(), which will result in a
>> single TLBI-by-range instruction, which is faster than a TLBI-by-va for every
>> device.
>>
>> If you think it is important for security to have each CLA exposed by an
>> independent device file, I'll take another look.
>
> Without concrete implementation examples, I find it hard to imagine
> how granular the CLA and accelerator blocks are. What I'm interested
> in is separating things into special character devices when they
> refer to units that you want to manage separately in userspace.
>
> If you have e.g. one accelerator for tensor operations and one for
> handling gzip, I would very much want to see those have a separate
> chardev nodes so a local administrator can give permissions to each
> one separately, and have device names that are sensible to the
> functionality underneath.
Unfortunately this doesn't map well to the HW: the MMIO is for the CLA interface
(each CPU has 1 CLA). Once you have access to that interface, you can
communicate with all of the accelerators that are connected to the CLA. We could
potentially use the availability masking control to only expose a single
accelerator for a given context (which would be chosen based on which file you
opened), but it wouldn't be possible for (e.g.) 2 different processes to access
the different accelerators concurrently - they would have to be subject to the
time slice model.
I'll think harder about what we might be able to do though.
>
> If you have separate accelerators for AES encryption and decryption,
> or a large set of identical accelerators that can run concurrently,
> those would of course get managed as a single device file.
>
> Most importantly, I don't think a global /dev/cla device node
> is a sensible interface from a management perspective as that
> would give unprivileged userspace direct control to something
> that is essentially arbitrary (or buggy) vendor firmware
> with DMA permissions.
OK I see your point.
While the interface supports up to 8 connected accelerators, we anticpate there
only being a single compute accelerator in practice. We decided to keep the
driver interface generic given the CLA spec, but perhaps it would be more
straightforward to limit the driver implementation to only permitting a single
accelerator?
>
>>>> Support shared read-write mmap of one or more CLA register pages. Create
>>>> a context for every domain covered by the mapping and resolve faults
>>>> only while that context owns the domain. Queue unassigned contexts with
>>>> the domain scheduler, drop mmap_lock while waiting for assignment and
>>>> retry the fault after the context is woken.
>>>
>>> I still need some time to better understand what this means.
>>
>> I can probably do a better job of explaining this: The kernel keeps a cla_ctx
>> object which represents a single {file description, mm_struct} context that
>> wants to use the cla_domain (collection of 1 or more cla_dev). Initially the VMA
>> is not populated so when user space tries to access, it will fault to the
>> driver. If the cla_domain is assigned to a different cla_ctx, the faulting
>> thread is put to sleep until the driver determines that it's the turn of that
>> cla_ctx to be assigned the domain. At that point the waiting thread(s) are woken
>> and map the devices from the domain to the VMA and return to user space. The
>> out-going cla_ctx had it's mappings removed during the reassignment process so
>> any user space access will now fault and sleep waiting for assignment.
>
> Got it, thanks
>
>>> Does a CPU have multiple concurrently running contexts?
>>
>> The HW only has a single HW context, hence the timesliced assignment approach
>> described above (assuming there is more than 1 concurrent user).
>
> Sorry, I think we have a clash of terminology. I meant whether
> a CPU can start multiple operations on one or more accelerator
> in a single cla_domain, and have each of those operate at the
> same time while the hardware is asynchronously processing them
> in parallel.
>
> It sounds like a single accelerator has one register to wait for
> completion and can only have single operation in progress at any
> time, but if multiple accelerators are in the same cla_ctx,
> can a single thread start an operation in each one before waiting
> for the first to complete?
CLAs can only be accessed/controlled from their local CPU. The expected model is
that you have a thread per CLA (pinned to the CPU) to submit operations only for
it's local CLA.
>
>>> Is a
>>> user process able to starve the allocation of other processes
>>> by just requesting a lot of them?
>>
>> In the current code, a process can theoretically create the same number of
>> cla_ctx as the number of file descriptors it can open(). It would then need to
>> mmap and access to get into the queue to be assigned the domain. I see it as
>> similar to threads; if process A creates 10 threads and process B creates 1
>> thread, then in the long run (ignoring cgroups et al) you'd expect A to get
>> 10/11th of the CPU time (IIUC?).
>>
>> Do you think this consitutes a DoS?
>
> I need to think about it more. Probably not a DoS, but if the resource
> is managed like CPU timeslices, I wonder whether you'd have to also
> consider things like realtime tasks or priority inversion.
Yes... we are considering realtime. I was trying not to dump too much into the
initial RFC though :)
Thanks,
Ryan
>
>>>> + wait_event_interruptible(ctx->waitq,
>>>> + READ_ONCE(domain->assigned_ctx) == ctx ||
>>>> + cla_ctx_is_dying(ctx) ||
>>>> + READ_ONCE(domain->broken));
>>>
>>> If you call wait_event_interruptible(), you have to check the return
>>> code and deal with it being interrupted.
>>
>> I believe this is already correct - I'm reeturning VM_FAULT_RETRY
>> unconditionally at this point, which is also the correct return code if we get
>> interrupted. This unwinds to arm64's do_page_fault() which then notices and
>> handles the fault:
>>
>> /* Quick path to respond to signals */
>> if (fault_signal_pending(fault, regs)) {
>> if (!user_mode(regs))
>> goto no_context;
>> return 0;
>> }
>
> Ok, makes sense.
>
>> I believe GUP and other handle_mm_fault() callers have similar logic.
>>
>> I'll add a comment to make that clear.
>
> Thanks
>
> Arnd
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: imx93-11x11-frdm: factor out common parts into dtsi
From: Frank Li @ 2026-07-17 16:29 UTC (permalink / raw)
To: Joseph Guo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260717-imx93w_frdm-v1-1-0cca6c0ba2f5@nxp.com>
On Fri, Jul 17, 2026 at 02:11:52PM +0900, Joseph Guo wrote:
> [You don't often get email from qijian.guo@nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> The i.MX93 Wireless FRDM board reuses most of the i.MX93 FRDM board.
> To avoid duplication and DTS-to-DTS includes, extract common hardware
> definitions from imx93-11x11-frdm.dts into imx93-11x11-frdm-common.dtsi
> to allow the common description shared by both boards.
>
> The FRDM-IMX93 board-specific .dts now includes the common dtsi and only
> contains board-specific overrides.
>
> Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
> ---
> .../dts/freescale/imx93-11x11-frdm-common.dtsi | 692 +++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts | 686 +-------------------
> 2 files changed, 694 insertions(+), 684 deletions(-)
Please use -M -C to generate patch. git can auto detect copy.
Frank
>
> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm-common.dtsi b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm-common.dtsi
> new file mode 100644
> index 0000000000000000000000000000000000000000..69e23570f71f40a3f3517d31e16a9ca1d3dfb1f2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm-common.dtsi
> @@ -0,0 +1,692 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +#include <dt-bindings/usb/pd.h>
> +
> +/ {
> +
> + aliases {
> + can0 = &flexcan2;
> + ethernet0 = &fec;
> + ethernet1 = &eqos;
> + i2c0 = &lpi2c1;
> + i2c1 = &lpi2c2;
> + i2c2 = &lpi2c3;
> + mmc0 = &usdhc1; /* EMMC */
> + mmc1 = &usdhc2; /* uSD */
> + rtc0 = &pcf2131;
> + serial0 = &lpuart1;
> + serial4 = &lpuart5;
> + };
> +
> + chosen {
> + stdout-path = &lpuart1;
> + };
> +
> + flexcan2_phy: can-phy {
> + compatible = "nxp,tja1051";
> + #phy-cells = <0>;
> + max-bitrate = <5000000>;
> + silent-gpios = <&pcal6524 23 GPIO_ACTIVE_HIGH>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + button-k2 {
> + label = "Button K2";
> + linux,code = <BTN_1>;
> + gpios = <&pcal6524 5 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> + interrupt-parent = <&pcal6524>;
> + interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
> + };
> +
> + button-k3 {
> + label = "Button K3";
> + linux,code = <BTN_2>;
> + gpios = <&pcal6524 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> + interrupt-parent = <&pcal6524>;
> + interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
> + };
> + };
> +
> + reg_usdhc2_vmmc: regulator-usdhc2 {
> + compatible = "regulator-fixed";
> + off-on-delay-us = <12000>;
> + pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
> + pinctrl-names = "default";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "VSD_3V3";
> + vin-supply = <&buck4>;
> + gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + reserved-memory {
> + ranges;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + linux,cma {
> + compatible = "shared-dma-pool";
> + alloc-ranges = <0 0x80000000 0 0x30000000>;
> + reusable;
> + size = <0 0x10000000>;
> + linux,cma-default;
> + };
> +
> + rsc_table: rsc-table@2021e000 {
> + reg = <0 0x2021e000 0 0x1000>;
> + no-map;
> + };
> +
> + vdev0vring0: vdev0vring0@a4000000 {
> + reg = <0 0xa4000000 0 0x8000>;
> + no-map;
> + };
> +
> + vdev0vring1: vdev0vring1@a4008000 {
> + reg = <0 0xa4008000 0 0x8000>;
> + no-map;
> + };
> +
> + vdev1vring0: vdev1vring0@a4010000 {
> + reg = <0 0xa4010000 0 0x8000>;
> + no-map;
> + };
> +
> + vdev1vring1: vdev1vring1@a4018000 {
> + reg = <0 0xa4018000 0 0x8000>;
> + no-map;
> + };
> +
> + vdevbuffer: vdevbuffer@a4020000 {
> + compatible = "shared-dma-pool";
> + reg = <0 0xa4020000 0 0x100000>;
> + no-map;
> + };
> + };
> +};
> +
> +&adc1 {
> + vref-supply = <&buck5>;
> + status = "okay";
> +};
> +
> +&mu1 {
> + status = "okay";
> +};
> +
> +&cm33 {
> + mboxes = <&mu1 0 1>,
> + <&mu1 1 1>,
> + <&mu1 3 1>;
> + mbox-names = "tx", "rx", "rxdb";
> + memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
> + <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
> + status = "okay";
> +};
> +
> +&eqos {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pinctrl_eqos>;
> + pinctrl-1 = <&pinctrl_eqos_sleep>;
> + phy-handle = <ðphy1>;
> + phy-mode = "rgmii-id";
> + status = "okay";
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clock-frequency = <5000000>;
> +
> + ethphy1: ethernet-phy@1 {
> + reg = <1>;
> + reset-assert-us = <10000>;
> + reset-deassert-us = <80000>;
> + reset-gpios = <&pcal6524 15 GPIO_ACTIVE_LOW>;
> + realtek,clkout-disable;
> + };
> + };
> +};
> +
> +&fec {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pinctrl_fec>;
> + pinctrl-1 = <&pinctrl_fec_sleep>;
> + phy-mode = "rgmii-id";
> + phy-handle = <ðphy2>;
> + fsl,magic-packet;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clock-frequency = <5000000>;
> +
> + ethphy2: ethernet-phy@2 {
> + reg = <2>;
> + reset-assert-us = <10000>;
> + reset-deassert-us = <80000>;
> + reset-gpios = <&pcal6524 16 GPIO_ACTIVE_LOW>;
> + realtek,clkout-disable;
> + };
> + };
> +};
> +
> +&flexcan2 {
> + phys = <&flexcan2_phy>;
> + pinctrl-0 = <&pinctrl_flexcan2>;
> + pinctrl-1 = <&pinctrl_flexcan2_sleep>;
> + pinctrl-names = "default", "sleep";
> + status = "okay";
> +};
> +
> +&lpi2c1 {
> + clock-frequency = <400000>;
> + pinctrl-0 = <&pinctrl_lpi2c1>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + pcal6408: gpio@20 {
> + compatible = "nxp,pcal6408";
> + reg = <0x20>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + reset-gpios = <&pcal6524 20 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +&lpi2c2 {
> + clock-frequency = <400000>;
> + pinctrl-0 = <&pinctrl_lpi2c2>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + pcal6524: gpio@22 {
> + compatible = "nxp,pcal6524";
> + reg = <0x22>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + interrupt-parent = <&gpio3>;
> + interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + pinctrl-0 = <&pinctrl_pcal6524>;
> + pinctrl-names = "default";
> + /* does not boot with supplier set, because it is the bucks interrupt parent */
> + /* vcc-supply = <&buck4>; */
> + };
> +
> + pmic@25 {
> + compatible = "nxp,pca9451a";
> + reg = <0x25>;
> + interrupt-parent = <&pcal6524>;
> + interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
> +
> + regulators {
> +
> + buck1: BUCK1 {
> + regulator-name = "VDD_SOC_0V8";
> + regulator-min-microvolt = <610000>;
> + regulator-max-microvolt = <950000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-ramp-delay = <3125>;
> + };
> +
> + buck2: BUCK2 {
> + regulator-name = "LPD4_x_VDDQ_0V6";
> + regulator-min-microvolt = <600000>;
> + regulator-max-microvolt = <670000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-ramp-delay = <3125>;
> + };
> +
> + buck4: BUCK4 {
> + regulator-name = "VDD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + buck5: BUCK5 {
> + regulator-name = "VDD_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + buck6: BUCK6 {
> + regulator-name = "LPD4_x_VDD2_1V1";
> + regulator-min-microvolt = <1060000>;
> + regulator-max-microvolt = <1140000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + ldo1: LDO1 {
> + regulator-name = "NVCC_BBSM_1V8";
> + regulator-min-microvolt = <1620000>;
> + regulator-max-microvolt = <1980000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + ldo4: LDO4 {
> + regulator-name = "VDD_ANA_0V8";
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <840000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + ldo5: LDO5 {
> + regulator-name = "NVCC_SD";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> + };
> + };
> +
> + eeprom: eeprom@50 {
> + compatible = "atmel,24c256";
> + reg = <0x50>;
> + pagesize = <64>;
> + vcc-supply = <&buck4>;
> + };
> +};
> +
> +&lpi2c3 {
> + clock-frequency = <400000>;
> + pinctrl-0 = <&pinctrl_lpi2c3>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + ptn5110: tcpc@50 {
> + compatible = "nxp,ptn5110", "tcpci";
> + reg = <0x50>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> +
> + typec1_con: connector {
> + compatible = "usb-c-connector";
> + data-role = "dual";
> + label = "USB-C";
> + op-sink-microwatt = <15000000>;
> + power-role = "dual";
> + self-powered;
> + sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
> + PDO_VAR(5000, 20000, 3000)>;
> + source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> + try-power-role = "sink";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + typec1_dr_sw: endpoint {
> + remote-endpoint = <&usb1_drd_sw>;
> + };
> + };
> + };
> + };
> + };
> +
> + pcf2131: rtc@53 {
> + compatible = "nxp,pcf2131";
> + reg = <0x53>;
> + interrupt-parent = <&pcal6524>;
> + interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
> + };
> +};
> +
> +&lpuart1 { /* console */
> + pinctrl-0 = <&pinctrl_uart1>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
> +
> +&lpuart5 {
> + pinctrl-0 = <&pinctrl_uart5>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + uart-has-rtscts;
> +
> + bluetooth {
> + compatible = "nxp,88w8987-bt";
> + device-wakeup-gpios = <&pcal6408 3 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&pcal6524 19 GPIO_ACTIVE_LOW>;
> + vcc-supply = <®_usdhc3_vmmc>;
> + };
> +};
> +
> +&usbotg1 {
> + adp-disable;
> + disable-over-current;
> + dr_mode = "otg";
> + hnp-disable;
> + srp-disable;
> + usb-role-switch;
> + samsung,picophy-dc-vol-level-adjust = <7>;
> + samsung,picophy-pre-emp-curr-control = <3>;
> + status = "okay";
> +
> + port {
> + usb1_drd_sw: endpoint {
> + remote-endpoint = <&typec1_dr_sw>;
> + };
> + };
> +};
> +
> +&usbotg2 {
> + disable-over-current;
> + dr_mode = "host";
> + samsung,picophy-dc-vol-level-adjust = <7>;
> + samsung,picophy-pre-emp-curr-control = <3>;
> + status = "okay";
> +};
> +
> +&usdhc1 {
> + bus-width = <8>;
> + non-removable;
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + vmmc-supply = <&buck4>;
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + bus-width = <4>;
> + cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
> + no-mmc;
> + no-sdio;
> + pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> + pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> + pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> + pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_usdhc2_gpio_sleep>;
> + pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> + vmmc-supply = <®_usdhc2_vmmc>;
> + status = "okay";
> +};
> +
> +&wdog3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_wdog>;
> + fsl,ext-reset-output;
> + status = "okay";
> +};
> +
> +&iomuxc {
> +
> + pinctrl_eqos: eqosgrp {
> + fsl,pins = <
> + MX93_PAD_ENET1_MDC__ENET_QOS_MDC 0x57e
> + MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO 0x57e
> + MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0 0x57e
> + MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e
> + MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e
> + MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e
> + MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x58e
> + MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e
> + MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e
> + MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1 0x57e
> + MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e
> + MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e
> + MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x58e
> + MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e
> + >;
> + };
> +
> + pinctrl_eqos_sleep: eqossleepgrp {
> + fsl,pins = <
> + MX93_PAD_ENET1_MDC__GPIO4_IO00 0x31e
> + MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x31e
> + MX93_PAD_ENET1_RD0__GPIO4_IO10 0x31e
> + MX93_PAD_ENET1_RD1__GPIO4_IO11 0x31e
> + MX93_PAD_ENET1_RD2__GPIO4_IO12 0x31e
> + MX93_PAD_ENET1_RD3__GPIO4_IO13 0x31e
> + MX93_PAD_ENET1_RXC__GPIO4_IO09 0x31e
> + MX93_PAD_ENET1_RX_CTL__GPIO4_IO08 0x31e
> + MX93_PAD_ENET1_TD0__GPIO4_IO05 0x31e
> + MX93_PAD_ENET1_TD1__GPIO4_IO04 0x31e
> + MX93_PAD_ENET1_TD2__GPIO4_IO03 0x31e
> + MX93_PAD_ENET1_TD3__GPIO4_IO02 0x31e
> + MX93_PAD_ENET1_TXC__GPIO4_IO07 0x31e
> + MX93_PAD_ENET1_TX_CTL__GPIO4_IO06 0x31e
> + >;
> + };
> +
> + pinctrl_fec: fecgrp {
> + fsl,pins = <
> + MX93_PAD_ENET2_MDC__ENET1_MDC 0x57e
> + MX93_PAD_ENET2_MDIO__ENET1_MDIO 0x57e
> + MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0 0x57e
> + MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1 0x57e
> + MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2 0x57e
> + MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3 0x57e
> + MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC 0x58e
> + MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL 0x57e
> + MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0 0x57e
> + MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1 0x57e
> + MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2 0x57e
> + MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3 0x57e
> + MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC 0x58e
> + MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
> + >;
> + };
> +
> + pinctrl_fec_sleep: fecsleepgrp {
> + fsl,pins = <
> + MX93_PAD_ENET2_MDC__GPIO4_IO14 0x51e
> + MX93_PAD_ENET2_MDIO__GPIO4_IO15 0x51e
> + MX93_PAD_ENET2_RD0__GPIO4_IO24 0x51e
> + MX93_PAD_ENET2_RD1__GPIO4_IO25 0x51e
> + MX93_PAD_ENET2_RD2__GPIO4_IO26 0x51e
> + MX93_PAD_ENET2_RD3__GPIO4_IO27 0x51e
> + MX93_PAD_ENET2_RXC__GPIO4_IO23 0x51e
> + MX93_PAD_ENET2_RX_CTL__GPIO4_IO22 0x51e
> + MX93_PAD_ENET2_TD0__GPIO4_IO19 0x51e
> + MX93_PAD_ENET2_TD1__GPIO4_IO18 0x51e
> + MX93_PAD_ENET2_TD2__GPIO4_IO17 0x51e
> + MX93_PAD_ENET2_TD3__GPIO4_IO16 0x51e
> + MX93_PAD_ENET2_TXC__GPIO4_IO21 0x51e
> + MX93_PAD_ENET2_TX_CTL__GPIO4_IO20 0x51e
> + >;
> + };
> +
> + pinctrl_flexcan2: flexcan2grp {
> + fsl,pins = <
> + MX93_PAD_GPIO_IO25__CAN2_TX 0x139e
> + MX93_PAD_GPIO_IO27__CAN2_RX 0x139e
> + >;
> + };
> +
> + pinctrl_flexcan2_sleep: flexcan2sleepgrp {
> + fsl,pins = <
> + MX93_PAD_GPIO_IO25__GPIO2_IO25 0x31e
> + MX93_PAD_GPIO_IO27__GPIO2_IO27 0x31e
> + >;
> + };
> +
> + pinctrl_lpi2c1: lpi2c1grp {
> + fsl,pins = <
> + MX93_PAD_I2C1_SCL__LPI2C1_SCL 0x40000b9e
> + MX93_PAD_I2C1_SDA__LPI2C1_SDA 0x40000b9e
> + >;
> + };
> +
> + pinctrl_lpi2c2: lpi2c2grp {
> + fsl,pins = <
> + MX93_PAD_I2C2_SCL__LPI2C2_SCL 0x40000b9e
> + MX93_PAD_I2C2_SDA__LPI2C2_SDA 0x40000b9e
> + >;
> + };
> +
> + pinctrl_lpi2c3: lpi2c3grp {
> + fsl,pins = <
> + MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
> + MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
> + >;
> + };
> +
> + pinctrl_pcal6524: pcal6524grp {
> + fsl,pins = <
> + MX93_PAD_CCM_CLKO2__GPIO3_IO27 0x31e
> + >;
> + };
> +
> + pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
> + fsl,pins = <
> + MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x31e
> + >;
> + };
> +
> + pinctrl_uart1: uart1grp {
> + fsl,pins = <
> + MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
> + MX93_PAD_UART1_TXD__LPUART1_TX 0x31e
> + >;
> + };
> +
> + pinctrl_uart5: uart5grp {
> + fsl,pins = <
> + MX93_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e
> + MX93_PAD_DAP_TDI__LPUART5_RX 0x31e
> + MX93_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e
> + MX93_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
> + >;
> + };
> +
> + /* need to config the SION for data and cmd pad, refer to ERR052021 */
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + MX93_PAD_SD1_CLK__USDHC1_CLK 0x1582
> + MX93_PAD_SD1_CMD__USDHC1_CMD 0x40001382
> + MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x40001382
> + MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x40001382
> + MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x40001382
> + MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x40001382
> + MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x40001382
> + MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x40001382
> + MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x40001382
> + MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x40001382
> + MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x1582
> + >;
> + };
> +
> + /* need to config the SION for data and cmd pad, refer to ERR052021 */
> + pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
> + fsl,pins = <
> + MX93_PAD_SD1_CLK__USDHC1_CLK 0x158e
> + MX93_PAD_SD1_CMD__USDHC1_CMD 0x4000138e
> + MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000138e
> + MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000138e
> + MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000138e
> + MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000138e
> + MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000138e
> + MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000138e
> + MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000138e
> + MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000138e
> + MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
> + >;
> + };
> +
> + /* need to config the SION for data and cmd pad, refer to ERR052021 */
> + pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
> + fsl,pins = <
> + MX93_PAD_SD1_CLK__USDHC1_CLK 0x15fe
> + MX93_PAD_SD1_CMD__USDHC1_CMD 0x400013fe
> + MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x400013fe
> + MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x400013fe
> + MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x400013fe
> + MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x400013fe
> + MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x400013fe
> + MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x400013fe
> + MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x400013fe
> + MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x400013fe
> + MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
> + >;
> + };
> +
> + pinctrl_usdhc2_gpio: usdhc2gpiogrp {
> + fsl,pins = <
> + MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e
> + >;
> + };
> +
> + pinctrl_usdhc2_gpio_sleep: usdhc2gpiosleepgrp {
> + fsl,pins = <
> + MX93_PAD_SD2_CD_B__GPIO3_IO00 0x51e
> + >;
> + };
> +
> + /* need to config the SION for data and cmd pad, refer to ERR052021 */
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582
> + MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382
> + MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382
> + MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382
> + MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382
> + MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382
> + MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
> + >;
> + };
> +
> + /* need to config the SION for data and cmd pad, refer to ERR052021 */
> + pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
> + fsl,pins = <
> + MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e
> + MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e
> + MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e
> + MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e
> + MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e
> + MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e
> + MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
> + >;
> + };
> +
> + /* need to config the SION for data and cmd pad, refer to ERR052021 */
> + pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
> + fsl,pins = <
> + MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe
> + MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe
> + MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe
> + MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe
> + MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe
> + MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe
> + MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
> + >;
> + };
> +
> + pinctrl_usdhc2_sleep: usdhc2-sleepgrp {
> + fsl,pins = <
> + MX93_PAD_SD2_CLK__GPIO3_IO01 0x51e
> + MX93_PAD_SD2_CMD__GPIO3_IO02 0x51e
> + MX93_PAD_SD2_DATA0__GPIO3_IO03 0x51e
> + MX93_PAD_SD2_DATA1__GPIO3_IO04 0x51e
> + MX93_PAD_SD2_DATA2__GPIO3_IO05 0x51e
> + MX93_PAD_SD2_DATA3__GPIO3_IO06 0x51e
> + MX93_PAD_SD2_VSELECT__GPIO3_IO19 0x51e
> + >;
> + };
> +
> + pinctrl_wdog: wdoggrp {
> + fsl,pins = <
> + MX93_PAD_WDOG_ANY__WDOG1_WDOG_ANY 0x31e
> + >;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
> index bd14ba28690c081817111aaabef12fb56a7c56a4..f2a31a0eacabff07532aee989eebd75a0c3e22e0 100644
> --- a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
> @@ -1,71 +1,14 @@
> // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> /dts-v1/;
>
> -#include <dt-bindings/usb/pd.h>
> #include "imx93.dtsi"
> +#include "imx93-11x11-frdm-common.dtsi"
>
> / {
> compatible = "fsl,imx93-11x11-frdm", "fsl,imx93";
> model = "NXP i.MX93 11X11 FRDM board";
>
> - aliases {
> - can0 = &flexcan2;
> - ethernet0 = &fec;
> - ethernet1 = &eqos;
> - i2c0 = &lpi2c1;
> - i2c1 = &lpi2c2;
> - i2c2 = &lpi2c3;
> - mmc0 = &usdhc1; /* EMMC */
> - mmc1 = &usdhc2; /* uSD */
> - rtc0 = &pcf2131;
> - serial0 = &lpuart1;
> - serial4 = &lpuart5;
> - };
> -
> - chosen {
> - stdout-path = &lpuart1;
> - };
> -
> - flexcan2_phy: can-phy {
> - compatible = "nxp,tja1051";
> - #phy-cells = <0>;
> - max-bitrate = <5000000>;
> - silent-gpios = <&pcal6524 23 GPIO_ACTIVE_HIGH>;
> - };
> -
> - gpio-keys {
> - compatible = "gpio-keys";
> -
> - button-k2 {
> - label = "Button K2";
> - linux,code = <BTN_1>;
> - gpios = <&pcal6524 5 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> - interrupt-parent = <&pcal6524>;
> - interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
> - };
> -
> - button-k3 {
> - label = "Button K3";
> - linux,code = <BTN_2>;
> - gpios = <&pcal6524 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> - interrupt-parent = <&pcal6524>;
> - interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
> - };
> - };
> -
> - reg_usdhc2_vmmc: regulator-usdhc2 {
> - compatible = "regulator-fixed";
> - off-on-delay-us = <12000>;
> - pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
> - pinctrl-names = "default";
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-name = "VSD_3V3";
> - vin-supply = <&buck4>;
> - gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
> - enable-active-high;
> - };
> -
> reg_usdhc3_vmmc: regulator-usdhc3 {
> compatible = "regulator-fixed";
> regulator-name = "VPCIe_3V3";
> @@ -76,51 +19,6 @@ reg_usdhc3_vmmc: regulator-usdhc3 {
> enable-active-high;
> };
>
> - reserved-memory {
> - ranges;
> - #address-cells = <2>;
> - #size-cells = <2>;
> -
> - linux,cma {
> - compatible = "shared-dma-pool";
> - alloc-ranges = <0 0x80000000 0 0x30000000>;
> - reusable;
> - size = <0 0x10000000>;
> - linux,cma-default;
> - };
> -
> - rsc_table: rsc-table@2021e000 {
> - reg = <0 0x2021e000 0 0x1000>;
> - no-map;
> - };
> -
> - vdev0vring0: vdev0vring0@a4000000 {
> - reg = <0 0xa4000000 0 0x8000>;
> - no-map;
> - };
> -
> - vdev0vring1: vdev0vring1@a4008000 {
> - reg = <0 0xa4008000 0 0x8000>;
> - no-map;
> - };
> -
> - vdev1vring0: vdev1vring0@a4010000 {
> - reg = <0 0xa4010000 0 0x8000>;
> - no-map;
> - };
> -
> - vdev1vring1: vdev1vring1@a4018000 {
> - reg = <0 0xa4018000 0 0x8000>;
> - no-map;
> - };
> -
> - vdevbuffer: vdevbuffer@a4020000 {
> - compatible = "shared-dma-pool";
> - reg = <0 0xa4020000 0 0x100000>;
> - no-map;
> - };
> - };
> -
> sound-mqs {
> compatible = "fsl,imx-audio-mqs";
> model = "mqs-audio";
> @@ -134,269 +32,6 @@ usdhc3_pwrseq: mmc-pwrseq {
> };
> };
>
> -&adc1 {
> - vref-supply = <&buck5>;
> - status = "okay";
> -};
> -
> -&mu1 {
> - status = "okay";
> -};
> -
> -&cm33 {
> - mboxes = <&mu1 0 1>,
> - <&mu1 1 1>,
> - <&mu1 3 1>;
> - mbox-names = "tx", "rx", "rxdb";
> - memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
> - <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
> - status = "okay";
> -};
> -
> -&eqos {
> - pinctrl-names = "default", "sleep";
> - pinctrl-0 = <&pinctrl_eqos>;
> - pinctrl-1 = <&pinctrl_eqos_sleep>;
> - phy-handle = <ðphy1>;
> - phy-mode = "rgmii-id";
> - status = "okay";
> -
> - mdio {
> - compatible = "snps,dwmac-mdio";
> - #address-cells = <1>;
> - #size-cells = <0>;
> - clock-frequency = <5000000>;
> -
> - ethphy1: ethernet-phy@1 {
> - reg = <1>;
> - reset-assert-us = <10000>;
> - reset-deassert-us = <80000>;
> - reset-gpios = <&pcal6524 15 GPIO_ACTIVE_LOW>;
> - realtek,clkout-disable;
> - };
> - };
> -};
> -
> -&fec {
> - pinctrl-names = "default", "sleep";
> - pinctrl-0 = <&pinctrl_fec>;
> - pinctrl-1 = <&pinctrl_fec_sleep>;
> - phy-mode = "rgmii-id";
> - phy-handle = <ðphy2>;
> - fsl,magic-packet;
> - status = "okay";
> -
> - mdio {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - clock-frequency = <5000000>;
> -
> - ethphy2: ethernet-phy@2 {
> - reg = <2>;
> - reset-assert-us = <10000>;
> - reset-deassert-us = <80000>;
> - reset-gpios = <&pcal6524 16 GPIO_ACTIVE_LOW>;
> - realtek,clkout-disable;
> - };
> - };
> -};
> -
> -&flexcan2 {
> - phys = <&flexcan2_phy>;
> - pinctrl-0 = <&pinctrl_flexcan2>;
> - pinctrl-1 = <&pinctrl_flexcan2_sleep>;
> - pinctrl-names = "default", "sleep";
> - status = "okay";
> -};
> -
> -&lpi2c1 {
> - clock-frequency = <400000>;
> - pinctrl-0 = <&pinctrl_lpi2c1>;
> - pinctrl-names = "default";
> - status = "okay";
> -
> - pcal6408: gpio@20 {
> - compatible = "nxp,pcal6408";
> - reg = <0x20>;
> - #gpio-cells = <2>;
> - gpio-controller;
> - reset-gpios = <&pcal6524 20 GPIO_ACTIVE_LOW>;
> - };
> -};
> -
> -&lpi2c2 {
> - clock-frequency = <400000>;
> - pinctrl-0 = <&pinctrl_lpi2c2>;
> - pinctrl-names = "default";
> - status = "okay";
> -
> - pcal6524: gpio@22 {
> - compatible = "nxp,pcal6524";
> - reg = <0x22>;
> - #interrupt-cells = <2>;
> - interrupt-controller;
> - interrupt-parent = <&gpio3>;
> - interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> - #gpio-cells = <2>;
> - gpio-controller;
> - pinctrl-0 = <&pinctrl_pcal6524>;
> - pinctrl-names = "default";
> - /* does not boot with supplier set, because it is the bucks interrupt parent */
> - /* vcc-supply = <&buck4>; */
> - };
> -
> - pmic@25 {
> - compatible = "nxp,pca9451a";
> - reg = <0x25>;
> - interrupt-parent = <&pcal6524>;
> - interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
> -
> - regulators {
> -
> - buck1: BUCK1 {
> - regulator-name = "VDD_SOC_0V8";
> - regulator-min-microvolt = <610000>;
> - regulator-max-microvolt = <950000>;
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-ramp-delay = <3125>;
> - };
> -
> - buck2: BUCK2 {
> - regulator-name = "LPD4_x_VDDQ_0V6";
> - regulator-min-microvolt = <600000>;
> - regulator-max-microvolt = <670000>;
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-ramp-delay = <3125>;
> - };
> -
> - buck4: BUCK4 {
> - regulator-name = "VDD_3V3";
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - buck5: BUCK5 {
> - regulator-name = "VDD_1V8";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - buck6: BUCK6 {
> - regulator-name = "LPD4_x_VDD2_1V1";
> - regulator-min-microvolt = <1060000>;
> - regulator-max-microvolt = <1140000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - ldo1: LDO1 {
> - regulator-name = "NVCC_BBSM_1V8";
> - regulator-min-microvolt = <1620000>;
> - regulator-max-microvolt = <1980000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - ldo4: LDO4 {
> - regulator-name = "VDD_ANA_0V8";
> - regulator-min-microvolt = <800000>;
> - regulator-max-microvolt = <840000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - ldo5: LDO5 {
> - regulator-name = "NVCC_SD";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> - };
> - };
> -
> - eeprom: eeprom@50 {
> - compatible = "atmel,24c256";
> - reg = <0x50>;
> - pagesize = <64>;
> - vcc-supply = <&buck4>;
> - };
> -};
> -
> -&lpi2c3 {
> - clock-frequency = <400000>;
> - pinctrl-0 = <&pinctrl_lpi2c3>;
> - pinctrl-names = "default";
> - status = "okay";
> -
> - ptn5110: tcpc@50 {
> - compatible = "nxp,ptn5110", "tcpci";
> - reg = <0x50>;
> - interrupt-parent = <&gpio3>;
> - interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> -
> - typec1_con: connector {
> - compatible = "usb-c-connector";
> - data-role = "dual";
> - label = "USB-C";
> - op-sink-microwatt = <15000000>;
> - power-role = "dual";
> - self-powered;
> - sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
> - PDO_VAR(5000, 20000, 3000)>;
> - source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> - try-power-role = "sink";
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> -
> - typec1_dr_sw: endpoint {
> - remote-endpoint = <&usb1_drd_sw>;
> - };
> - };
> - };
> - };
> - };
> -
> - pcf2131: rtc@53 {
> - compatible = "nxp,pcf2131";
> - reg = <0x53>;
> - interrupt-parent = <&pcal6524>;
> - interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
> - };
> -};
> -
> -&lpuart1 { /* console */
> - pinctrl-0 = <&pinctrl_uart1>;
> - pinctrl-names = "default";
> - status = "okay";
> -};
> -
> -&lpuart5 {
> - pinctrl-0 = <&pinctrl_uart5>;
> - pinctrl-names = "default";
> - status = "okay";
> -
> - uart-has-rtscts;
> -
> - bluetooth {
> - compatible = "nxp,88w8987-bt";
> - device-wakeup-gpios = <&pcal6408 3 GPIO_ACTIVE_HIGH>;
> - reset-gpios = <&pcal6524 19 GPIO_ACTIVE_LOW>;
> - vcc-supply = <®_usdhc3_vmmc>;
> - };
> -};
> -
> &mqs1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_mqs1>;
> @@ -418,57 +53,6 @@ &sai1 {
> status = "okay";
> };
>
> -&usbotg1 {
> - adp-disable;
> - disable-over-current;
> - dr_mode = "otg";
> - hnp-disable;
> - srp-disable;
> - usb-role-switch;
> - samsung,picophy-dc-vol-level-adjust = <7>;
> - samsung,picophy-pre-emp-curr-control = <3>;
> - status = "okay";
> -
> - port {
> - usb1_drd_sw: endpoint {
> - remote-endpoint = <&typec1_dr_sw>;
> - };
> - };
> -};
> -
> -&usbotg2 {
> - disable-over-current;
> - dr_mode = "host";
> - samsung,picophy-dc-vol-level-adjust = <7>;
> - samsung,picophy-pre-emp-curr-control = <3>;
> - status = "okay";
> -};
> -
> -&usdhc1 {
> - bus-width = <8>;
> - non-removable;
> - pinctrl-0 = <&pinctrl_usdhc1>;
> - pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
> - pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
> - pinctrl-names = "default", "state_100mhz", "state_200mhz";
> - vmmc-supply = <&buck4>;
> - status = "okay";
> -};
> -
> -&usdhc2 {
> - bus-width = <4>;
> - cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
> - no-mmc;
> - no-sdio;
> - pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> - pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> - pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> - pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_usdhc2_gpio_sleep>;
> - pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> - vmmc-supply = <®_usdhc2_vmmc>;
> - status = "okay";
> -};
> -
> &usdhc3 {
> bus-width = <4>;
> keep-power-in-suspend;
> @@ -483,126 +67,8 @@ &usdhc3 {
> status = "okay";
> };
>
> -&wdog3 {
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_wdog>;
> - fsl,ext-reset-output;
> - status = "okay";
> -};
>
> &iomuxc {
> -
> - pinctrl_eqos: eqosgrp {
> - fsl,pins = <
> - MX93_PAD_ENET1_MDC__ENET_QOS_MDC 0x57e
> - MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO 0x57e
> - MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0 0x57e
> - MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e
> - MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e
> - MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e
> - MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x58e
> - MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e
> - MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e
> - MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1 0x57e
> - MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e
> - MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e
> - MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x58e
> - MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e
> - >;
> - };
> -
> - pinctrl_eqos_sleep: eqossleepgrp {
> - fsl,pins = <
> - MX93_PAD_ENET1_MDC__GPIO4_IO00 0x31e
> - MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x31e
> - MX93_PAD_ENET1_RD0__GPIO4_IO10 0x31e
> - MX93_PAD_ENET1_RD1__GPIO4_IO11 0x31e
> - MX93_PAD_ENET1_RD2__GPIO4_IO12 0x31e
> - MX93_PAD_ENET1_RD3__GPIO4_IO13 0x31e
> - MX93_PAD_ENET1_RXC__GPIO4_IO09 0x31e
> - MX93_PAD_ENET1_RX_CTL__GPIO4_IO08 0x31e
> - MX93_PAD_ENET1_TD0__GPIO4_IO05 0x31e
> - MX93_PAD_ENET1_TD1__GPIO4_IO04 0x31e
> - MX93_PAD_ENET1_TD2__GPIO4_IO03 0x31e
> - MX93_PAD_ENET1_TD3__GPIO4_IO02 0x31e
> - MX93_PAD_ENET1_TXC__GPIO4_IO07 0x31e
> - MX93_PAD_ENET1_TX_CTL__GPIO4_IO06 0x31e
> - >;
> - };
> -
> - pinctrl_fec: fecgrp {
> - fsl,pins = <
> - MX93_PAD_ENET2_MDC__ENET1_MDC 0x57e
> - MX93_PAD_ENET2_MDIO__ENET1_MDIO 0x57e
> - MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0 0x57e
> - MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1 0x57e
> - MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2 0x57e
> - MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3 0x57e
> - MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC 0x58e
> - MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL 0x57e
> - MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0 0x57e
> - MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1 0x57e
> - MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2 0x57e
> - MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3 0x57e
> - MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC 0x58e
> - MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
> - >;
> - };
> -
> - pinctrl_fec_sleep: fecsleepgrp {
> - fsl,pins = <
> - MX93_PAD_ENET2_MDC__GPIO4_IO14 0x51e
> - MX93_PAD_ENET2_MDIO__GPIO4_IO15 0x51e
> - MX93_PAD_ENET2_RD0__GPIO4_IO24 0x51e
> - MX93_PAD_ENET2_RD1__GPIO4_IO25 0x51e
> - MX93_PAD_ENET2_RD2__GPIO4_IO26 0x51e
> - MX93_PAD_ENET2_RD3__GPIO4_IO27 0x51e
> - MX93_PAD_ENET2_RXC__GPIO4_IO23 0x51e
> - MX93_PAD_ENET2_RX_CTL__GPIO4_IO22 0x51e
> - MX93_PAD_ENET2_TD0__GPIO4_IO19 0x51e
> - MX93_PAD_ENET2_TD1__GPIO4_IO18 0x51e
> - MX93_PAD_ENET2_TD2__GPIO4_IO17 0x51e
> - MX93_PAD_ENET2_TD3__GPIO4_IO16 0x51e
> - MX93_PAD_ENET2_TXC__GPIO4_IO21 0x51e
> - MX93_PAD_ENET2_TX_CTL__GPIO4_IO20 0x51e
> - >;
> - };
> -
> - pinctrl_flexcan2: flexcan2grp {
> - fsl,pins = <
> - MX93_PAD_GPIO_IO25__CAN2_TX 0x139e
> - MX93_PAD_GPIO_IO27__CAN2_RX 0x139e
> - >;
> - };
> -
> - pinctrl_flexcan2_sleep: flexcan2sleepgrp {
> - fsl,pins = <
> - MX93_PAD_GPIO_IO25__GPIO2_IO25 0x31e
> - MX93_PAD_GPIO_IO27__GPIO2_IO27 0x31e
> - >;
> - };
> -
> - pinctrl_lpi2c1: lpi2c1grp {
> - fsl,pins = <
> - MX93_PAD_I2C1_SCL__LPI2C1_SCL 0x40000b9e
> - MX93_PAD_I2C1_SDA__LPI2C1_SDA 0x40000b9e
> - >;
> - };
> -
> - pinctrl_lpi2c2: lpi2c2grp {
> - fsl,pins = <
> - MX93_PAD_I2C2_SCL__LPI2C2_SCL 0x40000b9e
> - MX93_PAD_I2C2_SDA__LPI2C2_SDA 0x40000b9e
> - >;
> - };
> -
> - pinctrl_lpi2c3: lpi2c3grp {
> - fsl,pins = <
> - MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
> - MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
> - >;
> - };
> -
> pinctrl_mqs1: mqs1grp {
> fsl,pins = <
> MX93_PAD_PDM_CLK__MQS1_LEFT 0x31e
> @@ -610,149 +76,7 @@ MX93_PAD_PDM_BIT_STREAM0__MQS1_RIGHT 0x31e
> >;
> };
>
> - pinctrl_pcal6524: pcal6524grp {
> - fsl,pins = <
> - MX93_PAD_CCM_CLKO2__GPIO3_IO27 0x31e
> - >;
> - };
> -
> - pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
> - fsl,pins = <
> - MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x31e
> - >;
> - };
> -
> - pinctrl_uart1: uart1grp {
> - fsl,pins = <
> - MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
> - MX93_PAD_UART1_TXD__LPUART1_TX 0x31e
> - >;
> - };
> -
> - pinctrl_uart5: uart5grp {
> - fsl,pins = <
> - MX93_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e
> - MX93_PAD_DAP_TDI__LPUART5_RX 0x31e
> - MX93_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e
> - MX93_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
> - >;
> - };
> -
> - /* need to config the SION for data and cmd pad, refer to ERR052021 */
> - pinctrl_usdhc1: usdhc1grp {
> - fsl,pins = <
> - MX93_PAD_SD1_CLK__USDHC1_CLK 0x1582
> - MX93_PAD_SD1_CMD__USDHC1_CMD 0x40001382
> - MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x40001382
> - MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x40001382
> - MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x40001382
> - MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x40001382
> - MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x40001382
> - MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x40001382
> - MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x40001382
> - MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x40001382
> - MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x1582
> - >;
> - };
> -
> - /* need to config the SION for data and cmd pad, refer to ERR052021 */
> - pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
> - fsl,pins = <
> - MX93_PAD_SD1_CLK__USDHC1_CLK 0x158e
> - MX93_PAD_SD1_CMD__USDHC1_CMD 0x4000138e
> - MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000138e
> - MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000138e
> - MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000138e
> - MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000138e
> - MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000138e
> - MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000138e
> - MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000138e
> - MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000138e
> - MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
> - >;
> - };
> -
> - /* need to config the SION for data and cmd pad, refer to ERR052021 */
> - pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
> - fsl,pins = <
> - MX93_PAD_SD1_CLK__USDHC1_CLK 0x15fe
> - MX93_PAD_SD1_CMD__USDHC1_CMD 0x400013fe
> - MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x400013fe
> - MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x400013fe
> - MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x400013fe
> - MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x400013fe
> - MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x400013fe
> - MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x400013fe
> - MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x400013fe
> - MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x400013fe
> - MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
> - >;
> - };
> -
> - pinctrl_usdhc2_gpio: usdhc2gpiogrp {
> - fsl,pins = <
> - MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e
> - >;
> - };
> -
> - pinctrl_usdhc2_gpio_sleep: usdhc2gpiosleepgrp {
> - fsl,pins = <
> - MX93_PAD_SD2_CD_B__GPIO3_IO00 0x51e
> - >;
> - };
> -
> - /* need to config the SION for data and cmd pad, refer to ERR052021 */
> - pinctrl_usdhc2: usdhc2grp {
> - fsl,pins = <
> - MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582
> - MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382
> - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382
> - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382
> - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382
> - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382
> - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
> - >;
> - };
> -
> /* need to config the SION for data and cmd pad, refer to ERR052021 */
> - pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
> - fsl,pins = <
> - MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e
> - MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e
> - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e
> - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e
> - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e
> - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e
> - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
> - >;
> - };
> -
> - /* need to config the SION for data and cmd pad, refer to ERR052021 */
> - pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
> - fsl,pins = <
> - MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe
> - MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe
> - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe
> - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe
> - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe
> - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe
> - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
> - >;
> - };
> -
> - pinctrl_usdhc2_sleep: usdhc2-sleepgrp {
> - fsl,pins = <
> - MX93_PAD_SD2_CLK__GPIO3_IO01 0x51e
> - MX93_PAD_SD2_CMD__GPIO3_IO02 0x51e
> - MX93_PAD_SD2_DATA0__GPIO3_IO03 0x51e
> - MX93_PAD_SD2_DATA1__GPIO3_IO04 0x51e
> - MX93_PAD_SD2_DATA2__GPIO3_IO05 0x51e
> - MX93_PAD_SD2_DATA3__GPIO3_IO06 0x51e
> - MX93_PAD_SD2_VSELECT__GPIO3_IO19 0x51e
> - >;
> - };
> -
> - /* need to config the SION for data and cmd pad, refer to ERR052021 */
> pinctrl_usdhc3: usdhc3grp {
> fsl,pins = <
> MX93_PAD_SD3_CLK__USDHC3_CLK 0x1582
> @@ -798,10 +122,4 @@ MX93_PAD_SD3_DATA2__GPIO3_IO24 0x31e
> MX93_PAD_SD3_DATA3__GPIO3_IO25 0x31e
> >;
> };
> -
> - pinctrl_wdog: wdoggrp {
> - fsl,pins = <
> - MX93_PAD_WDOG_ANY__WDOG1_WDOG_ANY 0x31e
> - >;
> - };
> };
>
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v2] PCI: imx6: Add runtime PM support for i.MX95
From: Frank Li @ 2026-07-17 16:30 UTC (permalink / raw)
To: hongxing.zhu
Cc: frank.li, l.stach, lpieralisi, kwilczynski, mani, robh, bhelgaas,
s.hauer, kernel, festevam, linux-pci, linux-arm-kernel, imx,
linux-kernel, Richard Zhu
In-Reply-To: <20260708035928.580236-1-hongxing.zhu@oss.nxp.com>
On Wed, Jul 08, 2026 at 11:59:26AM +0800, hongxing.zhu@oss.nxp.com wrote:
> From: Richard Zhu <hongxing.zhu@nxp.com>
>
> Enable runtime PM support for i.MX95 PCIe Root Complex to allow dynamic
> power management when the PCIe link is idle.
>
> The i.MX95 PCIe controller supports entering D3hot state when PCIe
> devices are not actively in use. This implementation uses
> pm_runtime_no_callbacks() to leverage the PCI core's generic runtime PM
> handling. The PCI core automatically manages D-state transitions based
> on the runtime PM state of connected endpoint devices.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Changes in v2:
> Use devm_pm_runtime_set_active_enabled() simplify the codes and error
> path.
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index eae495a1b7990..578410f262aed 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -130,6 +130,7 @@ enum imx_pcie_variants {
> #define IMX_PCIE_FLAG_SKIP_L23_READY BIT(12)
> /* Preserve MSI capability for platforms that require it */
> #define IMX_PCIE_FLAG_KEEP_MSI_CAP BIT(13)
> +#define IMX_PCIE_FLAG_PM_RUNTIME BIT(14)
>
> #define imx_check_flag(pci, val) (pci->drvdata->flags & val)
>
> @@ -1973,6 +1974,13 @@ static int imx_pcie_probe(struct platform_device *pdev)
> */
> imx_pcie_add_lut_by_rid(imx_pcie, 0);
> } else {
> + if (imx_pcie->drvdata->flags & IMX_PCIE_FLAG_PM_RUNTIME) {
> + pm_runtime_no_callbacks(dev);
> + ret = devm_pm_runtime_set_active_enabled(dev);
> + if (ret < 0)
> + return ret;
> + }
> +
> /*
> * i.MX RC is powered off during suspend, force L2 entry to
> * ensure proper endpoint notification before power loss.
> @@ -2121,6 +2129,7 @@ static const struct imx_pcie_drvdata drvdata[] = {
> .flags = IMX_PCIE_FLAG_HAS_SERDES |
> IMX_PCIE_FLAG_HAS_LUT |
> IMX_PCIE_FLAG_8GT_ECN_ERR051586 |
> + IMX_PCIE_FLAG_PM_RUNTIME |
> IMX_PCIE_FLAG_SUPPORTS_SUSPEND,
> .ltssm_off = IMX95_PE0_GEN_CTRL_3,
> .ltssm_mask = IMX95_PCIE_LTSSM_EN,
> --
> 2.34.1
>
>
^ permalink raw reply
* [PATCH v2 0/7] Properly describe mt8167 watchdog and mmsys resets
From: Luca Leonardo Scorcia @ 2026-07-17 16:39 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Wim Van Sebroeck, Guenter Roeck,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Philipp Zabel, linux-watchdog,
devicetree, linux-kernel, linux-arm-kernel
Currently mt8167 inherits its watchdog from the included mt8516 dtsi,
which in turn falls back on mt6589-wdt. However according to the data
sheet mt8167 has 15 sw resets instead of 12, and the reset bits are
different from mt6589.
In the first two patches we improve the description of the resets for
mt6589 with values obtained from Android sources.
Then we introduce a dedicated mediatek,mt8167-wdt compatible for the
watchdog driver that describes correctly this SoC's resets. Also while
we're touching the bindings reset header, we add constants for the MMSYS
resets.
In the 6th patch we add a node for the mt8167 watchdog referring to the
new compatible in the SoC dtsi.
In the last patch, we define the mmsys reset table for the SoC. According
to the datasheet, there are 28 mmsys reset bits divided across two
adjacent registers.
Changes in v2:
- Sashiko pointed out correctly a missing entry in the mmsys reset table
in the last patch.
Initial version: [1]
[1] https://lore.kernel.org/linux-mediatek/20260717151134.678839-1-l.scorcia@gmail.com/
Luca Leonardo Scorcia (7):
dt-bindings: reset: Add MT6589 toprgu reset IDs
watchdog: mediatek: Add wdt/toprgu resets for MT6589
dt-bindings: watchdog: Add compatible for MediaTek mt8167
dt-bindings: reset: Add reset controller constants for mt8167
watchdog: mediatek: Add support for mt8167 TOPRGU/WDT
arm64: dts: mt8167: Properly describe the SoC watchdog
soc: mediatek: mtk-mmsys: Add resets for mt8167
.../bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
arch/arm64/boot/dts/mediatek/mt8167.dtsi | 7 +++
drivers/soc/mediatek/mt8167-mmsys.h | 41 ++++++++++++++
drivers/soc/mediatek/mtk-mmsys.c | 3 ++
drivers/watchdog/mtk_wdt.c | 13 ++++-
.../reset/mediatek,mt6589-resets.h | 24 +++++++++
.../reset/mediatek,mt8167-resets.h | 53 +++++++++++++++++++
7 files changed, 141 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/reset/mediatek,mt6589-resets.h
create mode 100644 include/dt-bindings/reset/mediatek,mt8167-resets.h
--
2.43.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox