* Re: [PATCH v4 12/21] misc: open-dice: replace deprecated mmap hook with mmap_prepare
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:04 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <5a83ab00195dc8d0609fa6cc525493010ac4ead1.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> The f_op->mmap interface is deprecated, so update driver to use its
> successor, mmap_prepare.
>
> The driver previously used vm_iomap_memory(), so this change replaces it
> with its mmap_prepare equivalent, mmap_action_simple_ioremap().
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> drivers/misc/open-dice.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/misc/open-dice.c b/drivers/misc/open-dice.c
> index 24c29e0f00ef..45060fb4ea27 100644
> --- a/drivers/misc/open-dice.c
> +++ b/drivers/misc/open-dice.c
> @@ -86,29 +86,32 @@ static ssize_t open_dice_write(struct file *filp, const char __user *ptr,
> /*
> * Creates a mapping of the reserved memory region in user address space.
> */
> -static int open_dice_mmap(struct file *filp, struct vm_area_struct *vma)
> +static int open_dice_mmap_prepare(struct vm_area_desc *desc)
> {
> + struct file *filp = desc->file;
> struct open_dice_drvdata *drvdata = to_open_dice_drvdata(filp);
>
> - if (vma->vm_flags & VM_MAYSHARE) {
> + if (vma_desc_test(desc, VMA_MAYSHARE_BIT)) {
> /* Do not allow userspace to modify the underlying data. */
> - if (vma->vm_flags & VM_WRITE)
> + if (vma_desc_test(desc, VMA_WRITE_BIT))
> return -EPERM;
> /* Ensure userspace cannot acquire VM_WRITE later. */
> - vm_flags_clear(vma, VM_MAYWRITE);
> + vma_desc_clear_flags(desc, VMA_MAYWRITE_BIT);
> }
>
> /* Create write-combine mapping so all clients observe a wipe. */
> - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> - vm_flags_set(vma, VM_DONTCOPY | VM_DONTDUMP);
> - return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> + desc->page_prot = pgprot_writecombine(desc->page_prot);
> + vma_desc_set_flags(desc, VMA_DONTCOPY_BIT, VMA_DONTDUMP_BIT);
> + mmap_action_simple_ioremap(desc, drvdata->rmem->base,
> + drvdata->rmem->size);
> + return 0;
> }
>
> static const struct file_operations open_dice_fops = {
> .owner = THIS_MODULE,
> .read = open_dice_read,
> .write = open_dice_write,
> - .mmap = open_dice_mmap,
> + .mmap_prepare = open_dice_mmap_prepare,
> };
>
> static int __init open_dice_probe(struct platform_device *pdev)
^ permalink raw reply
* [PATCH] gpio: fix up CONFIG_OF dependencies
From: Arnd Bergmann @ 2026-03-25 10:01 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Arnd Bergmann, Yixun Lan, Matthias Brugger,
AngeloGioacchino Del Regno, linux-gpio, linux-kernel, linux-riscv,
spacemit, linux-arm-kernel, linux-mediatek
From: Arnd Bergmann <arnd@arndb.de>
A number of GPIO drivers that used to have a CONFIG_OF_GPIO dependency now fail
to build on targets without CONFIG_OF:
WARNING: unmet direct dependencies detected for GPIO_SYSCON
Depends on [n]: GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && OF [=n]
Selected by [y]:
- GPIO_SAMA5D2_PIOBU [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && (ARCH_AT91 || COMPILE_TEST [=y])
drivers/gpio/gpio-mt7621.c: In function 'mediatek_gpio_bank_probe':
drivers/gpio/gpio-mt7621.c:254:20: error: 'struct gpio_chip' has no member named 'of_gpio_n_cells'
254 | rg->chip.gc.of_gpio_n_cells = 2;
| ^
drivers/gpio/gpio-tegra186.c: In function 'tegra186_gpio_of_xlate':
drivers/gpio/gpio-tegra186.c:502:25: error: 'struct gpio_chip' has no member named 'of_gpio_n_cells'
502 | if (WARN_ON(chip->of_gpio_n_cells < 2))
| ^~
drivers/gpio/gpio-lpc32xx.c: In function 'lpc32xx_gpio_probe':
drivers/gpio/gpio-lpc32xx.c:523:49: error: 'struct gpio_chip' has no member named 'of_xlate'
523 | lpc32xx_gpiochip[i].chip.of_xlate = lpc32xx_of_xlate;
| ^
drivers/gpio/gpio-spacemit-k1.c: In function 'spacemit_gpio_add_bank':
drivers/gpio/gpio-spacemit-k1.c:234:11: error: 'struct gpio_chip' has no member named 'of_gpio_n_cells'
234 | gc->of_gpio_n_cells = 3;
| ^~
Bring that back as a dependency.
Fixes: 7803501e5754 ("gpio: drop unneeded Kconfig dependencies on OF_GPIO")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
There may be more fallout from the change, this is just what I found immediately,
but you could already fold the changes into the broken patch while I look
for additional ones.
---
drivers/gpio/Kconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index e1e48e432133..bcb8ce89396c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -236,6 +236,7 @@ config GPIO_BRCMSTB
tristate "BRCMSTB GPIO support"
default y if (ARCH_BRCMSTB || BMIPS_GENERIC)
depends on ARCH_BRCMSTB || ARCH_BCM2835 || BMIPS_GENERIC || COMPILE_TEST
+ depends on OF
select GPIO_GENERIC
select IRQ_DOMAIN
help
@@ -450,6 +451,7 @@ config GPIO_LPC18XX
config GPIO_LPC32XX
tristate "NXP LPC32XX GPIO support"
depends on ARCH_LPC32XX || COMPILE_TEST
+ depends on OF
help
Select this option to enable GPIO driver for
NXP LPC32XX devices.
@@ -492,6 +494,7 @@ config GPIO_MPC8XXX
config GPIO_MT7621
bool "Mediatek MT7621 GPIO Support"
depends on SOC_MT7620 || SOC_MT7621 || COMPILE_TEST
+ depends on OF
select GPIO_GENERIC
select GPIOLIB_IRQCHIP
help
@@ -632,6 +635,7 @@ config GPIO_RTD
config GPIO_SAMA5D2_PIOBU
tristate "SAMA5D2 PIOBU GPIO support"
+ depends on OF
depends on MFD_SYSCON
depends on ARCH_AT91 || COMPILE_TEST
select GPIO_SYSCON
@@ -672,6 +676,7 @@ config GPIO_SNPS_CREG
config GPIO_SPACEMIT_K1
tristate "SPACEMIT K1 GPIO support"
depends on ARCH_SPACEMIT || COMPILE_TEST
+ depends on OF
select GPIO_GENERIC
select GPIOLIB_IRQCHIP
help
@@ -737,6 +742,7 @@ config GPIO_TEGRA186
tristate "NVIDIA Tegra186 GPIO support"
default ARCH_TEGRA_186_SOC || ARCH_TEGRA_194_SOC || ARCH_TEGRA_234_SOC
depends on ARCH_TEGRA_186_SOC || ARCH_TEGRA_194_SOC || ARCH_TEGRA_234_SOC || COMPILE_TEST
+ depends on OF
select GPIOLIB_IRQCHIP
select IRQ_DOMAIN_HIERARCHY
help
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Inject UNDEF when host is executing an smc with imm16 != 0
From: Sebastian Ene @ 2026-03-25 10:01 UTC (permalink / raw)
To: Fuad Tabba
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
suzuki.poulose, vdonnefort, will, yuzenghui
In-Reply-To: <CA+EHjTycaE363WXD1f9ztYv9cTe9xeo-3FQ2Ep0aVO4592XGtQ@mail.gmail.com>
On Tue, Mar 24, 2026 at 03:13:51PM +0000, Fuad Tabba wrote:
Hi Fuad,
> Hi Seb,
>
> On Tue, 24 Mar 2026 at 13:57, Sebastian Ene <sebastianene@google.com> wrote:
> >
> > The ARM Service Calling Convention (SMCCC) specifies that the function
> > identifier and parameters should be passed in registers, leaving the
> > 16-bit immediate field of the SMC instruction un-handled.
> > Currently, our pKVM handler ignores the immediate value, which could lead
> > to non-compliant software relying on implementation-defined behavior.
> > Enforce the host kernel running under pKVM to use an immediate value
> > of 0 by decoding the ISS from the ESR_EL2 and inject an undefined
> > instruction exception back to the caller.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index e7790097db93..ff6a90a4a4c7 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -756,13 +756,18 @@ static bool handle_host_mte(u64 esr)
> > void handle_trap(struct kvm_cpu_context *host_ctxt)
> > {
> > u64 esr = read_sysreg_el2(SYS_ESR);
> > + u16 imm16;
> >
> > switch (ESR_ELx_EC(esr)) {
> > case ESR_ELx_EC_HVC64:
> > handle_host_hcall(host_ctxt);
> > break;
> > case ESR_ELx_EC_SMC64:
> > - handle_host_smc(host_ctxt);
> > + imm16 = esr & U16_MAX;
> > + if (!imm16)
>
> Do we need to introduce a new variable for this? This isn't easier to read than:
> + if (!(esr & U16_MAX))
>
> Also, we have a mask for this: ESR_ELx_xVC_IMM_MASK , please use that instead
I will drop that variable and use the ESR_ELx_xVC_IMM_MASK as you pointed out.
>
> Cheers,
> /fuad
>
>
>
> > + handle_host_smc(host_ctxt);
> > + else
> > + inject_undef64();
> > break;
> > case ESR_ELx_EC_IABT_LOW:
> > case ESR_ELx_EC_DABT_LOW:
> > --
> > 2.53.0.983.g0bb29b3bc5-goog
> >
Thanks,
Sebastian
^ permalink raw reply
* Re: [PATCH v4 11/21] mm: add mmap_action_simple_ioremap()
From: Vlastimil Babka (SUSE) @ 2026-03-25 9:58 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <a08ef1c4542202684da63bb37f459d5dbbeddd91.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Currently drivers use vm_iomap_memory() as a simple helper function for
> I/O remapping memory over a range starting at a specified physical address
> over a specified length.
>
> In order to utilise this from mmap_prepare, separate out the core logic
> into __simple_ioremap_prep(), update vm_iomap_memory() to use it, and add
> simple_ioremap_prepare() to do the same with a VMA descriptor object.
>
> We also add MMAP_SIMPLE_IO_REMAP and relevant fields to the struct
> mmap_action type to permit this operation also.
>
> We use mmap_action_ioremap() to set up the actual I/O remap operation once
> we have checked and figured out the parameters, which makes
> simple_ioremap_prepare() easy to implement.
>
> We then add mmap_action_simple_ioremap() to allow drivers to make use of
> this mode.
>
> We update the mmap_prepare documentation to describe this mode. Finally,
> we update the VMA tests to reflect this change.
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/2] net: stmmac: fix pinctrl management during suspend/resume
From: Russell King (Oracle) @ 2026-03-25 9:55 UTC (permalink / raw)
To: Linus Walleij
Cc: Christophe Roullier, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
antonio.borneo, Maxime Chevallier, Vladimir Oltean, netdev,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <CAD++jLm5_mfx1572Cg+NPhuLoPu6DKDfOwK5XxRc4R_8M7kbYw@mail.gmail.com>
On Thu, Mar 19, 2026 at 10:43:25AM +0100, Linus Walleij wrote:
> On Tue, Mar 17, 2026 at 2:11 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> > I'm trying to get an answer on this, because the original patch
> > description here says:
> >
> > | In the deepest low-power modes, the pinctrl configuration is
> > | lost and is never restored if the interface is down.
> >
> > stmmac uses the "default" pinctrl state at probe time. This commit
> > says that is lost over suspend/resume - which to me sounds like
> > a pinctrl driver bug, because on resume, the pinctrl driver is not
> > ensuring that the pinctrl state is restored to whatever it was when
> > the suspend happened (whether the driver explicitly changed it or
> > not.)
> >
> > To put it another way...
> >
> > On entry to probe for a non-pinctrl driver, if DT describes a default
> > pinctrl state, that state will be selected by core code.
> >
> > On suspend, the driver is free to select another state if it so wishes,
> > or do nothing (e.g. it's unaware of pinctrl.)
> >
> > On resume, the pinctrl layer, what is expected to happen. Surely, it
> > is reasonable for a pinctrl unaware driver, or at least a driver which
> > has _not_ changed the pinctrl state to expect that the default pinctrl
> > state is still in effect when its resume function is called - and if
> > that is not the case, then there's a bug here.
> >
> > Another way to put it...
> >
> > We shouldn't be expecting device drivers to have to mess with pinctrl
> > e.g. switching to a sleep state and then back to a default state just
> > to have pinctrl settings restored to a functional state on resume.
>
> OK I see your point, the pinctrl hardware state should not change
> behind the back of the driver, and if it does, and that is worked
> around by these calls to restore the state using the pinctrl PM
> helpers become a messy quirk.
>
> - Selecting those states to reconfigure pins into special modes
> during sleep is OK.
>
> - Selecting those states to restore the hardware state inside the
> pin controller itself is NOT OK.
>
> If this is done for the latter reason, you're right of course, there is
> a bug in the pin controller. Certainly it is expected to maintain its
> own state over a suspend/resume cycle.
Thanks for the clarification. So, going back to the original patch:
"In the deepest low-power modes, the pinctrl configuration is lost
and is never restored if the interface is down.
This commit ensures that the pinctrl state is set in all cases."
This commit message seems to be suggesting that the switch to sleep
mode and back to default mode is to ensure that the pinctrl driver
for this platform correctly re-sets the pinctrl state back to the
default state - which suggests that this patch is the wrong approach
and there is a bug somewhere in the pin controller layer.
That said, for platforms that do provide a sleep state for stmmac, it
makes sense to switch the pinctrl to that state even when the netif
is down. So, I think there's actually two separate issues:
1. the pin controller not restoring the state that was set at suspend.
2. not switching to sleep state when supported when the netif is down.
and fixing (2) will mask (1) which will be bad. So, I think (1) needs
to be fixed first while we have an easy-to-test case, and my suggested
replacement patch is a better approach for (2).
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH 1/3] arm64: dts: freescale: imx95-toradex-smarc: Add SER2 interface
From: Franz Schnyder @ 2026-03-25 9:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel,
Francesco Dolcini, Franz Schnyder
In-Reply-To: <20260325-mainline-update-imx95-v1-0-b5ebe976655b@toradex.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
The Toradex SMARC iMX95 has four exposed serial interfaces, one of these
is SER2, which supports RTS/CTS.
Add UART support for SMARC SER2.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
.../arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts | 5 +++++
arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi | 16 ++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts
index 5b05f256fd52..7437e523ff63 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc-dev.dts
@@ -210,6 +210,11 @@ &lpuart3 {
status = "okay";
};
+/* SMARC SER2 */
+&lpuart6 {
+ status = "okay";
+};
+
/* SMARC MDIO, shared between all ethernet ports */
&netc_emdio {
status = "okay";
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index 7a73958f6eec..1d369983cf7d 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -22,6 +22,7 @@ aliases {
rtc1 = &scmi_bbm;
serial0 = &lpuart2;
serial1 = &lpuart1;
+ serial2 = &lpuart6;
serial3 = &lpuart3;
};
@@ -615,6 +616,13 @@ &lpuart3 {
pinctrl-0 = <&pinctrl_uart3>;
};
+/* SMARC SER2 */
+&lpuart6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart6>;
+ uart-has-rtscts;
+};
+
&mu7 {
status = "okay";
};
@@ -1105,6 +1113,14 @@ pinctrl_uart3: uart3grp {
<IMX95_PAD_GPIO_IO15__LPUART3_RX 0x31e>; /* SMARC P141 - SER3_RX */
};
+ /* SMARC SER2 */
+ pinctrl_uart6: uart6grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO34__LPUART6_CTS_B 0x31e>, /* SMARC P139 - SER2_CTS# */
+ <IMX95_PAD_GPIO_IO07__LPUART6_RTS_B 0x31e>, /* SMARC P138 - SER2_RTS# */
+ <IMX95_PAD_GPIO_IO05__LPUART6_RX 0x31e>, /* SMARC P137 - SER2_RX */
+ <IMX95_PAD_GPIO_IO04__LPUART6_TX 0x31e>; /* SMARC P136 - SER2_TX */
+ };
+
/* On-module eMMC */
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>, /* SD1_CLK */
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: freescale: imx95-toradex-smarc: Enable bluetooth on lpuart5
From: Franz Schnyder @ 2026-03-25 9:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel,
Francesco Dolcini, Franz Schnyder
In-Reply-To: <20260325-mainline-update-imx95-v1-0-b5ebe976655b@toradex.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
The Toradex SMARC iMX95 uses the MAYA-W260 WiFi/Bluetooth module, which
uses the UART interface for Bluetooth.
Add the missing UART support to enable bluetooth functionality on the
MAYA-W260.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
Although Documentation/devicetree/bindings/dts-coding-style.rst
recommends an empty line between status and latest property, leave it
unchanged for consistency with the rest of the file.
---
.../boot/dts/freescale/imx95-toradex-smarc.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index 1d369983cf7d..a90edefc5197 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -616,6 +616,19 @@ &lpuart3 {
pinctrl-0 = <&pinctrl_uart3>;
};
+/* On-module Bluetooth */
+&lpuart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_bt_uart>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ fw-init-baudrate = <3000000>;
+ };
+};
+
/* SMARC SER2 */
&lpuart6 {
pinctrl-names = "default";
@@ -830,6 +843,14 @@ &wdog3 {
};
&scmi_iomuxc {
+ /* On-module Bluetooth, UART pins shared with JTAG */
+ pinctrl_bt_uart: btuartgrp {
+ fsl,pins = <IMX95_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e>, /* WiFI_UART_RXD */
+ <IMX95_PAD_DAP_TDI__LPUART5_RX 0x31e>, /* WiFI_UART_TXD */
+ <IMX95_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e>, /* WiFI_UART_RTS# */
+ <IMX95_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e>; /* WiFI_UART_CTS# */
+ };
+
/* SMARC CAM_MCK */
pinctrl_cam_mck: cammckgrp {
fsl,pins = <IMX95_PAD_CCM_CLKO1__CCMSRCGPCMIX_TOP_CLKO_1 0x51e>; /* SMARC S6 - CAM_MCK */
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: freescale: imx95-toradex-smarc: Add Bluetooth and SER2
From: Franz Schnyder @ 2026-03-25 9:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel,
Francesco Dolcini, Franz Schnyder
This patch series adds support for missing interfaces on the Toradex
SMARC i.MX95 SoM.
It adds:
- SER2 interface
- UART interface for Bluetooth
- WIFI_UART_EN as a gpio-hog to select the UART function by default,
as the MAYA-W260 UART signals are shared with the JTAG.
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
Franz Schnyder (3):
arm64: dts: freescale: imx95-toradex-smarc: Add SER2 interface
arm64: dts: freescale: imx95-toradex-smarc: Enable bluetooth on lpuart5
arm64: dts: freescale: imx95-toradex-smarc: Use gpio-hog for WIFI_UART_EN
.../boot/dts/freescale/imx95-toradex-smarc-dev.dts | 5 +++
.../boot/dts/freescale/imx95-toradex-smarc.dtsi | 44 ++++++++++++++++++++++
2 files changed, 49 insertions(+)
---
base-commit: efc6947b672d449d6b4560a55ad3589a6bee746c
change-id: 20260324-mainline-update-imx95-00bdf6c54ba0
Best regards,
--
Franz Schnyder <franz.schnyder@toradex.com>
^ permalink raw reply
* Re: [RFC PATCH] arm64: dts: imx8mp-edm-g-wb: Use 0 for reserved bit
From: Eddie @ 2026-03-25 9:50 UTC (permalink / raw)
To: Frank Li
Cc: daniel.baluta, simona.toaca, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <acKyJTkqq-bV_3jZ@lizhi-Precision-Tower-5810>
Hi Frank,
>> Change 0x41 to 0x40 to leave the reserved bit cleared, as
>> recommended by the reference manual.
>
> Any impact if set bit 0 to 1?
>
I have not tested this on hardware with the bit cleared, so
I cannot confirm functional impact for sure, but according to
section 8.2.4.238 of the iMX8MP reference manual, bit 0 of
SW_PAD_CTL_PAD_SAI1_RXD6 is reserved with a reset value of 0.
The only defined fields are PE (bit 8), HYS (bit 7),
PUE (bit 6), ODE (bit 5), FSEL (bit 4), and DSE (bits 2:1).
Both 0x41 and 0x40 should result in identical pad behavior.
Leaving it set probably risks undefined behavior in future
revisions of the silicon.
>> This also allows for
>> easier conversion to symbolic macros.
>
> Can you send this patch also?
Yes, I will send a followup patch soon.
Thanks for the review.
Eduard
În mar., 24 mar. 2026 la 17:48, Frank Li <Frank.li@nxp.com> a scris:
>
> On Tue, Mar 10, 2026 at 09:10:53AM +0000, Eduard Bostina wrote:
>
> Remove RFC.
>
> > The i.MX8MP Reference Manual documents bit 0 of the
> > IOMUXC_SW_PAD_CTL_PAD registers as reserved. The hd3ss3220
> > IRQ pin (SAI1_RXD6/GPIO4_IO08) currently uses pad config
> > value 0x41 which sets this reserved bit.
> >
> > Change 0x41 to 0x40 to leave the reserved bit cleared, as
> > recommended by the reference manual.
>
> Any impact if set bit 0 to 1?
>
> > This also allows for
> > easier conversion to symbolic macros.
>
> Can you send this patch also?
>
> Frank
> >
> > Signed-off-by: Eduard Bostina <egbostina@gmail.com>
> > ---
> > arch/arm64/boot/dts/freescale/imx8mp-edm-g-wb.dts | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-edm-g-wb.dts b/arch/arm64/boot/dts/freescale/imx8mp-edm-g-wb.dts
> > index 242fa930b..a78401d11 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mp-edm-g-wb.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp-edm-g-wb.dts
> > @@ -345,7 +345,7 @@ MX8MP_IOMUXC_SAI1_TXD5__GPIO4_IO17 0x16 /* DSI_VDDEN */
> >
> > pinctrl_hd3ss3220_irq: hd3ss3220-irqgrp {
> > fsl,pins = <
> > - MX8MP_IOMUXC_SAI1_RXD6__GPIO4_IO08 0x41 /* GPIO_P253 */
> > + MX8MP_IOMUXC_SAI1_RXD6__GPIO4_IO08 0x40 /* GPIO_P253 */
> > >;
> > };
> >
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH v4 10/21] fs: afs: restore mmap_prepare implementation
From: Vlastimil Babka (SUSE) @ 2026-03-25 9:47 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <ad9a94350a9c7d2bdab79fc397ef0f64d3412d71.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Commit 9d5403b1036c ("fs: convert most other generic_file_*mmap() users to
> .mmap_prepare()") updated AFS to use the mmap_prepare callback in favour
> of the deprecated mmap callback.
>
> However, it did not account for the fact that mmap_prepare is called
> pre-merge, and may then be merged, nor that mmap_prepare can fail to map
> due to an out of memory error.
>
> This change was therefore since reverted.
>
> Both of those are cases in which we should not be incrementing a reference
> count.
>
> With the newly added vm_ops->mapped callback available, we can simply
> defer this operation to that callback which is only invoked once the
> mapping is successfully in place (but not yet visible to userspace as the
> mmap and VMA write locks are held).
>
> This allows us to once again reimplement the .mmap_prepare implementation
> for this file system.
>
> Therefore add afs_mapped() to implement this callback for AFS, and remove
> the code doing so in afs_mmap_prepare().
>
> Also update afs_vm_open(), afs_vm_close() and afs_vm_map_pages() to be
> consistent in how the vnode is accessed.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Yep that should take care of that reference count problem.
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> fs/afs/file.c | 42 +++++++++++++++++++++++++++++-------------
> 1 file changed, 29 insertions(+), 13 deletions(-)
>
> diff --git a/fs/afs/file.c b/fs/afs/file.c
> index 74d04af51ff4..85696ac984cc 100644
> --- a/fs/afs/file.c
> +++ b/fs/afs/file.c
> @@ -19,7 +19,7 @@
> #include <trace/events/netfs.h>
> #include "internal.h"
>
> -static int afs_file_mmap(struct file *file, struct vm_area_struct *vma);
> +static int afs_file_mmap_prepare(struct vm_area_desc *desc);
>
> static ssize_t afs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter);
> static ssize_t afs_file_splice_read(struct file *in, loff_t *ppos,
> @@ -28,6 +28,8 @@ static ssize_t afs_file_splice_read(struct file *in, loff_t *ppos,
> static void afs_vm_open(struct vm_area_struct *area);
> static void afs_vm_close(struct vm_area_struct *area);
> static vm_fault_t afs_vm_map_pages(struct vm_fault *vmf, pgoff_t start_pgoff, pgoff_t end_pgoff);
> +static int afs_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> + const struct file *file, void **vm_private_data);
>
> const struct file_operations afs_file_operations = {
> .open = afs_open,
> @@ -35,7 +37,7 @@ const struct file_operations afs_file_operations = {
> .llseek = generic_file_llseek,
> .read_iter = afs_file_read_iter,
> .write_iter = netfs_file_write_iter,
> - .mmap = afs_file_mmap,
> + .mmap_prepare = afs_file_mmap_prepare,
> .splice_read = afs_file_splice_read,
> .splice_write = iter_file_splice_write,
> .fsync = afs_fsync,
> @@ -61,6 +63,7 @@ const struct address_space_operations afs_file_aops = {
> };
>
> static const struct vm_operations_struct afs_vm_ops = {
> + .mapped = afs_mapped,
> .open = afs_vm_open,
> .close = afs_vm_close,
> .fault = filemap_fault,
> @@ -492,34 +495,47 @@ static void afs_drop_open_mmap(struct afs_vnode *vnode)
> /*
> * Handle setting up a memory mapping on an AFS file.
> */
> -static int afs_file_mmap(struct file *file, struct vm_area_struct *vma)
> +static int afs_file_mmap_prepare(struct vm_area_desc *desc)
> {
> - struct afs_vnode *vnode = AFS_FS_I(file_inode(file));
> int ret;
>
> - afs_add_open_mmap(vnode);
> + ret = generic_file_mmap_prepare(desc);
> + if (ret)
> + return ret;
>
> - ret = generic_file_mmap(file, vma);
> - if (ret == 0)
> - vma->vm_ops = &afs_vm_ops;
> - else
> - afs_drop_open_mmap(vnode);
> + desc->vm_ops = &afs_vm_ops;
> return ret;
> }
>
> +static int afs_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> + const struct file *file, void **vm_private_data)
> +{
> + struct afs_vnode *vnode = AFS_FS_I(file_inode(file));
> +
> + afs_add_open_mmap(vnode);
> + return 0;
> +}
> +
> static void afs_vm_open(struct vm_area_struct *vma)
> {
> - afs_add_open_mmap(AFS_FS_I(file_inode(vma->vm_file)));
> + struct file *file = vma->vm_file;
> + struct afs_vnode *vnode = AFS_FS_I(file_inode(file));
> +
> + afs_add_open_mmap(vnode);
> }
>
> static void afs_vm_close(struct vm_area_struct *vma)
> {
> - afs_drop_open_mmap(AFS_FS_I(file_inode(vma->vm_file)));
> + struct file *file = vma->vm_file;
> + struct afs_vnode *vnode = AFS_FS_I(file_inode(file));
> +
> + afs_drop_open_mmap(vnode);
> }
>
> static vm_fault_t afs_vm_map_pages(struct vm_fault *vmf, pgoff_t start_pgoff, pgoff_t end_pgoff)
> {
> - struct afs_vnode *vnode = AFS_FS_I(file_inode(vmf->vma->vm_file));
> + struct file *file = vmf->vma->vm_file;
> + struct afs_vnode *vnode = AFS_FS_I(file_inode(file));
>
> if (afs_check_validity(vnode))
> return filemap_map_pages(vmf, start_pgoff, end_pgoff);
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: mediatek: mt8173: add hana revision 2
From: Chen-Yu Tsai @ 2026-03-25 9:33 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Mateusz Koza, Frank Wunderlich,
Gary Bisson, Cristian Cozzolino, Jianeng Ceng, Max Shevchenko,
Sean Wang, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Icenowy Zheng
In-Reply-To: <20260325082546.1572405-2-zhengxingda@iscas.ac.cn>
On Wed, Mar 25, 2026 at 4:26 PM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
>
> The current mt8173-elm-hana.dts file only contains compatible strings
> for revision 3~6, makes boards with revision 0~2 to fail to match a
> revision-specific DTS and may fall back to the rev7 one (which lacks
> some gpio-keys).
>
> As I've got a Lenovo Flex 11 Chromebook with board revision 2, add it to
> the base hana DTB file.
>
> Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
I couldn't dig up which revisions were commercially available, but
our downstream kernel says that regvisions 0 through 6 are all
compatible.
Acked-by: Chen-Yu Tsai <wenst@chromium.org>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: mediatek: add mt8173-hana rev2
From: Chen-Yu Tsai @ 2026-03-25 9:33 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Mateusz Koza, Frank Wunderlich,
Gary Bisson, Cristian Cozzolino, Jianeng Ceng, Max Shevchenko,
Sean Wang, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Icenowy Zheng, Conor Dooley
In-Reply-To: <20260325082546.1572405-1-zhengxingda@iscas.ac.cn>
On Wed, Mar 25, 2026 at 4:25 PM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
>
> My Lenovo Flex 11 Chromebook contains a board with revision ID 2.
>
> Add rev2 to the compatible list of base hana DTB to allow depthcharge to
> match the DTB.
By consumer electronics standards, this device is ancient.
I couldn't dig up which revisions were commercially available, but
our downstream kernel says that regvisions 0 through 6 are all
compatible.
Acked-by: Chen-Yu Tsai <wenst@chromium.org>
> Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> Changes in v2:
> - Added Conor's A-b.
> - Changed mailbox to ISCAS one.
>
> Documentation/devicetree/bindings/arm/mediatek.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index 382d0eb4d0af6..2894c8a16c78c 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -148,6 +148,7 @@ properties:
> - const: google,hana-rev5
> - const: google,hana-rev4
> - const: google,hana-rev3
> + - const: google,hana-rev2
> - const: google,hana
> - const: mediatek,mt8173
> - description: Google Hana rev7 (Poin2 Chromebook 11C)
> --
> 2.52.0
>
^ permalink raw reply
* [PATCH v1] PCI: imx6: Fix reference clock source selection
From: Franz Schnyder @ 2026-03-25 9:31 UTC (permalink / raw)
To: Richard Zhu, Lucas Stach, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: Franz Schnyder, linux-pci, linux-arm-kernel, imx, linux-kernel,
Francesco Dolcini, stable
From: Franz Schnyder <franz.schnyder@toradex.com>
In the PCIe PHY init for the iMX95, the reference clock source selection
uses a conditional instead of always passing the mask. This currently
breaks functionality if the internal refclk is used.
Pass always IMX95_PCIE_REF_USE_PAD as the mask and clear the bit if
external refclk is not used.
Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode support")
Cc: stable@vger.kernel.org
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
drivers/pci/controller/dwc/pci-imx6.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 81a7093494c8..e0580d6efa57 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -268,8 +268,8 @@ static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
IMX95_PCIE_PHY_CR_PARA_SEL);
regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_PHY_GEN_CTRL,
- ext ? IMX95_PCIE_REF_USE_PAD : 0,
- IMX95_PCIE_REF_USE_PAD);
+ IMX95_PCIE_REF_USE_PAD,
+ ext ? IMX95_PCIE_REF_USE_PAD : 0);
regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_0,
IMX95_PCIE_REF_CLKEN,
ext ? 0 : IMX95_PCIE_REF_CLKEN);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Michael S. Tsirkin @ 2026-03-25 9:29 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Harald Freudenberger, Holger Dengler, Mark Brown, Jason Wang,
Xuan Zhuo, Eugenio Pérez, Alex Williamson, Juergen Gross,
Stefano Stabellini, Oleksandr Tyshchenko,
Christophe Leroy (CS GROUP), linux-kernel, driver-core,
linuxppc-dev, linux-hyperv, linux-pci, platform-driver-x86,
linux-arm-msm, linux-remoteproc, linux-s390, linux-spi,
virtualization, kvm, xen-devel, linux-arm-kernel
In-Reply-To: <20260324005919.2408620-1-dakr@kernel.org>
On Tue, Mar 24, 2026 at 01:59:04AM +0100, Danilo Krummrich wrote:
> This is the follow-up of the driver_override generalization in [1], converting
> the remaining 11 busses and removing the now-unused driver_set_override()
> helper.
>
> All of them (except AP, which has a different race condition) are prone to the
> potential UAF described in [2], caused by accessing the driver_override field
> from their corresponding match() callback.
>
> In order to address this, the generalized driver_override field in struct device
> is protected with a spinlock. The driver-core provides accessors, such as
> device_match_driver_override(), device_has_driver_override() and
> device_set_driver_override(), which all ensure proper locking internally.
>
> Additionally, the driver-core provides a driver_override flag in struct
> bus_type, which, once enabled, automatically registers generic sysfs callbacks,
> allowing userspace to modify the driver_override field.
>
> SPI and AP are a bit special; both print "\n" when driver_override is not set,
> whereas all other buses (and thus the driver-core) produce "(null)\n" in this
> case.
>
> Hence, SPI and AP do not take advantage of the driver_override flag in struct
> bus_type; AP additionally maintains a counter in its custom sysfs store().
>
> Technically, we could support a custom fallback string when driver_override is
> unset in struct bus_type, but only SPI would benefit from this, since AP has
> additional custom logic in store() anyways.
>
> (I'm not sure if there are userspace programs that strictly rely on this;
> driverctl seems to check for both, but I rather not break some userspace tool
> I'm not aware of. :)
>
> This series is based on v7.0-rc5 with no additional dependencies, hence those
> patches can be picked up by subsystems individually.
>
> [1] https://lore.kernel.org/driver-core/20260303115720.48783-1-dakr@kernel.org/
> [2] https://bugzilla.kernel.org/show_bug.cgi?id=220789
> [3] https://gitlab.com/driverctl/driverctl/-/blob/0.121/driverctl?ref_type=tags#L99
vdpa bits:
Acked-by: Michael S. Tsirkin <mst@redhat.com>
I assume it'll all be merged together?
> Danilo Krummrich (12):
> amba: use generic driver_override infrastructure
> bus: fsl-mc: use generic driver_override infrastructure
> cdx: use generic driver_override infrastructure
> hv: vmbus: use generic driver_override infrastructure
> PCI: use generic driver_override infrastructure
> platform/wmi: use generic driver_override infrastructure
> rpmsg: use generic driver_override infrastructure
> vdpa: use generic driver_override infrastructure
> s390/cio: use generic driver_override infrastructure
> s390/ap: use generic driver_override infrastructure
> spi: use generic driver_override infrastructure
> driver core: remove driver_set_override()
>
> drivers/amba/bus.c | 37 +++------------
> drivers/base/driver.c | 75 ------------------------------
> drivers/bus/fsl-mc/fsl-mc-bus.c | 43 +++--------------
> drivers/cdx/cdx.c | 40 ++--------------
> drivers/hv/vmbus_drv.c | 36 ++------------
> drivers/pci/pci-driver.c | 11 +++--
> drivers/pci/pci-sysfs.c | 28 -----------
> drivers/pci/probe.c | 1 -
> drivers/platform/wmi/core.c | 36 ++------------
> drivers/rpmsg/qcom_glink_native.c | 2 -
> drivers/rpmsg/rpmsg_core.c | 43 +++--------------
> drivers/rpmsg/virtio_rpmsg_bus.c | 1 -
> drivers/s390/cio/cio.h | 5 --
> drivers/s390/cio/css.c | 34 ++------------
> drivers/s390/crypto/ap_bus.c | 34 +++++++-------
> drivers/s390/crypto/ap_bus.h | 1 -
> drivers/s390/crypto/ap_queue.c | 24 +++-------
> drivers/spi/spi.c | 19 +++-----
> drivers/vdpa/vdpa.c | 48 ++-----------------
> drivers/vfio/fsl-mc/vfio_fsl_mc.c | 4 +-
> drivers/vfio/pci/vfio_pci_core.c | 5 +-
> drivers/xen/xen-pciback/pci_stub.c | 6 ++-
> include/linux/amba/bus.h | 5 --
> include/linux/cdx/cdx_bus.h | 4 --
> include/linux/device/driver.h | 2 -
> include/linux/fsl/mc.h | 4 --
> include/linux/hyperv.h | 5 --
> include/linux/pci.h | 6 ---
> include/linux/rpmsg.h | 4 --
> include/linux/spi/spi.h | 5 --
> include/linux/vdpa.h | 4 --
> include/linux/wmi.h | 4 --
> 32 files changed, 88 insertions(+), 488 deletions(-)
>
>
> base-commit: c369299895a591d96745d6492d4888259b004a9e
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH] ACPI: APEI: Handle repeated SEA error interrupts storm scenarios
From: hejunhao @ 2026-03-25 9:24 UTC (permalink / raw)
To: Shuai Xue, Rafael J. Wysocki, Luck, Tony
Cc: bp, guohanjun, mchehab, jarkko, yazen.ghannam, jane.chu, lenb,
Jonathan.Cameron, linux-acpi, linux-arm-kernel, linux-kernel,
linux-edac, shiju.jose, tanxiaofei, Linuxarm, Junhao He
In-Reply-To: <c72680a4-5133-4b93-8efb-2e72ce0ed7fa@linux.alibaba.com>
On 2026/3/25 10:12, Shuai Xue wrote:
> Hi, junhao
>
> On 3/24/26 6:04 PM, hejunhao wrote:
>> Hi shuai xue,
>>
>>
>> On 2026/3/3 22:42, Shuai Xue wrote:
>>> Hi, junhao,
>>>
>>> On 2/27/26 8:12 PM, hejunhao wrote:
>>>>
>>>>
>>>> On 2025/11/4 9:32, Shuai Xue wrote:
>>>>>
>>>>>
>>>>> 在 2025/11/4 00:19, Rafael J. Wysocki 写道:
>>>>>> On Thu, Oct 30, 2025 at 8:13 AM Junhao He <hejunhao3@h-partners.com> wrote:
>>>>>>>
>>>>>>> The do_sea() function defaults to using firmware-first mode, if supported.
>>>>>>> It invoke acpi/apei/ghes ghes_notify_sea() to report and handling the SEA
>>>>>>> error, The GHES uses a buffer to cache the most recent 4 kinds of SEA
>>>>>>> errors. If the same kind SEA error continues to occur, GHES will skip to
>>>>>>> reporting this SEA error and will not add it to the "ghes_estatus_llist"
>>>>>>> list until the cache times out after 10 seconds, at which point the SEA
>>>>>>> error will be reprocessed.
>>>>>>>
>>>>>>> The GHES invoke ghes_proc_in_irq() to handle the SEA error, which
>>>>>>> ultimately executes memory_failure() to process the page with hardware
>>>>>>> memory corruption. If the same SEA error appears multiple times
>>>>>>> consecutively, it indicates that the previous handling was incomplete or
>>>>>>> unable to resolve the fault. In such cases, it is more appropriate to
>>>>>>> return a failure when encountering the same error again, and then proceed
>>>>>>> to arm64_do_kernel_sea for further processing.
>>>
>>> There is no such function in the arm64 tree. If apei_claim_sea() returns
>>
>> Sorry for the mistake in the commit message. The function arm64_do_kernel_sea() should
>> be arm64_notify_die().
>>
>>> an error, the actual fallback path in do_sea() is arm64_notify_die(),
>>> which sends SIGBUS?
>>>
>>
>> If apei_claim_sea() returns an error, arm64_notify_die() will call arm64_force_sig_fault(inf->sig /* SIGBUS */, , , ),
>> followed by force_sig_fault(SIGBUS, , ) to force the process to receive the SIGBUS signal.
>
> So the process is expected to killed by SIGBUS?
Yes. The devmem process is expected to terminate upon receiving a SIGBUS signal, you can
see this at the last line of the test log after the patch is applied.
For other processes whether it terminates depends on whether it catches the signal; the kernel is
responsible for sending it immediately.
>
>>
>>>>>>>
>>>>>>> When hardware memory corruption occurs, a memory error interrupt is
>>>>>>> triggered. If the kernel accesses this erroneous data, it will trigger
>>>>>>> the SEA error exception handler. All such handlers will call
>>>>>>> memory_failure() to handle the faulty page.
>>>>>>>
>>>>>>> If a memory error interrupt occurs first, followed by an SEA error
>>>>>>> interrupt, the faulty page is first marked as poisoned by the memory error
>>>>>>> interrupt process, and then the SEA error interrupt handling process will
>>>>>>> send a SIGBUS signal to the process accessing the poisoned page.
>>>>>>>
>>>>>>> However, if the SEA interrupt is reported first, the following exceptional
>>>>>>> scenario occurs:
>>>>>>>
>>>>>>> When a user process directly requests and accesses a page with hardware
>>>>>>> memory corruption via mmap (such as with devmem), the page containing this
>>>>>>> address may still be in a free buddy state in the kernel. At this point,
>>>>>>> the page is marked as "poisoned" during the SEA claim memory_failure().
>>>>>>> However, since the process does not request the page through the kernel's
>>>>>>> MMU, the kernel cannot send SIGBUS signal to the processes. And the memory
>>>>>>> error interrupt handling process not support send SIGBUS signal. As a
>>>>>>> result, these processes continues to access the faulty page, causing
>>>>>>> repeated entries into the SEA exception handler. At this time, it lead to
>>>>>>> an SEA error interrupt storm.
>>>
>>> In such case, the user process which accessing the poisoned page will be killed
>>> by memory_fauilre?
>>>
>>> // memory_failure():
>>>
>>> if (TestSetPageHWPoison(p)) {
>>> res = -EHWPOISON;
>>> if (flags & MF_ACTION_REQUIRED)
>>> res = kill_accessing_process(current, pfn, flags);
>>> if (flags & MF_COUNT_INCREASED)
>>> put_page(p);
>>> action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED);
>>> goto unlock_mutex;
>>> }
>>>
>>> I think this problem has already been fixed by commit 2e6053fea379 ("mm/memory-failure:
>>> fix infinite UCE for VM_PFNMAP pfn").
>>>
>>> The root cause is that walk_page_range() skips VM_PFNMAP vmas by default when
>>> no .test_walk callback is set, so kill_accessing_process() returns 0 for a
>>> devmem-style mapping (remap_pfn_range, VM_PFNMAP), making the caller believe
>>> the UCE was handled properly while the process was never actually killed.
>>>
>>> Did you try the lastest kernel version?
>>>
>>
>> I retested this issue on the kernel v7.0.0-rc4 with the following debug patch and was still able to reproduce it.
>>
>>
>> @@ -1365,8 +1365,11 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
>> ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
>>
>> /* This error has been reported before, don't process it again. */
>> - if (ghes_estatus_cached(estatus))
>> + if (ghes_estatus_cached(estatus)) {
>> + pr_info("This error has been reported before, don't process it again.\n");
>> goto no_work;
>> + }
>>
>> the test log Only some debug logs are retained here.
>>
>> [2026/3/24 14:51:58.199] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32 0
>> [2026/3/24 14:51:58.369] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32
>> [2026/3/24 14:51:58.458] [ 130.558038][ C40] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
>> [2026/3/24 14:51:58.459] [ 130.572517][ C40] {1}[Hardware Error]: event severity: recoverable
>> [2026/3/24 14:51:58.459] [ 130.578861][ C40] {1}[Hardware Error]: Error 0, type: recoverable
>> [2026/3/24 14:51:58.459] [ 130.585203][ C40] {1}[Hardware Error]: section_type: ARM processor error
>> [2026/3/24 14:51:58.459] [ 130.592238][ C40] {1}[Hardware Error]: MIDR: 0x0000000000000000
>> [2026/3/24 14:51:58.459] [ 130.598492][ C40] {1}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
>> [2026/3/24 14:51:58.459] [ 130.607871][ C40] {1}[Hardware Error]: error affinity level: 0
>> [2026/3/24 14:51:58.459] [ 130.614038][ C40] {1}[Hardware Error]: running state: 0x1
>> [2026/3/24 14:51:58.459] [ 130.619770][ C40] {1}[Hardware Error]: Power State Coordination Interface state: 0
>> [2026/3/24 14:51:58.459] [ 130.627673][ C40] {1}[Hardware Error]: Error info structure 0:
>> [2026/3/24 14:51:58.459] [ 130.633839][ C40] {1}[Hardware Error]: num errors: 1
>> [2026/3/24 14:51:58.459] [ 130.639137][ C40] {1}[Hardware Error]: error_type: 0, cache error
>> [2026/3/24 14:51:58.459] [ 130.645652][ C40] {1}[Hardware Error]: error_info: 0x0000000020400014
>> [2026/3/24 14:51:58.459] [ 130.652514][ C40] {1}[Hardware Error]: cache level: 1
>> [2026/3/24 14:51:58.551] [ 130.658073][ C40] {1}[Hardware Error]: the error has not been corrected
>> [2026/3/24 14:51:58.551] [ 130.665194][ C40] {1}[Hardware Error]: physical fault address: 0x0000001351811800
>> [2026/3/24 14:51:58.551] [ 130.673097][ C40] {1}[Hardware Error]: Vendor specific error info has 48 bytes:
>> [2026/3/24 14:51:58.551] [ 130.680744][ C40] {1}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
>> [2026/3/24 14:51:58.551] [ 130.690471][ C40] {1}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
>> [2026/3/24 14:51:58.552] [ 130.700198][ C40] {1}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
>> [2026/3/24 14:51:58.552] [ 130.710083][ T9767] Memory failure: 0x1351811: recovery action for free buddy page: Recovered
>> [2026/3/24 14:51:58.638] [ 130.790952][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:51:58.903] [ 131.046994][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:51:58.991] [ 131.132360][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:51:59.969] [ 132.071431][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:52:00.860] [ 133.010255][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:52:01.927] [ 134.034746][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:52:02.906] [ 135.058973][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:52:03.971] [ 136.083213][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:52:04.860] [ 137.021956][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:52:06.018] [ 138.131460][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:52:06.905] [ 139.070280][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:52:07.886] [ 140.009147][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 14:52:08.596] [ 140.777368][ C40] {2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
>> [2026/3/24 14:52:08.683] [ 140.791921][ C40] {2}[Hardware Error]: event severity: recoverable
>> [2026/3/24 14:52:08.683] [ 140.798263][ C40] {2}[Hardware Error]: Error 0, type: recoverable
>> [2026/3/24 14:52:08.683] [ 140.804606][ C40] {2}[Hardware Error]: section_type: ARM processor error
>> [2026/3/24 14:52:08.683] [ 140.811641][ C40] {2}[Hardware Error]: MIDR: 0x0000000000000000
>> [2026/3/24 14:52:08.684] [ 140.817895][ C40] {2}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
>> [2026/3/24 14:52:08.684] [ 140.827274][ C40] {2}[Hardware Error]: error affinity level: 0
>> [2026/3/24 14:52:08.684] [ 140.833440][ C40] {2}[Hardware Error]: running state: 0x1
>> [2026/3/24 14:52:08.684] [ 140.839173][ C40] {2}[Hardware Error]: Power State Coordination Interface state: 0
>> [2026/3/24 14:52:08.684] [ 140.847076][ C40] {2}[Hardware Error]: Error info structure 0:
>> [2026/3/24 14:52:08.684] [ 140.853241][ C40] {2}[Hardware Error]: num errors: 1
>> [2026/3/24 14:52:08.684] [ 140.858540][ C40] {2}[Hardware Error]: error_type: 0, cache error
>> [2026/3/24 14:52:08.684] [ 140.865055][ C40] {2}[Hardware Error]: error_info: 0x0000000020400014
>> [2026/3/24 14:52:08.684] [ 140.871917][ C40] {2}[Hardware Error]: cache level: 1
>> [2026/3/24 14:52:08.684] [ 140.877475][ C40] {2}[Hardware Error]: the error has not been corrected
>> [2026/3/24 14:52:08.764] [ 140.884596][ C40] {2}[Hardware Error]: physical fault address: 0x0000001351811800
>> [2026/3/24 14:52:08.764] [ 140.892499][ C40] {2}[Hardware Error]: Vendor specific error info has 48 bytes:
>> [2026/3/24 14:52:08.766] [ 140.900145][ C40] {2}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
>> [2026/3/24 14:52:08.767] [ 140.909872][ C40] {2}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
>> [2026/3/24 14:52:08.767] [ 140.919598][ C40] {2}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
>> [2026/3/24 14:52:08.768] [ 140.929346][ T9767] Memory failure: 0x1351811: already hardware poisoned
>> [2026/3/24 14:52:08.768] [ 140.936072][ T9767] Memory failure: 0x1351811: Sending SIGBUS to busybox:9767 due to hardware memory corruption
>
> Did you cut off some logs here?
I just removed some duplicate debug logs: "This error has already been...", these were added by myself.
> The error log also indicates that the SIGBUS is delivered as expected.
An SError occurs at kernel time 130.558038. Then, after 10 seconds, the kernel
can re-enter the SEA processing flow and send the SIGBUS signal to the process.
This 10-second delay corresponds to the cache timeout threshold of the
ghes_estatus_cached() feature.
Therefore, the purpose of this patch is to send the SIGBUS signal to the process
immediately, rather than waiting for the timeout to expire.
>
>>
>>
>> Apply the patch:
>>
>> @@ -1365,8 +1365,11 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
>> ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
>>
>> /* This error has been reported before, don't process it again. */
>> - if (ghes_estatus_cached(estatus))
>> + if (ghes_estatus_cached(estatus)) {
>> + pr_info("This error has been reported before, don't process it again.\n");
>> + rc = -ECANCELED;
>> goto no_work;
>> + }
>>
>> [2026/3/24 16:45:40.084] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32 0
>> [2026/3/24 16:45:40.272] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32
>> [2026/3/24 16:45:40.362] [ 112.279324][ C40] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
>> [2026/3/24 16:45:40.362] [ 112.293797][ C40] {1}[Hardware Error]: event severity: recoverable
>> [2026/3/24 16:45:40.362] [ 112.300139][ C40] {1}[Hardware Error]: Error 0, type: recoverable
>> [2026/3/24 16:45:40.363] [ 112.306481][ C40] {1}[Hardware Error]: section_type: ARM processor error
>> [2026/3/24 16:45:40.363] [ 112.313516][ C40] {1}[Hardware Error]: MIDR: 0x0000000000000000
>> [2026/3/24 16:45:40.363] [ 112.319771][ C40] {1}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
>> [2026/3/24 16:45:40.363] [ 112.329151][ C40] {1}[Hardware Error]: error affinity level: 0
>> [2026/3/24 16:45:40.363] [ 112.335317][ C40] {1}[Hardware Error]: running state: 0x1
>> [2026/3/24 16:45:40.363] [ 112.341049][ C40] {1}[Hardware Error]: Power State Coordination Interface state: 0
>> [2026/3/24 16:45:40.363] [ 112.348953][ C40] {1}[Hardware Error]: Error info structure 0:
>> [2026/3/24 16:45:40.363] [ 112.355119][ C40] {1}[Hardware Error]: num errors: 1
>> [2026/3/24 16:45:40.363] [ 112.360418][ C40] {1}[Hardware Error]: error_type: 0, cache error
>> [2026/3/24 16:45:40.363] [ 112.366932][ C40] {1}[Hardware Error]: error_info: 0x0000000020400014
>> [2026/3/24 16:45:40.363] [ 112.373795][ C40] {1}[Hardware Error]: cache level: 1
>> [2026/3/24 16:45:40.453] [ 112.379354][ C40] {1}[Hardware Error]: the error has not been corrected
>> [2026/3/24 16:45:40.453] [ 112.386475][ C40] {1}[Hardware Error]: physical fault address: 0x0000001351811800
>> [2026/3/24 16:45:40.453] [ 112.394378][ C40] {1}[Hardware Error]: Vendor specific error info has 48 bytes:
>> [2026/3/24 16:45:40.453] [ 112.402027][ C40] {1}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
>> [2026/3/24 16:45:40.453] [ 112.411754][ C40] {1}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
>> [2026/3/24 16:45:40.453] [ 112.421480][ C40] {1}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
>> [2026/3/24 16:45:40.453] [ 112.431639][ T9769] Memory failure: 0x1351811: recovery action for free buddy page: Recovered
>> [2026/3/24 16:45:40.531] [ 112.512520][ C40] This error has been reported before, don't process it again.
>> [2026/3/24 16:45:40.757] Bus error (core dumped)
>>
>
>
> Thanks.
> Shuai
>
>
> .
>
^ permalink raw reply
* [PATCH v4 9/9] arm64: dts: amlogic: t7: khadas-vim4: Add MMC nodes
From: Ronald Claveau @ 2026-03-25 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Ronald Claveau
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-0-44c7b4a5e459@aliel.fr>
Enable and configure the three MMC controllers for the Khadas VIM4 board:
- sd_emmc_a: SDIO interface for the BCM43752 Wi-Fi module
- sd_emmc_b: SD card slot
- sd_emmc_c: eMMC storage
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 90 +++++++++++++++++++++-
1 file changed, 89 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 770f06b0b16c7..5a73ae081036c 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -14,7 +14,10 @@ / {
compatible = "khadas,vim4", "amlogic,a311d2", "amlogic,t7";
aliases {
- serial0 = &uart_a;
+ serial0 = &uart_a;
+ mmc0 = &sd_emmc_c;
+ mmc1 = &sd_emmc_b;
+ mmc2 = &sd_emmc_a;
};
memory@0 {
@@ -159,6 +162,91 @@ &pwm_ab {
pinctrl-names = "default";
};
+/* SDIO */
+&sd_emmc_a {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ cap-sdio-irq;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+ no-mmc;
+ no-sd;
+
+ power-domains = <&pwrc PWRC_T7_SDIO_A_ID>;
+
+ keep-power-in-suspend;
+
+ mmc-pwrseq = <&sdio_pwrseq>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_1v8>;
+
+ brcmf: wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm43752-fmac", "brcm,bcm4329-fmac";
+ };
+};
+
+/* SD card */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ max-frequency = <200000000>;
+ disable-wp;
+ no-sdio;
+ no-mmc;
+
+ power-domains = <&pwrc PWRC_T7_SDIO_B_ID>;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <&sd_3v3>;
+ vqmmc-supply = <&vddio_c>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_ctrl_pins>, <&emmc_data_8b_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ disable-wp;
+ non-removable;
+ no-sdio;
+ no-sd;
+
+ power-domains = <&pwrc PWRC_T7_EMMC_ID>;
+
+ vmmc-supply = <&vddio_3v3>;
+ vqmmc-supply = <&vddio_1v8>;
+};
+
&uart_a {
status = "okay";
clocks = <&xtal>, <&xtal>, <&xtal>;
--
2.49.0
^ permalink raw reply related
* [PATCH v4 7/9] arm64: dts: amlogic: t7: khadas-vim4: Add SDIO power sequence and WiFi clock
From: Ronald Claveau @ 2026-03-25 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Ronald Claveau
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-0-44c7b4a5e459@aliel.fr>
Add the SDIO power sequence node using mmc-pwrseq-simple and a
32.768kHz PWM-based clock required by the Wi-Fi module.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 2450084d37642..770f06b0b16c7 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -67,6 +67,15 @@ sd_3v3: regulator-sdcard-3v3 {
regulator-always-on;
};
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ post-power-on-delay-ms = <500>;
+ power-off-delay-us = <200000>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
+
vcc5v: regulator-vcc-5v {
compatible = "regulator-fixed";
regulator-name = "VCC5V";
@@ -135,6 +144,19 @@ vddio_c: regulator-gpio-c {
states = <1800000 1
3300000 0>;
};
+
+ wifi32k: wifi32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ab 0 30518 0>;
+ };
+};
+
+&pwm_ab {
+ status = "okay";
+ pinctrl-0 = <&pwm_a_pins>;
+ pinctrl-names = "default";
};
&uart_a {
--
2.49.0
^ permalink raw reply related
* [PATCH v4 5/9] arm64: dts: amlogic: t7: Add PWM controller nodes
From: Ronald Claveau @ 2026-03-25 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Ronald Claveau, Nick Xie
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-0-44c7b4a5e459@aliel.fr>
Add device tree nodes for the seven PWM controllers available
on the Amlogic T7 SoC, using amlogic,meson-s4-pwm as fallback compatible.
All nodes are disabled by default and should be
enabled in the board-specific DTS file.
Co-developed-by: Nick Xie <nick@khadas.com>
Signed-off-by: Nick Xie <nick@khadas.com>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 63 +++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index eb09a26bcd0e0..581cdaebfe637 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -511,6 +511,69 @@ sec_ao: ao-secure@10220 {
amlogic,has-chip-id;
};
+ pwm_ao_ef: pwm@30000 {
+ compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
+ reg = <0x0 0x30000 0x0 0x24>;
+ clocks = <&clkc_periphs CLKID_PWM_AO_E>,
+ <&clkc_periphs CLKID_PWM_AO_F>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm_ao_gh: pwm@32000 {
+ compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
+ reg = <0x0 0x32000 0x0 0x24>;
+ clocks = <&clkc_periphs CLKID_PWM_AO_G>,
+ <&clkc_periphs CLKID_PWM_AO_H>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm_ab: pwm@58000 {
+ compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
+ reg = <0x0 0x58000 0x0 0x24>;
+ clocks = <&clkc_periphs CLKID_PWM_A>,
+ <&clkc_periphs CLKID_PWM_B>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm_cd: pwm@5a000 {
+ compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
+ reg = <0x0 0x5a000 0x0 0x24>;
+ clocks = <&clkc_periphs CLKID_PWM_C>,
+ <&clkc_periphs CLKID_PWM_D>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm_ef: pwm@5c000 {
+ compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
+ reg = <0x0 0x5c000 0x0 0x24>;
+ clocks = <&clkc_periphs CLKID_PWM_E>,
+ <&clkc_periphs CLKID_PWM_F>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm_ao_ab: pwm@5e000 {
+ compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
+ reg = <0x0 0x5e000 0x0 0x24>;
+ clocks = <&clkc_periphs CLKID_PWM_AO_A>,
+ <&clkc_periphs CLKID_PWM_AO_B>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm_ao_cd: pwm@60000 {
+ compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
+ reg = <0x0 0x60000 0x0 0x24>;
+ clocks = <&clkc_periphs CLKID_PWM_AO_C>,
+ <&clkc_periphs CLKID_PWM_AO_D>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
sd_emmc_a: mmc@88000 {
compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
reg = <0x0 0x88000 0x0 0x800>;
--
2.49.0
^ permalink raw reply related
* [PATCH v4 8/9] dt-bindings: net: wireless: brcm: Add compatible for bcm43752
From: Ronald Claveau @ 2026-03-25 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Ronald Claveau
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-0-44c7b4a5e459@aliel.fr>
Add bcm43752 compatible with its bcm4329 compatible fallback.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
index 3be7576787644..81fd3e37452a6 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
@@ -42,6 +42,7 @@ properties:
- brcm,bcm4356-fmac
- brcm,bcm4359-fmac
- brcm,bcm4366-fmac
+ - brcm,bcm43752-fmac
- cypress,cyw4373-fmac
- cypress,cyw43012-fmac
- infineon,cyw43439-fmac
--
2.49.0
^ permalink raw reply related
* [PATCH v4 6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
From: Ronald Claveau @ 2026-03-25 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Ronald Claveau
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-0-44c7b4a5e459@aliel.fr>
Add voltage regulator nodes describing the VIM4 power tree,
required by peripheral nodes such as the SD card controller.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 90 ++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index fffdab96b12eb..2450084d37642 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -6,6 +6,8 @@
/dts-v1/;
#include "amlogic-t7.dtsi"
+#include <dt-bindings/gpio/amlogic,t7-periphs-pinctrl.h>
+#include <dt-bindings/gpio/gpio.h>
/ {
model = "Khadas vim4";
@@ -45,6 +47,94 @@ xtal: xtal-clk {
#clock-cells = <0>;
};
+ dc_in: regulator-dc-in {
+ compatible = "regulator-fixed";
+ regulator-name = "DC_IN";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ sd_3v3: regulator-sdcard-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "SD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vddao_3v3>;
+ gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
+ regulator-boot-on;
+ enable-active-low;
+ regulator-always-on;
+ };
+
+ vcc5v: regulator-vcc-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_in>;
+
+ gpio = <&gpio GPIOH_4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vcc5v0_usb: regulator-vcc-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC5V0_USB";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v>;
+
+ gpio = <&gpio GPIOY_5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vddao_1v8: regulator-vddao-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ vddao_3v3: regulator-vddao-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_in>;
+ regulator-always-on;
+ };
+
+ vddio_1v8: regulator-vddio-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddio_3v3>;
+ regulator-always-on;
+ };
+
+ vddio_3v3: regulator-vddio-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ vddio_c: regulator-gpio-c {
+ compatible = "regulator-gpio";
+ regulator-name = "VDDIO_C";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vddio_3v3>;
+ gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
+ states = <1800000 1
+ 3300000 0>;
+ };
};
&uart_a {
--
2.49.0
^ permalink raw reply related
* [PATCH v4 0/9] arm64: dts: amlogic: Add MMC/SD/SDIO support for Khadas VIM4 (Amlogic T7)
From: Ronald Claveau @ 2026-03-25 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Ronald Claveau, Nick Xie
This patch series depends on Jian's SCMI clock patches yet to merge
https://lore.kernel.org/all/20260313070022.700437-1-jian.hu@amlogic.com/
This series adds device tree support for the MMC, SD card and SDIO
interfaces on the Amlogic T7 SoC and the Khadas VIM4 board.
The first patches add the necessary building blocks in the T7 SoC
DTSI: pinctrl nodes for pin muxing, PWM controller nodes, and MMC
controller nodes. The amlogic,t7-mmc and amlogic,t7-pwm compatible
strings are introduced with fallbacks to existing drivers, avoiding
the need for new driver code.
The remaining patches enable these interfaces on the Khadas VIM4
board, including the power regulators, the SDIO power sequence and
32.768kHz PWM clock required by the BCM43752 Wi-Fi module, and the
board-specific MMC controller configurations.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Changes in v4:
- Address potential DT binding API break from Xianwei's feedback.
- Change underscore to dash in pinctrl nodes names from Xianwei's feedback.
- Link to v3: https://lore.kernel.org/r/20260323-add-emmc-t7-vim4-v3-0-5159d90a984c@aliel.fr
Changes in v3:
- Remove all changes about fixed pll clock from analog controller.
- Use clocks retrieved through SCMI.
- Add other MMC controllers
- Manage Wi-Fi module enablement.
- Link to v2: https://lore.kernel.org/r/20260218101709.35450-1-linux-kernel-dev@aliel.fr
Changes in v2:
- Resend v1 patches as attached to the first patch.
- Link to v1: https://lore.kernel.org/r/20260218101709.35450-1-linux-kernel-dev@aliel.fr
---
Ronald Claveau (9):
arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
dt-bindings: mmc: amlogic: Add compatible for T7 mmc
arm64: dts: amlogic: t7: Add MMC controller nodes
arm64: dts: amlogic: t7: Add PWM pinctrl nodes
arm64: dts: amlogic: t7: Add PWM controller nodes
arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
arm64: dts: amlogic: t7: khadas-vim4: Add SDIO power sequence and WiFi clock
dt-bindings: net: wireless: brcm: Add compatible for bcm43752
arm64: dts: amlogic: t7: khadas-vim4: Add MMC nodes
.../bindings/mmc/amlogic,meson-gx-mmc.yaml | 4 +
.../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 202 ++++++++++++-
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 336 +++++++++++++++++++++
4 files changed, 542 insertions(+), 1 deletion(-)
---
base-commit: f6eb9ae8b9fc13c3971e4a6d1e8442f253001f36
change-id: 20260320-add-emmc-t7-vim4-6ad16e94614f
prerequisite-message-id: <20260313070022.700437-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* [PATCH v4 3/9] arm64: dts: amlogic: t7: Add MMC controller nodes
From: Ronald Claveau @ 2026-03-25 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Ronald Claveau
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-0-44c7b4a5e459@aliel.fr>
Add device tree nodes for the three MMC controllers available
on the Amlogic T7 SoC, using amlogic,meson-axg-mmc as fallback compatible.
All nodes are disabled by default and should be
enabled in the board-specific DTS file.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 39 +++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 016b5429c8d1b..62c87d0ef7065 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -374,6 +374,45 @@ sec_ao: ao-secure@10220 {
reg = <0x0 0x10220 0x0 0x140>;
amlogic,has-chip-id;
};
+
+ sd_emmc_a: mmc@88000 {
+ compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
+ reg = <0x0 0x88000 0x0 0x800>;
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_A>,
+ <&clkc_periphs CLKID_SD_EMMC_A>,
+ <&scmi_clk CLKID_FCLK_DIV2>;
+ clock-names = "core", "clkin0", "clkin1";
+ assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_A_SEL>;
+ assigned-clock-parents = <&xtal>;
+ };
+
+ sd_emmc_b: mmc@8a000 {
+ compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
+ reg = <0x0 0x8a000 0x0 0x800>;
+ interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_B>,
+ <&clkc_periphs CLKID_SD_EMMC_B>,
+ <&scmi_clk CLKID_FCLK_DIV2>;
+ clock-names = "core", "clkin0", "clkin1";
+ assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_B_SEL>;
+ assigned-clock-parents = <&xtal>;
+ };
+
+ sd_emmc_c: mmc@8c000 {
+ compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
+ reg = <0x0 0x8c000 0x0 0x800>;
+ interrupts = <GIC_SPI 178 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_C>,
+ <&clkc_periphs CLKID_SD_EMMC_C>,
+ <&scmi_clk CLKID_FCLK_DIV2>;
+ clock-names = "core", "clkin0", "clkin1";
+ assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_C_SEL>;
+ assigned-clock-parents = <&xtal>;
+ };
};
};
--
2.49.0
^ permalink raw reply related
* [PATCH v4 4/9] arm64: dts: amlogic: t7: Add PWM pinctrl nodes
From: Ronald Claveau @ 2026-03-25 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Ronald Claveau
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-0-44c7b4a5e459@aliel.fr>
These pinctrl nodes are required by the PWM drivers to configure
pin muxing at runtime.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 136 ++++++++++++++++++++++++++++
1 file changed, 136 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 62c87d0ef7065..eb09a26bcd0e0 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -307,6 +307,142 @@ mux {
};
};
+ pwm_a_pins: pwm-a {
+ mux {
+ groups = "pwm_a";
+ function = "pwm_a";
+ bias-disable;
+ };
+ };
+
+ pwm_ao_a_pins: pwm-ao-a {
+ mux {
+ groups = "pwm_ao_a";
+ function = "pwm_ao_a";
+ bias-disable;
+ };
+ };
+
+ pwm_ao_b_pins: pwm-ao-b {
+ mux {
+ groups = "pwm_ao_b";
+ function = "pwm_ao_b";
+ bias-disable;
+ };
+ };
+
+ pwm_ao_c_pins: pwm-ao-c {
+ mux {
+ groups = "pwm_ao_c";
+ function = "pwm_ao_c";
+ bias-disable;
+ };
+ };
+
+ pwm_ao_c_hiz_pins: pwm-ao-c-hiz {
+ mux {
+ groups = "pwm_ao_c_hiz";
+ function = "pwm_ao_c_hiz";
+ bias-disable;
+ };
+ };
+
+ pwm_ao_d_pins: pwm-ao-d {
+ mux {
+ groups = "pwm_ao_d";
+ function = "pwm_ao_d";
+ bias-disable;
+ };
+ };
+
+ pwm_ao_e_pins: pwm-ao-e {
+ mux {
+ groups = "pwm_ao_e";
+ function = "pwm_ao_e";
+ bias-disable;
+ };
+ };
+
+ pwm_ao_f_pins: pwm-ao-f {
+ mux {
+ groups = "pwm_ao_f";
+ function = "pwm_ao_f";
+ bias-disable;
+ };
+ };
+
+ pwm_ao_g_pins: pwm-ao-g {
+ mux {
+ groups = "pwm_ao_g";
+ function = "pwm_ao_g";
+ bias-disable;
+ };
+ };
+
+ pwm_ao_g_hiz_pins: pwm-ao-g-hiz {
+ mux {
+ groups = "pwm_ao_g_hiz";
+ function = "pwm_ao_g_hiz";
+ bias-disable;
+ };
+ };
+
+ pwm_ao_h_pins: pwm-ao-h {
+ mux {
+ groups = "pwm_ao_h";
+ function = "pwm_ao_h";
+ bias-disable;
+ };
+ };
+
+ pwm_b_pins: pwm-b {
+ mux {
+ groups = "pwm_b";
+ function = "pwm_b";
+ bias-disable;
+ };
+ };
+
+ pwm_c_pins: pwm-c {
+ mux {
+ groups = "pwm_c";
+ function = "pwm_c";
+ bias-disable;
+ };
+ };
+
+ pwm_d_pins: pwm-d {
+ mux {
+ groups = "pwm_d";
+ function = "pwm_d";
+ bias-disable;
+ };
+ };
+
+ pwm_e_pins: pwm-e {
+ mux {
+ groups = "pwm_e";
+ function = "pwm_e";
+ bias-disable;
+ };
+ };
+
+ pwm_f_pins: pwm-f {
+ mux {
+ groups = "pwm_f";
+ function = "pwm_f";
+ bias-disable;
+ };
+ };
+
+ pwm_vs_pins: pwm-vs {
+ mux {
+ groups = "pwm_vs";
+ function = "pwm_vs";
+ bias-disable;
+ };
+ };
+
sdcard_pins: sdcard {
mux {
groups = "sdcard_d0",
--
2.49.0
^ permalink raw reply related
* [PATCH v4 1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
From: Ronald Claveau @ 2026-03-25 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Ronald Claveau
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-0-44c7b4a5e459@aliel.fr>
These pinctrl nodes are required by the eMMC, SD card and SDIO drivers
to configure pin muxing at runtime.
- eMMC: control, 4-bit/8-bit data, data strobe and clock gate pins
- SD card: data, clock, command and clock gate pins
- SDIO: data, clock, command and clock gate pins
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 98 +++++++++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 6510068bcff92..016b5429c8d1b 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -250,6 +250,104 @@ gpio: bank@4000 {
#gpio-cells = <2>;
gpio-ranges = <&periphs_pinctrl 0 0 157>;
};
+
+ emmc_ctrl_pins: emmc-ctrl {
+ mux-0 {
+ groups = "emmc_cmd";
+ function = "emmc";
+ bias-pull-up;
+ };
+
+ mux-1 {
+ groups = "emmc_clk";
+ function = "emmc";
+ bias-disable;
+ };
+ };
+
+ emmc_data_4b_pins: emmc-data-4b {
+ mux-0 {
+ groups = "emmc_nand_d0",
+ "emmc_nand_d1",
+ "emmc_nand_d2",
+ "emmc_nand_d3";
+ function = "emmc";
+ bias-pull-up;
+ };
+ };
+
+ emmc_data_8b_pins: emmc-data-8b {
+ mux-0 {
+ groups = "emmc_nand_d0",
+ "emmc_nand_d1",
+ "emmc_nand_d2",
+ "emmc_nand_d3",
+ "emmc_nand_d4",
+ "emmc_nand_d5",
+ "emmc_nand_d6",
+ "emmc_nand_d7";
+ function = "emmc";
+ bias-pull-up;
+ };
+ };
+
+ emmc_ds_pins: emmc-ds {
+ mux {
+ groups = "emmc_nand_ds";
+ function = "emmc";
+ bias-pull-down;
+ };
+ };
+
+ emmc_clk_gate_pins: emmc-clk-gate {
+ mux {
+ groups = "GPIOB_8";
+ function = "gpio_periphs";
+ bias-pull-down;
+ };
+ };
+
+ sdcard_pins: sdcard {
+ mux {
+ groups = "sdcard_d0",
+ "sdcard_d1",
+ "sdcard_d2",
+ "sdcard_d3",
+ "sdcard_clk",
+ "sdcard_cmd";
+ function = "sdcard";
+ bias-pull-up;
+ };
+ };
+
+ sdcard_clk_gate_pins: sdcard-clk-gate {
+ mux {
+ groups = "GPIOC_4";
+ function = "gpio_periphs";
+ bias-pull-down;
+ };
+ };
+
+ sdio_pins: sdio {
+ mux-0 {
+ groups = "sdio_d0",
+ "sdio_d1",
+ "sdio_d2",
+ "sdio_d3",
+ "sdio_clk",
+ "sdio_cmd";
+ function = "sdio";
+ bias-pull-up;
+ };
+ };
+
+ sdio_clk_gate_pins: sdio-clk-gate {
+ mux {
+ groups = "GPIOX_4";
+ function = "gpio_periphs";
+ bias-pull-up;
+ };
+ };
};
gpio_intc: interrupt-controller@4080 {
--
2.49.0
^ permalink raw reply related
* [PATCH v4 2/9] dt-bindings: mmc: amlogic: Add compatible for T7 mmc
From: Ronald Claveau @ 2026-03-25 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Ronald Claveau
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-0-44c7b4a5e459@aliel.fr>
Add amlogic,t7-mmc compatible string, falling back to amlogic,meson-axg-mmc
as the T7 MMC controller is compatible with the AXG implementation.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
index 57646575a13f8..976f36de2091c 100644
--- a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
@@ -19,6 +19,10 @@ allOf:
properties:
compatible:
oneOf:
+ - items:
+ - enum:
+ - amlogic,t7-mmc
+ - const: amlogic,meson-axg-mmc
- const: amlogic,meson-axg-mmc
- items:
- const: amlogic,meson-gx-mmc
--
2.49.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox