* [GIT PULL] i.MX arm64 defconfig change for v7.2
From: Frank.Li @ 2026-06-08 15:36 UTC (permalink / raw)
To: soc, arm; +Cc: Frank.Li, kernel, imx, linux-arm-kernel
From: Frank.Li@nxp.com
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-defconfig-7.2
for you to fetch changes up to 27b93b1a2857586bc422994bf1b9f986841edeb3:
arm64: defconfig: Enable DP83822 PHY driver (2026-06-05 13:25:31 -0400)
----------------------------------------------------------------
i.MX arm64 defconfig for v7.2
- Enable DP83822 PHY driver.
----------------------------------------------------------------
Stefan Wahren (1):
arm64: defconfig: Enable DP83822 PHY driver
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [PATCH v1] ARM: mstar: Drop OF node references after mapping
From: Yuho Choi @ 2026-06-08 15:34 UTC (permalink / raw)
To: Daniel Palmer, Romain Perier, Russell King
Cc: linux-arm-kernel, linux-kernel, Yuho Choi
of_find_compatible_node() returns a device node with its reference
count incremented. of_iomap() uses the node to map the register range,
but does not consume that reference.
Drop the node references after mapping the smpctrl and l3bridge
registers.
Fixes: 312b62b6610c ("ARM: mstar: Add machine for MStar/Sigmastar Armv7 SoCs")
Fixes: 5919eec0f092 ("ARM: mstar: SMP support")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
arch/arm/mach-mstar/mstarv7.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-mstar/mstarv7.c b/arch/arm/mach-mstar/mstarv7.c
index 274c4f0df270..64262b8f10a0 100644
--- a/arch/arm/mach-mstar/mstarv7.c
+++ b/arch/arm/mach-mstar/mstarv7.c
@@ -86,6 +86,7 @@ static int mstarv7_boot_secondary(unsigned int cpu, struct task_struct *idle)
np = of_find_compatible_node(NULL, NULL, "mstar,smpctrl");
smpctrl = of_iomap(np, 0);
+ of_node_put(np);
if (!smpctrl)
return -ENODEV;
@@ -116,6 +117,7 @@ static void __init mstarv7_init(void)
np = of_find_compatible_node(NULL, NULL, "mstar,l3bridge");
l3bridge = of_iomap(np, 0);
+ of_node_put(np);
if (l3bridge)
soc_mb = mstarv7_mb;
else
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 50/78] drm/mediatek: dpi: Switch to atomic_create_state
From: AngeloGioacchino Del Regno @ 2026-06-08 15:32 UTC (permalink / raw)
To: Maxime Ripard, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-50-0a91018bf886@kernel.org>
On 6/8/26 16:36, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> To: Philipp Zabel <p.zabel@pengutronix.de>
> To: Matthias Brugger <matthias.bgg@gmail.com>
> To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 51/78] drm/mediatek: dsi: Switch to atomic_create_state
From: AngeloGioacchino Del Regno @ 2026-06-08 15:32 UTC (permalink / raw)
To: Maxime Ripard, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-51-0a91018bf886@kernel.org>
On 6/8/26 16:36, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> To: Philipp Zabel <p.zabel@pengutronix.de>
> To: Matthias Brugger <matthias.bgg@gmail.com>
> To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 52/78] drm/mediatek: hdmi: Switch to atomic_create_state
From: AngeloGioacchino Del Regno @ 2026-06-08 15:32 UTC (permalink / raw)
To: Maxime Ripard, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-52-0a91018bf886@kernel.org>
On 6/8/26 16:36, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> To: Philipp Zabel <p.zabel@pengutronix.de>
> To: Matthias Brugger <matthias.bgg@gmail.com>
> To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 53/78] drm/mediatek: hdmi_v2: Switch to atomic_create_state
From: AngeloGioacchino Del Regno @ 2026-06-08 15:31 UTC (permalink / raw)
To: Maxime Ripard, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-53-0a91018bf886@kernel.org>
On 6/8/26 16:36, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> To: Philipp Zabel <p.zabel@pengutronix.de>
> To: Matthias Brugger <matthias.bgg@gmail.com>
> To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 1/1] KVM: arm64: Make kvm_s2_fault_pin_pfn() fault-in interruptible
From: Marc Zyngier @ 2026-06-08 15:28 UTC (permalink / raw)
To: Jia He
Cc: Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <20260608104336.2405384-2-justin.he@arm.com>
On Mon, 08 Jun 2026 11:43:36 +0100,
Jia He <justin.he@arm.com> wrote:
>
> arm64 KVM faults guest memory into the host in kvm_s2_fault_pin_pfn() via
> __kvm_faultin_pfn(). Today this request is made non-interruptible, so if
> the host fault-in path blocks for a long time, a vCPU thread that already
> has a pending signal cannot leave the fault-in path until GUP eventually
> completes.
>
> This is particularly painful during VM teardown, where userspace may
> signal vCPU threads while they are blocked faulting in guest memory. In
> that case there is no benefit in continuing to wait for the fault to
> complete; the vCPU should return to userspace and let the pending signal
> be handled.
>
> Ask the generic KVM fault-in helper to use FOLL_INTERRUPTIBLE. When GUP
> reports a pending signal it returns KVM_PFN_ERR_SIGPENDING; handle it by
> calling kvm_handle_signal_exit() and returning -EINTR. This matches the
> behaviour expected by the generic KVM fault-in path and mirrors the
> signal-exit handling already done by the arm64 run loop, which sets
> run->exit_reason = KVM_EXIT_INTR before returning to userspace. It is
> also consistent with architectures such as x86 that already allow the
> fault-in to be interrupted by pending signals.
Only x86, AFAICT. s390 handles signals, but doesn't set GUP as
interruptible.
>
> The interrupted fault does not install a partial stage-2 mapping: the
> -EINTR is returned before any mapping is created, so the fault is simply
> retried on a subsequent vCPU entry once userspace re-enters KVM_RUN. The
> only observable effect in the absence of a pending signal is none; this
This sentence reads bizarrely. Do you mean to say "there is no
observable effect in the absence of a pending signal"?
> does not make ordinary stage-2 faults abortable.
>
> Signed-off-by: Jia He <justin.he@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 4da9281312eb..dfb779e6d792 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1872,19 +1872,27 @@ static int kvm_s2_fault_pin_pfn(const struct kvm_s2_fault_desc *s2fd,
> struct kvm_s2_fault_vma_info *s2vi)
> {
> int ret;
> + unsigned int flags = FOLL_INTERRUPTIBLE;
>
> ret = kvm_s2_fault_get_vma_info(s2fd, s2vi);
> if (ret)
> return ret;
>
> + if (kvm_is_write_fault(s2fd->vcpu))
> + flags |= FOLL_WRITE;
> +
nit: you might as well keep the assignment and the update together.
> s2vi->pfn = __kvm_faultin_pfn(s2fd->memslot, get_canonical_gfn(s2fd, s2vi),
> - kvm_is_write_fault(s2fd->vcpu) ? FOLL_WRITE : 0,
> + flags,
> &s2vi->map_writable, &s2vi->page);
> if (unlikely(is_error_noslot_pfn(s2vi->pfn))) {
> if (s2vi->pfn == KVM_PFN_ERR_HWPOISON) {
> kvm_send_hwpoison_signal(s2fd->hva, __ffs(s2vi->vma_pagesize));
> return 0;
> }
> + if (is_sigpending_pfn(s2vi->pfn)) {
> + kvm_handle_signal_exit(s2fd->vcpu);
> + return -EINTR;
> + }
> return -EFAULT;
> }
>
The VNCR handling code also uses __kvm_faultin_pfn(). Why isn't it
similarly updated, given that you are specifically singling out NV as
an area of concern?
Similarly. pkvm_mem_abort() is using FOLL* flags and could benefit
from the same optimisation.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH RFC 4/4] Documentation/kernel-parameters: add/update printk_delay/boot_delay
From: Petr Mladek @ 2026-06-08 15:26 UTC (permalink / raw)
To: Andrew Murray
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <20260601-deprecate_boot_delay-v1-4-c34c187142a6@thegoodpenguin.co.uk>
On Mon 2026-06-01 00:17:40, Andrew Murray wrote:
> boot_delay has been deprecated in favour of an extended printk_delay,
> let's update kernel-parameters to reflect the addition of printk_delay
> and the deprecation of boot_delay.
>
> Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
LGTM:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* [PATCH v5 4/4] arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
From: Alexander Stein @ 2026-06-08 14:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Alexander Stein, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260608142144.564871-1-alexander.stein@ew.tq-group.com>
This adds an overlay for the supported LVDS display AUO G133HAN01.
Configure the video PLL frequency to exactly match typical pixel clock of
141.200 MHz.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v5:
* Fix dtbs_check warnings by adding reg property
arch/arm64/boot/dts/freescale/Makefile | 2 +
...p-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso | 81 +++++++++++++++++++
2 files changed, 83 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2f4568e7105f4..0c390ef6f7571 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -498,8 +498,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33-imx219.dtb
+imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtbo
imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtbo
imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
new file mode 100644
index 0000000000000..2d2dfda944faa
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Martin Schmiedel
+ */
+
+/dts-v1/;
+/plugin/;
+
+&backlight_lvds0 {
+ status = "okay";
+};
+
+&panel_lvds0 {
+ compatible = "auo,g133han01";
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+
+ panel_in_lvds0: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+
+ panel_in_lvds1: endpoint {
+ remote-endpoint = <&ldb_lvds_ch1>;
+ };
+ };
+ };
+};
+
+&lcdif2 {
+ status = "okay";
+};
+
+&lvds_bridge {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ ldb_lvds_ch0: endpoint {
+ remote-endpoint = <&panel_in_lvds0>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ ldb_lvds_ch1: endpoint {
+ remote-endpoint = <&panel_in_lvds1>;
+ };
+ };
+ };
+};
+
+// Update VIDEO_PLL1 frequency
+&media_blk_ctrl {
+ assigned-clock-rates = <500000000>, <200000000>,
+ <0>, <0>, <500000000>,
+ <988400000>;
+};
+
+&pwm3 {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC 3/4] printk: nbcon: move printk_delay to console emiting code
From: Petr Mladek @ 2026-06-08 15:25 UTC (permalink / raw)
To: Andrew Murray
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <20260601-deprecate_boot_delay-v1-3-c34c187142a6@thegoodpenguin.co.uk>
On Mon 2026-06-01 00:17:39, Andrew Murray wrote:
> The printk_delay and boot_delay features are helpful for debugging
> as kernel output can be slowed down during boot allowing messages to
> be seen before scrolling off the screen, or to correlate timing between
> some physical event and console output.
>
> However, since the introduction of nbcon and the legacy printer thread
> for PREEMPT_RT kernels, printk records are now emited to the console
> asynchronously to the caller of printk. Thus, any printk delay added by
> boot_delay/printk_delay continues to slow down the calling process but
> may not have any impact to the rate in which records are emited to the
> console.
>
> Let's address this by moving the printk delay from the calling code
> to the console emiting code instead. Whilst this ensures that delays
> are still observed (especially for slower consoles), it doesn't improve
> the use-case of using boot_delay/printk_delay to correlate timings
> between physical events and console output.
>
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
The declaration is needed just inside kernel/printk/ directory.
It should better be done via kernel/printk/internal.h
> @@ -209,6 +209,7 @@ extern bool nbcon_device_try_acquire(struct console *con);
> extern void nbcon_device_release(struct console *con);
> void nbcon_atomic_flush_unsafe(void);
> bool pr_flush(int timeout_ms, bool reset_on_progress);
> +void printk_delay(bool use_atomic);
> #else
> static inline __printf(1, 0)
> int vprintk(const char *s, va_list args)
> @@ -326,6 +327,9 @@ static inline bool pr_flush(int timeout_ms, bool reset_on_progress)
> {
> return true;
> }
> +static inline void printk_delay(bool use_atomic)
> +{
> +}
>
> #endif
>
> diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> index d7044a7a214bdd4537a5e20d876d99bc3ffe8b3a..a507a2fed5bf4366e24330f763b842a698ecf6f7 100644
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -1267,11 +1267,16 @@ static int nbcon_kthread_func(void *__console)
>
> con_flags = console_srcu_read_flags(con);
>
> + wctxt.len = 0;
> +
> if (console_is_usable(con, con_flags, false))
> backlog = nbcon_emit_one(&wctxt, false);
>
> console_srcu_read_unlock(cookie);
>
> + if (backlog && wctxt.len > 0)
Heh, this is tricky. It might probably work but it is not guarantted
by design.
The "backlog" name is a bit misleading. The value is basically
wctxt.ctxt.backlog. The real meaning is that printk_get_next_message()
was able to read a message. It means that there _was_ a backlog.
But it is not clear whether there are still pending messages or not.
Also it is not clear that whether the message was pushed to the
console or not. It might have been supressed in which case
(wctxt.len == 0). But it might also be emitted only partially
when a higher priority context took over the console context
ownership.
I would prefer to explicitely set some flag when
nbcon_emit_next_record() really called con->write*().
See below.
> + printk_delay(false);
> +
> cond_resched();
>
> } while (backlog);
> @@ -1525,6 +1530,8 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
> }
>
> progress = nbcon_emit_one(&wctxt, use_atomic);
> + if (progress && wctxt.len > 0)
Same here.
> + printk_delay(use_atomic);
>
> if (use_atomic) {
> start_critical_timings();
> @@ -1584,6 +1591,8 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> if (!nbcon_context_try_acquire(ctxt, false))
> return -EPERM;
>
> + wctxt.len = 0;
> +
> /*
> * nbcon_emit_next_record() returns false when
> * the console was handed over or taken over.
> @@ -1595,7 +1604,9 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> nbcon_context_release(ctxt);
> }
>
> - if (!ctxt->backlog) {
> + if (ctxt->backlog && wctxt.len > 0) {
> + printk_delay(true);
> + } else {
This changes the semantic. The original code call this when
no message was read. The new code would call this path also
when the output was suppressed. It would probably work.
But still.
> /* Are there reserved but not yet finalized records? */
> if (nbcon_seq_read(con) < stop_seq)
> err = -ENOENT;
As mentioned above, I would add a flag which would be set when
con->write*() was called.
It modifies the type of unsafe_takeover in struct nbcon_write_context.
But it actually makes it more compatible with struct nbcon_state.
My proposal (on top of this patch):
diff --git a/include/linux/console.h b/include/linux/console.h
index 5520e4477ad7..5a86942e55ef 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -290,6 +290,7 @@ struct nbcon_context {
* @outbuf: Pointer to the text buffer for output
* @len: Length to write
* @unsafe_takeover: If a hostile takeover in an unsafe state has occurred
+ * @emitted: The write context tried to emit the message. Might be incomplete.
* @cpu: CPU on which the message was generated
* @pid: PID of the task that generated the message
* @comm: Name of the task that generated the message
@@ -298,7 +299,8 @@ struct nbcon_write_context {
struct nbcon_context __private ctxt;
char *outbuf;
unsigned int len;
- bool unsafe_takeover;
+ unsigned char unsafe_takeover : 1;
+ unsigned char emitted : 1
#ifdef CONFIG_PRINTK_EXECUTION_CTX
int cpu;
pid_t pid;
diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
index a507a2fed5bf..060534becefc 100644
--- a/kernel/printk/nbcon.c
+++ b/kernel/printk/nbcon.c
@@ -1069,6 +1069,9 @@ static bool nbcon_emit_next_record(struct nbcon_write_context *wctxt, bool use_a
else
con->write_thread(con, wctxt);
+ /* Tried to emit something. Might be incomplete. */
+ wctxt.emitted = 1;
+
if (!wctxt->outbuf) {
/*
* Ownership was lost and reacquired by the driver. Handle it
@@ -1267,14 +1270,14 @@ static int nbcon_kthread_func(void *__console)
con_flags = console_srcu_read_flags(con);
- wctxt.len = 0;
+ wctxt.emitted = 0;
if (console_is_usable(con, con_flags, false))
backlog = nbcon_emit_one(&wctxt, false);
console_srcu_read_unlock(cookie);
- if (backlog && wctxt.len > 0)
+ if (wctxt.emitted)
printk_delay(false);
cond_resched();
@@ -1530,7 +1533,7 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
}
progress = nbcon_emit_one(&wctxt, use_atomic);
- if (progress && wctxt.len > 0)
+ if (wctxt.emitted)
printk_delay(use_atomic);
if (use_atomic) {
@@ -1591,7 +1594,7 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
if (!nbcon_context_try_acquire(ctxt, false))
return -EPERM;
- wctxt.len = 0;
+ wctxt.emitted = 0;
/*
* nbcon_emit_next_record() returns false when
@@ -1604,9 +1607,10 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
nbcon_context_release(ctxt);
}
- if (ctxt->backlog && wctxt.len > 0) {
+ if (wctxt.emitted)
printk_delay(true);
- } else {
+
+ if (!ctxt->backlog) {
/* Are there reserved but not yet finalized records? */
if (nbcon_seq_read(con) < stop_seq)
err = -ENOENT;
^ permalink raw reply related
* Re: [PATCH 2/2] KVM: arm64: Remove superfluous aligning of gfn for dirty logging
From: Leonardo Bras @ 2026-06-08 15:23 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: Leonardo Bras, linux-arm-kernel, kvmarm, linux-kernel,
Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Gavin Shan
In-Reply-To: <20260605153248.2412064-3-weilin.chang@arm.com>
On Fri, Jun 05, 2026 at 04:32:48PM +0100, Wei-Lin Chang wrote:
> Stage-2 mapping size is forced to PAGE_SIZE when dirty logging is
> enabled for a memslot, therefore we don't need to align it down to
> a possibly larger vma size or THP adjusted size, they won't happen.
>
IIRC there was some effort being made in terms of tracking in LEVEL2 block
granularity instead of LEVEL3 (PAGE_SIZE). It makes sense as some platforms
can have very fast networking so setup time is more relevant than actual
sending time.
Would not making this change affect such effort?
Thanks!
Leo
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 06c46124d3e7..d1f6ff7c2943 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -2050,13 +2050,12 @@ static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
>
> /*
> * Mark the page dirty only if the fault is handled successfully,
> - * making sure we adjust the canonical IPA if the mapping size has
> - * been updated (via a THP upgrade, for example).
> + * mapping size is forced to PAGE_SIZE if dirty logging is enabled,
> + * so we don't have to adjust the canonical IPA here.
> */
> if (writable && !ret) {
> - phys_addr_t ipa = gfn_to_gpa(get_canonical_gfn(s2fd, s2vi));
> - ipa &= ~(mapping_size - 1);
> - mark_page_dirty_in_slot(kvm, s2fd->memslot, gpa_to_gfn(ipa));
> + gfn_t canonical_gfn = get_canonical_gfn(s2fd, s2vi);
> + mark_page_dirty_in_slot(kvm, s2fd->memslot, canonical_gfn);
> }
>
> if (ret != -EAGAIN)
> --
> 2.43.0
>
^ permalink raw reply
* [GIT PULL] ARM: soc: updates for v7.2
From: Kevin Hilman @ 2026-06-08 15:21 UTC (permalink / raw)
To: soc; +Cc: linux-omap, linux-arm-kernel
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap.git tags/omap-for-v7.2/soc-signed
for you to fetch changes up to 2a7a9e20b9e8b5dc4fdef777e67d390dcb3a8ea4:
ARM: omap2: simplify allocation for omap_device (2026-05-11 09:51:01 -0700)
----------------------------------------------------------------
ARM: soc: updates for v7.2
Minor update for omap_device core code.
----------------------------------------------------------------
Rosen Penev (1):
ARM: omap2: simplify allocation for omap_device
arch/arm/mach-omap2/omap_device.c | 29 ++++++++++-------------------
arch/arm/mach-omap2/omap_device.h | 4 ++--
2 files changed, 12 insertions(+), 21 deletions(-)
^ permalink raw reply
* [GIT PULL] ARM: dts: OMAP updates for v7.2
From: Kevin Hilman @ 2026-06-08 15:19 UTC (permalink / raw)
To: soc; +Cc: linux-omap, linux-arm-kernel
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap.git tags/omap-for-v7.2/dt-signed
for you to fetch changes up to b6aefeea7b4aa9158c1dcec8c050a678af7bf9b0:
ARM: dts: dm8168-evm: Set stdout-path to uart3 (2026-05-06 14:23:24 -0700)
----------------------------------------------------------------
ARM: dts: OMAP updates for v7.2
Minor DTS fixes & updates
----------------------------------------------------------------
Andreas Kemnade (1):
ARM: dts: ti/omap: omap4-epson-embt2ws: fix typo in iio device property
Christopher Obbard (1):
ARM: dts: dm8168-evm: Set stdout-path to uart3
Ivaylo Dimitrov (2):
arch: arm: dts: cpcap-mapphone: Set VAUDIO regulator always-on
arch: arm: dts: cpcap-mapphone: Add audio-codec jack detection interrupts
Jihed Chaibi (1):
ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint
arch/arm/boot/dts/ti/omap/am335x-sl50.dts | 4 ++--
arch/arm/boot/dts/ti/omap/dm8168-evm.dts | 4 ++++
arch/arm/boot/dts/ti/omap/motorola-cpcap-mapphone.dtsi | 6 +++++-
arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts | 4 ++--
4 files changed, 13 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH v5 06/14] arm64: dts: imx8mp-var-som-symphony: enable PCIe
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add the PCIe reference clock and enable the PCIe controller and PHY on
the Symphony carrier board.
Describe the PERST# reset GPIO and configure the PHY to use an external
reference clock input.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
-
v3->v4:
- Add pcie reset-gpios instead of deprecated one
v2->v3:
-
v1->v2:
- Adjust PCIe controller configuration
.../dts/freescale/imx8mp-var-som-symphony.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index fdac4ceb4c19..698f02fc39a5 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -48,6 +48,12 @@ led-0 {
};
};
+ pcie0_refclk: pcie0-refclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ };
+
reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
compatible = "regulator-fixed";
regulator-name = "VSD_3V3";
@@ -146,6 +152,18 @@ rtc@68 {
};
};
+&pcie {
+ reset-gpios = <&pcal6408 1 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&pcie_phy {
+ clocks = <&pcie0_refclk>;
+ clock-names = "ref";
+ fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+ status = "okay";
+};
+
&snvs_pwrkey {
status = "okay";
};
--
2.47.3
^ permalink raw reply related
* [PATCH v5 05/14] arm64: dts: imx8mp-var-som-symphony: enable header UARTs
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Enable UART1 and UART4 on the Symphony carrier board and add the
corresponding pinctrl configurations.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
-
v3->v4:
-
v2->v3:
-
v1->v2:
-
.../dts/freescale/imx8mp-var-som-symphony.dts | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index cb3348aafa07..fdac4ceb4c19 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -154,6 +154,13 @@ &snvs_rtc {
status = "disabled";
};
+/* Header UART */
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
/* Console */
&uart2 {
pinctrl-names = "default";
@@ -161,6 +168,13 @@ &uart2 {
status = "okay";
};
+/* Header UART */
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
&usb3_0 {
status = "okay";
};
@@ -261,6 +275,13 @@ MX8MP_IOMUXC_GPIO1_IO05__GPIO1_IO05 0x10
>;
};
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x40
+ MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x40
+ >;
+ };
+
pinctrl_uart2: uart2grp {
fsl,pins = <
MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x40
@@ -268,6 +289,13 @@ MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x40
>;
};
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART4_RXD__UART4_DCE_RX 0x40
+ MX8MP_IOMUXC_UART4_TXD__UART4_DCE_TX 0x40
+ >;
+ };
+
pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
fsl,pins = <
MX8MP_IOMUXC_GPIO1_IO14__GPIO1_IO14 0x1c4
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 1/6] dt-bindings: iommu: arm,smmu: Document interconnects property
From: Bibek Kumar Patro @ 2026-06-08 13:44 UTC (permalink / raw)
To: Konrad Dybcio, Will Deacon, Robin Murphy, Joerg Roedel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <1b5ef5b8-c9f2-4eea-8040-22c1d704b529@oss.qualcomm.com>
On 6/8/2026 3:22 PM, Konrad Dybcio wrote:
> On 5/26/26 4:42 PM, Bibek Kumar Patro wrote:
>> Some SoC implementations require a bandwidth vote on an interconnect
>> path before the SMMU register space is accessible. Add the optional
>> 'interconnects' property to the binding to allow platform DT nodes
>> to describe this path.
>>
>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>> ---
>> .../devicetree/bindings/iommu/arm,smmu.yaml | 27 ++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> index 06fb5c8e7547cb7a92823adc2772b94f747376a6..3a677ff1a18fcdf5c0ca9ec8a017d41f9eb5ff09 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> @@ -243,6 +243,13 @@ properties:
>> minItems: 1
>> maxItems: 3
>>
>> + interconnects:
>> + maxItems: 1
>> + description:
>> + Interconnect path to the SMMU register space. Required on SoCs
>> + where the SMMU registers are only accessible after a bandwidth
>> + vote has been placed on the interconnect fabric.
>> +
>> nvidia,memory-controller:
>> description: |
>> A phandle to the memory controller on NVIDIA Tegra186 and later SoCs.
>> @@ -602,6 +609,26 @@ allOf:
>> clock-names: false
>> clocks: false
>>
>> + - if:
>> + properties:
>> + compatible:
>> + items:
>> + - enum:
>> + - qcom,qcs615-smmu-500
>> + - qcom,qcs8300-smmu-500
>> + - qcom,sa8775p-smmu-500
>> + - qcom,sc7280-smmu-500
>
> This is a list of targets that happen to be supported by QLI.. but should
> this list not contain _all_ Qualcomm SoCs, or at least a much broader range?
>
> Perhaps
>
> if: properties: compatible: contains: qcom,adreno-smmu
>
> ?
>
As of now platforms where the issues [1] getting reported are added, the
list will grow.
<We still have to evaluate and test on other non-QLI platforms hosted in
upstream [2]>
[1]: https://github.com/qualcomm-linux/kernel/issues/297
[2]:
https://lore.kernel.org/all/a437f9f9-3560-40f8-85ea-35433e33c428@oss.qualcomm.com/
> Konrad
^ permalink raw reply
* Re: [PATCH 12/18] pinctrl: airoha: move driver to separate directory
From: Bartosz Golaszewski @ 2026-06-08 14:55 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-13-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:48 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> Preparation step. Later the driver will be split on several SoC
> specific drivers and a common code. So it's better put them to
> a separate directory.
>
> No functional changes.
>
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 2/2] soc: aspeed: add host-side PCIe BMC device driver
From: Grégoire Layet @ 2026-06-08 14:51 UTC (permalink / raw)
To: joel, andrew
Cc: andrew, jacky_chou, yh_chung, ninad, linux-aspeed,
linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1780929570.git.gregoire.layet@9elements.com>
Taken from ASPEED 6.18 Kernel SDK
Add support for VUART over PCIe between BMC and host.
This add host side driver.
Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
Signed-off-by: aspeedyh <yh_chung@aspeedtech.com>
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
Tested-by: Grégoire Layet <gregoire.layet@9elements.com>
---
drivers/soc/aspeed/Kconfig | 8 +
drivers/soc/aspeed/Makefile | 1 +
drivers/soc/aspeed/aspeed-host-bmc-dev.c | 249 +++++++++++++++++++++++
3 files changed, 258 insertions(+)
create mode 100644 drivers/soc/aspeed/aspeed-host-bmc-dev.c
diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
index 3e1fcf3c3268..5deefb64e8c7 100644
--- a/drivers/soc/aspeed/Kconfig
+++ b/drivers/soc/aspeed/Kconfig
@@ -11,6 +11,14 @@ config ASPEED_BMC_DEV
Enable support for the ASPEED AST2600 BMC Device.
This exposes the PCIe-to-LPC bridge of the BMC to the host over PCIe.
+config ASPEED_HOST_BMC_DEV
+ tristate "ASPEED Host BMC Device"
+ depends on PCI
+ depends on SERIAL_8250
+ help
+ Enable support for the ASPEED AST2600 BMC Device on the Host.
+ This configure the PCIe and setup two 8250 compatible VUART ports.
+
config ASPEED_LPC_CTRL
tristate "ASPEED LPC firmware cycle control"
select REGMAP
diff --git a/drivers/soc/aspeed/Makefile b/drivers/soc/aspeed/Makefile
index fab0d247df66..3fd3f6d8d36e 100644
--- a/drivers/soc/aspeed/Makefile
+++ b/drivers/soc/aspeed/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_ASPEED_BMC_DEV) += aspeed-bmc-dev.o
+obj-$(CONFIG_ASPEED_HOST_BMC_DEV) += aspeed-host-bmc-dev.o
obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
obj-$(CONFIG_ASPEED_UART_ROUTING) += aspeed-uart-routing.o
diff --git a/drivers/soc/aspeed/aspeed-host-bmc-dev.c b/drivers/soc/aspeed/aspeed-host-bmc-dev.c
new file mode 100644
index 000000000000..7cb52a770fb6
--- /dev/null
+++ b/drivers/soc/aspeed/aspeed-host-bmc-dev.c
@@ -0,0 +1,249 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright (C) ASPEED Technology Inc.
+
+#include <linux/init.h>
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/pci.h>
+#include <linux/serial_core.h>
+#include <linux/serial_8250.h>
+
+static DEFINE_IDA(bmc_device_ida);
+
+#define VUART_MAX_PARMS 2
+#define MAX_MSI_NUM 8
+#define BMC_MULTI_MSI 32
+
+#define DRIVER_NAME "aspeed-host-bmc-dev"
+
+enum aspeed_platform_id {
+ ASPEED,
+};
+
+enum msi_index {
+ VUART0_MSI,
+ VUART1_MSI,
+};
+
+/* Match msi_index */
+static int ast2600_msi_idx_table[MAX_MSI_NUM] = { 16, 15 };
+
+struct aspeed_platform {
+ int (*setup)(struct pci_dev *pdev);
+};
+
+struct aspeed_pci_bmc_dev {
+ struct device *dev;
+ struct aspeed_platform *platform;
+ kernel_ulong_t driver_data;
+ int id;
+
+ unsigned long message_bar_base;
+ unsigned long message_bar_size;
+ void __iomem *msg_bar_reg;
+
+ struct uart_8250_port uart[VUART_MAX_PARMS];
+ int uart_line[VUART_MAX_PARMS];
+
+ /* Interrupt
+ * The index of array is using to enum msi_index
+ */
+ int *msi_idx_table;
+};
+
+static void aspeed_pci_setup_irq_resource(struct pci_dev *pdev)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+
+ /* Assign static msi index table by platform */
+ pci_bmc_dev->msi_idx_table = ast2600_msi_idx_table;
+
+ if (pci_alloc_irq_vectors(pdev, 1, BMC_MULTI_MSI, PCI_IRQ_INTX | PCI_IRQ_MSI) <= 1)
+ /* Set all msi index to the first vector */
+ memset(pci_bmc_dev->msi_idx_table, 0, sizeof(int) * MAX_MSI_NUM);
+}
+
+static int aspeed_pci_bmc_device_setup_vuart(struct pci_dev *pdev)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
+ u16 vuart_ioport;
+ int ret, i;
+
+ for (i = 0; i < VUART_MAX_PARMS; i++) {
+ /* Assign the line to non-exist device */
+ pci_bmc_dev->uart_line[i] = -ENOENT;
+ vuart_ioport = 0x3F8 - (i * 0x100);
+ pci_bmc_dev->uart[i].port.flags = UPF_SKIP_TEST | UPF_BOOT_AUTOCONF | UPF_SHARE_IRQ;
+ pci_bmc_dev->uart[i].port.uartclk = 115200 * 16;
+ pci_bmc_dev->uart[i].port.irq =
+ pci_irq_vector(pdev, pci_bmc_dev->msi_idx_table[VUART0_MSI + i]);
+ pci_bmc_dev->uart[i].port.dev = dev;
+ pci_bmc_dev->uart[i].port.iotype = UPIO_MEM32;
+ pci_bmc_dev->uart[i].port.iobase = 0;
+ pci_bmc_dev->uart[i].port.mapbase =
+ pci_bmc_dev->message_bar_base + (vuart_ioport << 2);
+ pci_bmc_dev->uart[i].port.membase = 0;
+ pci_bmc_dev->uart[i].port.type = PORT_16550A;
+ pci_bmc_dev->uart[i].port.flags |= (UPF_IOREMAP | UPF_FIXED_PORT | UPF_FIXED_TYPE);
+ pci_bmc_dev->uart[i].port.regshift = 2;
+ ret = serial8250_register_8250_port(&pci_bmc_dev->uart[i]);
+ if (ret < 0) {
+ dev_err_probe(dev, ret, "Can't setup PCIe VUART\n");
+ return ret;
+ }
+ pci_bmc_dev->uart_line[i] = ret;
+ }
+ return 0;
+}
+
+static void aspeed_pci_host_bmc_device_release_vuart(struct pci_dev *pdev)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+ int i;
+
+ for (i = 0; i < VUART_MAX_PARMS; i++) {
+ if (pci_bmc_dev->uart_line[i] >= 0)
+ serial8250_unregister_port(pci_bmc_dev->uart_line[i]);
+ }
+}
+
+static int aspeed_pci_host_setup(struct pci_dev *pdev)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+ int rc = 0;
+
+ /* Get Message BAR */
+ pci_bmc_dev->message_bar_base = pci_resource_start(pdev, 1);
+ pci_bmc_dev->message_bar_size = pci_resource_len(pdev, 1);
+ pci_bmc_dev->msg_bar_reg = pci_ioremap_bar(pdev, 1);
+ if (!pci_bmc_dev->msg_bar_reg)
+ return -ENOMEM;
+
+ if (pdev->revision < 0x27) {
+ /* AST2600 ERRTA40: dummy read */
+ (void)__raw_readl((void __iomem *)pci_bmc_dev->msg_bar_reg);
+ } else {
+ /* AST2700 not supported */
+ pr_err("AST2700 detected but not supported");
+ goto out_free0;
+ }
+
+ rc = aspeed_pci_bmc_device_setup_vuart(pdev);
+ if (rc) {
+ pr_err("Cannot setup Virtual UART");
+ goto out_free0;
+ }
+
+ return 0;
+
+out_free0:
+ pci_iounmap(pdev, pci_bmc_dev->msg_bar_reg);
+
+ return rc;
+}
+
+static struct aspeed_platform aspeed_pcie_host[] = {
+ { .setup = aspeed_pci_host_setup },
+ { 0 }
+};
+
+static int aspeed_pci_host_bmc_device_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev;
+ int rc = 0;
+
+ pr_info("ASPEED BMC PCI ID %04x:%04x, IRQ=%u\n", pdev->vendor, pdev->device, pdev->irq);
+
+ pci_bmc_dev = devm_kzalloc(&pdev->dev, sizeof(*pci_bmc_dev), GFP_KERNEL);
+ if (!pci_bmc_dev)
+ return -ENOMEM;
+
+ /* Get platform id */
+ pci_bmc_dev->driver_data = ent->driver_data;
+ pci_bmc_dev->platform = &aspeed_pcie_host[ent->driver_data];
+
+ pci_bmc_dev->id = ida_alloc(&bmc_device_ida, GFP_KERNEL);
+ if (pci_bmc_dev->id < 0)
+ return pci_bmc_dev->id;
+
+ rc = pci_enable_device(pdev);
+ if (rc) {
+ dev_err(&pdev->dev, "pci_enable_device() returned error %d\n", rc);
+ return rc;
+ }
+
+ pci_set_master(pdev);
+ pci_set_drvdata(pdev, pci_bmc_dev);
+
+ /* Prepare IRQ resource */
+ aspeed_pci_setup_irq_resource(pdev);
+
+ /* Setup BMC PCI device */
+ rc = pci_bmc_dev->platform->setup(pdev);
+ if (rc) {
+ dev_err(&pdev->dev, "ASPEED PCIe Host device returned error %d\n", rc);
+ pci_free_irq_vectors(pdev);
+ pci_disable_device(pdev);
+ return rc;
+ }
+
+ return 0;
+}
+
+static void aspeed_pci_host_bmc_device_remove(struct pci_dev *pdev)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+
+ if (pci_bmc_dev->driver_data == ASPEED)
+ aspeed_pci_host_bmc_device_release_vuart(pdev);
+
+ ida_free(&bmc_device_ida, pci_bmc_dev->id);
+
+ pci_iounmap(pdev, pci_bmc_dev->msg_bar_reg);
+
+ pci_free_irq_vectors(pdev);
+ pci_disable_device(pdev);
+}
+
+/**
+ * This table holds the list of (VendorID,DeviceID) supported by this driver
+ *
+ */
+static struct pci_device_id aspeed_host_bmc_dev_pci_ids[] = {
+ /* ASPEED BMC Device */
+ { PCI_DEVICE(0x1A03, 0x2402), .class = 0xFF0000, .class_mask = 0xFFFF00,
+ .driver_data = ASPEED },
+ {
+ 0,
+ }
+};
+
+MODULE_DEVICE_TABLE(pci, aspeed_host_bmc_dev_pci_ids);
+
+static struct pci_driver aspeed_host_bmc_dev_driver = {
+ .name = DRIVER_NAME,
+ .id_table = aspeed_host_bmc_dev_pci_ids,
+ .probe = aspeed_pci_host_bmc_device_probe,
+ .remove = aspeed_pci_host_bmc_device_remove,
+};
+
+static int __init aspeed_host_bmc_device_init(void)
+{
+ return pci_register_driver(&aspeed_host_bmc_dev_driver);
+}
+
+static void aspeed_host_bmc_device_exit(void)
+{
+ /* unregister pci driver */
+ pci_unregister_driver(&aspeed_host_bmc_dev_driver);
+}
+
+late_initcall(aspeed_host_bmc_device_init);
+module_exit(aspeed_host_bmc_device_exit);
+
+MODULE_AUTHOR("Ryan Chen <ryan_chen@aspeedtech.com>");
+MODULE_DESCRIPTION("ASPEED Host BMC DEVICE Driver");
+MODULE_LICENSE("GPL");
--
2.51.2
^ permalink raw reply related
* [PATCH v2 1/2] soc: aspeed: add BMC-side PCIe BMC device driver
From: Grégoire Layet @ 2026-06-08 14:51 UTC (permalink / raw)
To: joel, andrew
Cc: andrew, jacky_chou, yh_chung, ninad, linux-aspeed,
linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1780929570.git.gregoire.layet@9elements.com>
Taken from ASPEED 6.18 Kernel SDK
Add support for VUART over PCIe between BMC and host.
This add BMC side driver.
Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
Signed-off-by: aspeedyh <yh_chung@aspeedtech.com>
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
Tested-by: Grégoire Layet <gregoire.layet@9elements.com>
---
drivers/soc/aspeed/Kconfig | 7 ++
drivers/soc/aspeed/Makefile | 1 +
drivers/soc/aspeed/aspeed-bmc-dev.c | 187 ++++++++++++++++++++++++++++
3 files changed, 195 insertions(+)
create mode 100644 drivers/soc/aspeed/aspeed-bmc-dev.c
diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
index f579ee0b5afa..3e1fcf3c3268 100644
--- a/drivers/soc/aspeed/Kconfig
+++ b/drivers/soc/aspeed/Kconfig
@@ -4,6 +4,13 @@ if ARCH_ASPEED || COMPILE_TEST
menu "ASPEED SoC drivers"
+config ASPEED_BMC_DEV
+ tristate "ASPEED BMC Device"
+ default n
+ help
+ Enable support for the ASPEED AST2600 BMC Device.
+ This exposes the PCIe-to-LPC bridge of the BMC to the host over PCIe.
+
config ASPEED_LPC_CTRL
tristate "ASPEED LPC firmware cycle control"
select REGMAP
diff --git a/drivers/soc/aspeed/Makefile b/drivers/soc/aspeed/Makefile
index b35d74592964..fab0d247df66 100644
--- a/drivers/soc/aspeed/Makefile
+++ b/drivers/soc/aspeed/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_ASPEED_BMC_DEV) += aspeed-bmc-dev.o
obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
obj-$(CONFIG_ASPEED_UART_ROUTING) += aspeed-uart-routing.o
diff --git a/drivers/soc/aspeed/aspeed-bmc-dev.c b/drivers/soc/aspeed/aspeed-bmc-dev.c
new file mode 100644
index 000000000000..7a204b543c97
--- /dev/null
+++ b/drivers/soc/aspeed/aspeed-bmc-dev.c
@@ -0,0 +1,187 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright (C) ASPEED Technology Inc.
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+#include <linux/regmap.h>
+#include <linux/interrupt.h>
+#include <linux/mfd/syscon.h>
+
+#define SCU_TRIGGER_MSI
+
+/* AST2600 SCU */
+#define ASPEED_SCU04 0x04
+#define AST2600A3_SCU04 0x05030303
+#define ASPEED_SCUC20 0xC20
+#define ASPEED_SCUC24 0xC24
+#define MSI_ROUTING_MASK GENMASK(11, 10)
+#define PCIDEV1_INTX_MSI_HOST2BMC_EN BIT(18)
+#define MSI_ROUTING_PCIe2LPC_PCIDEV0 (0x1 << 10)
+#define MSI_ROUTING_PCIe2LPC_PCIDEV1 (0x2 << 10)
+
+#define ASPEED_SCU_PCIE_CONF_CTRL 0xC20
+#define SCU_PCIE_CONF_BMC_DEV_EN BIT(8)
+#define SCU_PCIE_CONF_BMC_DEV_EN_MMIO BIT(9)
+#define SCU_PCIE_CONF_BMC_DEV_EN_MSI BIT(11)
+#define SCU_PCIE_CONF_BMC_DEV_EN_IRQ BIT(13)
+#define SCU_PCIE_CONF_BMC_DEV_EN_DMA BIT(14)
+#define SCU_PCIE_CONF_BMC_DEV_EN_E2L BIT(15)
+#define SCU_PCIE_CONF_BMC_DEV_EN_LPC_DECODE BIT(21)
+
+#define ASPEED_SCU_BMC_DEV_CLASS 0xC68
+
+
+struct aspeed_platform {
+ int (*init)(struct platform_device *pdev);
+};
+
+struct aspeed_bmc_device {
+ struct device *dev;
+ int id;
+ void __iomem *reg_base;
+
+ int pcie2lpc;
+ int irq;
+
+ const struct aspeed_platform *platform;
+
+ struct regmap *scu;
+ int pcie_irq;
+};
+
+
+static int aspeed_ast2600_init(struct platform_device *pdev)
+{
+ struct aspeed_bmc_device *bmc_device = platform_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
+ u32 pcie_config_ctl = SCU_PCIE_CONF_BMC_DEV_EN_IRQ |
+ SCU_PCIE_CONF_BMC_DEV_EN_MMIO | SCU_PCIE_CONF_BMC_DEV_EN;
+ u32 scu_id;
+
+ bmc_device->scu = syscon_regmap_lookup_by_phandle(dev->of_node, "aspeed,scu");
+ if (IS_ERR(bmc_device->scu)) {
+ dev_err(&pdev->dev, "failed to find SCU regmap\n");
+ return PTR_ERR(bmc_device->scu);
+ }
+
+ if (bmc_device->pcie2lpc)
+ pcie_config_ctl |= SCU_PCIE_CONF_BMC_DEV_EN_E2L |
+ SCU_PCIE_CONF_BMC_DEV_EN_LPC_DECODE;
+
+ regmap_update_bits(bmc_device->scu, ASPEED_SCU_PCIE_CONF_CTRL,
+ pcie_config_ctl, pcie_config_ctl);
+
+ /* update class code to others as it is a MFD device */
+ regmap_write(bmc_device->scu, ASPEED_SCU_BMC_DEV_CLASS, 0xff000000);
+
+#ifdef SCU_TRIGGER_MSI
+ //SCUC24[17]: Enable PCI device 1 INTx/MSI from SCU560[15]. Will be added in next version
+ regmap_update_bits(bmc_device->scu, ASPEED_SCUC20, BIT(11) | BIT(14), BIT(11) | BIT(14));
+
+ regmap_read(bmc_device->scu, ASPEED_SCU04, &scu_id);
+ if (scu_id == AST2600A3_SCU04)
+ regmap_update_bits(bmc_device->scu, ASPEED_SCUC24,
+ PCIDEV1_INTX_MSI_HOST2BMC_EN | MSI_ROUTING_MASK,
+ PCIDEV1_INTX_MSI_HOST2BMC_EN | MSI_ROUTING_PCIe2LPC_PCIDEV1);
+ else
+ regmap_update_bits(bmc_device->scu, ASPEED_SCUC24,
+ BIT(17) | BIT(14) | BIT(11), BIT(17) | BIT(14) | BIT(11));
+#else
+ //SCUC24[18]: Enable PCI device 1 INTx/MSI from Host-to-BMC controller.
+ regmap_update_bits(bmc_device->scu, 0xc24, BIT(18) | BIT(14), BIT(18) | BIT(14));
+#endif
+
+
+ return 0;
+}
+
+
+static struct aspeed_platform ast2600_plaform = {
+ .init = aspeed_ast2600_init
+};
+
+
+static const struct of_device_id aspeed_bmc_device_of_matches[] = {
+ { .compatible = "aspeed,ast2600-bmc-device", .data = &ast2600_plaform },
+ {},
+};
+MODULE_DEVICE_TABLE(of, aspeed_bmc_device_of_matches);
+
+static int aspeed_bmc_device_probe(struct platform_device *pdev)
+{
+ struct aspeed_bmc_device *bmc_device;
+ struct device *dev = &pdev->dev;
+ const void *md = of_device_get_match_data(dev);
+ int ret = 0;
+
+ if (!md)
+ return -ENODEV;
+
+ bmc_device = devm_kzalloc(&pdev->dev, sizeof(struct aspeed_bmc_device), GFP_KERNEL);
+ if (!bmc_device)
+ return -ENOMEM;
+ dev_set_drvdata(dev, bmc_device);
+
+ bmc_device->platform = md;
+
+ bmc_device->id = of_alias_get_id(dev->of_node, "bmcdev");
+ if (bmc_device->id < 0)
+ bmc_device->id = 0;
+
+ bmc_device->dev = dev;
+ bmc_device->reg_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(bmc_device->reg_base))
+ return PTR_ERR(bmc_device->reg_base);
+
+ bmc_device->irq = platform_get_irq(pdev, 0);
+ if (bmc_device->irq < 0) {
+ dev_err(&pdev->dev, "platform get of irq[=%d] failed!\n", bmc_device->irq);
+ return bmc_device->irq;
+ }
+
+ if (of_property_read_bool(dev->of_node, "pcie2lpc"))
+ bmc_device->pcie2lpc = 1;
+
+ ret = bmc_device->platform->init(pdev);
+ if (ret) {
+ dev_err(dev, "Initialize bmc device failed\n");
+ goto out;
+ }
+
+ dev_info(dev, "aspeed bmc device: driver successfully loaded.\n");
+
+ return 0;
+
+out:
+ dev_warn(dev, "aspeed bmc device: driver init failed (ret=%d)!\n", ret);
+ return ret;
+}
+
+static void aspeed_bmc_device_remove(struct platform_device *pdev)
+{
+ struct aspeed_bmc_device *bmc_device = platform_get_drvdata(pdev);
+
+ devm_free_irq(&pdev->dev, bmc_device->irq, bmc_device);
+ devm_kfree(&pdev->dev, bmc_device);
+}
+
+static struct platform_driver aspeed_bmc_device_driver = {
+ .probe = aspeed_bmc_device_probe,
+ .remove = aspeed_bmc_device_remove,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = aspeed_bmc_device_of_matches,
+ },
+};
+
+module_platform_driver(aspeed_bmc_device_driver);
+
+MODULE_AUTHOR("Ryan Chen <ryan_chen@aspeedtech.com>");
+MODULE_DESCRIPTION("ASPEED BMC DEVICE Driver");
+MODULE_LICENSE("GPL");
\ No newline at end of file
--
2.51.2
^ permalink raw reply related
* [PATCH v2 0/2] soc: aspeed: Add BMC and host driver for PCIe BMC device
From: Grégoire Layet @ 2026-06-08 14:51 UTC (permalink / raw)
To: joel, andrew
Cc: andrew, jacky_chou, yh_chung, ninad, linux-aspeed,
linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1780409151.git.gregoire.layet@9elements.com>
This is a v2 for upstreaming the VUART over PCIe BMC device driver from the ASPEED kernel SDK (branch master-v6.18) [1].
There are two drivers: a BMC-side driver and a host-side driver.
Together they enable host<->BMC VUART communication via PCIe.
This v2 narrows down the scope to VUART support only, to address review feedback on v1 [2]
that the additional subsystems (shared memory, doorbell and mailbox) were software-defined
IPC channels better used with rpmsg or virtio.
Those subsystems are deferred to a separate future series.
VUART data flow and MSI interrupts have been verified working on the test hardware.
Tested on:
BMC:
- Asus IPMI Kommando Card R1.01, AST2600 A3.
- OpenBMC
Host:
- Linux kernel v7.0.0
This v2 only supports AST2600; the AST2700 is untested and not supported by this patch.
Changes since v1 [2]:
- BMC driver: trimmed down to only SCU and PCIe initialization
- Host driver: removed shared memory misc device, sysfs doorbell, mailbox setup and message queue handler.
Driver now only supports VUART registration.
- Host driver: Fixed cleanup path: removed pci_release_regions() call as there was no matching pci_request_regions call
[1]: https://github.com/AspeedTech-BMC/linux/tree/aspeed-master-v6.18/drivers/soc/aspeed
[2]: https://lore.kernel.org/linux-aspeed/cover.1780409151.git.gregoire.layet@9elements.com/
Grégoire Layet (2):
soc: aspeed: add BMC-side PCIe BMC device driver
soc: aspeed: add host-side PCIe BMC device driver
drivers/soc/aspeed/Kconfig | 15 ++
drivers/soc/aspeed/Makefile | 2 +
drivers/soc/aspeed/aspeed-bmc-dev.c | 187 +++++++++++++++++
drivers/soc/aspeed/aspeed-host-bmc-dev.c | 249 +++++++++++++++++++++++
4 files changed, 453 insertions(+)
create mode 100644 drivers/soc/aspeed/aspeed-bmc-dev.c
create mode 100644 drivers/soc/aspeed/aspeed-host-bmc-dev.c
--
2.51.2
^ permalink raw reply
* Re: [PATCH 05/18] pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin function
From: Bartosz Golaszewski @ 2026-06-08 14:52 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-6-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:41 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> phy4_led1 pin function maps led incorrectly. It uses the same map as
> phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
>
> Fixes: 579839c9548c ("pinctrl: airoha: convert PHY LED GPIO to macro")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone
From: Sebastian Ene @ 2026-06-08 14:51 UTC (permalink / raw)
To: Will Deacon
Cc: Marc Zyngier, catalin.marinas, oupton, joey.gouly, korneld,
kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, vdonnefort,
yuzenghui, Sudeep Holla
In-Reply-To: <aibUXmzfDsVWcZjY@willie-the-truck>
On Mon, Jun 08, 2026 at 03:40:30PM +0100, Will Deacon wrote:
> Hey Seb,
>
> On Mon, Jun 08, 2026 at 02:22:22PM +0000, Sebastian Ene wrote:
> > On Fri, May 29, 2026 at 04:32:24PM +0100, Will Deacon wrote:
> > > I'd probably structure it as a separate patch per call, tbh. That way,
> > > the commit message can talk about the specific fields that are reserved
> > > for a given call. See below.
> > >
> > > > Refactor the handling logic in pKVM FF-A proxy to support checking for
> > > > SBZ/MBZ values. While at it, drop the do_ffa_mem_xfer macro and replace
> > > > it with two functions that make it clear that we re-write the
> > > > function-id with a 64-bit variant, to keep the same behavior as before.
> > > > Keep each handler in an array of structures together with a mask that
> > > > corresponds to the SBZ registers the spec expects.
> > >
> > > Although I agree that we should be enforcing SBZ/MBZ paramaters (because
> > > we have no idea what they might do in future versions of the spec), I
> > > also think that doing this at the register level is too coarse.
> > >
> > > For example, the VM ID parameter to FFA_NOTIFICATION_BITMAP_CREATE has bits
> > > 31:16 as MBZ. So I think we probably need to do the checking on a
> > > per-function basis, like Per is doing in his series:
> > >
> > > https://lore.kernel.org/r/20260501-host-direct-messages-v6-0-3f4af727ed85@google.com
> > >
> >
> > For the newly added calls like FFA_NOTIFICATION_* we can do that in a
> > separate functions, but what about the other existing calls that have
> > MBZ registers ? that was the reason for the inline proposal in :
> > https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/
> > (to avoid duplicate checks).
>
> For unused parameter registers that are SBZ, I think you could just add
> a helper, e.g.:
>
> ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int reg);
>
> which takes the index of the first unused register and then checks that
> all the registers from there to the last unused parameter register are
> zero. You can then just call that directly before you start parsing the
> SBZ/MBZ fields on the used parameter registers and there's no need for
> the table-based indirection in [1].
I see, will do that, thanks.
Sebastian
>
> Will
>
> [1] https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/
^ permalink raw reply
* Re: [RFC PATCH 2/2] firmware: arm_scmi: Add bus support for autoloading
From: Daniel Lezcano @ 2026-06-08 14:51 UTC (permalink / raw)
To: Cristian Marussi
Cc: arm-scmi, guomin_chen, linux-arm-kernel, peng.fan, quic_xinqzhan,
sudeep.holla
In-Reply-To: <20250203100154.140877-2-cristian.marussi@arm.com>
On Mon, Feb 03, 2025 at 10:01:54AM +0000, Cristian Marussi wrote:
> Emit proper MODALIAS uevents when SCMI devices are created and make sure
> all the standard protocol devices are requested when the bus is
> initialized.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
Hi Cristian,
what is the status of this patch ?
^ permalink raw reply
* Re: [PATCH 04/18] pinctrl: airoha: an7583: fix misprint in gpio19 pinconf
From: Bartosz Golaszewski @ 2026-06-08 14:50 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-5-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:40 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> Pin 21 (gpio19) duplicate pinconf settings of pin 20. Fix it using
> a proper bit number in the configuration register.
>
> Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 03/18] pinctrl: airoha: an7581: fix misprint in gpio19 pinconf
From: Bartosz Golaszewski @ 2026-06-08 14:50 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-4-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:39 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> Pin 32 (gpio19) duplicate pinconf settings of pin 31. Fix it using
> a proper bit number in the configuration register.
>
> Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
I think the term we typically use is "typo" but I won't die on that hill.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox