* [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 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 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 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
* 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
* 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 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 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 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
* [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
* [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 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 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 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 4/6] can: rockchip-canfd: enable erratum 5 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>
Lowering the clock-frequency as described in the erratum, also
leads to empty RX-fifos immediately, indicating that the
erratum is also present on the RK3588 variant.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
drivers/net/can/rockchip/rockchip_canfd-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 105ca4d5cbef..f3c8b54a9f02 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -53,7 +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_RK3568_ERRATUM_5 | RKCANFD_QUIRK_RK3568_ERRATUM_6,
RKCANFD_QUIRK_CANFD_BROKEN,
};
--
2.47.3
^ permalink raw reply related
* [PATCH 0/6] Enable CAN support 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
The RK3588 uses basically the same CAN controller as the RK3588, except
the documentation stopped claiming for it to support CAN-FD.
So add a compatible to the binding, the basic driver support and the
errata I could test for so far + enable CAN on the Tiger-Haikou board.
I'm not sure if more errata apply, so I've added Elaine Zhang in Cc
to maybe add more information.
Heiko Stuebner (6):
dt-bindings: can: rockchip_canfd: add compatible for the RK3588
variant
can: rockchip-canfd: add support for the RK3588 variant
can: rockchip-canfd: enable erratum 6 on RK3588
can: rockchip-canfd: enable erratum 5 on RK3588
arm64: dts: rockchip: Add RK3588 CAN controller nodes
arm64: dts: rockchip: Enable CAN controller on RK3588-Tiger-Haikou
.../net/can/rockchip,rk3568v2-canfd.yaml | 1 +
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 39 +++++++++++++++++++
.../boot/dts/rockchip/rk3588-tiger-haikou.dts | 6 +++
.../net/can/rockchip/rockchip_canfd-core.c | 12 ++++++
drivers/net/can/rockchip/rockchip_canfd.h | 1 +
5 files changed, 59 insertions(+)
--
2.47.3
^ permalink raw reply
* Re: [PATCH v3 5/6] irqchip/gic-v3-its: some minor improvement in comments
From: Thomas Gleixner @ 2026-06-30 16:46 UTC (permalink / raw)
To: Kemeng Shi, maz; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260623020135.3584-6-shikemeng@huaweicloud.com>
On Tue, Jun 23 2026 at 10:01, Kemeng Shi wrote:
> 1. "If it some" -> "If some"
> 2. "by table by reading" -> by reading"
> 3. "reading bit at offset '62'" -> "reading GITS_BASER_INDIRECT"
Please don't enumerate WHAT the patch is doing. We all can see that from
the patch itself.
Something like that is sufficient and clear enough:
'Fix grammar and replace a bit number with the symbol for better
readability'
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
From: Conor Dooley @ 2026-06-30 17:01 UTC (permalink / raw)
To: Gregor Herburger
Cc: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <qgoblikagfbcmbqoryw4ajfa6qyx3wpj4qfeuuntima542qlkq@evebdvjaxern>
[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]
On Tue, Jun 30, 2026 at 03:56:32PM +0200, Gregor Herburger wrote:
> Hi Conor,
>
> On Fri, Jun 26, 2026 at 04:57:35PM +0100, Conor Dooley wrote:
> > On Fri, Jun 26, 2026 at 09:35:05AM +0200, Gregor Herburger wrote:
> > > The Raspberry Pi firmware allows to set a reboot mode called tryboot
> > > that allows to try booting from a different partition to allow updating
> > > of the boot partition. Allow reboot mode properties by referencing the
> > > reboot-mode schema.
> > >
> > > Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> > > ---
> > > .../devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 5 ++++-
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > > index 983ea80eaec97..30b490e0d9fb3 100644
> > > --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > > @@ -133,11 +133,14 @@ properties:
> > > required:
> > > - compatible
> > >
> > > +allOf:
> > > + - $ref: /schemas/power/reset/reboot-mode.yaml#
> > > +
> > > required:
> > > - compatible
> > > - mboxes
> > >
> > > -additionalProperties: false
> > > +unevaluatedProperties: false
> >
> > I think you should keep additionalProperties: false and add
> > mode-normal: true
> > mode-tryboot: true
> >
> > (I don't know if the latter works though, you may need to have a $ref to
> > uint32-array).
> >
> > What you've done permits freeform reboot modes, but I think only normal
> > and tryboot are valid?
>
> Ah yes good point. I do think it should be restricted to
> 'mode-{normal,tryboot}'.
>
> Sashiko also suggested to set maxItems to 1 and I think that is a good idea as
> well, because afaik the firmware only accepts a 32bit value for the reboot flag.
> The $ref to uin32 is not needed that is already enforced by the
> patternProperties "^mode-.*$": in reboot-mode.yaml.
>
> Therefore I will add the following (and keep additionalProperties: false):
>
> properties:
> ...
>
> mode-normal:
> maxItems: 1
>
> mode-tryboot:
> maxItems: 1
>
> allOf:
> - $ref: /schemas/power/reset/reboot-mode.yaml#
>
>
> I will do some more testing and send a v2 later.
Cool, sounds good to me.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
From: Conor Dooley @ 2026-06-30 17:05 UTC (permalink / raw)
To: Gokul Praveen
Cc: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar
In-Reply-To: <20260630134324.61085-3-g-praveen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
On Tue, Jun 30, 2026 at 07:13:24PM +0530, Gokul Praveen wrote:
> Update maxItems value of "clocks" property to 3 as description of
> this parameter already indicates 3 clocks(refclk,pll1_refclk(optional)
> and phy_en_refclk(optional))
>
> Update the "clock-names" property as well with the 3 clocks.
>
> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
> ---
> .../devicetree/bindings/phy/phy-cadence-torrent.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> index 9af39b33646a..54fe78da297a 100644
> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> @@ -34,7 +34,7 @@ properties:
>
> clocks:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
> description:
> PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
> pll1_refclk is optional and used for multi-protocol configurations requiring
> @@ -47,7 +47,7 @@ properties:
> minItems: 1
> items:
> - const: refclk
> - - enum: [ pll1_refclk, phy_en_refclk ]
> + - enum: [refclk, pll1_refclk, phy_en_refclk ]
This does not do what you want it to do, I would think, since it means
you can only have two clock names.
Additionally, please restrict 3 clocks to only whatever new TI device
actually has 3 clocks.
pw-bot: changes-requested
Thanks,
Conor.
>
> reg:
> minItems: 1
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 01/10] dt-bindings: mailbox: Add Apple t8122 ASC mailbox
From: Conor Dooley @ 2026-06-30 17:05 UTC (permalink / raw)
To: michael.reeves077
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jassi Brar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Dmitry Torokhov,
Jiri Kosina, Benjamin Tissoires, asahi, linux-arm-kernel,
linux-kernel, devicetree, iommu, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-1-506d936a1707@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: mailbox: apple: Add DockChannel mailbox
From: Conor Dooley @ 2026-06-30 17:07 UTC (permalink / raw)
To: michael.reeves077
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jassi Brar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Dmitry Torokhov,
Jiri Kosina, Benjamin Tissoires, asahi, linux-arm-kernel,
linux-kernel, devicetree, iommu, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-2-506d936a1707@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]
On Tue, Jun 30, 2026 at 10:54:30PM +1000, Michael Reeves via B4 Relay wrote:
> From: Michael Reeves <michael.reeves077@gmail.com>
>
> DockChannel is a FIFO and interrupt block used by Apple coprocessors
> to exchange byte-stream traffic with the AP.
>
> Describe it as a mailbox provider so HID and future serial clients can
> use the common mailbox API.
>
> Signed-off-by: Michael Reeves <michael.reeves077@gmail.com>
> ---
> .../bindings/mailbox/apple,dockchannel.yaml | 75 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 76 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/apple,dockchannel.yaml b/Documentation/devicetree/bindings/mailbox/apple,dockchannel.yaml
> new file mode 100644
> index 000000000000..4f326d8f3d5a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/apple,dockchannel.yaml
Please name this file matching the t8112 compatible (since that's your
fallback).
Otherwise, this looks good.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: changes-requested
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 03/10] dt-bindings: iommu: apple,dart: Add t8122 compatible
From: Conor Dooley @ 2026-06-30 17:07 UTC (permalink / raw)
To: michael.reeves077
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jassi Brar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Dmitry Torokhov,
Jiri Kosina, Benjamin Tissoires, asahi, linux-arm-kernel,
linux-kernel, devicetree, iommu, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-3-506d936a1707@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 04/10] dt-bindings: input: apple: Add DockChannel HID transport
From: Conor Dooley @ 2026-06-30 17:08 UTC (permalink / raw)
To: michael.reeves077
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jassi Brar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Dmitry Torokhov,
Jiri Kosina, Benjamin Tissoires, asahi, linux-arm-kernel,
linux-kernel, devicetree, iommu, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-4-506d936a1707@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
On Tue, Jun 30, 2026 at 10:54:32PM +1000, Michael Reeves via B4 Relay wrote:
> From: Michael Reeves <michael.reeves077@gmail.com>
>
> Apple internal keyboards and trackpads behind MTP are exposed through a
> DockChannel HID transport.
>
> Add the client binding tying together the RTKit ASC mailbox,
> DockChannel mailbox, and MTP DART. The keyboard child can provide the
> HID country code used by hid-apple to distinguish layout variants.
>
> Signed-off-by: Michael Reeves <michael.reeves077@gmail.com>
> ---
> .../bindings/input/apple,dockchannel-hid.yaml | 91 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 92 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/apple,dockchannel-hid.yaml b/Documentation/devicetree/bindings/input/apple,dockchannel-hid.yaml
> new file mode 100644
> index 000000000000..dbba4fc38971
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/apple,dockchannel-hid.yaml
Same thing here about the filename. Looks good otherwise, so please
change that.
pw-bot: changes-requested
\x02
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC v2 PATCH] reserve_mem: add support for static memory
From: Shyam Saini @ 2026-06-30 17:09 UTC (permalink / raw)
To: shyamsaini, ardb, catalin.marinas, david, linux-arm-kernel, will
Cc: akpm, bboscaccy, bp, dapeng1.mi, ebiggers, elver, enelsonmoore,
feng.tang, gpiccoli, kees, kuba, linux-doc, linux-kernel,
linux-mm, lirongqing, peterz, rdunlap, rppt, tgopinath, tony.luck
In-Reply-To: <aj6SqipC/dIN01iN@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Hi Everyone,
> On 25 Jun 2026 11:37, Mike Rapoport wrote:
> > Hi Shyam,
> >
> > On Wed, Jun 24, 2026 at 06:22:33PM -0700, Shyam Saini wrote:
> > > On 21 Jun 2026 13:36, Mike Rapoport wrote:
> > > > On Thu, Jun 18, 2026 at 11:23:31PM -0700, Shyam Saini wrote:
> > > > > reserve_mem relies on dynamic memory allocation, this limits the
> > > > > usecase where memory is required to be preserved across the boots.
> > > > > Eg: ramoops memory reservation on ACPI platforms
> > > > >
> > > > > So add support to pass a pre-determined static address and reserve
> > > > > memory at a specified location. This enables use case like ramoops
> > > > > on ACPI platforms to reliably access ramoops region with previous
> > > > > boot logs.
> > > > >
> > > > > Also skip the parsing of <align> when static address is passed.
> > > > >
> > > > > Example syntax for static address
> > > > > reserve_mem=4M@0x1E0000000:oops
> > > >
> > > > reserve_mem is best effort by design because such hacks as well as memmap=
> > > > cannot guarantee this memory is actually free.
> > > >
> > > > If you want to preserve ramoops reliably, use KHO with reserve_mem.
> > > > The first kernel will allocate memory, this memory will be preserved by KHO
> > > > and could be picked up by the second kernel.
> > >
> > > ok, On ARM64 DTS systems, we can reserve ramoops memory in the device tree during
> > > the warm reboot.
> >
> > The cc list actually implied x86 ;-)
> > Added arm64 folks now.
>
> Thanks for adding ARM folks, I had just included whatever get_maintainer script
> suggested, sorry.
> > > For an equivalent ARM64 ACPI platform, what is the recommended way to reserve
> > > and preserve that memory across the boots?
> >
> > I don't think it exists, but a command line option (be it memmap= or
> > reserve_mem=) does not seem the right way to me.
> >
> > Most of the arguments that were made against adding memmap= to arm64 [1]
> > apply here.
> >
> > If kexec is an option, KHO provides a reliable way to preserve memory
> > across boots.
> >
> > If kexec is not an option, we should look for a generic way to specify
> > something like DT's reserved_mem for ACPI/EFI systems.
> >
> > [1] https://lkml.kernel.org/lkml/20201118063314.22940-1-song.bao.hua@hisilicon.com/T/
> >
> Well, kexec is one of the option for my use case, it also requires
> memory reservation during warm reboot, I think memory can be reserved in
> the firmware but this will create a dependency on firmware for Linux
> reservation.
>
> It would be great to have a in kernel memory reservation mechanism for
> ARM64 ACPI platforms. I believe some other use cases like PMEM
> reservation would also benefit from this.
>
Following up on this, As Mike pointed that reserve_mem is best effort
reservation mechanism, so what is the recommended reliable Linux
mechanism, if any, to reserve a predetermined memory range during
early boot on ARM64/ACPI platforms for warm boot scenarios? KHO is
one option, but I'm specifically looking for a solution that preserves
the region across warm reboots.
Please let me know.
Thanks,
Shyam
^ permalink raw reply
* Re: [PATCH net-next v9 2/6] dt-bindings: ethernet: eswin: add EIC7700 eth1 RX clock inversion variant
From: Conor Dooley @ 2026-06-30 17:14 UTC (permalink / raw)
To: lizhi2
Cc: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms, lee, wens
In-Reply-To: <20260630063239.1158-1-lizhi2@eswincomputing.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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