* Re: [PATCH v5 8/8] futex: Use runtime constants for __futex_hash() hot path
From: Peter Zijlstra @ 2026-07-01 7:57 UTC (permalink / raw)
To: K Prateek Nayak
Cc: Arnd Bergmann, Thomas Gleixner, Ingo Molnar,
Sebastian Andrzej Siewior, Borislav Petkov, Dave Hansen, x86,
Catalin Marinas, Will Deacon, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, Samuel Holland, Charlie Jenkins, linux-arm-kernel,
linux-riscv, linux-s390, H. Peter Anvin, Thomas Huth,
Sean Christopherson, Jisheng Zhang, Alexandre Ghiti,
Christian Borntraeger, Sven Schnelle
In-Reply-To: <20260630045531.3939-9-kprateek.nayak@amd.com>
On Tue, Jun 30, 2026 at 04:55:31AM +0000, K Prateek Nayak wrote:
> From: Peter Zijlstra <peterz@infradead.org>
>
> Runtime constify the read-only after init data __futex_shift(shift_32),
> __futex_mask(mask_32), and __futex_queues(ptr) used in __futex_hash()
> hot path to avoid referencing global variable.
>
> This also allows __futex_queues to be allocated dynamically to
> "nr_node_ids" slots instead of reserving config dependent MAX_NUMNODES
> (1 << CONFIG_NODES_SHIFT) worth of slots upfront.
>
> Runtime constants are initialized before their first access and
> runtime_const_init() provides necessary barrier to ensure subsequent
> accesses are not reordered against their initialization.
>
> No functional changes intended.
>
> [ prateek: Dynamically allocate __futex_queues, mark the global data
> __ro_after_init since they are constified after futex_init(). ]
>
> Link: https://patch.msgid.link/20260227161841.GH606826@noisy.programming.kicks-ass.net
> Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> # MAX_NUMNODES bloat
> Not-yet-signed-off-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
The big $1M question: does it actually make it go faster? The whole
point here was performance, right? But I'm not seeing numbers showing
how awesome these patches are.
^ permalink raw reply
* Re: [PATCH v2 9/9] vdso/gettimeofday: Verify COMPAT_32BIT_TIME interactions
From: Philippe Mathieu-Daudé @ 2026-07-01 7:51 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S. Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
Arnd Bergmann, linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-9-520d194640dd@linutronix.de>
On 30/6/26 09:38, Thomas WeiÃschuh wrote:
> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> provide any 32-bit time related functionality.
>
> Add some build-time validations to make sure the architecture-specific
> glue satisfies this requirement.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> lib/vdso/gettimeofday.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 8/9] sparc: vdso: Respect COMPAT_32BIT_TIME
From: Philippe Mathieu-Daudé @ 2026-07-01 7:50 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S. Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
Arnd Bergmann, linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-8-520d194640dd@linutronix.de>
On 30/6/26 09:38, Thomas WeiÃschuh wrote:
> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> provide any 32-bit time related functionality. This is the intended
> effect of the kconfig option and also the fallback system calls would
> also not be implemented.
>
> Currently the kconfig option does not affect the gettimeofday() syscall,
> so also keep that in the vDSO.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> arch/sparc/vdso/vclock_gettime.c | 4 ++++
> arch/sparc/vdso/vdso32/vdso32.lds.S | 6 ++++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v12 6/6] arm64: dts: s32g: describe GPIO and EIRQ resources in SIUL2 pinctrl node
From: Bartosz Golaszewski @ 2026-07-01 7:50 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, linux-gpio, linux-kernel,
NXP S32 Linux Team, Pengutronix Kernel Team, Vincent Guittot,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chester Lin, Matthias Brugger,
Ghennadi Procopciuc, Larisa Grigore, Lee Jones, Shawn Guo,
Sascha Hauer, Fabio Estevam, Dong Aisheng, Jacky Bai,
Greg Kroah-Hartman, Rafael J. Wysocki, Srinivas Kandagatla
In-Reply-To: <20260630125403.546375-7-khristineandreea.barbulescu@oss.nxp.com>
On Tue, 30 Jun 2026 14:54:03 +0200, Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> said:
> Update the SIUL2 pinctrl node to describe the additional register
> ranges and DT properties used by the updated SIUL2 driver.
>
> Besides the MSCR and IMCR ranges used for pinmux and pin
> configuration, the SIUL2 block also provides PGPDO and
> PGPDI registers for GPIO output and input operations,
> as well as an EIRQ register window for external interrupt configuration.
>
> The driver supports both legacy pinctrl-only DTs and
> extended DTs with GPIO and IRQ.
>
> Reflect these resources in the SIUL2 pinctrl node by adding:
> - the PGPDO and PGPDI register ranges
> - the EIRQ register range
> - gpio-controller, #gpio-cells and gpio-ranges
> - interrupt-controller, #interrupt-cells and interrupts
>
> Keep the hardware description aligned with the updated SIUL2
> driver, where pinctrl, GPIO data access and the EIRQ register
> block are described under the same device node.
>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v12 5/6] pinctrl: s32cc: implement GPIO functionality
From: Bartosz Golaszewski @ 2026-07-01 7:50 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, linux-gpio, linux-kernel,
NXP S32 Linux Team, Pengutronix Kernel Team, Vincent Guittot,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chester Lin, Matthias Brugger,
Ghennadi Procopciuc, Larisa Grigore, Lee Jones, Shawn Guo,
Sascha Hauer, Fabio Estevam, Dong Aisheng, Jacky Bai,
Greg Kroah-Hartman, Rafael J. Wysocki, Srinivas Kandagatla
In-Reply-To: <20260630125403.546375-6-khristineandreea.barbulescu@oss.nxp.com>
On Tue, 30 Jun 2026 14:54:02 +0200, Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> said:
> From: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
>
> The updated SIUL2 block groups pinctrl, GPIO data access
> and interrupt control within the same hardware unit.
> The SIUL2 driver is therefore structured as a monolithic
> pinctrl/GPIO driver.
>
> GPIO data access and direction handling are implemented using the
> gpio-regmap library backed by a virtual regmap. The virtual regmap
> translates the gpio-regmap register model to the underlying SIUL2
> registers: MSCR for direction, PGPDI for input values and PGPDO for
> output values.
>
> The existing pinctrl GPIO callbacks are used for the request/free path:
> they switch the pad to GPIO mode on request and restore the previous
> MSCR configuration when the GPIO is released.
>
> This change came as a result of upstream review in the
> following series:
> https://lore.kernel.org/linux-gpio/20260120115923.3463866-4-khristineandreea.barbulescu@oss.nxp.com/T/#m543c9edbdde74bdc68b6a2364e8b975356c33043
> https://lore.kernel.org/all/20260504131148.3622697-7-khristineandreea.barbulescu@oss.nxp.com/
>
> Support both SIUL2 DT layouts:
> - legacy pinctrl-only binding
> - extended pinctrl/GPIO/irqchip binding
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 5/9] ARM: VDSO: Respect COMPAT_32BIT_TIME
From: Philippe Mathieu-Daudé @ 2026-07-01 7:49 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S. Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
Arnd Bergmann, linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-5-520d194640dd@linutronix.de>
On 30/6/26 09:38, Thomas WeiÃschuh wrote:
> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> provide any 32-bit time related functionality. This is the intended
> effect of the kconfig option and also the fallback system calls would
> also not be implemented.
>
> Currently the kconfig option does not affect the gettimeofday() syscall,
> so also keep that in the vDSO.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> arch/arm/vdso/vdso.lds.S | 2 ++
> arch/arm/vdso/vgettimeofday.c | 14 ++++++++------
> 2 files changed, 10 insertions(+), 6 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 4/9] arm64: vdso32: Respect COMPAT_32BIT_TIME
From: Philippe Mathieu-Daudé @ 2026-07-01 7:49 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S. Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
Arnd Bergmann, linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-4-520d194640dd@linutronix.de>
On 30/6/26 09:38, Thomas WeiÃschuh wrote:
> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> provide any 32-bit time related functionality. This is the intended
> effect of the kconfig option and also the fallback system calls would
> also not be implemented.
>
> Currently the kconfig option does not affect the gettimeofday() syscall,
> so also keep that in the vDSO.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> arch/arm64/kernel/vdso32/vdso.lds.S | 2 ++
> arch/arm64/kernel/vdso32/vgettimeofday.c | 14 ++++++++------
> 2 files changed, 10 insertions(+), 6 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 2/9] vdso/gettimeofday: Validate system call existence for time() and gettimeofday()
From: Philippe Mathieu-Daudé @ 2026-07-01 7:47 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S. Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
Arnd Bergmann, linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-2-520d194640dd@linutronix.de>
On 30/6/26 09:38, Thomas WeiÃschuh wrote:
> Not all architectures have the system calls for time() and
> gettimeofday(). When the system call is missing, the vDSO function
> should also not be present.
>
> Validate that.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> lib/vdso/gettimeofday.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v12 4/6] dt-bindings: pinctrl: s32g2-siul2: describe GPIO and EIRQ resources
From: Bartosz Golaszewski @ 2026-07-01 7:47 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, linux-gpio, linux-kernel,
NXP S32 Linux Team, Pengutronix Kernel Team, Vincent Guittot,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chester Lin, Matthias Brugger,
Ghennadi Procopciuc, Larisa Grigore, Lee Jones, Shawn Guo,
Sascha Hauer, Fabio Estevam, Dong Aisheng, Jacky Bai,
Greg Kroah-Hartman, Rafael J. Wysocki, Srinivas Kandagatla
In-Reply-To: <20260630125403.546375-5-khristineandreea.barbulescu@oss.nxp.com>
On Tue, 30 Jun 2026 14:54:01 +0200, Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> said:
> Extend the S32G2 SIUL2 pinctrl binding to describe the GPIO data and
> external interrupt resources present in the same SIUL2 hardware block.
>
> Besides the MSCR and IMCR registers used for pin multiplexing and pad
> configuration, SIUL2 also contains PGPDO and PGPDI registers
> for GPIO data and EIRQ registers for external interrupt control.
>
> Add GPIO controller properties because the SIUL2 block also provides
> GPIO functionality, and gpio-ranges are needed to describe the
> mapping between GPIO lines and pin controller pins.
>
> Document the interrupt controller properties. The SIUL2 block
> contains EIRQ hardware as part of the same register space. IRQ support
> itself will be added in a follow-up patch series.
>
> Update the example accordingly to show the complete SIUL2 register
> layout, including the GPIO data and EIRQ register windows.
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v3 2/2] memory: mtk-smi: Add mt8189 support
From: Congcong Yao @ 2026-07-01 7:44 UTC (permalink / raw)
To: Yong Wu, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-mediatek, linux-kernel, devicetree, linux-arm-kernel,
Project_Global_Chrome_Upstream_Group, jarried.lin, vince-wl.liu,
justin.yeh, Zhengnan Chen, Congcong Yao
In-Reply-To: <20260701074533.175803-1-Congcong.Yao@mediatek.com>
From: Zhengnan Chen <zhengnan.chen@mediatek.com>
Add the necessary platform data and ostdl setting to enable support
for mt8189 smi.
Signed-off-by: Zhengnan Chen <zhengnan.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Congcong Yao <congcong.yao@mediatek.com>
---
drivers/memory/mtk-smi.c | 44 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index aaeba8ab211e..f2d5462af681 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -401,6 +401,30 @@ static const u8 mtk_smi_larb_mt8188_ostd[][SMI_LARB_PORT_NR_MAX] = {
[25] = {0x01},
};
+static const u8 mtk_smi_larb_mt8189_ostd[][SMI_LARB_PORT_NR_MAX] = {
+ [0] = {0x8, 0x20, 0x20, 0x20, 0x20, 0x20, 0x10, 0x0,},
+ [1] = {0x8, 0x20, 0x20, 0x20, 0x20, 0x20, 0x10, 0x0,},
+ [2] = {0x7, 0x7, 0x4, 0x4, 0x0, 0x0, 0x2, 0x2, 0x7, 0x7, 0x0,},
+ [4] = {0x2F, 0x1E, 0x9, 0x1, 0x1, 0x1, 0x1, 0x2, 0x2, 0x5, 0x1, 0x17,},
+ [7] = {0x20, 0x2, 0x1, 0x1, 0x1, 0x4, 0x2, 0x1, 0x1, 0x2, 0x3, 0x2,
+ 0xA, 0xF, 0x4, 0x6, 0x5, 0x1,},
+ [9] = {0x6, 0x3, 0xC, 0x6, 0x1, 0x4, 0x3, 0x1, 0x2, 0x4, 0x5, 0x2,
+ 0x4, 0x2, 0x3, 0xB, 0x1, 0x4, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1,
+ 0x1, 0x1,},
+ [11] = {0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1,
+ 0x1, 0x1, 0x1, 0xB, 0x1, 0x4, 0x6, 0x5, 0x6, 0x1, 0x5, 0x2,
+ 0x9, 0x5,},
+ [13] = {0x2, 0x8, 0x8, 0x8, 0x4, 0x4, 0x4, 0x4, 0x4, 0xE, 0x4, 0x1,
+ 0x6, 0x6, 0x2,},
+ [14] = {0x1, 0x1, 0x1, 0x20, 0xE, 0x4, 0x8, 0x8, 0x6, 0x4,},
+ [16] = {0x1E, 0xC, 0x2, 0x8, 0xE, 0x2, 0x1E, 0x10, 0x4, 0x2, 0x2, 0x2,
+ 0x2, 0x2, 0x4, 0x2, 0x4,},
+ [17] = {0x1E, 0xC, 0x2, 0x8, 0xE, 0x2, 0x1E, 0x10, 0x4, 0x2, 0x2, 0x2,
+ 0x2, 0x2, 0x4, 0x2, 0x4,},
+ [19] = {0x2, 0x1, 0x3, 0x1,},
+ [20] = {0x7, 0x7, 0x3, 0x3, 0x1, 0x1,},
+};
+
static const u8 mtk_smi_larb_mt8192_ostd[][SMI_LARB_PORT_NR_MAX] = {
[0] = {0x2, 0x2, 0x28, 0xa, 0xc, 0x28,},
[1] = {0x2, 0x2, 0x18, 0x18, 0x18, 0xa, 0xc, 0x28,},
@@ -533,6 +557,13 @@ static const struct mtk_smi_larb_gen mtk_smi_larb_mt8188 = {
.ostd = mtk_smi_larb_mt8188_ostd,
};
+static const struct mtk_smi_larb_gen mtk_smi_larb_mt8189 = {
+ .config_port = mtk_smi_larb_config_port_gen2_general,
+ .flags_general = MTK_SMI_FLAG_THRT_UPDATE | MTK_SMI_FLAG_SW_FLAG |
+ MTK_SMI_FLAG_SLEEP_CTL | MTK_SMI_FLAG_CFG_PORT_SEC_CTL,
+ .ostd = mtk_smi_larb_mt8189_ostd,
+};
+
static const struct mtk_smi_larb_gen mtk_smi_larb_mt8192 = {
.config_port = mtk_smi_larb_config_port_gen2_general,
.ostd = mtk_smi_larb_mt8192_ostd,
@@ -556,6 +587,7 @@ static const struct of_device_id mtk_smi_larb_of_ids[] = {
{.compatible = "mediatek,mt8183-smi-larb", .data = &mtk_smi_larb_mt8183},
{.compatible = "mediatek,mt8186-smi-larb", .data = &mtk_smi_larb_mt8186},
{.compatible = "mediatek,mt8188-smi-larb", .data = &mtk_smi_larb_mt8188},
+ {.compatible = "mediatek,mt8189-smi-larb", .data = &mtk_smi_larb_mt8189},
{.compatible = "mediatek,mt8192-smi-larb", .data = &mtk_smi_larb_mt8192},
{.compatible = "mediatek,mt8195-smi-larb", .data = &mtk_smi_larb_mt8195},
{}
@@ -808,6 +840,16 @@ static const struct mtk_smi_common_plat mtk_smi_common_mt8188_vpp = {
.init = mtk_smi_common_mt8195_init,
};
+static const struct mtk_smi_common_plat mtk_smi_common_mt8189 = {
+ .type = MTK_SMI_GEN2,
+ .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(3) | F_MMU1_LARB(5) |
+ F_MMU1_LARB(7),
+};
+
+static const struct mtk_smi_common_plat mtk_smi_sub_common_mt8189 = {
+ .type = MTK_SMI_GEN2_SUB_COMM,
+};
+
static const struct mtk_smi_common_plat mtk_smi_common_mt8192 = {
.type = MTK_SMI_GEN2,
.has_gals = true,
@@ -852,6 +894,8 @@ static const struct of_device_id mtk_smi_common_of_ids[] = {
{.compatible = "mediatek,mt8186-smi-common", .data = &mtk_smi_common_mt8186},
{.compatible = "mediatek,mt8188-smi-common-vdo", .data = &mtk_smi_common_mt8188_vdo},
{.compatible = "mediatek,mt8188-smi-common-vpp", .data = &mtk_smi_common_mt8188_vpp},
+ {.compatible = "mediatek,mt8189-smi-common", .data = &mtk_smi_common_mt8189},
+ {.compatible = "mediatek,mt8189-smi-sub-common", .data = &mtk_smi_sub_common_mt8189},
{.compatible = "mediatek,mt8192-smi-common", .data = &mtk_smi_common_mt8192},
{.compatible = "mediatek,mt8195-smi-common-vdo", .data = &mtk_smi_common_mt8195_vdo},
{.compatible = "mediatek,mt8195-smi-common-vpp", .data = &mtk_smi_common_mt8195_vpp},
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: memory-controllers: mtk-smi: Add support for mt8189
From: Congcong Yao @ 2026-07-01 7:44 UTC (permalink / raw)
To: Yong Wu, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-mediatek, linux-kernel, devicetree, linux-arm-kernel,
Project_Global_Chrome_Upstream_Group, jarried.lin, vince-wl.liu,
justin.yeh, Zhengnan Chen, Congcong Yao
In-Reply-To: <20260701074533.175803-1-Congcong.Yao@mediatek.com>
From: Zhengnan Chen <zhengnan.chen@mediatek.com>
Add smi larb, common and sub-commom binding description for mt8189.
About what smi-sub-common is, please check the below diagram,
we add it in mediatek,smi-common.yaml file.
Signed-off-by: Zhengnan Chen <zhengnan.chen@mediatek.com>
Signed-off-by: Congcong Yao <congcong.yao@mediatek.com>
---
.../mediatek,smi-common.yaml | 18 ++++++++++++++++++
.../memory-controllers/mediatek,smi-larb.yaml | 3 +++
2 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
index 0762e0ff66ef..4e1deeff92b1 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
@@ -25,6 +25,21 @@ description: |
SMI generation 1 to transform the smi clock into emi clock domain, but that is
not needed for SMI generation 2.
+ The smi-common connects with smi-larb and IOMMU. The maximum inputs number of
+ a smi-common is 8. In SMI generation 2, the engines number may be over 8.
+ In this case, we use a smi-sub-common to merge some larbs.
+ The block diagram something is like:
+
+ IOMMU
+ | |
+ smi-common
+ ---------------------------
+ | | ...
+ larb0 sub-common ... <-max number is 8
+ ----------------
+ | | ...
+ larb1 larbX ... <-max number is 8
+
properties:
compatible:
oneOf:
@@ -40,6 +55,8 @@ properties:
- mediatek,mt8186-smi-common
- mediatek,mt8188-smi-common-vdo
- mediatek,mt8188-smi-common-vpp
+ - mediatek,mt8189-smi-common
+ - mediatek,mt8189-smi-sub-common
- mediatek,mt8192-smi-common
- mediatek,mt8195-smi-common-vdo
- mediatek,mt8195-smi-common-vpp
@@ -108,6 +125,7 @@ allOf:
compatible:
contains:
enum:
+ - mediatek,mt8189-smi-sub-common
- mediatek,mt8195-smi-sub-common
then:
required:
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
index 2e7fac4b5094..9a5dafd7c07e 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
@@ -27,6 +27,7 @@ properties:
- mediatek,mt8183-smi-larb
- mediatek,mt8186-smi-larb
- mediatek,mt8188-smi-larb
+ - mediatek,mt8189-smi-larb
- mediatek,mt8192-smi-larb
- mediatek,mt8195-smi-larb
@@ -85,6 +86,7 @@ allOf:
- mediatek,mt8183-smi-larb
- mediatek,mt8186-smi-larb
- mediatek,mt8188-smi-larb
+ - mediatek,mt8189-smi-larb
- mediatek,mt8195-smi-larb
then:
@@ -119,6 +121,7 @@ allOf:
- mediatek,mt6779-smi-larb
- mediatek,mt8186-smi-larb
- mediatek,mt8188-smi-larb
+ - mediatek,mt8189-smi-larb
- mediatek,mt8192-smi-larb
- mediatek,mt8195-smi-larb
--
2.43.0
^ permalink raw reply related
* [PATCH v3 0/2] MT8189 SMI SUPPORT
From: Congcong Yao @ 2026-07-01 7:44 UTC (permalink / raw)
To: Yong Wu, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-mediatek, linux-kernel, devicetree, linux-arm-kernel,
Project_Global_Chrome_Upstream_Group, jarried.lin, vince-wl.liu,
justin.yeh, Congcong Yao
Based on tag: next-20260629, linux-next/master
This patchset add mt8189 smi support.
---
Changes in v3:
- Change the clock numbers of smi-sub-common to minium 3
- Link to v2:
https://lore.kernel.org/linux-mediatek/20260427070444.20247-1-zhengnan.chen@mediatek.com/
---
Zhengnan Chen (2):
dt-bindings: memory-controllers: mtk-smi: Add support for mt8189
memory: mtk-smi: Add mt8189 support
.../mediatek,smi-common.yaml | 18 ++++++++
.../memory-controllers/mediatek,smi-larb.yaml | 3 ++
drivers/memory/mtk-smi.c | 44 +++++++++++++++++++
3 files changed, 65 insertions(+)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 0/5] arm64: dts: describe the Lynx 10G and 28G SerDes blocks for Layerscape SoCs
From: Ioana Ciornei @ 2026-07-01 7:42 UTC (permalink / raw)
To: Frank Li
Cc: Frank.Li, robh, krzk+dt, conor+dt, devicetree, vladimir.oltean,
linux-arm-kernel, linux-kernel
In-Reply-To: <akQlJlYaZkaZI_jh@lizhi-Precision-Tower-5810>
On Tue, Jun 30, 2026 at 04:20:54PM -0400, Frank Li wrote:
> On Tue, Jun 30, 2026 at 02:04:54PM +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 patch also transitions the LX2160A SoC dtsi to use the
> > device-specific Lynx28G SerDes compatible.
> >
>
> Next time please cc imx@lists.linux.dev, otherwise, patchwork can't see
> this patch.
Ok, sure. Will send shortly a v2 integrating some changes generated by
the sashiko review.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Krzysztof Kozlowski @ 2026-07-01 7:35 UTC (permalink / raw)
To: Markus Probst
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <20260630-rtc_s35390a_int1-v1-1-1b2239e16be2@posteo.de>
On Tue, Jun 30, 2026 at 07:22:21PM +0000, Markus Probst wrote:
> Synology NAS devices use the output pin for interrupt signal 1 to wake up
> the system.
>
> Move devicetree bindings for sii,s35390a into its own file.
> Add sii,wakealarm-output-pin property to enable the use of the output
> pin for interrupt signal 1 for the wake alarm, which makes it possible to
> set an wake alarm on Synology NAS devices.
>
> Signed-off-by: Markus Probst <markus.probst@posteo.de>
> ---
> .../devicetree/bindings/rtc/sii,s35390a.yaml | 54 ++++++++++++++++++++++
> .../devicetree/bindings/rtc/trivial-rtc.yaml | 3 --
> MAINTAINERS | 1 +
> include/dt-bindings/rtc/s35390a.h | 9 ++++
> 4 files changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
> new file mode 100644
> index 000000000000..31a578673870
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/sii,s35390a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: S-35390A 2-WIRE REAL-TIME CLOCK
> +
> +maintainers:
> + - Alexandre Belloni <alexandre.belloni@bootlin.com>
This should be someone caring about this hardware.
> +
> +description:
> + The S-35390A is a CMOS 2-wire real-time clock IC which operates with the
> + very low current consumption in the wide range of operation voltage.
> +
> +allOf:
> + - $ref: rtc.yaml#
> +
> +properties:
> + compatible:
> + const: sii,s35390a
> +
> + reg:
> + maxItems: 1
> +
> + sii,wakealarm-output-pin:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [1, 2]
> + description: |
> + The output pin to wake up the system.
> + Default will use the output pin for interrupt signal 2.
> + <S35390A_OUTPUT_PIN_INT1> : Output pin for interrupt signal 1
> + <S35390A_OUTPUT_PIN_INT2> : Output pin for interrupt signal 2
Does that mean device generates the interrupts?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: can: rockchip_canfd: add compatible for the RK3588 variant
From: Krzysztof Kozlowski @ 2026-07-01 7:33 UTC (permalink / raw)
To: Heiko Stuebner
Cc: mkl, mailhol, kernel, robh, krzk+dt, conor+dt, shawn.lin,
linux-can, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-2-heiko@sntech.de>
On Tue, Jun 30, 2026 at 06:43:31PM +0200, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner@cherry.de>
>
> The RK3588 uses a variant of the CAN(-FD) controller introduced at first
> with the RK3568 SoC.
>
> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
> ---
> .../devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> index a077c0330013..02211ea3ec41 100644
> --- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> @@ -20,6 +20,7 @@ properties:
> - items:
> - const: rockchip,rk3568v3-canfd
> - const: rockchip,rk3568v2-canfd
> + - const: rockchip,rk3588-canfd
So this is just an enum with the first entry.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
From: Jie Gan @ 2026-07-01 7:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin, Konrad Dybcio,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <9aa63427-ba41-436d-ab19-a533082d336a@kernel.org>
On 7/1/2026 3:26 PM, Krzysztof Kozlowski wrote:
> On 01/07/2026 09:16, Jie Gan wrote:
>>
>>
>> On 7/1/2026 2:57 PM, Krzysztof Kozlowski wrote:
>>> On Wed, Jul 01, 2026 at 09:53:41AM +0800, Jie Gan wrote:
>>>> The TNOC compatible previously only allowed the two-string AMBA form
>>>> "qcom,coresight-tnoc", "arm,primecell", which forces the device onto the
>>>> AMBA bus.
>>>>
>>>> Convert the compatible to a oneOf and add a standalone
>>>> "qcom,coresight-agtnoc" compatible alongside the existing AMBA form. The
>>>> standalone string carries no "arm,primecell" entry, so the device is
>>>> created on the platform bus instead of the AMBA bus.
>>>
>>> That's a Linux driver specific reason, so not a valid one.
>>>
>>> Describe the hardware instead.
>>>
>>> Also, you do not get other compatible for the same device.
>>
>> The device is intended to be discovered and probed via the AMBA bus.
>> However, due to a hardware issue, AMBA probing does not work correctly.
>> While adding the arm,primecell-periphid property would allow the
>
> If this is not AMBA bus device, then drop primecell compatible.
Will drop the primecell compatible and update the description.
>
>> existing AMBA driver to bind, but I think that's a temp WA. As
>> Suzuki/Leo pointed out, we should not add the property to pretend the
>> device as an AMBA device.
>>
>> Instead, I introduced a dedicated compatible string so the device can be
>> handled by the existing platform driver without relying on the missing
>
> As I said, that's a Linux driver specific reason, so not a valid one.
>
> Fix your drivers if you insist on that.
>
>> AMBA primecell identification. The purpose of the new compatible is to
>> clearly distinguish this platform-specific case from the standard
>> AMBA-based implementation. Or shall I re-use the existing compatible
>> "qcom,coresight-tnoc" as platform standalone compatible?
>>
>> We already have a similar pattern for the interconnect TraceNoC device,
>> which uses the platform-specific compatible string qcom,coresight-itnoc.
> I do not see there a fake, duplicated compatible for the same device.
> Can you elaborate how is that relevant?
Will fix it by removing AMBA related description.
Shall I update the clock name from apb_pclk to apb as a platform device?
Thanks,
Jie
>
> Best regards,
> Krzysztof
^ permalink raw reply
* RE: [PATCH] hwrng: xilinx-trng: propagate timeout before any data is read
From: Jain, Harsh (AECG-SSW) @ 2026-07-01 7:31 UTC (permalink / raw)
To: Pengpeng Hou, Botcha, Mounika, Olivia Mackall, Herbert Xu,
Simek, Michal, linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Pandey, Radhey Shyam, Savitala, Sarat Chand
In-Reply-To: <20260623060728.18906-1-pengpeng@iscas.ac.cn>
AMD General
Reviewed-by : Harsh Jain <h.jain@amd.com>
> -----Original Message-----
> From: Pengpeng Hou <pengpeng@iscas.ac.cn>
> Sent: Tuesday, June 23, 2026 11:37 AM
> To: Botcha, Mounika <Mounika.Botcha@amd.com>; Jain, Harsh (AECG-SSW)
> <h.jain@amd.com>; Olivia Mackall <olivia@selenic.com>; Herbert Xu
> <herbert@gondor.apana.org.au>; Simek, Michal <michal.simek@amd.com>; linux-
> crypto@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org
> Cc: Pengpeng Hou <pengpeng@iscas.ac.cn>
> Subject: [PATCH] hwrng: xilinx-trng: propagate timeout before any data is read
>
>
> xtrng_readblock32() polls for 16-byte chunks but returns the number of
> bytes read even when the first poll times out. Its caller then treats a
> zero return as a short successful read, and partial reads for full
> 32-byte blocks can make the tail copy use a fixed block offset rather
> than the amount already produced.
>
> Return the poll error when no data has been read, preserve partial
> positive returns after some data is available, stop the generator on all
> collection exits, and append tail bytes at the current output count.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/char/hw_random/xilinx-trng.c | 32 +++++++++++++++++++++-------
> 1 file changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/hw_random/xilinx-trng.c b/drivers/char/hw_random/xilinx-
> trng.c
> index f615d5adddde..4a1a168bb46a 100644
> --- a/drivers/char/hw_random/xilinx-trng.c
> +++ b/drivers/char/hw_random/xilinx-trng.c
> @@ -87,8 +87,8 @@ static void xtrng_softreset(struct xilinx_rng *rng)
> xtrng_readwrite32(rng->rng_base + TRNG_CTRL_OFFSET,
> TRNG_CTRL_PRNGSRST_MASK, 0);
> }
>
> -/* Return no. of bytes read */
> -static size_t xtrng_readblock32(void __iomem *rng_base, __be32 *buf, int
> blocks32, bool wait)
> +/* Return no. of bytes read or a negative error before any data is read. */
> +static int xtrng_readblock32(void __iomem *rng_base, __be32 *buf, int blocks32,
> bool wait)
> {
> int read = 0, ret;
> int timeout = 1;
> @@ -103,8 +103,11 @@ static size_t xtrng_readblock32(void __iomem *rng_base,
> __be32 *buf, int blocks3
> ret = readl_poll_timeout(rng_base + TRNG_STATUS_OFFSET, val,
> (val & TRNG_STATUS_QCNT_MASK) ==
> TRNG_STATUS_QCNT_16_BYTES, !!wait, timeout);
> - if (ret)
> + if (ret) {
> + if (!read)
> + return ret;
> break;
> + }
>
> for (idx = 0; idx < TRNG_READ_4_WORD; idx++) {
> *(buf + read) = cpu_to_be32(ioread32(rng_base +
> TRNG_CORE_OUTPUT_OFFSET));
> @@ -119,27 +122,40 @@ static int xtrng_collect_random_data(struct xilinx_rng
> *rng, u8 *rand_gen_buf,
> {
> u8 randbuf[TRNG_SEC_STRENGTH_BYTES];
> int byteleft, blocks, count = 0;
> + int full_blocks_bytes;
> int ret;
>
> byteleft = no_of_random_bytes & (TRNG_SEC_STRENGTH_BYTES - 1);
> blocks = no_of_random_bytes >> TRNG_SEC_STRENGTH_SHIFT;
> + full_blocks_bytes = blocks * TRNG_SEC_STRENGTH_BYTES;
> xtrng_readwrite32(rng->rng_base + TRNG_CTRL_OFFSET,
> TRNG_CTRL_PRNGSTART_MASK,
> TRNG_CTRL_PRNGSTART_MASK);
> if (blocks) {
> ret = xtrng_readblock32(rng->rng_base, (__be32 *)rand_gen_buf, blocks,
> wait);
> - if (!ret)
> - return 0;
> + if (ret <= 0) {
> + count = ret;
> + goto out_stop;
> + }
> count += ret;
> + if (ret < full_blocks_bytes)
> + goto out_stop;
> }
>
> if (byteleft) {
> ret = xtrng_readblock32(rng->rng_base, (__be32 *)randbuf, 1, wait);
> + if (ret < 0) {
> + if (!count)
> + count = ret;
> + goto out_stop;
> + }
> if (!ret)
> - return count;
> - memcpy(rand_gen_buf + (blocks * TRNG_SEC_STRENGTH_BYTES),
> randbuf, byteleft);
> - count += byteleft;
> + goto out_stop;
> + ret = min(ret, no_of_random_bytes - count);
> + memcpy(rand_gen_buf + count, randbuf, ret);
> + count += ret;
> }
>
> +out_stop:
> xtrng_readwrite32(rng->rng_base + TRNG_CTRL_OFFSET,
> TRNG_CTRL_PRNGMODE_MASK |
> TRNG_CTRL_PRNGSTART_MASK, 0U);
>
> --
> 2.50.1 (Apple Git-155)
^ permalink raw reply
* Re: [PATCH v6 3/5] mfd: aaeon: Add SRG-IMX8P MCU driver
From: Bartosz Golaszewski @ 2026-07-01 7:31 UTC (permalink / raw)
To: Thomas Perrot (Schneider Electric)
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
In-Reply-To: <20260630-dev-b4-aaeon-mcu-driver-v6-3-d66b5fcbd2f0@bootlin.com>
On Tue, 30 Jun 2026 14:51:13 +0200, "Thomas Perrot (Schneider
Electric)" <thomas.perrot@bootlin.com> said:
> Add Multi-Function Device (MFD) driver for the Aaeon SRG-IMX8P
> embedded controller. This driver provides the core I2C communication
> interface and registers child devices (GPIO and watchdog controllers).
>
> The driver implements a custom regmap bus over I2C to match the MCU's
> fixed 3-byte command format [opcode, arg, value]. Register addresses
> are encoded as 16-bit values (opcode << 8 | arg) using the
> AAEON_MCU_REG() macro defined in the shared header. The regmap
> instance is shared with child drivers via dev_get_regmap(). Concurrent
> I2C accesses from child drivers are serialized by regmap's built-in
> locking.
>
> I2C transfers use heap-allocated DMA-safe buffers rather than
> stack-allocated ones, as required by I2C controllers that perform DMA.
>
> Regmap caching is enabled (REGCACHE_MAPLE) with a volatile_reg
> callback that marks GPIO input read registers (opcode 0x72) and the
> watchdog status register (opcode 0x63, arg 0x02) as volatile. All
> other registers written by the driver (GPIO direction,
> GPO state, watchdog control) are stable and can be safely cached.
>
> Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
> ---
> MAINTAINERS | 2 +
> drivers/mfd/Kconfig | 11 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/aaeon-mcu.c | 205 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/aaeon-mcu.h | 40 +++++++++
> 5 files changed, 259 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea9d55f76f35..f91b6a1826d0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -191,6 +191,8 @@ M: Thomas Perrot <thomas.perrot@bootlin.com>
> R: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> S: Maintained
> F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
> +F: drivers/mfd/aaeon-mcu.c
> +F: include/linux/mfd/aaeon-mcu.h
>
> AAEON UPBOARD FPGA MFD DRIVER
> M: Thomas Richard <thomas.richard@bootlin.com>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index aace5766b38a..ed5169c7a683 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1561,6 +1561,17 @@ config ABX500_CORE
> remain unchanged when IC changes. Binding of the functions to
> actual register access is done by the IC core driver.
>
> +config MFD_AAEON_MCU
> + tristate "Aaeon SRG-IMX8P MCU Driver"
> + depends on I2C
> + select MFD_CORE
> + select REGMAP
> + help
> + Select this option to enable support for the Aaeon SRG-IMX8P
> + onboard microcontroller (MCU). This driver provides the core
> + functionality to communicate with the MCU over I2C. The MCU
> + provides GPIO and watchdog functionality.
> +
> config AB8500_CORE
> bool "ST-Ericsson AB8500 Mixed Signal Power Management chip"
> depends on ABX500_CORE && MFD_DB8500_PRCMU
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index e75e8045c28a..34db5b033584 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
> obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o
> obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
> obj-$(CONFIG_MFD_88PM886_PMIC) += 88pm886.o
> +obj-$(CONFIG_MFD_AAEON_MCU) += aaeon-mcu.o
> obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
> obj-$(CONFIG_MFD_SM501) += sm501.o
> obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o
> diff --git a/drivers/mfd/aaeon-mcu.c b/drivers/mfd/aaeon-mcu.c
> new file mode 100644
> index 000000000000..306aaac1bd60
> --- /dev/null
> +++ b/drivers/mfd/aaeon-mcu.c
> @@ -0,0 +1,205 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Aaeon MCU driver
> + *
> + * Copyright (C) 2026 Bootlin
> + * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> + * Author: Thomas Perrot <thomas.perrot@bootlin.com>
> + */
> +
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/mfd/aaeon-mcu.h>
> +#include <linux/mfd/core.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +struct aaeon_mcu {
> + struct i2c_client *client;
> + u8 *cmd; /* DMA-safe 3-byte write buffer [opcode, arg, value] */
> + u8 *response; /* DMA-safe 1-byte read buffer for MCU acknowledgment */
> +};
> +
> +static const struct mfd_cell aaeon_mcu_devs[] = {
> + MFD_CELL_BASIC("aaeon-mcu-wdt", NULL, NULL, 0, 0),
> + MFD_CELL_BASIC("aaeon-mcu-gpio", NULL, NULL, 0, 0),
> +};
> +
> +/* Number of bytes in a MCU command: [opcode, arg, value] */
> +#define AAEON_MCU_CMD_LEN 3
> +
> +/*
> + * Custom regmap bus for the Aaeon MCU I2C protocol.
> + *
> + * The MCU uses a fixed 3-byte command format [opcode, arg, value] followed
> + * by a 1-byte response. It requires a STOP condition between the command
> + * write and the response read, so two separate i2c_transfer() calls are
> + * issued. The regmap lock serialises concurrent accesses from the GPIO
> + * and watchdog child drivers.
> + *
> + * Register addresses are encoded as a 16-bit big-endian value where the
> + * high byte is the opcode and the low byte is the argument, matching the
> + * wire layout produced by regmap for reg_bits=16.
> + */
I would have preferred this implemented as a quirk in the i2c regmap but
won't die on that hill.
> +
> +static int aaeon_mcu_regmap_write(void *context, const void *data, size_t count)
> +{
> + struct aaeon_mcu *mcu = context;
> + struct i2c_client *client = mcu->client;
> + struct i2c_msg write_msg;
> + /* The MCU always sends a response byte after each command; discard it. */
> + struct i2c_msg response_msg;
> + int ret;
> +
> + memcpy(mcu->cmd, data, count);
> +
> + write_msg.addr = client->addr;
> + write_msg.flags = I2C_M_DMA_SAFE;
> + write_msg.buf = mcu->cmd;
> + write_msg.len = count;
> +
> + response_msg.addr = client->addr;
> + response_msg.flags = I2C_M_RD | I2C_M_DMA_SAFE;
> + response_msg.buf = mcu->response;
> + response_msg.len = 1;
> +
> + ret = i2c_transfer(client->adapter, &write_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + ret = i2c_transfer(client->adapter, &response_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static int aaeon_mcu_regmap_read(void *context, const void *reg_buf,
> + size_t reg_size, void *val_buf, size_t val_size)
> +{
> + struct aaeon_mcu *mcu = context;
> + struct i2c_client *client = mcu->client;
> + struct i2c_msg write_msg;
> + struct i2c_msg read_msg;
> + int ret;
> +
> + /*
> + * reg_buf holds the 2-byte big-endian register address [opcode, arg].
> + * Append a trailing 0x00 to form the full 3-byte MCU command.
> + */
> + mcu->cmd[0] = ((u8 *)reg_buf)[0];
> + mcu->cmd[1] = ((u8 *)reg_buf)[1];
> + mcu->cmd[2] = 0x00;
> +
> + write_msg.addr = client->addr;
> + write_msg.flags = I2C_M_DMA_SAFE;
> + write_msg.buf = mcu->cmd;
> + write_msg.len = AAEON_MCU_CMD_LEN;
> +
> + read_msg.addr = client->addr;
> + read_msg.flags = I2C_M_RD | I2C_M_DMA_SAFE;
> + read_msg.buf = val_buf;
> + read_msg.len = val_size;
> +
> + ret = i2c_transfer(client->adapter, &write_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + ret = i2c_transfer(client->adapter, &read_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static const struct regmap_bus aaeon_mcu_regmap_bus = {
> + .write = aaeon_mcu_regmap_write,
> + .read = aaeon_mcu_regmap_read,
> +};
> +
> +static bool aaeon_mcu_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + /*
> + * GPIO input registers are driven by external signals and can change
> + * at any time without CPU involvement, always read from hardware.
> + *
> + * The watchdog status register reflects hardware state and can change
> + * autonomously.
> + *
> + * All other registers are written by the driver and their values are
> + * stable, so they can be safely cached.
> + */
> + if ((reg >> 8) == AAEON_MCU_READ_GPIO_OPCODE)
> + return true;
> + if (reg == AAEON_MCU_REG(AAEON_MCU_CONTROL_WDT_OPCODE, 0x02))
> + return true;
> + return false;
> +}
> +
> +static const struct regmap_config aaeon_mcu_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 8,
> + .reg_format_endian = REGMAP_ENDIAN_BIG,
> + .max_register = AAEON_MCU_MAX_REGISTER,
> + .volatile_reg = aaeon_mcu_volatile_reg,
> + .cache_type = REGCACHE_MAPLE,
> +};
> +
> +static int aaeon_mcu_probe(struct i2c_client *client)
> +{
> + struct aaeon_mcu *ddata;
> + struct regmap *regmap;
> +
> + ddata = devm_kzalloc(&client->dev, sizeof(*ddata), GFP_KERNEL);
> + if (!ddata)
> + return -ENOMEM;
> +
> + ddata->client = client;
> +
> + ddata->cmd = devm_kzalloc(&client->dev, AAEON_MCU_CMD_LEN * sizeof(*ddata->cmd),
Why not devm_kcalloc()?
> + GFP_KERNEL);
> + if (!ddata->cmd)
> + return -ENOMEM;
> +
> + ddata->response = devm_kzalloc(&client->dev, sizeof(*ddata->response), GFP_KERNEL);
> + if (!ddata->response)
> + return -ENOMEM;
> +
> + regmap = devm_regmap_init(&client->dev, &aaeon_mcu_regmap_bus,
> + ddata, &aaeon_mcu_regmap_config);
> + if (IS_ERR(regmap))
> + return dev_err_probe(&client->dev, PTR_ERR(regmap),
> + "failed to initialize regmap\n");
> +
> + return devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO,
> + aaeon_mcu_devs, ARRAY_SIZE(aaeon_mcu_devs),
> + NULL, 0, NULL);
> +}
> +
> +static const struct of_device_id aaeon_mcu_of_match[] = {
> + { .compatible = "aaeon,srg-imx8p-mcu" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, aaeon_mcu_of_match);
> +
> +static struct i2c_driver aaeon_mcu_driver = {
> + .driver = {
> + .name = "aaeon-mcu",
> + .of_match_table = aaeon_mcu_of_match,
> + },
> + .probe = aaeon_mcu_probe,
> +};
> +module_i2c_driver(aaeon_mcu_driver);
> +
> +MODULE_DESCRIPTION("Aaeon MCU Driver");
> +MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/aaeon-mcu.h b/include/linux/mfd/aaeon-mcu.h
> new file mode 100644
> index 000000000000..3a1aeec85d60
> --- /dev/null
> +++ b/include/linux/mfd/aaeon-mcu.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Aaeon MCU driver definitions
> + *
> + * Copyright (C) 2026 Bootlin
> + * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> + * Author: Thomas Perrot <thomas.perrot@bootlin.com>
> + */
> +
> +#ifndef __LINUX_MFD_AAEON_MCU_H
> +#define __LINUX_MFD_AAEON_MCU_H
> +
> +/*
> + * MCU register address: the high byte is the command opcode, the low
> + * byte is the argument. This matches the 3-byte wire format
> + * [opcode, arg, value] used by the MCU I2C protocol.
> + */
> +#define AAEON_MCU_REG(op, arg) (((op) << 8) | (arg))
> +
> +/*
> + * Opcode for GPIO input reads. These registers are volatile, their values
> + * are driven by external signals and can change without CPU involvement.
> + * Used by the MFD driver's volatile_reg callback to bypass the regmap cache.
> + */
> +#define AAEON_MCU_READ_GPIO_OPCODE 0x72
> +
> +/*
> + * Opcode for watchdog control and status commands.
> + * The status register (arg=0x02) reflects hardware state and is volatile.
> + */
> +#define AAEON_MCU_CONTROL_WDT_OPCODE 0x63
> +
> +/*
> + * Highest register address in the MCU register map.
> + * The WRITE_GPIO opcode (0x77) with the highest GPIO argument (0x0B = 11,
> + * i.e. MAX_GPIOS - 1) produces the largest encoded address.
> + */
> +#define AAEON_MCU_MAX_REGISTER AAEON_MCU_REG(0x77, 0x0B)
> +
> +#endif /* __LINUX_MFD_AAEON_MCU_H */
>
> --
> 2.54.0
>
>
Bart
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite VAR-SOM-MX8 QuadMax Boards
From: Krzysztof Kozlowski @ 2026-07-01 7:30 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Daniel Baluta, Dario Binacchi, Josua Mayer,
Alexander Stein, Ernest Van Hoecke, Maud Spierings,
Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <449840f7b6ffb71b677ccf814a0294c981854033.1782812572.git.stefano.r@variscite.com>
On Tue, Jun 30, 2026 at 11:46:54AM +0200, Stefano Radaelli wrote:
> From: Stefano Radaelli <stefano.r@variscite.com>
>
> Add DT compatible strings for Variscite VAR-SOM-MX8 QuadMax SoM and
> Variscite Symphony development carrier Board.
>
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v2 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
From: Bartosz Golaszewski @ 2026-07-01 7:27 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Viacheslav Bocharov
Cc: Bartosz Golaszewski, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Marek Szyprowski, Robin Murphy,
Diederik de Haas, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260625115718.1678991-1-v@baodeep.com>
On Thu, 25 Jun 2026 14:57:16 +0300, Viacheslav Bocharov wrote:
> gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
> the underlying chip's can_sleep, but under that lock it calls config and
> direction ops that reach sleeping pinctrl paths. On a controller with
> non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
> runs from atomic context:
>
> BUG: sleeping function called from invalid context
> ... pinctrl_gpio_set_config <- gpiochip_generic_config
> <- gpio_shared_proxy_set_config (voting spinlock held)
> <- ... <- mmc_pwrseq_simple_probe
>
> [...]
Applied, thanks!
[2/2] pinctrl: meson: restore non-sleeping GPIO access
https://git.kernel.org/brgl/c/9777530157e7b82fd994327ff878c4245dadc931
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
From: Krzysztof Kozlowski @ 2026-07-01 7:26 UTC (permalink / raw)
To: Jie Gan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin, Konrad Dybcio,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <4117c406-0d75-4eb1-842e-1d346b7fbf99@oss.qualcomm.com>
On 01/07/2026 09:16, Jie Gan wrote:
>
>
> On 7/1/2026 2:57 PM, Krzysztof Kozlowski wrote:
>> On Wed, Jul 01, 2026 at 09:53:41AM +0800, Jie Gan wrote:
>>> The TNOC compatible previously only allowed the two-string AMBA form
>>> "qcom,coresight-tnoc", "arm,primecell", which forces the device onto the
>>> AMBA bus.
>>>
>>> Convert the compatible to a oneOf and add a standalone
>>> "qcom,coresight-agtnoc" compatible alongside the existing AMBA form. The
>>> standalone string carries no "arm,primecell" entry, so the device is
>>> created on the platform bus instead of the AMBA bus.
>>
>> That's a Linux driver specific reason, so not a valid one.
>>
>> Describe the hardware instead.
>>
>> Also, you do not get other compatible for the same device.
>
> The device is intended to be discovered and probed via the AMBA bus.
> However, due to a hardware issue, AMBA probing does not work correctly.
> While adding the arm,primecell-periphid property would allow the
If this is not AMBA bus device, then drop primecell compatible.
> existing AMBA driver to bind, but I think that's a temp WA. As
> Suzuki/Leo pointed out, we should not add the property to pretend the
> device as an AMBA device.
>
> Instead, I introduced a dedicated compatible string so the device can be
> handled by the existing platform driver without relying on the missing
As I said, that's a Linux driver specific reason, so not a valid one.
Fix your drivers if you insist on that.
> AMBA primecell identification. The purpose of the new compatible is to
> clearly distinguish this platform-specific case from the standard
> AMBA-based implementation. Or shall I re-use the existing compatible
> "qcom,coresight-tnoc" as platform standalone compatible?
>
> We already have a similar pattern for the interconnect TraceNoC device,
> which uses the platform-specific compatible string qcom,coresight-itnoc.
I do not see there a fake, duplicated compatible for the same device.
Can you elaborate how is that relevant?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
From: Krzysztof Kozlowski @ 2026-07-01 7:24 UTC (permalink / raw)
To: Gregor Herburger
Cc: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20260630-rpi-tryboot-v2-2-f68d2dc6aa27@linutronix.de>
On Tue, Jun 30, 2026 at 10:59:28PM +0200, Gregor Herburger wrote:
> The Raspberry Pi firmware allows to set a reboot mode called tryboot
> that allows to try booting from a different partition to allow updating
> of the boot partition. Allow reboot mode properties by referencing the
> reboot-mode schema. The firmware allows a 32bit value to be sent as
> reboot flag so restrict the maxItems to 1.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 9 +++++++++
> 1 file changed, 9 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
From: Jie Gan @ 2026-07-01 7:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin, Konrad Dybcio,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260701-stirring-piculet-of-vastness-a361e5@quoll>
On 7/1/2026 2:57 PM, Krzysztof Kozlowski wrote:
> On Wed, Jul 01, 2026 at 09:53:41AM +0800, Jie Gan wrote:
>> The TNOC compatible previously only allowed the two-string AMBA form
>> "qcom,coresight-tnoc", "arm,primecell", which forces the device onto the
>> AMBA bus.
>>
>> Convert the compatible to a oneOf and add a standalone
>> "qcom,coresight-agtnoc" compatible alongside the existing AMBA form. The
>> standalone string carries no "arm,primecell" entry, so the device is
>> created on the platform bus instead of the AMBA bus.
>
> That's a Linux driver specific reason, so not a valid one.
>
> Describe the hardware instead.
>
> Also, you do not get other compatible for the same device.
The device is intended to be discovered and probed via the AMBA bus.
However, due to a hardware issue, AMBA probing does not work correctly.
While adding the arm,primecell-periphid property would allow the
existing AMBA driver to bind, but I think that's a temp WA. As
Suzuki/Leo pointed out, we should not add the property to pretend the
device as an AMBA device.
Instead, I introduced a dedicated compatible string so the device can be
handled by the existing platform driver without relying on the missing
AMBA primecell identification. The purpose of the new compatible is to
clearly distinguish this platform-specific case from the standard
AMBA-based implementation. Or shall I re-use the existing compatible
"qcom,coresight-tnoc" as platform standalone compatible?
We already have a similar pattern for the interconnect TraceNoC device,
which uses the platform-specific compatible string qcom,coresight-itnoc.
Thanks,
Jie
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [PATCH v2] RFC: ARM: breakpoint: CFI breakpoints only on demand
From: Linus Walleij @ 2026-07-01 7:11 UTC (permalink / raw)
To: Russell King, Nathan Chancellor, Sami Tolvanen, Kees Cook,
Russell King (Oracle)
Cc: linux-arm-kernel, linux-kernel, stable, slipher, Linus Walleij
This removes the stub hw_breakpoint_cfi_handler() from ARM, making
it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless
CFI is actively used in the kernel.
When not instrumenting with CFI, we fall through to return 1 from
hw_breakpoint_pending() "unhandled fault" so userspace can make use
of this breakpoint.
This of course does not work if userspace want to use CFI and custom
breakpoints at the same time, and CONFIG_CFI does exist as something
users might want to select for their kernel. If this is not good
acceptable we need to think about other ways for CFI to interfer, such
as not using BKPT at all (rather something like BUG()) and back out
the offending patch until the compiler behaviour has changed.
Fixes: c3f89986fde7 ("ARM: 9391/2: hw_breakpoint: Handle CFI breakpoints")
Reported-by: slipher <slipher@protonmail.com>
Closes: https://lore.kernel.org/lkml/kJqktbpLphg_Pk5I5SPptgTLjl3E3eq5mN5UzCslyFj7Q1Irp-wDid4mj5eQVd2iZtRGXgeZd8goq195EkXdjyt864YMc8mVb2B9NGH91NQ=@protonmail.com/
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
Trying to solve the CFI bug. Let's see of this first
approach is acceptable for the reporter.
---
Changes in v2:
- Resending as non-RFC so it can be applied as a band-aid.
- Link to v1: https://patch.msgid.link/20260626-arm32-cfi-bug-v1-1-a467b5050c0b@kernel.org
---
arch/arm/kernel/hw_breakpoint.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index cd4b34c96e35..007023db6a5d 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -929,10 +929,6 @@ static void hw_breakpoint_cfi_handler(struct pt_regs *regs)
break;
}
}
-#else
-static void hw_breakpoint_cfi_handler(struct pt_regs *regs)
-{
-}
#endif
/*
@@ -964,9 +960,11 @@ static int hw_breakpoint_pending(unsigned long addr, unsigned int fsr,
case ARM_ENTRY_SYNC_WATCHPOINT:
watchpoint_handler(addr, fsr, regs);
break;
+#ifdef CONFIG_CFI
case ARM_ENTRY_CFI_BREAKPOINT:
hw_breakpoint_cfi_handler(regs);
break;
+#endif
default:
ret = 1; /* Unhandled fault. */
}
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260626-arm32-cfi-bug-10fb960749c4
Best regards,
--
Linus Walleij <linusw@kernel.org>
^ permalink raw reply related
* Re: [PATCH v2 2/3] dt-bindings: arm: rockchip: Add Graperain G3568 series
From: Krzysztof Kozlowski @ 2026-07-01 7:07 UTC (permalink / raw)
To: Coia Prant
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260630153810.3574714-6-coiaprant@gmail.com>
On Tue, Jun 30, 2026 at 11:38:11PM +0800, Coia Prant wrote:
> Document Graperain G3568 v2
> which is a development board based on RK3568 SoC.
Broken wrapping.
Best regards,
Krzysztof
^ 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