* [PATCH 1/6] dt-bindings: can: rockchip_canfd: add compatible for the RK3588 variant
From: Heiko Stuebner @ 2026-06-30 16:43 UTC (permalink / raw)
To: mkl, mailhol
Cc: kernel, robh, krzk+dt, conor+dt, heiko, shawn.lin, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-1-heiko@sntech.de>
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
reg:
maxItems: 1
--
2.47.3
^ permalink raw reply related
* [PATCH 2/6] can: rockchip-canfd: add support for the RK3588 variant
From: Heiko Stuebner @ 2026-06-30 16:43 UTC (permalink / raw)
To: mkl, mailhol
Cc: kernel, robh, krzk+dt, conor+dt, heiko, shawn.lin, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-1-heiko@sntech.de>
From: Heiko Stuebner <heiko.stuebner@cherry.de>
The RK3588 SoC uses a variant of this controller.
From the start it does not claim to support can-fd in any part of the
documentation, so it seems that is still broken.
Further errata will be enabled in subsequent patches, with more
in-depth explanation.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
drivers/net/can/rockchip/rockchip_canfd-core.c | 11 +++++++++++
drivers/net/can/rockchip/rockchip_canfd.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 29de0c01e4ed..707f387e7cf4 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -50,6 +50,12 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
RKCANFD_QUIRK_CANFD_BROKEN,
};
+static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588 = {
+ .model = RKCANFD_MODEL_RK3588,
+ .quirks = /* Possibly more errata */
+ RKCANFD_QUIRK_CANFD_BROKEN,
+};
+
static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
{
switch (model) {
@@ -57,6 +63,8 @@ static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
return "rk3568v2";
case RKCANFD_MODEL_RK3568V3:
return "rk3568v3";
+ case RKCANFD_MODEL_RK3588:
+ return "rk3588";
}
return "<unknown>";
@@ -846,6 +854,9 @@ static const struct of_device_id rkcanfd_of_match[] = {
}, {
.compatible = "rockchip,rk3568v3-canfd",
.data = &rkcanfd_devtype_data_rk3568v3,
+ }, {
+ .compatible = "rockchip,rk3588-canfd",
+ .data = &rkcanfd_devtype_data_rk3588,
}, {
/* sentinel */
},
diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
index 93131c7d7f54..92566822e141 100644
--- a/drivers/net/can/rockchip/rockchip_canfd.h
+++ b/drivers/net/can/rockchip/rockchip_canfd.h
@@ -434,6 +434,7 @@
enum rkcanfd_model {
RKCANFD_MODEL_RK3568V2 = 0x35682,
RKCANFD_MODEL_RK3568V3 = 0x35683,
+ RKCANFD_MODEL_RK3588 = 0x3588,
};
struct rkcanfd_devtype_data {
--
2.47.3
^ permalink raw reply related
* [PATCH 3/6] can: rockchip-canfd: enable erratum 6 on RK3588
From: Heiko Stuebner @ 2026-06-30 16:43 UTC (permalink / raw)
To: mkl, mailhol
Cc: kernel, robh, krzk+dt, conor+dt, heiko, shawn.lin, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-1-heiko@sntech.de>
From: Heiko Stuebner <heiko.stuebner@cherry.de>
Sending extended CAN frames from the RK3588's CAN controller, sometimes
sends standard frames, as explained in the erratum's description:
can0 00001234 [4] DE AD BE EF
can0 00000001 [4] DE AD BE EF
can0 000007FF [4] DE AD BE EF
can0 00000800 [4] DE AD BE EF
can0 1FFFFFFF [4] DE AD BE EF
can0 12345678 [4] DE AD BE EF
can0 234 [4] DE AD BE EF
can0 00000001 [4] DE AD BE EF
Enabling the erratum, introduces the correct behaviour in re-sending the
frame:
can0 1FFFFFFF [4] DE AD BE EF
can0 12345678 [4] DE AD BE EF
can0 234 [4] DE AD BE EF
can0 00001234 [4] DE AD BE EF
can0 00000001 [4] DE AD BE EF
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
drivers/net/can/rockchip/rockchip_canfd-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 707f387e7cf4..105ca4d5cbef 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -53,6 +53,7 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588 = {
.model = RKCANFD_MODEL_RK3588,
.quirks = /* Possible more Errata */
+ RKCANFD_QUIRK_RK3568_ERRATUM_6,
RKCANFD_QUIRK_CANFD_BROKEN,
};
--
2.47.3
^ permalink raw reply related
* [PATCH 6/6] arm64: dts: rockchip: Enable CAN controller on RK3588-Tiger-Haikou
From: Heiko Stuebner @ 2026-06-30 16:43 UTC (permalink / raw)
To: mkl, mailhol
Cc: kernel, robh, krzk+dt, conor+dt, heiko, shawn.lin, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-1-heiko@sntech.de>
From: Heiko Stuebner <heiko.stuebner@cherry.de>
CAN0 is piped through the Q7-connector to the CAN-Header on the Haikou
base-board, so enable support for it there.
At least on RK3588-Tiger, the CAN clocks default to 99MHz, limiting
usable CAN bitrates without skew. Errata documentation mentions
300MHz as the default frequency on RK3568, so replicate this here
to allow more bitrates.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts b/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts
index 873fbeb8daa1..6273e695b039 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts
@@ -155,6 +155,12 @@ vddd_audio_1v6: regulator-vddd-audio-1v6 {
};
};
+&can0 {
+ assigned-clocks = <&cru CLK_CAN0>;
+ assigned-clock-rates = <300000000>;
+ status = "okay";
+};
+
&combphy2_psu {
status = "okay";
};
--
2.47.3
^ permalink raw reply related
* [PATCH 5/6] arm64: dts: rockchip: Add RK3588 CAN controller nodes
From: Heiko Stuebner @ 2026-06-30 16:43 UTC (permalink / raw)
To: mkl, mailhol
Cc: kernel, robh, krzk+dt, conor+dt, heiko, shawn.lin, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-1-heiko@sntech.de>
From: Heiko Stuebner <heiko.stuebner@cherry.de>
The RK3588 has 3 CAN controllers, so add the core nodes for them.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 39 +++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index fc1fdbfd3162..ba82e2f057d2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -2648,6 +2648,45 @@ dmac1: dma-controller@fea30000 {
#dma-cells = <1>;
};
+ can0: can@fea50000 {
+ compatible = "rockchip,rk3588-canfd";
+ reg = <0x0 0xfea50000 0x0 0x1000>;
+ interrupts = <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN0>, <&cru PCLK_CAN0>;
+ clock-names = "baud", "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can0m0_pins>;
+ resets = <&cru SRST_CAN0>, <&cru SRST_P_CAN0>;
+ reset-names = "can", "apb";
+ status = "disabled";
+ };
+
+ can1: can@fea60000 {
+ compatible = "rockchip,rk3588-canfd";
+ reg = <0x0 0xfea60000 0x0 0x1000>;
+ interrupts = <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN1>, <&cru PCLK_CAN1>;
+ clock-names = "baud", "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can1m0_pins>;
+ resets = <&cru SRST_CAN1>, <&cru SRST_P_CAN1>;
+ reset-names = "can", "apb";
+ status = "disabled";
+ };
+
+ can2: can@fea70000 {
+ compatible = "rockchip,rk3588-canfd";
+ reg = <0x0 0xfea70000 0x0 0x1000>;
+ interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN2>, <&cru PCLK_CAN2>;
+ clock-names = "baud", "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can2m0_pins>;
+ resets = <&cru SRST_CAN2>, <&cru SRST_P_CAN2>;
+ reset-names = "can", "apb";
+ status = "disabled";
+ };
+
i2c1: i2c@fea90000 {
compatible = "rockchip,rk3588-i2c", "rockchip,rk3399-i2c";
reg = <0x0 0xfea90000 0x0 0x1000>;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 4/6] irqchip/gic-v3-its: Add ITS address info in more error logs
From: Thomas Gleixner @ 2026-06-30 16:43 UTC (permalink / raw)
To: Kemeng Shi, maz; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260623020135.3584-5-shikemeng@huaweicloud.com>
On Tue, Jun 23 2026 at 10:01, Kemeng Shi wrote:
> We have a lot of logs containing ITS address info which is helpful to
We have nothing ...
> distiguish which ITS occurs error. Just add ITS address info into more
> exsiting error logs.
existing
'Just add ITS ...' does tell WHAT the patch does but does not explian
WHY this is required, useful or whatever reason you have.
^ permalink raw reply
* Re: [PATCH v3 3/6] irqchip/gic-v3-its: Fix leak in its_vpe_irq_domain_alloc()
From: Thomas Gleixner @ 2026-06-30 16:42 UTC (permalink / raw)
To: Kemeng Shi, maz; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260623020135.3584-4-shikemeng@huaweicloud.com>
On Tue, Jun 23 2026 at 10:01, Kemeng Shi wrote:
> We miss to teardown the vpe when its_irq_gic_domain_alloc() is failed.
We miss nothing. Change logs want to be written in passive voice. It's documented.
> Just fix this.
'Just fix this' tells nothing and is just a sloppy pointless phrase.
Lacks a Fixes: tag as well
^ permalink raw reply
* Re: [PATCH v3 2/6] irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its()
From: Thomas Gleixner @ 2026-06-30 16:40 UTC (permalink / raw)
To: Kemeng Shi, maz; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260623020135.3584-3-shikemeng@huaweicloud.com>
On Tue, Jun 23 2026 at 10:01, Kemeng Shi wrote:
> Fix its node leak when its_probe_one() failed in
> gic_acpi_parse_madt_its().
Lacks a Fixes: tag as well
^ permalink raw reply
* Re: [PATCH v3 1/6] irqchip/gic-v3-its: Fix memleak in its_probe_one()
From: Thomas Gleixner @ 2026-06-30 16:40 UTC (permalink / raw)
To: Kemeng Shi, maz; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260623020135.3584-2-shikemeng@huaweicloud.com>
On Tue, Jun 23 2026 at 10:01, Kemeng Shi wrote:
> Fix collection leak when its_init_domain() failed in its_probe_one().
>
Lacks a Fixes: tag
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document 2-lanes
From: Rob Herring (Arm) @ 2026-06-30 16:39 UTC (permalink / raw)
To: Christian Marangi
Cc: AngeloGioacchino Del Regno, Lorenzo Pieralisi, Michael Turquette,
Stephen Boyd, Ryder Lee, Manivannan Sadhasivam, linux-arm-kernel,
Philipp Zabel, Conor Dooley, linux-mediatek, linux-kernel,
devicetree, Jianjun Wang, Krzysztof Kozlowski, linux-clk,
Bjorn Helgaas, Brian Masney, Matthias Brugger,
Krzysztof Wilczyński, linux-pci
In-Reply-To: <20260626092029.3525264-4-ansuelsmth@gmail.com>
On Fri, 26 Jun 2026 11:20:27 +0200, Christian Marangi wrote:
> To permit proper documentation of required property to support PCIe
> configured for 2-lanes mode, split the Airoha schema part from the
> mediatek-gen3 schema to a dedicated schema.
>
> A PCIe configured for 2-lanes mode require an additional reg for the
> secondary PCIe to be configured and the airoha,scu phandle to correctly
> configure the PCIe MUX.
>
> Rework the mediatek-gen3 schema to drop any redundant constraint previsouly
> introduced for Airoha PCIe properties.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> .../bindings/pci/airoha,en7581-pcie.yaml | 251 ++++++++++++++++++
> .../bindings/pci/mediatek-pcie-gen3.yaml | 77 +-----
> 2 files changed, 256 insertions(+), 72 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 3/4] printk: nbcon: move printk_delay to console emiting code
From: Andrew Murray @ 2026-06-30 16:35 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Andrew Morton, Sebastian Andrzej Siewior, Clark Williams,
Randy Dunlap, Linus Torvalds, Greg Kroah-Hartman
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-rpi-kernel,
linux-rt-devel, Andrew Murray
In-Reply-To: <20260630-deprecate_boot_delay-v2-0-f9883d36aa4b@thegoodpenguin.co.uk>
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.
Behavior change:
Please note that printk delays now occur after messages are emitted
rather than before.
Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
---
include/linux/console.h | 5 ++++-
include/linux/printk.h | 1 -
kernel/printk/internal.h | 6 ++++++
kernel/printk/nbcon.c | 13 +++++++++++++
kernel/printk/printk.c | 15 +++++++--------
5 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/include/linux/console.h b/include/linux/console.h
index d624200cfc1708bf73925892a466efe0c95c5586..3478b556c0eb9579530409dc6fbb9b5a8bff581c 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -290,6 +290,8 @@ 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 attempted 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 +300,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/include/linux/printk.h b/include/linux/printk.h
index f594c1266bfd411f2238b45374e8a71222f0407c..8885e11367d50ea1cd7642249852d011e589adb4 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -188,7 +188,6 @@ extern int __printk_ratelimit(const char *func);
extern bool printk_timed_ratelimit(unsigned long *caller_jiffies,
unsigned int interval_msec);
-extern int printk_delay_msec;
extern int dmesg_restrict;
extern void wake_up_klogd(void);
diff --git a/kernel/printk/internal.h b/kernel/printk/internal.h
index 85fbf1801cbe070ad96d253bccdf775a11bf945a..c3586f8b8360208902bbbd4607413997bcbd5fb9 100644
--- a/kernel/printk/internal.h
+++ b/kernel/printk/internal.h
@@ -33,6 +33,8 @@ int devkmsg_sysctl_set_loglvl(const struct ctl_table *table, int write,
# define force_legacy_kthread() (false)
#endif
+extern unsigned int printk_delay_msec;
+
#ifdef CONFIG_PRINTK
#ifdef CONFIG_PRINTK_CALLER
@@ -131,6 +133,8 @@ static inline void nbcon_kthread_wake(struct console *con)
rcuwait_wake_up(&con->rcuwait); /* LMM(nbcon_kthread_wake:A) */
}
+void printk_delay(bool use_atomic);
+
#else
#define PRINTK_PREFIX_MAX 0
@@ -162,6 +166,8 @@ static inline bool nbcon_legacy_emit_next_record(struct console *con, bool *hand
static inline void nbcon_kthread_wake(struct console *con) { }
static inline void nbcon_kthreads_wake(void) { }
+static inline void printk_delay(bool use_atomic) { }
+
#endif /* CONFIG_PRINTK */
extern bool have_boot_console;
diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
index 4b03b019cd5ee25d68e9ace84392045e91241a7f..ae45cb0589c0effafc66f1756bdaecd1c1e53ab9 100644
--- a/kernel/printk/nbcon.c
+++ b/kernel/printk/nbcon.c
@@ -1069,6 +1069,8 @@ static bool nbcon_emit_next_record(struct nbcon_write_context *wctxt, bool use_a
else
con->write_thread(con, wctxt);
+ wctxt->emitted = 1;
+
if (!wctxt->outbuf) {
/*
* Ownership was lost and reacquired by the driver. Handle it
@@ -1267,11 +1269,16 @@ static int nbcon_kthread_func(void *__console)
con_flags = console_srcu_read_flags(con);
+ 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.emitted)
+ printk_delay(false);
+
cond_resched();
} while (backlog);
@@ -1525,6 +1532,8 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
}
progress = nbcon_emit_one(&wctxt, use_atomic);
+ if (progress && wctxt.emitted)
+ printk_delay(use_atomic);
if (use_atomic) {
start_critical_timings();
@@ -1584,6 +1593,8 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
if (!nbcon_context_try_acquire(ctxt, false))
return -EPERM;
+ wctxt.emitted = 0;
+
/*
* nbcon_emit_next_record() returns false when
* the console was handed over or taken over.
@@ -1600,6 +1611,8 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
if (nbcon_seq_read(con) < stop_seq)
err = -ENOENT;
break;
+ } else if (wctxt.emitted > 0) {
+ printk_delay(true);
}
}
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index cc203327247aa4f81f55b907c66ac88f30ce6da8..5278d9cb19e4177a00998fba5c1438251e033578 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2140,18 +2140,17 @@ static inline void late_boot_delay_msec(void)
}
}
-static inline void printk_delay(int level)
+void printk_delay(bool use_atomic)
{
- bool suppress = !is_printk_force_console() &&
- suppress_message_printing(level);
-
- if (likely(!printk_delay_msec) || suppress)
+ if (likely(!printk_delay_msec))
return;
if (system_state < SYSTEM_RUNNING)
early_boot_delay_msec();
- else
+ else if (use_atomic)
late_boot_delay_msec();
+ else
+ msleep(printk_delay_msec);
}
#define CALLER_ID_MASK 0x80000000
@@ -2471,8 +2470,6 @@ asmlinkage int vprintk_emit(int facility, int level,
ft.legacy_direct = false;
}
- printk_delay(level);
-
printed_len = vprintk_store(facility, level, dev_info, fmt, args);
if (ft.nbcon_atomic)
@@ -3211,6 +3208,8 @@ static bool console_emit_next_record(struct console *con, bool *handover, int co
*handover = console_lock_spinning_disable_and_check(cookie);
printk_safe_exit_irqrestore(flags);
}
+ printk_delay(true);
+
skip:
return true;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/4] Documentation/kernel-parameters: add/update printk_delay/boot_delay
From: Andrew Murray @ 2026-06-30 16:36 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Andrew Morton, Sebastian Andrzej Siewior, Clark Williams,
Randy Dunlap, Linus Torvalds, Greg Kroah-Hartman
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-rpi-kernel,
linux-rt-devel, Andrew Murray
In-Reply-To: <20260630-deprecate_boot_delay-v2-0-f9883d36aa4b@thegoodpenguin.co.uk>
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.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
---
Documentation/admin-guide/kernel-parameters.txt | 31 +++++++++++++++++++++----
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 2884103b93bca7b76cd3a93946276074cf62d0a1..1118feda87b1b04543b1da0bd52c090b1fddaeac 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -650,11 +650,19 @@ Kernel parameters
See Documentation/block/cmdline-partition.rst
boot_delay= [KNL,EARLY]
- Milliseconds to delay each printk during boot.
- Only works if GENERIC_CALIBRATE_DELAY is enabled,
- and you may also have to specify "lpj=". Boot_delay
- values larger than 10 seconds (10000) are assumed
- erroneous and ignored.
+ Milliseconds to delay each printk during and post boot.
+ Boot time delays only work if GENERIC_CALIBRATE_DELAY
+ is enabled.
+
+ Once booted the delay can be removed or adjusted via
+ the printk_delay sysctl.
+
+ Please note that you may also have to specify "lpj=".
+ Boot_delay values larger than 10 seconds (10000) are
+ assumed erroneous and ignored.
+
+ This will soon be deprecated, please use printk_delay
+ instead.
Format: integer
bootconfig [KNL,EARLY]
@@ -5468,6 +5476,19 @@ Kernel parameters
printk.time= Show timing data prefixed to each printk message line
Format: <bool> (1/Y/y=enable, 0/N/n=disable)
+ printk_delay= [KNL,EARLY]
+ Milliseconds to delay each printk during and post boot.
+ Boot time delays only work if GENERIC_CALIBRATE_DELAY
+ is enabled.
+
+ Once booted the delay can be removed or adjusted via
+ the printk_delay sysctl.
+
+ Please note that you may also have to specify "lpj=".
+ printk_delay values larger than 10 seconds (10000) are
+ assumed erroneous and ignored.
+ Format: integer
+
proc_mem.force_override= [KNL]
Format: {always | ptrace | never}
Traditionally /proc/pid/mem allows memory permissions to be
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/4] printk: deprecate boot_delay in favour of printk_delay
From: Andrew Murray @ 2026-06-30 16:35 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Andrew Morton, Sebastian Andrzej Siewior, Clark Williams,
Randy Dunlap, Linus Torvalds, Greg Kroah-Hartman
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-rpi-kernel,
linux-rt-devel, Andrew Murray
In-Reply-To: <20260630-deprecate_boot_delay-v2-0-f9883d36aa4b@thegoodpenguin.co.uk>
The boot_delay (BOOT_PRINTK_DELAY) kernel parameter and printk_delay sysctl
are two distinct mechanisms for providing similar functionality which add a
delay prior to each printed printk message.
boot_delay provides a kernel parameter for delaying printk output from
kernel start through to boot (SYSTEM_RUNNING), whereas printk_delay is
configurable only via sysctl and thus is only used post boot.
Let's deprecate the boot_delay feature in favour of printk_delay. In order
to preserve functionality, we'll also extend printk_delay such that it can
additionally configured via an early kernel parameter.
Behavior change:
The delay enabled by both "boot_delay" and "printk_delay" continues
working even in SYSTEM_RUNNING state. It must be explicitly stopped
by setting printk_delay=0 via sysctl.
The delay is skipped when the message is suppressed in all system
states. It used to skipped only for the boot_delay.
Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
---
kernel/printk/printk.c | 77 ++++++++++++++++++++++++++++++++------------------
1 file changed, 49 insertions(+), 28 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 77f53eaed13216c6c3946adabc0c8fdba6401d91..cc203327247aa4f81f55b907c66ac88f30ce6da8 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1291,40 +1291,28 @@ static bool suppress_message_printing(int level)
#ifdef CONFIG_GENERIC_CALIBRATE_DELAY
-static int boot_delay; /* msecs delay after each printk during bootup */
static unsigned long long loops_per_msec; /* based on boot_delay */
-static int __init boot_delay_setup(char *str)
+static void __init printk_delay_calculate(void)
{
unsigned long lpj;
lpj = preset_lpj ? preset_lpj : 1000000; /* some guess */
loops_per_msec = (unsigned long long)lpj / 1000 * HZ;
- get_option(&str, &boot_delay);
- if (boot_delay > 10 * 1000)
- boot_delay = 0;
-
- pr_debug("boot_delay: %u, preset_lpj: %ld, lpj: %lu, "
+ pr_debug("printk_delay: %u, preset_lpj: %ld, lpj: %lu, "
"HZ: %d, loops_per_msec: %llu\n",
- boot_delay, preset_lpj, lpj, HZ, loops_per_msec);
- return 0;
+ printk_delay_msec, preset_lpj, lpj, HZ, loops_per_msec);
}
-early_param("boot_delay", boot_delay_setup);
-static void boot_delay_msec(int level)
+static void early_boot_delay_msec(void)
{
unsigned long long k;
unsigned long timeout;
- bool suppress = !is_printk_force_console() &&
- suppress_message_printing(level);
-
- if ((boot_delay == 0 || system_state >= SYSTEM_RUNNING) || suppress)
- return;
- k = (unsigned long long)loops_per_msec * boot_delay;
+ k = (unsigned long long)loops_per_msec * printk_delay_msec;
- timeout = jiffies + msecs_to_jiffies(boot_delay);
+ timeout = jiffies + msecs_to_jiffies(printk_delay_msec);
while (k) {
k--;
cpu_relax();
@@ -1339,11 +1327,34 @@ static void boot_delay_msec(int level)
}
}
#else
-static inline void boot_delay_msec(int level)
+static inline void __init printk_delay_calculate(void)
+{
+}
+
+static inline void early_boot_delay_msec(void)
{
}
#endif
+static int __init printk_delay_setup(char *str)
+{
+ get_option(&str, &printk_delay_msec);
+ if (printk_delay_msec > 10 * 1000)
+ printk_delay_msec = 0;
+
+ printk_delay_calculate();
+
+ return 0;
+}
+early_param("printk_delay", printk_delay_setup);
+
+static int __init boot_delay_setup(char *str)
+{
+ pr_warn("boot_delay will soon be deprecated, please use printk_delay instead\n");
+ return printk_delay_setup(str);
+}
+early_param("boot_delay", boot_delay_setup);
+
static bool printk_time = IS_ENABLED(CONFIG_PRINTK_TIME);
module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
@@ -2117,20 +2128,30 @@ static u8 *__printk_recursion_counter(void)
local_irq_restore(flags); \
} while (0)
-int printk_delay_msec __read_mostly;
+unsigned int printk_delay_msec __read_mostly;
+
+static inline void late_boot_delay_msec(void)
+{
+ unsigned int m = printk_delay_msec;
+
+ while (m--) {
+ mdelay(1);
+ touch_nmi_watchdog();
+ }
+}
static inline void printk_delay(int level)
{
- boot_delay_msec(level);
+ bool suppress = !is_printk_force_console() &&
+ suppress_message_printing(level);
- if (unlikely(printk_delay_msec)) {
- int m = printk_delay_msec;
+ if (likely(!printk_delay_msec) || suppress)
+ return;
- while (m--) {
- mdelay(1);
- touch_nmi_watchdog();
- }
- }
+ if (system_state < SYSTEM_RUNNING)
+ early_boot_delay_msec();
+ else
+ late_boot_delay_msec();
}
#define CALLER_ID_MASK 0x80000000
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/4] printk: remove BOOT_PRINTK_DELAY config option
From: Andrew Murray @ 2026-06-30 16:35 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Andrew Morton, Sebastian Andrzej Siewior, Clark Williams,
Randy Dunlap, Linus Torvalds, Greg Kroah-Hartman
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-rpi-kernel,
linux-rt-devel, Andrew Murray
In-Reply-To: <20260630-deprecate_boot_delay-v2-0-f9883d36aa4b@thegoodpenguin.co.uk>
The boot_delay (BOOT_PRINTK_DELAY) kernel parameter and printk_delay sysctl
are two distinct mechanisms for providing similar functionality which add a
delay prior to each printed printk message.
In preparation of combining them into a single configurable feature, let's
first remove the kconfig option BOOT_PRINTK_DELAY.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/arm/configs/bcm2835_defconfig | 1 -
kernel/printk/printk.c | 2 +-
lib/Kconfig.debug | 18 ------------------
4 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b5493a7f8f22812833308b22f2cc35b0a42e55b2..2884103b93bca7b76cd3a93946276074cf62d0a1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -651,7 +651,7 @@ Kernel parameters
boot_delay= [KNL,EARLY]
Milliseconds to delay each printk during boot.
- Only works if CONFIG_BOOT_PRINTK_DELAY is enabled,
+ Only works if GENERIC_CALIBRATE_DELAY is enabled,
and you may also have to specify "lpj=". Boot_delay
values larger than 10 seconds (10000) are assumed
erroneous and ignored.
diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 4a8ac09843d73280cc42dbbf63fe3cc9f31dacd2..51a1e94d5aa6c22202778082b877a202a6b9c04d 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -174,7 +174,6 @@ CONFIG_NLS_UTF8=y
CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=32
CONFIG_PRINTK_TIME=y
-CONFIG_BOOT_PRINTK_DELAY=y
CONFIG_DYNAMIC_DEBUG=y
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
# CONFIG_ENABLE_MUST_CHECK is not set
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 2fe9a963c823a41e7df10c29939a2abb55462859..77f53eaed13216c6c3946adabc0c8fdba6401d91 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1289,7 +1289,7 @@ static bool suppress_message_printing(int level)
return (level >= console_loglevel && !ignore_loglevel);
}
-#ifdef CONFIG_BOOT_PRINTK_DELAY
+#ifdef CONFIG_GENERIC_CALIBRATE_DELAY
static int boot_delay; /* msecs delay after each printk during bootup */
static unsigned long long loops_per_msec; /* based on boot_delay */
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 1244dcac2294ad99fda37fa6767c9e76f16a4d14..b552ea51cd53b79cf5d58b8c4deff409b1982862 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -99,24 +99,6 @@ config MESSAGE_LOGLEVEL_DEFAULT
by default. To change that, use loglevel=<x> in the kernel bootargs,
or pick a different CONSOLE_LOGLEVEL_DEFAULT configuration value.
-config BOOT_PRINTK_DELAY
- bool "Delay each boot printk message by N milliseconds"
- depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY
- help
- This build option allows you to read kernel boot messages
- by inserting a short delay after each one. The delay is
- specified in milliseconds on the kernel command line,
- using "boot_delay=N".
-
- It is likely that you would also need to use "lpj=M" to preset
- the "loops per jiffy" value.
- See a previous boot log for the "lpj" value to use for your
- system, and then set "lpj=M" before setting "boot_delay=N".
- NOTE: Using this option may adversely affect SMP systems.
- I.e., processors other than the first one may not boot up.
- BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect
- what it believes to be lockup conditions.
-
config DYNAMIC_DEBUG
bool "Enable dynamic printk() support"
default n
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/4] printk: nbcon: deprecate boot_delay in favour of printk_delay
From: Andrew Murray @ 2026-06-30 16:35 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Andrew Morton, Sebastian Andrzej Siewior, Clark Williams,
Randy Dunlap, Linus Torvalds, Greg Kroah-Hartman
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-rpi-kernel,
linux-rt-devel, Andrew Murray
The boot_delay (BOOT_PRINTK_DELAY) kernel parameter and printk_delay
sysctl are two distinct mechanisms for providing similar functionality
which add a delay prior to each printed printk message.
boot_delay provides a kernel parameter for delaying printk output from
kernel start through to boot (SYSTEM_RUNNING), whereas printk_delay is
configurable only via sysctl and thus is only used post boot.
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, especially for slow consoles.
To address these issues, let's deprecate boot_delay, extend printk_delay
to be useable from kernel start and ensure that delays occur at the point
where console messages are printed rather than queued.
Please note that this patchset results in delays occuring after a message
is printed rather than, as it is now, before.
Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
---
Please see the following related work for additional context:
- https://lore.kernel.org/all/20260503214214.3475670-1-rdunlap@infradead.org/
- https://lore.kernel.org/all/20260505-printk_delay-v1-1-5dba51d7f17c@thegoodpenguin.co.uk/
- https://lore.kernel.org/r/20260601-deprecate_boot_delay-v1-0-c34c187142a6@thegoodpenguin.co.uk (v1)
---
Changes in v2:
- Rebased onto v7.2-rc1
- Correctly handle negative values for printk_delay_msec (patch 2)
- Add missing newline in pr_warn (patch 2)
- Improved patch descriptions for (patches 2 and 3)
- Use new emitted flag in nbcon_context/nbcon_write_context in place of backlog && wctxt.len checks (patch 3)
- Use unsigned char for unsafe_takeover field instead of bool in nbcon_write_context (patch 3)
- Move printk_delay_msec and printk_delay from printk.h to internal.h (patch 3)
- Revert regression added in v1 to __nbcon_atomic_flush_pending_con (patch 3)
- Move printk_delay later in console_emit_next_record ensuring delay is always after emit (across nbcon/legacy) (patch 3)
- Fixed typo in documentation s/boot_delay/printk_delay/g in printk_delay= section (patch 4)
- Link to v1: https://lore.kernel.org/r/20260601-deprecate_boot_delay-v1-0-c34c187142a6@thegoodpenguin.co.uk
---
Andrew Murray (4):
printk: remove BOOT_PRINTK_DELAY config option
printk: deprecate boot_delay in favour of printk_delay
printk: nbcon: move printk_delay to console emiting code
Documentation/kernel-parameters: add/update printk_delay/boot_delay
Documentation/admin-guide/kernel-parameters.txt | 31 +++++++--
arch/arm/configs/bcm2835_defconfig | 1 -
include/linux/console.h | 5 +-
include/linux/printk.h | 1 -
kernel/printk/internal.h | 6 ++
kernel/printk/nbcon.c | 13 ++++
kernel/printk/printk.c | 84 +++++++++++++++----------
lib/Kconfig.debug | 18 ------
8 files changed, 101 insertions(+), 58 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260515-deprecate_boot_delay-72516da3845a
Best regards,
--
Andrew Murray <amurray@thegoodpenguin.co.uk>
^ permalink raw reply
* [PATCH 1/1] MAINTAINERS: media: nxp: imx8-isi: Add Frank Li as reviewer and i.MX mailing list
From: Frank.Li @ 2026-06-30 16:34 UTC (permalink / raw)
To: laurent.pinchart, mchehab, kernel, estevam, linux-media, imx,
linux-arm-kernel, linux-kernel
Cc: Frank Li
From: Frank Li <Frank.Li@nxp.com>
Add Frank Li as a reviewer and the i.MX mailing list for the i.MX8 ISI
driver. This helps ensure patches receive review by the NXP i.MX
maintainers.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 361a4f447277c..62ed60238b1cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19470,7 +19470,9 @@ F: drivers/iio/adc/vf610_adc.c
NXP i.MX 8M ISI DRIVER
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+R: Frank Li <Frank.Li@nxp.com>
L: linux-media@vger.kernel.org
+L: imx@lists.linux.dev
S: Maintained
F: Documentation/devicetree/bindings/media/fsl,imx8*-isi.yaml
F: Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/4] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Manivannan Sadhasivam @ 2026-06-30 16:22 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Marc Zyngier, Rob Herring,
devicetree, linux-arm-kernel, linux-doc, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260618220427.14325-2-marek.vasut+renesas@mailbox.org>
On Fri, Jun 19, 2026 at 12:01:59AM +0200, Marek Vasut wrote:
> In case MSI are enabled, but DWC built-in iMSI-RX is not in use, the
> MSI are handled via GIC ITS. Configure all controller MSI registers
> fully.
>
> Set or clear MSI capability register MSICAP0 MSI enable MSIE bit and
> PCIe Interrupt Status 0 Enable register PCIEINTSTS0EN MSI interrupt
> enable MSI_CTRL_INT bit according to MSI enable state, set both bits
> if MSI are enabled, clear both bits if MSI are disabled.
>
> If MSI are disabled, or MSI are enabled and iMSI-RX is used, then
> deconfigure AXIINTCADDR and AXIINTCCONT to 0, which disables any
> pass through of MSI TLPs onto the AXI bus and then further into
> GIC ITS translation registers.
>
> If MSI are enabled and iMSI-RX is not used, the configure AXIINTCADDR
> with target address of GIC ITS translation registers, and configure
> AXIINTCCONT to enable MSI TLP pass through onto AXI bus and into the
> GIC ITS. This specific configuration allows handling of MSI via the
> GIC ITS instead of integrated iMSI-RX.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Same as patch 3, SoB chain is broken. Rest LGTM!
- Mani
> ---
> NOTE: This would not be possible without prior work from Shimoda-san
> ---
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: Pull GITS_TRANSLATER address from DT, which also fixes missing +0x40
> offset of the GITS_TRANSLATER register
> ---
> drivers/pci/controller/dwc/pcie-rcar-gen4.c | 118 +++++++++++++++++++-
> 1 file changed, 113 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index 8b03c42f8c84c..6300ab4dc38b3 100644
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> @@ -13,8 +13,11 @@
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/iopoll.h>
> +#include <linux/irqchip/arm-gic-v3.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <linux/pci.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> @@ -31,6 +34,10 @@
> #define DEVICE_TYPE_RC BIT(4)
> #define BIFUR_MOD_SET_ON BIT(0)
>
> +/* MSI Capability */
> +#define MSICAP0 0x0050
> +#define MSICAP0_MSIE BIT(16)
> +
> /* PCIe Interrupt Status 0 */
> #define PCIEINTSTS0 0x0084
>
> @@ -55,6 +62,14 @@
> #define APP_HOLD_PHY_RST BIT(16)
> #define APP_LTSSM_ENABLE BIT(0)
>
> +/* INTC address */
> +#define AXIINTCADDR 0x0a00
> +
> +/* INTC control & mask */
> +#define AXIINTCCONT 0x0a04
> +#define INTC_EN BIT(31)
> +#define INTC_MASK GENMASK(11, 2)
> +
> /* PCIe Power Management Control */
> #define PCIEPWRMNGCTRL 0x0070
> #define APP_CLK_REQ_N BIT(11)
> @@ -305,13 +320,103 @@ static struct rcar_gen4_pcie *rcar_gen4_pcie_alloc(struct platform_device *pdev)
> return rcar;
> }
>
> +static int rcar_gen4_pcie_host_msi_addr(struct dw_pcie_rp *pp, u32 *msi_addr)
> +{
> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> + struct device_node *msi_node = NULL;
> + struct device *dev = dw->dev;
> + struct resource res;
> + u64 addr;
> + int ret;
> +
> + /*
> + * Either the "msi-parent" or the "msi-map" phandle needs to exist
> + * to obtain the MSI node.
> + */
> + of_msi_xlate(dev, &msi_node, 0);
> + if (!msi_node)
> + return -ENODEV;
> +
> + /* Check if "msi-parent" or the "msi-map" points to ARM GICv3 ITS. */
> + if (!of_device_is_compatible(msi_node, "arm,gic-v3-its"))
> + return dev_err_probe(dev, -ENODEV, "Compatible MSI controller not found\n");
> +
> + /* Derive GITS_TRANSLATER address from GICv3 */
> + ret = of_address_to_resource(msi_node, 0, &res);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "MSI controller resources not obtained\n");
> +
> + addr = res.start + GITS_TRANSLATER;
> + if (addr >= SZ_4G)
> + return dev_err_probe(dev, -EINVAL, "MSI controller address above 32bit range\n");
> +
> + *msi_addr = addr;
> + return 0;
> +}
> +
> +static int rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> + u32 val;
> + int ret;
> +
> + /* Make sure MSICAP0 MSIE is configured. */
> + val = dw_pcie_readl_dbi(dw, MSICAP0);
> + if (pci_msi_enabled())
> + val |= MSICAP0_MSIE;
> + else
> + val &= ~MSICAP0_MSIE;
> + dw_pcie_writel_dbi(dw, MSICAP0, val);
> +
> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
> + /* Clear AXIINTC mapping. */
> + writel(0, rcar->base + AXIINTCADDR);
> + writel(0, rcar->base + AXIINTCCONT);
> + } else {
> + ret = rcar_gen4_pcie_host_msi_addr(pp, &val);
> + if (ret)
> + goto err;
> +
> + /* Point AXIINTC to GIC ITS and enable. */
> + writel(val, rcar->base + AXIINTCADDR);
> + writel(INTC_EN | INTC_MASK, rcar->base + AXIINTCCONT);
> + }
> +
> + /* Configure MSI interrupt signal */
> + val = readl(rcar->base + PCIEINTSTS0EN);
> + if (pci_msi_enabled())
> + val |= MSI_CTRL_INT;
> + else
> + val &= ~MSI_CTRL_INT;
> + writel(val, rcar->base + PCIEINTSTS0EN);
> +
> + return 0;
> +
> +err:
> + /* Deconfigure MSICAP0 MSIE. */
> + val = dw_pcie_readl_dbi(dw, MSICAP0);
> + val &= ~MSICAP0_MSIE;
> + dw_pcie_writel_dbi(dw, MSICAP0, val);
> +
> + /* Clear AXIINTC mapping. */
> + writel(0, rcar->base + AXIINTCADDR);
> + writel(0, rcar->base + AXIINTCCONT);
> +
> + /* Deconfigure MSI interrupt signal */
> + val = readl(rcar->base + PCIEINTSTS0EN);
> + val &= ~MSI_CTRL_INT;
> + writel(val, rcar->base + PCIEINTSTS0EN);
> +
> + return ret;
> +}
> +
> /* Host mode */
> static int rcar_gen4_pcie_host_init(struct dw_pcie_rp *pp)
> {
> struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> int ret;
> - u32 val;
>
> gpiod_set_value_cansleep(dw->pe_rst, 1);
>
> @@ -328,16 +433,19 @@ static int rcar_gen4_pcie_host_init(struct dw_pcie_rp *pp)
> dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_0, 0x0);
> dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_1, 0x0);
>
> - /* Enable MSI interrupt signal */
> - val = readl(rcar->base + PCIEINTSTS0EN);
> - val |= MSI_CTRL_INT;
> - writel(val, rcar->base + PCIEINTSTS0EN);
> + ret = rcar_gen4_pcie_host_msi_init(pp);
> + if (ret)
> + goto err;
>
> msleep(PCIE_T_PVPERL_MS); /* pe_rst requires 100msec delay */
>
> gpiod_set_value_cansleep(dw->pe_rst, 0);
>
> return 0;
> +
> +err:
> + rcar_gen4_pcie_common_deinit(rcar);
> + return ret;
> }
>
> static void rcar_gen4_pcie_host_deinit(struct dw_pcie_rp *pp)
> --
> 2.53.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: (subset) [PATCH v5 0/2] media: nxp: imx8-isi: Add virtual channel and frame descriptor support
From: Frank Li @ 2026-06-30 16:20 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Guoniu Zhou, Frank Li, Aisheng Dong, linux-media,
imx, linux-arm-kernel, linux-kernel, Guoniu Zhou
In-Reply-To: <20260629202302.GK3054459@killaraus.ideasonboard.com>
On Mon, Jun 29, 2026 at 11:23:02PM +0300, Laurent Pinchart wrote:
> On Mon, Jun 29, 2026 at 03:42:31PM -0400, Frank.Li@oss.nxp.com wrote:
> > From: Frank Li <Frank.Li@nxp.com>
> >
> >
> > On Thu, 21 May 2026 17:10:03 +0800, Guoniu Zhou wrote:
> > > This patch series enhances the i.MX ISI driver's with virtual channel
> > > support and adds frame descriptor capabilities to the crossbar subdevice.
> >
> > Applied, thanks!
> >
> > [1/2] media: imx8-isi: crossbar: Add get_frame_desc operation
> > commit: 3e15a3510908c990ee352aa206d5f9c23d4b216e
>
> Is this a mistake ? Patch 1/2 has no R-b tag, and you're not listed as
> maintainer for this driver.
Sorry, I missed checking Maintainer files, in media summit, agree on I pick
imx's media drivers, but forget finalize the file\dir list. Can you help
summery which files\dir I should take care?
If you have concern about this patch, I can drop it.
Frank
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix max receive size configuration
From: Lorenzo Bianconi @ 2026-06-30 16:19 UTC (permalink / raw)
To: Paolo Abeni
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Simon Horman, linux-arm-kernel, linux-mediatek, netdev,
Madhur Agrawal
In-Reply-To: <94901706-e7f3-4ff7-9b19-9965f593e228@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Jun 30, Paolo Abeni wrote:
> On 6/25/26 8:49 AM, Lorenzo Bianconi wrote:
> > Set the GDM maximum receive size to AIROHA_MAX_RX_SIZE unconditionally
> > during hardware initialization instead of updating it according to the
> > configured MTU. This avoids dropping incoming frames that exceed the
> > current MTU but could still be processed by the networking stack, which
> > is able to fragment the reply on the TX side (e.g. ICMP echo requests).
> > Move the per-port MTU configuration to the PPE egress path where it
> > belongs, and set the tx frame size running airoha_ppe_set_xmit_frame_size()
> > to dynamically track the maximum MTU across running interfaces sharing
> > the same PPE instance.
> > Fix the PPE MTU register addressing to pack two port entries per
> > register word and add WAN_MTU0 configuration for non-LAN GDM devices.
> >
> > Fixes: 54d989d58d2a ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
> > Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> PW bot is on holiday, no automated notifications for a while.
It's too hot even for the bot :)
Regards,
Lorenzo
>
> Applied, thanks!
>
> /P
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Jason Gunthorpe @ 2026-06-30 16:18 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Aneesh Kumar K.V, Catalin Marinas, iommu, linux-arm-kernel,
linux-kernel, linux-coco, Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <9f20ce61-1edd-411e-a7c3-be541fb89cb4@amd.com>
On Mon, Jun 22, 2026 at 10:58:23AM +1000, Alexey Kardashevskiy wrote:
> > I think it was a big mistake for the AMD SME stuff to overload the
> > decrypted/encrypted CC stuff which should mean shared/private in a
> > guest context to also mean things about physical memory encryption in
> > the host. It is really confusing.
>
> It is a bit in the PTE which says "encrypted", what do you mean by overloaded?...
Encrypted meaning I'm using DRAM encryption on the host and Encrypted
meaning this page is private and inaccessible to the hypervisor are
very different things with very different requirements and is
confusing they have been overloaded in Linux :(
> > The SME side is just a bad arch choice, the real world doesn't work
> > well if you set high address bits in your dma_addr_t. I think AMD
> > needs to use those restricted swiotlb pool where it allocates this
> > very special "SME Disabled" memory that will have a low
> > dma_addr_t.
>
> The generic __init iommu_subsys_init(void) calls
> iommu_set_default_translated() if CC_ATTR_MEM_ENCRYPT (==force the
> use of IOMMU) and eliminates the bouncing by default, pretty
> much.
Sure, I know, it is a gross solution to a self inflict error.
> We (AMD) do not really want to force Cbit in DMA handles and
> it is not happening unless "iommu=pt".
Lots of real HW won't work will because of this, so yeah you pretty
much have to. But also there is HW that is fine, like you can use a
mlx5 device and it will handle the C bit just fine.
It is pretty hacky to globally force the iommu mode because some
devices end up not working.
> > Then alloc and bouncing will get memory with a suitable
> > dma_addr_t. This has nothing to do with force_dma_unencrypted() which
> > is only a CC guest concept and nothing else in the OS should ever
> > touch decrypted memory.
>
> True.
>
> Although, with "iommu=pt" enabled, dma handles from swiotlb should
> not have Cbit so these swiotlb pages have to be unencrypted.
That is how it should ideall work, in this case the purpose of the
swiotlb pool is to provide low dma address memory because the device
cannot reach the normal linux dram addresses.
> As you mentioned in another mail in the thread, DMAing to
> unencrypted memory with mem_encrypt=on make no sense security
> wise.
Yes, pretty much.
> May be enforce either mem_encrypt=on or iommu=pt is allowed at
> the same time but not both? I am worried though that some weirdo
> still has a use case for it.
Arguably it should be done per device. The problem is the iommu layer
doesn't know what the dma mask is until the driver binds so it can't
detect a device that is unable to reach any dram and switch away from
identity automatically. That would be much cleaner.
> > > I am looking for a way to set up my "sev-guest" device such as when
> >
> > Whats a "sev-guest" device?
>
> It is a platform device, presented in SNP VMs as /dev/sev-guest and
> the guest userspace calls ioctls on it when it needs VM attestation
> report/certificates/etc.
>
> The sev-guest driver makes calls to the HV (GHCB protocol) to:
> 1) get report/certificates/measurements from the HV <- this is done
> via shared memory as the HV writes to it;
> 2) asks the HV to get the digests from the PSP <- this is done via
> encrypted memory (buuuut it is software encrypted and as far as the
> hw is concerned - it is shared - no Cbit, no RMP - these buffers
> contain plaintext headers of the PSP requests and cyphertext of the
> request/response body).
Ok, but here you have overloaded the word encrypted again :( Decrypted
memory containing ciphertext I think you mean
> > > dma_alloc_attrs(snp_dev->dev,...) happens, it allocates a page from
> > > the shared swiotlb pool (with no actual bouncing) and there is no
> > > obvious way to trick the DMA layer into doing that.
> >
> > Why do you need this?
>
> /dev/sev-guest uses only shared memory (from the HW standpoint), and
> it is normally lot less than 1MB. If hugepages are used, then today
> it allocates 4K pages (they come encrypted and likely backed with a
> 2M page), the driver converts them to shared to make that GHCB
> call. The conversion smashes backing 2M page to 4K pages (+RMP
> +IOPDE as there is possible ongoing DMA), which is a problem (I have
> mentioned it as "TMPM" before - a hw/fw helper to do the smashing).
Okay, but this has nothing to do with sev-guest at all, and should not
be solved uniquely for it.
The DMA API in general has a problem spraying allocations all over
system memory and fragmenting the RMP/GPT/etc and yes it needs a
solution, but it should be entirely in the DMA API and have no
special involvment with sev-guest. sev-guest should just make coherent
allocations and use them in the normal way.
> The idea here is that if swiotlb is already shared, the sev-guest
> could use that memory pool.
dma_alloc_coherent using the swiotlb pool instead of allocating and
converting in general is a reasonable proposal, IMHO. Again, nothing
to do with sev-guest.
Jason
^ permalink raw reply
* Re: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Rob Herring @ 2026-06-30 16:13 UTC (permalink / raw)
To: Nas Chung
Cc: mchehab, hverkuil, krzk+dt, conor+dt, shawnguo, s.hauer,
linux-media, devicetree, linux-kernel, linux-imx,
linux-arm-kernel, jackson.lee, lafley.kim, marek.vasut
In-Reply-To: <20260624072043.238-3-nas.chung@chipsnmedia.com>
On Wed, Jun 24, 2026 at 04:20:36PM +0900, Nas Chung wrote:
> Add documentation for the Chips&Media Wave6 video codec on NXP i.MX SoCs.
>
> The hardware contains one control register region and four interface
> register regions for a shared video processing engine. The control region
> manages shared resources such as firmware memory, while each interface
> region has its own MMIO range and interrupt.
>
> The control region and each interface region are distinct DMA requesters
> and can be associated with separate IOMMU stream IDs. Represent the
> control region as the parent node and the interface register regions as
> child nodes to describe these resources.
>
> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> ---
> .../bindings/media/nxp,imx95-vpu.yaml | 163 ++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 170 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
> new file mode 100644
> index 000000000000..9a5ca53e15a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
> @@ -0,0 +1,163 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/nxp,imx95-vpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Chips&Media Wave6 Series multi-standard codec IP on NXP i.MX SoCs
> +
> +maintainers:
> + - Nas Chung <nas.chung@chipsnmedia.com>
> + - Jackson Lee <jackson.lee@chipsnmedia.com>
> +
> +description:
> + The Chips&Media Wave6 codec IP is a multi-standard video encoder/decoder.
> + On NXP i.MX SoCs, the Wave6 codec IP exposes one control register region and
> + four interface register regions for a shared video processing engine.
> + The parent node describes the control region, which has its own MMIO range and
> + manages shared resources such as firmware memory. The child nodes describe the
> + interface register regions. Each interface region has its own MMIO range and
> + interrupt.
> + The control region and the interface regions are distinct DMA requesters.
> + The control region and each interface region can be associated with separate
> + IOMMU stream IDs, allowing DMA isolation between them.
> +
> +properties:
> + compatible:
> + enum:
> + - nxp,imx95-vpu
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: VPU core clock
> + - description: VPU associated block clock
> +
> + clock-names:
> + items:
> + - const: core
> + - const: vpublk
> +
> + power-domains:
> + items:
> + - description: Main VPU power domain
> + - description: Performance power domain
> +
> + power-domain-names:
> + items:
> + - const: vpu
> + - const: perf
> +
> + memory-region:
> + maxItems: 1
> +
> + sram:
> + $ref: /schemas/types.yaml#/definitions/phandle
Already has a type. You just need to define how many phandles (maxItems: 1).
> + description:
> + phandle to the SRAM node used to store reference data, reducing DMA
> + memory bandwidth.
Drop 'phandle to the SRAM node'
Rob
^ permalink raw reply
* Re: [Linux-stm32] [PATCH v6 10/16] arm64: dts: st: add sai1 pins for stm32mp25
From: Olivier MOYSAN @ 2026-06-30 16:09 UTC (permalink / raw)
To: Dario Binacchi, linux-kernel
Cc: Rob Herring, Conor Dooley, devicetree, francesco.utel,
domenico.acri, Maxime Coquelin, Krzysztof Kozlowski, michael,
linux-amarula, linux-stm32, linux-arm-kernel
In-Reply-To: <20260630092628.1695560-11-dario.binacchi@amarulasolutions.com>
Hi Dario,
On 6/30/26 11:24, Dario Binacchi wrote:
> Add the sai1 pins used on MicroGEA-STM32MP257-RMM board.
>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> ---
>
> (no changes since v1)
>
> arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 45 +++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
> index 695c9d771853..002fbc724b9d 100644
> --- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
> @@ -520,6 +520,51 @@ pins {
> };
> };
>
> + /omit-if-no-ref/
> + sai1a_pins_a: sai1a-0 {
> + pins1 {
> + pinmux = <STM32_PINMUX('D', 9, AF3)>, /* SAI1_SD_A */
> + <STM32_PINMUX('D', 8, AF3)>, /* SAI1_FS_A */
> + <STM32_PINMUX('D', 10, AF3)>; /* SAI1_SCK_A */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <1>;
> + };
> + pins2 {
> + pinmux = <STM32_PINMUX('D', 11, AF3)>; /* SAI1_MCLK_A */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <2>;
> + };
> + };
> +
> + /omit-if-no-ref/
> + sai1a_sleep_pins_a: sai1a-sleep-0 {
> + pins {
> + pinmux = <STM32_PINMUX('D', 9, ANALOG)>, /* SAI1_SD_A */
> + <STM32_PINMUX('D', 8, ANALOG)>, /* SAI1_FS_A */
> + <STM32_PINMUX('D', 10, ANALOG)>, /* SAI1_SCK_A */
> + <STM32_PINMUX('D', 11, ANALOG)>; /* SAI1_MCLK_A */
> + };
> + };
> +
> + /omit-if-no-ref/
> + sai1b_pins_a: sai1b-0 {
> + pins {
> + pinmux = <STM32_PINMUX('D', 4, AF4)>; /* SAI1_SD_B */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + };
> +
> + /omit-if-no-ref/
> + sai1b_sleep_pins_a: sai1b-sleep-0 {
> + pins {
> + pinmux = <STM32_PINMUX('D', 4, ANALOG)>; /* SAI1_SD_B */
> + };
> + };
> +
> /omit-if-no-ref/
> sdmmc1_b4_pins_a: sdmmc1-b4-0 {
> pins1 {
You can add Reviewed-by: Olivier Moysan <olivier.moysan@foss.st.com>
Thanks & Regards
Olivier
^ permalink raw reply
* Re: [PATCH v2 05/13] KVM: arm64: Detect (via ACPI) and initialize HACDBSIRQ
From: Oliver Upton @ 2026-06-30 16:03 UTC (permalink / raw)
To: Leonardo Bras
Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki,
Len Brown, Saket Dumbre, Paolo Bonzini, Jonathan Cameron,
Chengwen Feng, Kees Cook, Mikołaj Lenczewski, James Morse,
Zeng Heng, mrigendrachaubey, Thomas Huth, Ryan Roberts,
Yeoreum Yun, Mark Brown, Kevin Brodsky, James Clark, Fuad Tabba,
Raghavendra Rao Ananta, Lorenzo Pieralisi, Sascha Bischoff,
Anshuman Khandual, Tian Zheng, linux-arm-kernel, linux-kernel,
kvmarm, linux-acpi, acpica-devel, kvm
In-Reply-To: <akPXqZQBKET1SyvN@LeoBrasDK>
On Tue, Jun 30, 2026 at 03:50:17PM +0100, Leonardo Bras wrote:
> On Mon, Jun 29, 2026 at 10:22:12AM -0700, Oliver Upton wrote:
> > If we need to initialize the IRQ I'd really like to see device tree
> > bindings for HACDBSIRQ as well. Pretty much any system us plebs can get
> > our hands on is gonna be DT anyway.
>
> Agree. I started out with ACPI because that's what the main target is, as
> dirty-logging is focused in Live Migration, which is usually more
> appreciated in the server space, which generally uses ACPI.
>
> I spoke to some people, and I could not hear of anyone releasing a product
> based in DT that would implement this yet, so I postponed the DT
> enablement.
Nested virt is always a good example. In some distant future KVM could
expose FEAT_HACDBS to the L1 hypervisor, and the VMM may be using DT
instead of ACPI (like kvmtool).
> >
> > > +static irqreturn_t hacdbsirq_handler(int irq, void *pcpu)
> > > +{
> > > + u64 cons = read_sysreg_s(SYS_HACDBSCONS_EL2);
> > > + unsigned long err = FIELD_GET(HACDBSCONS_EL2_ERR_REASON, cons);
> > > +
> > > + switch (err) {
> > > + case HACDBSCONS_EL2_ERR_REASON_NOF:
> > > + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> > > + break;
> > > + case HACDBSCONS_EL2_ERR_REASON_IPAHACF:
> > > + /* When size not a power of two >= 4k, exit with reserved TTLW */
> > > + int index = FIELD_GET(HACDBSCONS_EL2_INDEX, cons);
> > > +
> > > + if (index >= this_cpu_read(hacdbs_pcp.size)) {
> > > + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> > > + break;
> > > + }
> > > + fallthrough;
> > > + case HACDBSCONS_EL2_ERR_REASON_STRUCTF:
> > > + case HACDBSCONS_EL2_ERR_REASON_IPAF:
> > > + this_cpu_write(hacdbs_pcp.status, HACDBS_ERROR);
> > > + break;
> > > + }
> > > +
> > > + return IRQ_HANDLED;
> > > +}
> >
> > I have a pretty extreme distaste for creating a state machine between
> > the callsite and the IRQ handler. The callsite should poll HACDBS for
> > completion. The thread has nothing better to do anyway.
>
> Well, there is one argument it could just wait and save some energy, but I
> agree it is not relevant in server space.
I wouldn't suggest polling in a tight loop :) I'd say use something like
__mdelay() to get the core into a low-power state w/o using a naked WFI.
In fact, that already uses WFxT under the hood.
> The main reason I did this is
> because I am planning on later doing an improved version of this that would
> clean the dirty-bit *while* running the guest, and having the IRQ is needed
> for exiting guest so we can notify userspace the cleaning is done. So I
> laid the HACDBSIRQ infra here so we don't have both polling and IRQ options
> happening.
>
> That idea would require us to add new API (a return value for 'cleaned'),
> and also a new flag for the clean ioctl. We also need the VMM to
> implement that, but then we get a proper cpu usage of cleaning time.
>
> I wanted to start with a backwards compatible version, and do the above
> idea once I put my hands in hardware that implements HACDBS, so I can
> properly measure how much performance we get on above strategy.
>
> What do you think?
Yeah, I'd want to see some extremely compelling performance numbers for
this approach before considering it, alongside the necessary VMM patches
to actually activate it.
Seems likely to me that the VMM will want the background thread back
ASAP that calls the clean ioctl so you'll need to work out how to cope
with idle vCPUs in that case.
Even still, with this hypothetical approach I'd expect KVM to inspect
the HACDBS state on every exit. The IRQ is just a convenient kick back
out to the main KVM_RUN loop.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH v6 03/20] dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
From: Jason Gunthorpe @ 2026-06-30 16:02 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley, Cheloha, Scott
In-Reply-To: <25155bd6-4348-4aa8-ba70-0a882fc84db9@amd.com>
On Thu, Jun 18, 2026 at 12:39:21PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 18/6/26 01:41, Jason Gunthorpe wrote:
> > On Wed, Jun 17, 2026 at 10:50:39AM +1000, Alexey Kardashevskiy wrote:
> > > > @@ -193,16 +193,31 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> > > > dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> > > > {
> > > > bool remap = false, set_uncached = false;
> > > > - bool mark_mem_decrypt = true;
> > > > + bool mark_mem_decrypt = false;
> > > > struct page *page;
> > > > void *ret;
> > > > + /*
> > > > + * DMA_ATTR_CC_SHARED is not a caller-visible dma_alloc_*()
> > > > + * attribute. The direct allocator uses it internally after it has
> > > > + * decided that the backing pages must be shared/decrypted, so the
> > > > + * rest of the allocation path can consistently select DMA addresses,
> > > > + * choose compatible pools and restore encryption on free.
> > >
> > > Why this limit?
> > >
> > > Context: I am looking for a memory pool for a few shared pages (to
> > > do some guest<->host communication), SWIOTLB seems like the right
> > > fit but swiotlb_alloc() is not exported and
> > > dma_direct_alloc(DMA_ATTR_CC_SHARED) is not allowed. Thanks,
> >
> > Then setup your struct device so that the DMA API knows the
> > guest<->host channel requires unecrypted and it will work correctly.
> >
> > I think this is a reasonable API to use for that, and I was just
> > advocating that hyperv should be using it too.
> >
> > But it all relies on a properly setup struct device.
>
> Sounds good but how do I do that in practice?
I think we haven't got there yet, I understood Dan's plan was to add a
bit in the struct device that signals if the device must be
unencrypted or can support all memory.
Currently the dma api assumes all devices must have unencrypted by
default so it should be fine already, shouldn't it?
> not externally available so I'll have to trick the DMA layer into
> using SWIOTLB (which is still all shared, right?) as I specifically
> want to skip page conversions. Setting low DMA mask won't guarantee
> that the DMA layer won't allocate a page outside of SWIOTLB and
> convert it. Manually do
Why so particular? Any address that satisifies the constraints should
be good enough?
Jason
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Geert Uytterhoeven @ 2026-06-30 16:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Linus Walleij, Bartosz Golaszewski,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, open list:GPIO SUBSYSTEM, dri-devel, linux-i2c,
linux-iio, linux-input, linux-mmc @ vger . kernel . org,
linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <ff4d7043-1929-4fa1-ba5e-f28403ad6fcc@app.fastmail.com>
Hi Arnd,
On Mon, 29 Jun 2026 at 19:54, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jun 29, 2026, at 17:29, Geert Uytterhoeven wrote:
> > On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
> >> From: Arnd Bergmann <arnd@arndb.de>
> >>
> >> Most remaining users of desc_to_gpio() only call it for printing debug
> >> information.
> >>
> >> Replace this with a new gpiod_name() helper that returns the
> >> gpio_desc->name string after checking the gpio_desc pointer.
> >>
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> --- a/drivers/gpio/gpio-aggregator.c
> >> +++ b/drivers/gpio/gpio-aggregator.c
> >> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
> >>
> >> fwd->descs[offset] = desc;
> >>
> >> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
> >> - desc_to_gpio(desc), gpiod_to_irq(desc));
> >> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
> >> + gpiod_name(desc), gpiod_to_irq(desc));
> >>
> >> return 0;
> >> }
> >
> > Before, this printed:
> >
> > gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
> > gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
> >
> > After, this prints:
> >
> > gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
> > gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
> >
> > Same results for instantiation using sysfs or configfs[1], although
> > the latter does have optional support for specifying the name.
>
> I wonder how many of the other instances have the same problem
> then. Would it be appropriate for gpiochip_fwd_desc_add() to set
> a name itself to address this one?
I don't think it would be appropriate for the GPIO aggregator to set
that name. What we want to print here (for debugging) is the physical
GPIO that an aggregator's GPIO is mapped to, not some consumer or line
name (which is not guaranteed to be unique).
E.g. "<chip-name>.<offset>" would be fine. As gpiod_name() can only
return a fixed string or an existing string, it can't return such a
formatted string, though. And consumers don't have access to chip info?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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