* [PATCH 01/12] dt-bindings: serial: renesas,scif: Document RZ/G3L SoC
From: Biju @ 2026-01-20 12:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-kernel, linux-serial, devicetree,
linux-renesas-soc, Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260120125232.349708-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Add SCIF binding documentation for Renesas RZ/G3L SoC. SCIF block on the
RZ/G3L is identical to one found on the RZ/G3S SoC.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
Documentation/devicetree/bindings/serial/renesas,scif.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
index a6ef02327be8..82f54446835e 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
@@ -82,6 +82,7 @@ properties:
- renesas,scif-r9a07g043 # RZ/G2UL and RZ/Five
- renesas,scif-r9a07g054 # RZ/V2L
- renesas,scif-r9a08g045 # RZ/G3S
+ - renesas,scif-r9a08g046 # RZ/G3L
- const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback
- items:
--
2.43.0
^ permalink raw reply related
* [PATCH 00/12] Add support for Renesas RZ/G3L SoC and SMARC-EVK platform
From: Biju @ 2026-01-20 12:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Vinod Koul, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-kernel, linux-serial, dmaengine, devicetree,
linux-clk, linux-renesas-soc, Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
Hi all,
This patch series adds initial support for the Renesas RZ/G3L SoC and
RZ/G3L SMARC EVK platform. The RZ/G3L device is a general-purpose
microprocessor with a quad-core CA-55, single core CM-33, Mali-G31
3-D Graphics and other peripherals.
Support for the below list of blocks is added in the SoC DTSI (r9a08g046.dtsi):
- EXT CLK
- 4X CA55
- SCIF
- CPG
- GIC
- ARMv8 Timer
This series also adds SCIF support for the RZ/G3L SMARC EVK board (r9a08g046l68-smarc.dts).
Test logs:
/ #uname -r
6.19.0-rc6-next-20260119-g31b78275d04b
/ # cat /proc/cpuinfo
processor : 0
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 1
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 2
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 3
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
/ # cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
11: 262 109 324 98 GICv3 27 Level arch_timer
14: 0 0 0 0 GICv3 185 Edge error
15: 0 0 0 0 GICv3 186 Edge 11820000.dma-controller:0
16: 0 0 0 0 GICv3 187 Edge 11820000.dma-controller:1
17: 0 0 0 0 GICv3 188 Edge 11820000.dma-controller:2
18: 0 0 0 0 GICv3 189 Edge 11820000.dma-controller:3
19: 0 0 0 0 GICv3 190 Edge 11820000.dma-controller:4
20: 0 0 0 0 GICv3 191 Edge 11820000.dma-controller:5
21: 0 0 0 0 GICv3 192 Edge 11820000.dma-controller:6
22: 0 0 0 0 GICv3 193 Edge 11820000.dma-controller:7
23: 0 0 0 0 GICv3 194 Edge 11820000.dma-controller:8
24: 0 0 0 0 GICv3 195 Edge 11820000.dma-controller:9
25: 0 0 0 0 GICv3 196 Edge 11820000.dma-controller:10
26: 0 0 0 0 GICv3 197 Edge 11820000.dma-controller:11
27: 0 0 0 0 GICv3 198 Edge 11820000.dma-controller:12
28: 0 0 0 0 GICv3 199 Edge 11820000.dma-controller:13
29: 0 0 0 0 GICv3 200 Edge 11820000.dma-controller:14
30: 0 0 0 0 GICv3 201 Edge 11820000.dma-controller:15
31: 0 0 0 0 GICv3 418 Level 100ac000.serial:rx err
32: 4 0 0 0 GICv3 420 Level 100ac000.serial:rx full
33: 206 0 0 0 GICv3 421 Level 100ac000.serial:tx empty
34: 0 0 0 0 GICv3 419 Level 100ac000.serial:break
35: 13 0 0 0 GICv3 422 Level 100ac000.serial:rx ready
IPI0: 23 26 19 22 Rescheduling interrupts
IPI1: 237 385 152 90 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop NMIs
IPI4: 0 0 0 0 Timer broadcast interrupts
IPI5: 0 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 CPU backtrace interrupts
IPI7: 0 0 0 0 KGDB roundup interrupts
/ # cat /proc/meminfo
MemTotal: 1887948 kB
MemFree: 1849056 kB
MemAvailable: 1816424 kB
/ # cat /sys/devices/soc0/family
RZ/G3L
/ # cat /sys/devices/soc0/machine
Renesas SMARC EVK version 2 based on r9a08g046l48
/ # cat /sys/devices/soc0/soc_id
r9a08g046
/ # cat /sys/devices/soc0/revision
0
Biju Das (12):
dt-bindings: serial: renesas,scif: Document RZ/G3L SoC
dt-bindings: dma: rz-dmac: Document RZ/G3L SoC
dt-bindings: soc: renesas: Document Renesas RZ/G3L SoC variants
dt-bindings: soc: renesas: Document RZ/G3L SMARC SoM and Carrier-II
EVK
dt-bindings: soc: renesas: renesas,rzg2l-sysc: Document RZ/G3L SoC
soc: renesas: rz-sysc: Add SoC identification for RZ/G3L SoC
dt-bindings: clock: Document RZ/G3L SoC
clk: renesas: Add support for RZ/G3L SoC
arm64: dts: renesas: Add initial DTSI for RZ/G3L SoC
arm64: dts: renesas: Add initial support for RZ/G3L SMARC SoM
arm64: dts: renesas: renesas-smarc2: Move usb3 nodes to board DTS
arm64: dts: renesas: Add initial device tree for RZ/G3L SMARC EVK
board
.../bindings/clock/renesas,rzg2l-cpg.yaml | 1 +
.../bindings/dma/renesas,rz-dmac.yaml | 1 +
.../bindings/serial/renesas,scif.yaml | 1 +
.../soc/renesas/renesas,rzg2l-sysc.yaml | 1 +
.../bindings/soc/renesas/renesas.yaml | 13 +
arch/arm64/boot/dts/renesas/Makefile | 2 +
arch/arm64/boot/dts/renesas/r9a08g046.dtsi | 219 +++++++++++
.../boot/dts/renesas/r9a08g046l48-smarc.dts | 41 +++
arch/arm64/boot/dts/renesas/r9a08g046l48.dtsi | 13 +
.../boot/dts/renesas/r9a09g047e57-smarc.dts | 6 +
.../boot/dts/renesas/renesas-smarc2.dtsi | 8 -
.../boot/dts/renesas/rzg3l-smarc-som.dtsi | 22 ++
drivers/clk/renesas/Kconfig | 7 +-
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r9a08g046-cpg.c | 137 +++++++
drivers/clk/renesas/rzg2l-cpg.c | 6 +
drivers/clk/renesas/rzg2l-cpg.h | 1 +
drivers/soc/renesas/Kconfig | 12 +
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/r9a08g046-sysc.c | 91 +++++
drivers/soc/renesas/rz-sysc.c | 3 +
drivers/soc/renesas/rz-sysc.h | 1 +
include/dt-bindings/clock/r9a08g046-cpg.h | 339 ++++++++++++++++++
23 files changed, 918 insertions(+), 9 deletions(-)
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046l48.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi
create mode 100644 drivers/clk/renesas/r9a08g046-cpg.c
create mode 100644 drivers/soc/renesas/r9a08g046-sysc.c
create mode 100644 include/dt-bindings/clock/r9a08g046-cpg.h
--
2.43.0
^ permalink raw reply
* Re: [PATCH] MEDIATEK: serial: 8250_mtk: Add ACPI support
From: Zhiyong Tao (陶志勇) @ 2026-01-20 9:07 UTC (permalink / raw)
To: gregkh@linuxfoundation.org
Cc: Project_Global_Digits_Upstream_Group, fred2599@gmail.com,
Yenchia Chen (陳彥嘉),
AngeloGioacchino Del Regno, Vasanth Reddy,
linux-kernel@vger.kernel.org,
Liguo Zhang (张立国), jirislaby@kernel.org,
linux-serial@vger.kernel.org, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <2026011631-zips-provider-6c46@gregkh>
On Fri, 2026-01-16 at 14:20 +0100, Greg KH wrote:
> On Mon, Jan 05, 2026 at 10:39:55AM +0800, Zhiyong Tao wrote:
> > From: "Zhiyong.Tao" <zhiyong.tao@mediatek.com>
> >
> > Add ACPI support to 8250_mtk driver. This makes it possible to
> > use UART on ARM-based desktops with EDK2 UEFI firmware.
> >
> > Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com>
> > Signed-off-by: Zhiyong.Tao <zhiyong.tao@mediatek.com>
>
> Please use your name, not '.' in it, like your email has. Yenchia
> did
> it properly here.
>
> thanks,
>
> greg k-h
>
> ==> Thank you for your suggestion. I will fix this change in the next
> version.
^ permalink raw reply
* Re: [PATCH 1/2] serial: 8250: 8250_omap.c: Add support for handling UART error conditions
From: Kumar, Udit @ 2026-01-20 5:28 UTC (permalink / raw)
To: Moteen Shah, gregkh, jirislaby
Cc: linux-kernel, linux-serial, vigneshr, gehariprasath, g-praveen,
j-keerthy, u-kumar1
In-Reply-To: <20260112081829.63049-2-m-shah@ti.com>
please check subject of patch
On 1/12/2026 1:48 PM, Moteen Shah wrote:
> The DMA IRQ handler does not accounts for the overrun(OE) or any other
accounts to account
> errors being reported by the IP before triggering a DMA transaction which
transaction, which
> leads to the interrupts not being handled resulting into an IRQ storm.
>
> The way to handle OE is to:
> 1. Reset the RX FIFO.
> 2. Read the UART_RESUME register, which clears the internal flag
>
> Earlier, the driver issued DMA transations even in case of OE which shouldn't
transations to transactions
> be done according to the OE handling mechanism mentioned above, as we are
> resetting the FIFO's, refer section: "12.1.6.4.8.1.3.6 Overrun During
FIFO's to FIFO
> Receive" [0].
>
> [0] https://www.ti.com/lit/pdf/spruiu1
>
> Signed-off-by: Moteen Shah <m-shah@ti.com>
> ---
> drivers/tty/serial/8250/8250_omap.c | 23 +++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 9e49ef48b851..e26bae0a6488 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -100,6 +100,9 @@
> #define OMAP_UART_REV_52 0x0502
> #define OMAP_UART_REV_63 0x0603
>
> +/* Resume register */
> +#define UART_OMAP_RESUME 0x0B
> +
> /* Interrupt Enable Register 2 */
> #define UART_OMAP_IER2 0x1B
> #define UART_OMAP_IER2_RHR_IT_DIS BIT(2)
> @@ -119,7 +122,6 @@
> /* Timeout low and High */
> #define UART_OMAP_TO_L 0x26
> #define UART_OMAP_TO_H 0x27
> -
> struct omap8250_priv {
> void __iomem *membase;
> int line;
> @@ -1256,6 +1258,20 @@ static u16 omap_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir, u16 status
> return status;
> }
>
> +static void am654_8250_handle_uart_errors(struct uart_8250_port *up, u8 iir, u16 status)
> +{
> + if (status & UART_LSR_OE) {
> + serial8250_clear_and_reinit_fifos(up);
> + serial_in(up, UART_LSR);
> + serial_in(up, UART_OMAP_RESUME);
> + } else {
> + if (status & (UART_LSR_FE | UART_LSR_PE | UART_LSR_BI))
> + serial_in(up, UART_RX);
> + if (iir & UART_IIR_XOFF)
> + serial_in(up, UART_IIR);
> + }
> +}
> +
> static void am654_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir,
> u16 status)
> {
> @@ -1266,7 +1282,8 @@ static void am654_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir,
> * Queue a new transfer if FIFO has data.
> */
> if ((status & (UART_LSR_DR | UART_LSR_BI)) &&
> - (up->ier & UART_IER_RDI)) {
> + (up->ier & UART_IER_RDI) && !(status & UART_LSR_OE)) {
> + am654_8250_handle_uart_errors(up, iir, status);
may be you can think of splitting error handing into 2 functions ie
handle BI or so and OE error.
when you call above function am654_8250_handle_uart_errors, first
condition will be always false.
> omap_8250_rx_dma(up);
> serial_out(up, UART_OMAP_EFR2, UART_OMAP_EFR2_TIMEOUT_BEHAVE);
> } else if ((iir & 0x3f) == UART_IIR_RX_TIMEOUT) {
> @@ -1282,6 +1299,8 @@ static void am654_8250_handle_rx_dma(struct uart_8250_port *up, u8 iir,
> serial_out(up, UART_OMAP_EFR2, 0x0);
> up->ier |= UART_IER_RLSI | UART_IER_RDI;
> serial_out(up, UART_IER, up->ier);
> + } else {
> + am654_8250_handle_uart_errors(up, iir, status);
I assume , you will hit this else only case of OE ? , if yes then do you
think, call to error handling should be conditional ?
> }
> }
>
^ permalink raw reply
* Re: [PATCH 2/2] serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done
From: Kumar, Udit @ 2026-01-20 5:18 UTC (permalink / raw)
To: Moteen Shah, gregkh, jirislaby
Cc: linux-kernel, linux-serial, vigneshr, gehariprasath, g-praveen,
j-keerthy, u-kumar1
In-Reply-To: <20260112081829.63049-3-m-shah@ti.com>
Please check subject
git log drivers/tty/serial/8250/8250_omap.c
serial: 8250_omap: ....
On 1/12/2026 1:48 PM, Moteen Shah wrote:
> Clear rx_running flag only after DMA teardown polling completes. In the
> previous implementation the flag was being cleared while hardware teardown
hardware to DMA please,
> was still in progress, creating a mismatch between software state
> (flag = 0, "ready") and hardware state (still terminating).
>
> Signed-off-by: Moteen Shah <m-shah@ti.com>
> ---
> drivers/tty/serial/8250/8250_omap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index e26bae0a6488..272bc07c9a6b 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -931,7 +931,6 @@ static void __dma_rx_do_complete(struct uart_8250_port *p)
> goto out;
>
> cookie = dma->rx_cookie;
> - dma->rx_running = 0;
>
> /* Re-enable RX FIFO interrupt now that transfer is complete */
> if (priv->habit & UART_HAS_RHR_IT_DIS) {
> @@ -965,6 +964,7 @@ static void __dma_rx_do_complete(struct uart_8250_port *p)
> goto out;
> ret = tty_insert_flip_string(tty_port, dma->rx_buf, count);
>
> + dma->rx_running = 0;
> p->port.icount.rx += ret;
> p->port.icount.buf_overrun += count - ret;
> out:
^ permalink raw reply
* Re: [PATCH v8] tty: tty_port: add workqueue to flip TTY buffer
From: Jiri Slaby @ 2026-01-19 7:08 UTC (permalink / raw)
To: Xin Zhao, gregkh, tj; +Cc: hch, linux-kernel, linux-serial
In-Reply-To: <20251223034836.2625547-1-jackzxcui1989@163.com>
On 23. 12. 25, 4:48, Xin Zhao wrote:
> On the embedded platform, certain critical data, such as IMU data, is
> transmitted through UART. The tty_flip_buffer_push() interface in the TTY
> layer uses system_dfl_wq to handle the flipping of the TTY buffer.
> Although the unbound workqueue can create new threads on demand and wake
> up the kworker thread on an idle CPU, it may be preempted by real-time
> tasks or other high-prio tasks.
>
> flush_to_ldisc() needs to wake up the relevant data handle thread. When
> executing __wake_up_common_lock(), it calls spin_lock_irqsave(), which
> does not disable preemption but disables migration in RT-Linux. This
> prevents the kworker thread from being migrated to other cores by CPU's
> balancing logic, resulting in long delays. The call trace is as follows:
> __wake_up_common_lock
> __wake_up
> ep_poll_callback
> __wake_up_common
> __wake_up_common_lock
> __wake_up
> n_tty_receive_buf_common
> n_tty_receive_buf2
> tty_ldisc_receive_buf
> tty_port_default_receive_buf
> flush_to_ldisc
>
> In our system, the processing interval for each frame of IMU data
> transmitted via UART can experience significant jitter due to this issue.
> Instead of the expected 10 to 15 ms frame processing interval, we see
> spikes up to 30 to 35 ms. Moreover, in just one or two hours, there can
> be 2 to 3 occurrences of such high jitter, which is quite frequent. This
> jitter exceeds the software's tolerable limit of 20 ms.
>
> Introduce flip_wq in tty_port which can be set by tty_port_link_wq() or as
> default linked to default workqueue allocated when tty_register_driver().
> The default workqueue is allocated with flag WQ_SYSFS, so that cpumask and
> nice can be set dynamically. The execution timing of tty_port_link_wq() is
> not clearly restricted. The newly added function tty_port_link_driver_wq()
> checks whether the flip_wq of the tty_port has already been assigned when
> linking the default tty_driver's workqueue to the port. After the user has
> set a custom workqueue for a certain tty_port using tty_port_link_wq(), the
> system will only use this custom workqueue, even if tty_driver does not
> have %TTY_DRIVER_CUSTOM_WORKQUEUE flag.
>
> Introduce %TTY_DRIVER_CUSTOM_WORKQUEUE flag meaning not to create the
> default single tty_driver workqueue. Two reasons why need to introduce the
> %TTY_DRIVER_CUSTOM_WORKQUEUE flag:
> 1. If the WQ_SYSFS parameter is enabled, workqueue_sysfs_register() will
> fail when trying to create a workqueue with the same name. The pty is an
> example of this; if both CONFIG_LEGACY_PTYS and CONFIG_UNIX98_PTYS are
> enabled, the call to tty_register_driver() in unix98_pty_init() will fail.
> 2. Different tty ports may be used for different tasks, which may require
> separate core binding control via workqueues. In this case, the workqueue
> created by default in the tty driver is unnecessary. Enabling this flag
> prevents the creation of this redundant workqueue.
>
> After applying this patch, we can set the related UART TTY flip buffer
> workqueue by sysfs. We set the cpumask to CPU cores associated with the
> IMU tasks, and set the nice to -20. Testing has shown significant
> improvement in the previously described issue, with almost no stuttering
> occurring anymore.
>
> Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
This forgotten XMAS present LGTM ;).
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
--
js
suse labs
^ permalink raw reply
* Re: [PATCH v5 11/11] arm64: dts: microchip: add EV23X71A board
From: Claudiu Beznea @ 2026-01-18 14:03 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
linusw, olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial
Cc: luka.perkov
In-Reply-To: <20260115114021.111324-12-robert.marko@sartura.hr>
On 1/15/26 13:37, Robert Marko wrote:
> Microchip EV23X71A is an LAN9696 based evaluation board.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH v5 6/7] riscv: dts: spacemit: add initial support for K3 SoC
From: Guodong Xu @ 2026-01-18 13:58 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Paul Walmsley, Conor Dooley, Kevin Meng Zhang, Andrew Jones,
devicetree, linux-riscv, linux-kernel, spacemit, linux-serial,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan,
Daniel Lezcano, Samuel Holland, Anup Patel, Greg Kroah-Hartman,
Jiri Slaby, Lubomir Rintel, Yangyu Chen, Thomas Gleixner
In-Reply-To: <c0395221-4248-4eb7-949e-ac86c40ec99b@gmx.de>
Hi, Heinrich
On Sun, Jan 18, 2026 at 7:41 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 1/15/26 07:51, Guodong Xu wrote:
> > SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
> > Add nodes of uarts, timer and interrupt-controllers. Also add M-mode
> > APLIC (maplic) and IMSIC (mimsic) nodes to represent the hardware
> > topology and ready for potential firmware usage.
> >
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> > v5: Update the copyright year to 2026.
> > Set M-mode maplic and mimsic status to "reserved".
> > Update the commit message per Yixun's suggestion.
> > In maplic node, use riscv,delegation to match kernel binding. OpenSBI
> > accepts both delegate and delegation, but the binding documents only
> > riscv,delegation.
> > v4: Fix missing blank space after commas in compatible string.
> > Add m-mode imsic and aplic node.
> > Reorder properties in simsic, saplic, mimsic, and maplic nodes
> > to match DTS coding style.
> > v3: Remove "supm" from the riscv,isa-extensions list.
> > v2: Remove aliases from k3.dtsi, they should be in board DTS.
> > Updated riscv,isa-extensions with new extensions from the extensions.yaml.
> > ---
> > arch/riscv/boot/dts/spacemit/k3.dtsi | 590 +++++++++++++++++++++++++++++++++++
> > 1 file changed, 590 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > new file mode 100644
> > index 000000000000..53425badfea9
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > @@ -0,0 +1,590 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (c) 2026 SpacemiT (Hangzhou) Technology Co. Ltd
> > + * Copyright (c) 2026 Guodong Xu <guodong@riscstar.com>
> > + */
> > +
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +
> > +/dts-v1/;
> > +
> > +/ {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + model = "SpacemiT K3";
> > + compatible = "spacemit,k3";
> > +
> > + cpus: cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + timebase-frequency = <24000000>;
> > +
> > + cpu_0: cpu@0 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <0>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache0>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu0_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_1: cpu@1 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <1>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache0>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu1_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_2: cpu@2 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <2>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache0>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu2_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_3: cpu@3 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <3>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache0>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu3_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_4: cpu@4 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <4>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache1>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu4_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_5: cpu@5 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <5>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
>
> Should zvl256b be added to the X100 description to indicate the vector
> length?
This is a general topic relevant to all "v" capable RISC-V cores.
To my knowledge, there are currently no upstream Device Tree bindings defined
for zvl*b or vlen. Instead of defining this statically in the DTS, the kernel
history suggests a preference for dynamic discovery. With the existence of
CSR_VLENB, reading it during kernel boot (or say 'hart boot') makes more sense.
This is what actually happening in the kernel right now.
This approach has been part of the design since the earliest
implementations [1].
Link: https://lore.kernel.org/linux-riscv/e896db91e3303f64ac401021f848e536e9d42aaa.1590474856.git.greentime.hu@sifive.com/
[1]
BR,
Guodong Xu
>
> Best regards
>
> Heinrich
>
>
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache1>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu5_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_6: cpu@6 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <6>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache1>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu6_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu_7: cpu@7 {
> > + compatible = "spacemit,x100", "riscv";
> > + device_type = "cpu";
> > + reg = <7>;
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> > + "sha", "shcounterenw", "shgatpa", "shtvala",
> > + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> > + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> > + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> > + "sstvala", "sstvecd", "ssu64xl", "svade",
> > + "svinval", "svnapot", "svpbmt", "za64rs",
> > + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> > + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> > + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> > + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> > + "zicond", "zicsr", "zifencei", "zihintntl",
> > + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> > + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> > + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> > + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> > + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> > + riscv,cbom-block-size = <64>;
> > + riscv,cbop-block-size = <64>;
> > + riscv,cboz-block-size = <64>;
> > + i-cache-block-size = <64>;
> > + i-cache-size = <65536>;
> > + i-cache-sets = <256>;
> > + d-cache-block-size = <64>;
> > + d-cache-size = <65536>;
> > + d-cache-sets = <256>;
> > + next-level-cache = <&l2_cache1>;
> > + mmu-type = "riscv,sv39";
> > +
> > + cpu7_intc: interrupt-controller {
> > + compatible = "riscv,cpu-intc";
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + l2_cache0: cache-controller-0 {
> > + compatible = "cache";
> > + cache-block-size = <64>;
> > + cache-level = <2>;
> > + cache-size = <4194304>;
> > + cache-sets = <4096>;
> > + cache-unified;
> > + };
> > +
> > + l2_cache1: cache-controller-1 {
> > + compatible = "cache";
> > + cache-block-size = <64>;
> > + cache-level = <2>;
> > + cache-size = <4194304>;
> > + cache-sets = <4096>;
> > + cache-unified;
> > + };
> > +
> > + cpu-map {
> > + cluster0 {
> > + core0 {
> > + cpu = <&cpu_0>;
> > + };
> > + core1 {
> > + cpu = <&cpu_1>;
> > + };
> > + core2 {
> > + cpu = <&cpu_2>;
> > + };
> > + core3 {
> > + cpu = <&cpu_3>;
> > + };
> > + };
> > +
> > + cluster1 {
> > + core0 {
> > + cpu = <&cpu_4>;
> > + };
> > + core1 {
> > + cpu = <&cpu_5>;
> > + };
> > + core2 {
> > + cpu = <&cpu_6>;
> > + };
> > + core3 {
> > + cpu = <&cpu_7>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + soc: soc {
> > + compatible = "simple-bus";
> > + interrupt-parent = <&saplic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + dma-noncoherent;
> > + ranges;
> > +
> > + uart0: serial@d4017000 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017000 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <42 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart2: serial@d4017100 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017100 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <44 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart3: serial@d4017200 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017200 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <45 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart4: serial@d4017300 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017300 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <46 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart5: serial@d4017400 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017400 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <47 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart6: serial@d4017500 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017500 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <48 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart7: serial@d4017600 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017600 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <49 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart8: serial@d4017700 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017700 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <50 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart9: serial@d4017800 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd4017800 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <51 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + uart10: serial@d401f000 {
> > + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> > + reg = <0x0 0xd401f000 0x0 0x100>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clock-frequency = <14700000>;
> > + interrupts = <281 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + simsic: interrupt-controller@e0400000 {
> > + compatible = "spacemit,k3-imsics", "riscv,imsics";
> > + reg = <0x0 0xe0400000 0x0 0x200000>;
> > + #interrupt-cells = <0>;
> > + #msi-cells = <0>;
> > + interrupt-controller;
> > + interrupts-extended = <&cpu0_intc 9>, <&cpu1_intc 9>,
> > + <&cpu2_intc 9>, <&cpu3_intc 9>,
> > + <&cpu4_intc 9>, <&cpu5_intc 9>,
> > + <&cpu6_intc 9>, <&cpu7_intc 9>;
> > + msi-controller;
> > + riscv,guest-index-bits = <6>;
> > + riscv,hart-index-bits = <4>;
> > + riscv,num-guest-ids = <511>;
> > + riscv,num-ids = <511>;
> > + };
> > +
> > + saplic: interrupt-controller@e0804000 {
> > + compatible = "spacemit,k3-aplic", "riscv,aplic";
> > + reg = <0x0 0xe0804000 0x0 0x4000>;
> > + #interrupt-cells = <2>;
> > + interrupt-controller;
> > + msi-parent = <&simsic>;
> > + riscv,num-sources = <512>;
> > + };
> > +
> > + clint: timer@e081c000 {
> > + compatible = "spacemit,k3-clint", "sifive,clint0";
> > + reg = <0x0 0xe081c000 0x0 0x4000>;
> > + interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
> > + <&cpu1_intc 3>, <&cpu1_intc 7>,
> > + <&cpu2_intc 3>, <&cpu2_intc 7>,
> > + <&cpu3_intc 3>, <&cpu3_intc 7>,
> > + <&cpu4_intc 3>, <&cpu4_intc 7>,
> > + <&cpu5_intc 3>, <&cpu5_intc 7>,
> > + <&cpu6_intc 3>, <&cpu6_intc 7>,
> > + <&cpu7_intc 3>, <&cpu7_intc 7>;
> > + };
> > +
> > + mimsic: interrupt-controller@f1000000 {
> > + compatible = "spacemit,k3-imsics", "riscv,imsics";
> > + reg = <0x0 0xf1000000 0x0 0x10000>;
> > + #interrupt-cells = <0>;
> > + #msi-cells = <0>;
> > + interrupt-controller;
> > + interrupts-extended = <&cpu0_intc 11>, <&cpu1_intc 11>,
> > + <&cpu2_intc 11>, <&cpu3_intc 11>,
> > + <&cpu4_intc 11>, <&cpu5_intc 11>,
> > + <&cpu6_intc 11>, <&cpu7_intc 11>;
> > + msi-controller;
> > + riscv,guest-index-bits = <6>;
> > + riscv,hart-index-bits = <4>;
> > + riscv,num-guest-ids = <511>;
> > + riscv,num-ids = <511>;
> > +
> > + status = "reserved";
> > + };
> > +
> > + maplic: interrupt-controller@f1800000 {
> > + compatible = "spacemit,k3-aplic", "riscv,aplic";
> > + reg = <0x0 0xf1800000 0x0 0x4000>;
> > + #interrupt-cells = <2>;
> > + interrupt-controller;
> > + msi-parent = <&mimsic>;
> > + riscv,children = <&saplic>;
> > + riscv,delegation = <&saplic 1 512>;
> > + riscv,num-sources = <512>;
> > +
> > + status = "reserved";
> > + };
> > + };
> > +};
> >
>
^ permalink raw reply
* Re: [PATCH v5 6/7] riscv: dts: spacemit: add initial support for K3 SoC
From: Heinrich Schuchardt @ 2026-01-17 23:41 UTC (permalink / raw)
To: Guodong Xu
Cc: Paul Walmsley, Conor Dooley, Kevin Meng Zhang, Andrew Jones,
devicetree, linux-riscv, linux-kernel, spacemit, linux-serial,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan,
Daniel Lezcano, Samuel Holland, Anup Patel, Greg Kroah-Hartman,
Jiri Slaby, Lubomir Rintel, Yangyu Chen, Thomas Gleixner
In-Reply-To: <20260115-k3-basic-dt-v5-6-6990ac9f4308@riscstar.com>
On 1/15/26 07:51, Guodong Xu wrote:
> SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
> Add nodes of uarts, timer and interrupt-controllers. Also add M-mode
> APLIC (maplic) and IMSIC (mimsic) nodes to represent the hardware
> topology and ready for potential firmware usage.
>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v5: Update the copyright year to 2026.
> Set M-mode maplic and mimsic status to "reserved".
> Update the commit message per Yixun's suggestion.
> In maplic node, use riscv,delegation to match kernel binding. OpenSBI
> accepts both delegate and delegation, but the binding documents only
> riscv,delegation.
> v4: Fix missing blank space after commas in compatible string.
> Add m-mode imsic and aplic node.
> Reorder properties in simsic, saplic, mimsic, and maplic nodes
> to match DTS coding style.
> v3: Remove "supm" from the riscv,isa-extensions list.
> v2: Remove aliases from k3.dtsi, they should be in board DTS.
> Updated riscv,isa-extensions with new extensions from the extensions.yaml.
> ---
> arch/riscv/boot/dts/spacemit/k3.dtsi | 590 +++++++++++++++++++++++++++++++++++
> 1 file changed, 590 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> new file mode 100644
> index 000000000000..53425badfea9
> --- /dev/null
> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> @@ -0,0 +1,590 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (c) 2026 SpacemiT (Hangzhou) Technology Co. Ltd
> + * Copyright (c) 2026 Guodong Xu <guodong@riscstar.com>
> + */
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + model = "SpacemiT K3";
> + compatible = "spacemit,k3";
> +
> + cpus: cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + timebase-frequency = <24000000>;
> +
> + cpu_0: cpu@0 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <0>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu0_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_1: cpu@1 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <1>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu1_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_2: cpu@2 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <2>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu2_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_3: cpu@3 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <3>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache0>;
> + mmu-type = "riscv,sv39";
> +
> + cpu3_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_4: cpu@4 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <4>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu4_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_5: cpu@5 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <5>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
Should zvl256b be added to the X100 description to indicate the vector
length?
Best regards
Heinrich
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu5_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_6: cpu@6 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <6>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu6_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + cpu_7: cpu@7 {
> + compatible = "spacemit,x100", "riscv";
> + device_type = "cpu";
> + reg = <7>;
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "h",
> + "sha", "shcounterenw", "shgatpa", "shtvala",
> + "shvsatpa", "shvstvala", "shvstvecd", "smaia",
> + "smstateen", "ssaia", "ssccptr", "sscofpmf",
> + "sscounterenw", "ssnpm", "ssstateen", "sstc",
> + "sstvala", "sstvecd", "ssu64xl", "svade",
> + "svinval", "svnapot", "svpbmt", "za64rs",
> + "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> + "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> + "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> + "ziccamoa", "ziccif", "zicclsm", "zicntr",
> + "zicond", "zicsr", "zifencei", "zihintntl",
> + "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> + "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> + "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> + "zvkned", "zvkng", "zvknha", "zvknhb", "zvks",
> + "zvksc", "zvksed", "zvksg", "zvksh", "zvkt";
> + riscv,cbom-block-size = <64>;
> + riscv,cbop-block-size = <64>;
> + riscv,cboz-block-size = <64>;
> + i-cache-block-size = <64>;
> + i-cache-size = <65536>;
> + i-cache-sets = <256>;
> + d-cache-block-size = <64>;
> + d-cache-size = <65536>;
> + d-cache-sets = <256>;
> + next-level-cache = <&l2_cache1>;
> + mmu-type = "riscv,sv39";
> +
> + cpu7_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> + };
> +
> + l2_cache0: cache-controller-0 {
> + compatible = "cache";
> + cache-block-size = <64>;
> + cache-level = <2>;
> + cache-size = <4194304>;
> + cache-sets = <4096>;
> + cache-unified;
> + };
> +
> + l2_cache1: cache-controller-1 {
> + compatible = "cache";
> + cache-block-size = <64>;
> + cache-level = <2>;
> + cache-size = <4194304>;
> + cache-sets = <4096>;
> + cache-unified;
> + };
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu_0>;
> + };
> + core1 {
> + cpu = <&cpu_1>;
> + };
> + core2 {
> + cpu = <&cpu_2>;
> + };
> + core3 {
> + cpu = <&cpu_3>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <&cpu_4>;
> + };
> + core1 {
> + cpu = <&cpu_5>;
> + };
> + core2 {
> + cpu = <&cpu_6>;
> + };
> + core3 {
> + cpu = <&cpu_7>;
> + };
> + };
> + };
> + };
> +
> + soc: soc {
> + compatible = "simple-bus";
> + interrupt-parent = <&saplic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + dma-noncoherent;
> + ranges;
> +
> + uart0: serial@d4017000 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <42 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart2: serial@d4017100 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017100 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <44 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart3: serial@d4017200 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017200 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <45 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart4: serial@d4017300 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017300 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <46 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart5: serial@d4017400 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017400 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <47 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart6: serial@d4017500 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017500 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <48 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart7: serial@d4017600 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017600 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <49 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart8: serial@d4017700 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017700 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <50 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart9: serial@d4017800 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd4017800 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <51 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart10: serial@d401f000 {
> + compatible = "spacemit,k3-uart", "intel,xscale-uart";
> + reg = <0x0 0xd401f000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14700000>;
> + interrupts = <281 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + simsic: interrupt-controller@e0400000 {
> + compatible = "spacemit,k3-imsics", "riscv,imsics";
> + reg = <0x0 0xe0400000 0x0 0x200000>;
> + #interrupt-cells = <0>;
> + #msi-cells = <0>;
> + interrupt-controller;
> + interrupts-extended = <&cpu0_intc 9>, <&cpu1_intc 9>,
> + <&cpu2_intc 9>, <&cpu3_intc 9>,
> + <&cpu4_intc 9>, <&cpu5_intc 9>,
> + <&cpu6_intc 9>, <&cpu7_intc 9>;
> + msi-controller;
> + riscv,guest-index-bits = <6>;
> + riscv,hart-index-bits = <4>;
> + riscv,num-guest-ids = <511>;
> + riscv,num-ids = <511>;
> + };
> +
> + saplic: interrupt-controller@e0804000 {
> + compatible = "spacemit,k3-aplic", "riscv,aplic";
> + reg = <0x0 0xe0804000 0x0 0x4000>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + msi-parent = <&simsic>;
> + riscv,num-sources = <512>;
> + };
> +
> + clint: timer@e081c000 {
> + compatible = "spacemit,k3-clint", "sifive,clint0";
> + reg = <0x0 0xe081c000 0x0 0x4000>;
> + interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
> + <&cpu1_intc 3>, <&cpu1_intc 7>,
> + <&cpu2_intc 3>, <&cpu2_intc 7>,
> + <&cpu3_intc 3>, <&cpu3_intc 7>,
> + <&cpu4_intc 3>, <&cpu4_intc 7>,
> + <&cpu5_intc 3>, <&cpu5_intc 7>,
> + <&cpu6_intc 3>, <&cpu6_intc 7>,
> + <&cpu7_intc 3>, <&cpu7_intc 7>;
> + };
> +
> + mimsic: interrupt-controller@f1000000 {
> + compatible = "spacemit,k3-imsics", "riscv,imsics";
> + reg = <0x0 0xf1000000 0x0 0x10000>;
> + #interrupt-cells = <0>;
> + #msi-cells = <0>;
> + interrupt-controller;
> + interrupts-extended = <&cpu0_intc 11>, <&cpu1_intc 11>,
> + <&cpu2_intc 11>, <&cpu3_intc 11>,
> + <&cpu4_intc 11>, <&cpu5_intc 11>,
> + <&cpu6_intc 11>, <&cpu7_intc 11>;
> + msi-controller;
> + riscv,guest-index-bits = <6>;
> + riscv,hart-index-bits = <4>;
> + riscv,num-guest-ids = <511>;
> + riscv,num-ids = <511>;
> +
> + status = "reserved";
> + };
> +
> + maplic: interrupt-controller@f1800000 {
> + compatible = "spacemit,k3-aplic", "riscv,aplic";
> + reg = <0x0 0xf1800000 0x0 0x4000>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + msi-parent = <&mimsic>;
> + riscv,children = <&saplic>;
> + riscv,delegation = <&saplic 1 512>;
> + riscv,num-sources = <512>;
> +
> + status = "reserved";
> + };
> + };
> +};
>
^ permalink raw reply
* [tty:tty-linus] BUILD SUCCESS 27aff0a56b3c77ea1a73641c9b3c4172a8f7238f
From: kernel test robot @ 2026-01-17 2:02 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-linus
branch HEAD: 27aff0a56b3c77ea1a73641c9b3c4172a8f7238f serial: 8250_pci: Fix broken RS485 for F81504/508/512
elapsed time: 729m
configs tested: 175
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-22
arc defconfig gcc-15.2.0
arc haps_hs_defconfig gcc-15.2.0
arc randconfig-001-20260117 gcc-12.5.0
arc randconfig-002-20260117 gcc-12.5.0
arm alldefconfig gcc-15.2.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm mxs_defconfig gcc-15.2.0
arm randconfig-001-20260117 gcc-12.5.0
arm randconfig-002-20260117 gcc-12.5.0
arm randconfig-003-20260117 gcc-12.5.0
arm randconfig-004-20260117 gcc-12.5.0
arm spear3xx_defconfig gcc-15.2.0
arm stm32_defconfig gcc-15.2.0
arm64 allmodconfig clang-22
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260117 clang-22
arm64 randconfig-002-20260117 clang-22
arm64 randconfig-003-20260117 clang-22
arm64 randconfig-004-20260117 clang-22
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260117 clang-22
csky randconfig-002-20260117 clang-22
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260117 clang-22
hexagon randconfig-002-20260117 clang-22
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260117 gcc-13
i386 buildonly-randconfig-002-20260117 gcc-13
i386 buildonly-randconfig-003-20260117 gcc-13
i386 buildonly-randconfig-004-20260117 gcc-13
i386 buildonly-randconfig-005-20260117 gcc-13
i386 buildonly-randconfig-006-20260117 gcc-13
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260117 gcc-14
i386 randconfig-002-20260117 gcc-14
i386 randconfig-003-20260117 gcc-14
i386 randconfig-004-20260117 gcc-14
i386 randconfig-005-20260117 gcc-14
i386 randconfig-006-20260117 gcc-14
i386 randconfig-007-20260117 gcc-14
i386 randconfig-011-20260117 gcc-14
i386 randconfig-012-20260117 gcc-14
i386 randconfig-013-20260117 gcc-14
i386 randconfig-014-20260117 gcc-14
i386 randconfig-015-20260117 gcc-14
i386 randconfig-016-20260117 gcc-14
i386 randconfig-017-20260117 gcc-14
loongarch allmodconfig clang-22
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260117 clang-22
loongarch randconfig-002-20260117 clang-22
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k amcore_defconfig gcc-15.2.0
m68k defconfig clang-19
m68k virt_defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips cu1830-neo_defconfig gcc-15.2.0
mips loongson3_defconfig gcc-15.2.0
nios2 allmodconfig clang-22
nios2 allnoconfig clang-22
nios2 defconfig clang-19
nios2 randconfig-001-20260117 clang-22
nios2 randconfig-002-20260117 clang-22
openrisc allmodconfig clang-22
openrisc allnoconfig clang-22
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-22
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260117 clang-22
parisc randconfig-002-20260117 clang-22
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-22
powerpc amigaone_defconfig gcc-15.2.0
powerpc ge_imp3a_defconfig gcc-15.2.0
powerpc randconfig-001-20260117 clang-22
powerpc randconfig-002-20260117 clang-22
powerpc tqm5200_defconfig gcc-15.2.0
powerpc tqm8540_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260117 clang-22
powerpc64 randconfig-002-20260117 clang-22
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260117 gcc-10.5.0
riscv randconfig-002-20260117 gcc-10.5.0
s390 allmodconfig clang-19
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260117 gcc-10.5.0
s390 randconfig-002-20260117 gcc-10.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-22
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260117 gcc-10.5.0
sh randconfig-002-20260117 gcc-10.5.0
sh sh7785lcr_defconfig gcc-15.2.0
sparc allnoconfig clang-22
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260117 gcc-14.3.0
sparc randconfig-002-20260117 gcc-14.3.0
sparc64 allmodconfig clang-22
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260117 gcc-14.3.0
sparc64 randconfig-002-20260117 gcc-14.3.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260117 gcc-14.3.0
um randconfig-002-20260117 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260117 clang-20
x86_64 randconfig-002-20260117 clang-20
x86_64 randconfig-003-20260117 clang-20
x86_64 randconfig-004-20260117 clang-20
x86_64 randconfig-005-20260117 clang-20
x86_64 randconfig-006-20260117 clang-20
x86_64 randconfig-011-20260117 clang-20
x86_64 randconfig-012-20260117 clang-20
x86_64 randconfig-013-20260117 clang-20
x86_64 randconfig-014-20260117 clang-20
x86_64 randconfig-015-20260117 clang-20
x86_64 randconfig-016-20260117 clang-20
x86_64 randconfig-071-20260117 clang-20
x86_64 randconfig-072-20260117 clang-20
x86_64 randconfig-073-20260117 clang-20
x86_64 randconfig-074-20260117 clang-20
x86_64 randconfig-075-20260117 clang-20
x86_64 randconfig-076-20260117 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-22
xtensa allyesconfig clang-22
xtensa randconfig-001-20260117 gcc-14.3.0
xtensa randconfig-002-20260117 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [tty:tty-testing] BUILD SUCCESS 0e19f73ffde187458fadfff60eb4771bff704296
From: kernel test robot @ 2026-01-17 2:01 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
branch HEAD: 0e19f73ffde187458fadfff60eb4771bff704296 tty: hvc-iucv: Remove KMSG_COMPONENT macro
elapsed time: 728m
configs tested: 175
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-22
arc defconfig gcc-15.2.0
arc haps_hs_defconfig gcc-15.2.0
arc randconfig-001-20260117 gcc-12.5.0
arc randconfig-002-20260117 gcc-12.5.0
arm alldefconfig gcc-15.2.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm mxs_defconfig gcc-15.2.0
arm randconfig-001-20260117 gcc-12.5.0
arm randconfig-002-20260117 gcc-12.5.0
arm randconfig-003-20260117 gcc-12.5.0
arm randconfig-004-20260117 gcc-12.5.0
arm spear3xx_defconfig gcc-15.2.0
arm stm32_defconfig gcc-15.2.0
arm64 allmodconfig clang-22
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260117 clang-22
arm64 randconfig-002-20260117 clang-22
arm64 randconfig-003-20260117 clang-22
arm64 randconfig-004-20260117 clang-22
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260117 clang-22
csky randconfig-002-20260117 clang-22
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260117 clang-22
hexagon randconfig-002-20260117 clang-22
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260117 gcc-13
i386 buildonly-randconfig-002-20260117 gcc-13
i386 buildonly-randconfig-003-20260117 gcc-13
i386 buildonly-randconfig-004-20260117 gcc-13
i386 buildonly-randconfig-005-20260117 gcc-13
i386 buildonly-randconfig-006-20260117 gcc-13
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260117 gcc-14
i386 randconfig-002-20260117 gcc-14
i386 randconfig-003-20260117 gcc-14
i386 randconfig-004-20260117 gcc-14
i386 randconfig-005-20260117 gcc-14
i386 randconfig-006-20260117 gcc-14
i386 randconfig-007-20260117 gcc-14
i386 randconfig-011-20260117 gcc-14
i386 randconfig-012-20260117 gcc-14
i386 randconfig-013-20260117 gcc-14
i386 randconfig-014-20260117 gcc-14
i386 randconfig-015-20260117 gcc-14
i386 randconfig-016-20260117 gcc-14
i386 randconfig-017-20260117 gcc-14
loongarch allmodconfig clang-22
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260117 clang-22
loongarch randconfig-002-20260117 clang-22
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k amcore_defconfig gcc-15.2.0
m68k defconfig clang-19
m68k virt_defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips cu1830-neo_defconfig gcc-15.2.0
mips loongson3_defconfig gcc-15.2.0
nios2 allmodconfig clang-22
nios2 allnoconfig clang-22
nios2 defconfig clang-19
nios2 randconfig-001-20260117 clang-22
nios2 randconfig-002-20260117 clang-22
openrisc allmodconfig clang-22
openrisc allnoconfig clang-22
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-22
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260117 clang-22
parisc randconfig-002-20260117 clang-22
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-22
powerpc amigaone_defconfig gcc-15.2.0
powerpc ge_imp3a_defconfig gcc-15.2.0
powerpc randconfig-001-20260117 clang-22
powerpc randconfig-002-20260117 clang-22
powerpc tqm5200_defconfig gcc-15.2.0
powerpc tqm8540_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260117 clang-22
powerpc64 randconfig-002-20260117 clang-22
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260117 gcc-10.5.0
riscv randconfig-002-20260117 gcc-10.5.0
s390 allmodconfig clang-19
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260117 gcc-10.5.0
s390 randconfig-002-20260117 gcc-10.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-22
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260117 gcc-10.5.0
sh randconfig-002-20260117 gcc-10.5.0
sh sh7785lcr_defconfig gcc-15.2.0
sparc allnoconfig clang-22
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260117 gcc-14.3.0
sparc randconfig-002-20260117 gcc-14.3.0
sparc64 allmodconfig clang-22
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260117 gcc-14.3.0
sparc64 randconfig-002-20260117 gcc-14.3.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260117 gcc-14.3.0
um randconfig-002-20260117 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260117 clang-20
x86_64 randconfig-002-20260117 clang-20
x86_64 randconfig-003-20260117 clang-20
x86_64 randconfig-004-20260117 clang-20
x86_64 randconfig-005-20260117 clang-20
x86_64 randconfig-006-20260117 clang-20
x86_64 randconfig-011-20260117 clang-20
x86_64 randconfig-012-20260117 clang-20
x86_64 randconfig-013-20260117 clang-20
x86_64 randconfig-014-20260117 clang-20
x86_64 randconfig-015-20260117 clang-20
x86_64 randconfig-016-20260117 clang-20
x86_64 randconfig-071-20260117 clang-20
x86_64 randconfig-072-20260117 clang-20
x86_64 randconfig-073-20260117 clang-20
x86_64 randconfig-074-20260117 clang-20
x86_64 randconfig-075-20260117 clang-20
x86_64 randconfig-076-20260117 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-22
xtensa allyesconfig clang-22
xtensa randconfig-001-20260117 gcc-14.3.0
xtensa randconfig-002-20260117 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2] serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists
From: Kendall Willis @ 2026-01-16 19:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: d-gole, vishalm, sebin.francis, msp, khilman, linux-kernel,
linux-serial, Kendall Willis
In TI K3 SoCs, I/O daisy chaining is used to allow wakeup from UART when the
UART controller is off. Set UART device as wakeup capable using out-of-band
wakeup if the 'wakeup' pinctrl state exists and the device may wakeup.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Kendall Willis <k-willis@ti.com>
---
Testing
-------
Tested on a AM62P SK EVM board. Suspend/resume verified with the Main UART
wakeup source by entering a keypress on the console.
This github branch has all the necessary patches to test the patch
using Main UART as a wakeup source:
https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/all
---
Changes in v2:
- Remove extraneous information about patches that need to be
implemented to allow Main UART wakeup on K3 TI SoCs.
- Link to v1: https://lore.kernel.org/r/20251230-uart-wakeup-v1-1-13f1bb905f14@ti.com
---
drivers/tty/serial/8250/8250_omap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 9e49ef48b851bf6cd3b04a77a4d0d7b4e064dc5f..6a5722b722650c1710e79fb76fc1a01cdeccc68f 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1363,6 +1363,8 @@ static int omap8250_select_wakeup_pinctrl(struct device *dev,
if (!device_may_wakeup(dev))
return 0;
+ device_set_out_band_wakeup(dev);
+
return pinctrl_select_state(priv->pinctrl, priv->pinctrl_wakeup);
}
---
base-commit: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b
change-id: 20251230-uart-wakeup-00faeac7c994
Best regards,
--
Kendall Willis <k-willis@ti.com>
^ permalink raw reply related
* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Rob Herring @ 2026-01-16 17:30 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi
In-Reply-To: <ysfkemsf4w7r3eoahfpjdr3z3buec5kvw4qol2njhxrz5tsdpo@4scz632uaj5i>
On Fri, Jan 16, 2026 at 8:43 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Fri, Jan 16, 2026 at 08:19:07AM -0600, Rob Herring wrote:
> > On Thu, Jan 15, 2026 at 4:42 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Wed, Jan 14, 2026 at 11:45:42AM -0600, Rob Herring wrote:
> > > > On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > >
> > > > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote:
> > > > > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
> > > > > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
> > > > > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the
> > > > > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
> > > > > > > devices. Spec also provides an optional interface to connect the UIM card,
> > > > > > > but that is not covered in this binding.
> > > > > > >
> > > > > > > The connector provides a primary power supply of 3.3v, along with an
> > > > > > > optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
> > > > > > > 1.8v sideband signaling.
> > > > > > >
> > > > > > > The connector also supplies optional signals in the form of GPIOs for fine
> > > > > > > grained power management.
> > > > > > >
> > > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > > > ---
> > > > > > > .../bindings/connector/pcie-m2-e-connector.yaml | 154 +++++++++++++++++++++
> > > > > > > MAINTAINERS | 1 +
> > > > > > > 2 files changed, 155 insertions(+)
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..b65b39ddfd19
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > > > @@ -0,0 +1,154 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: PCIe M.2 Mechanical Key E Connector
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > > > +
> > > > > > > +description:
> > > > > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E
> > > > > > > + connector. Mechanical Key E connectors are used to connect Wireless
> > > > > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host
> > > > > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C.
> > > > > > > +
> > > > > > > +properties:
> > > > > > > + compatible:
> > > > > > > + const: pcie-m2-e-connector
> > > > > > > +
> > > > > > > + vpcie3v3-supply:
> > > > > > > + description: A phandle to the regulator for 3.3v supply.
> > > > > > > +
> > > > > > > + vpcie1v8-supply:
> > > > > > > + description: A phandle to the regulator for VIO 1.8v supply.
> > > > > >
> > > > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you
> > > > > > may need something in DT to ensure those are powered. However, there's
> > > > > > no guarantee that it's a single supply.
> > > > > >
> > > > >
> > > > > 1.8v VIO supply is an optional supply and is only required if the platform
> > > > > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in
> > > > > the example for completeness.
> > > >
> > > > My point is that PERST# and WAKE# supplies could be 2 different 1.8V
> > > > supplies and those supply the I/O pads of the GPIO pins (and possibly
> > > > external pull-ups) that drive them. The 1.8V supply doesn't supply
> > > > 1.8V to the slot, so making it a slot/connector property is wrong.
> > > >
> > >
> > > Ok, I get your point that VIO 1.8v supply is just limited to the I/O logic and
> > > not the whole card/adapter. But I don't get your multiple supplies concern. Spec
> > > says, "A 1.8 V supply pin called VIO 1.8 V is used to supply the on-Adapter I/O
> > > buffer circuitry operating at 1.8 V." So it implies that either the single
> > > supply available to the card through VIO might be used to power the whole I/O
> > > circuit logic or the card can derive its own 1.8v supply from 3.3v supply.
> > >
> > > So how come the card can have 2 different 1.8v supplies powering the I/O
> > > circuitry?
> >
> > Is there a pin on the connector for 1.8V supply? I don't have the
> > spec, but the pinout I found[1] didn't show one. If there's a pin,
> > then I have no concern.
> >
>
> Oh yes, there is a single VIO pin defined in the spec for multiple Keys. Since
> it is optional, it could've been omitted in the design you referenced.
>
> So should I name it as vio1v8-supply or vpcie1v8-supply? I don't see any other
> 1.8v supplies other than the VIO supply though.
vpcie1v8 is fine.
Rob
^ permalink raw reply
* Re: [PATCH] serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists
From: Greg Kroah-Hartman @ 2026-01-16 15:47 UTC (permalink / raw)
To: Kendall Willis
Cc: Jiri Slaby, d-gole, vishalm, sebin.francis, msp, khilman, a-kaur,
s-kochidanadu, linux-kernel, linux-serial
In-Reply-To: <f7a2e47b-a37e-4735-91ea-4fcac3217186@ti.com>
On Fri, Jan 16, 2026 at 09:37:44AM -0600, Kendall Willis wrote:
> On 1/16/26 07:16, Greg Kroah-Hartman wrote:
> > On Tue, Dec 30, 2025 at 03:24:51PM -0600, Kendall Willis wrote:
> > > In TI K3 SoCs, I/O daisy chaining is used to allow wakeup from UART when
> > > the UART controller is off. Set UART device as wakeup capable using
> > > out-of-band wakeup if the 'wakeup' pinctrl state exists and the device may
> > > wakeup.
> > >
> > > Signed-off-by: Kendall Willis <k-willis@ti.com>
> > > ---
> > > Implementation
> > > --------------
> > > This patch is intended to be implemented along with the following
> > > series. This patch has no dependencies on any of the other series:
> > >
> > > 1. "pmdomain: ti_sci: handle wakeup constraint for out-of-band wakeup":
> > > Skips setting constraints for wakeup sources that have out-of-band
> > > wakeup capability.
> > > https://github.com/kwillis01/linux/commits/v6.19/uart-daisy-chain/pmdomain
> > >
> > > 2. "serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists"
> > > (this patch): Implements out-of-band wakeup from the UARTs for TI K3
> > > SoCs
> > > https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/uart-wakeup
> > >
> > > 3. "arm64: dts: ti: k3-am62: Support Main UART wakeup": Implements the
> > > functionality to wakeup the system from the Main UART
> > > https://github.com/kwillis01/linux/tree/b4/uart-daisy-chain-dts
> >
> > How am I to pull any of this into the mainline kernel tree? If this is
> > dependant on those out-of-tree stuff, there's no need for me to take
> > this now, please submit this all together properly.
>
> This patch has no dependencies on the listed series. I listed them so that
> there was a full picture of the feature implementation. The "pmdomain:
> ti_sci: handle wakeup constraint for out-of-band wakeup" patch has been
> merged already [1]. The "arm64: dts: ti: k3-am62: Support Main UART wakeup"
> series is posted [2] and has a dependency on this patch. Sorry for the
> confusion with the GitHub links, in the future I either won't add them or
> will add lore links instead.
>
> [1] https://lore.kernel.org/all/20251230-pmdomain-v1-1-3a009d1ff72e@ti.com/
> [2] https://lore.kernel.org/all/20260106-b4-uart-daisy-chain-dts-v3-0-398a66258f2c@ti.com/
>
> Best,
> Kendall Willis <k-willis@ti.com>
Great, can you resend this then without that information to confuse me?
:)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists
From: Kendall Willis @ 2026-01-16 15:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, d-gole, vishalm, sebin.francis, msp, khilman, a-kaur,
s-kochidanadu, linux-kernel, linux-serial
In-Reply-To: <2026011620-clause-gecko-2cb0@gregkh>
On 1/16/26 07:16, Greg Kroah-Hartman wrote:
> On Tue, Dec 30, 2025 at 03:24:51PM -0600, Kendall Willis wrote:
>> In TI K3 SoCs, I/O daisy chaining is used to allow wakeup from UART when
>> the UART controller is off. Set UART device as wakeup capable using
>> out-of-band wakeup if the 'wakeup' pinctrl state exists and the device may
>> wakeup.
>>
>> Signed-off-by: Kendall Willis <k-willis@ti.com>
>> ---
>> Implementation
>> --------------
>> This patch is intended to be implemented along with the following
>> series. This patch has no dependencies on any of the other series:
>>
>> 1. "pmdomain: ti_sci: handle wakeup constraint for out-of-band wakeup":
>> Skips setting constraints for wakeup sources that have out-of-band
>> wakeup capability.
>> https://github.com/kwillis01/linux/commits/v6.19/uart-daisy-chain/pmdomain
>>
>> 2. "serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists"
>> (this patch): Implements out-of-band wakeup from the UARTs for TI K3
>> SoCs
>> https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/uart-wakeup
>>
>> 3. "arm64: dts: ti: k3-am62: Support Main UART wakeup": Implements the
>> functionality to wakeup the system from the Main UART
>> https://github.com/kwillis01/linux/tree/b4/uart-daisy-chain-dts
>
> How am I to pull any of this into the mainline kernel tree? If this is
> dependant on those out-of-tree stuff, there's no need for me to take
> this now, please submit this all together properly.
This patch has no dependencies on the listed series. I listed them so
that there was a full picture of the feature implementation. The
"pmdomain: ti_sci: handle wakeup constraint for out-of-band wakeup"
patch has been merged already [1]. The "arm64: dts: ti: k3-am62: Support
Main UART wakeup" series is posted [2] and has a dependency on this
patch. Sorry for the confusion with the GitHub links, in the future I
either won't add them or will add lore links instead.
[1] https://lore.kernel.org/all/20251230-pmdomain-v1-1-3a009d1ff72e@ti.com/
[2]
https://lore.kernel.org/all/20260106-b4-uart-daisy-chain-dts-v3-0-398a66258f2c@ti.com/
Best,
Kendall Willis <k-willis@ti.com>
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Manivannan Sadhasivam @ 2026-01-16 14:42 UTC (permalink / raw)
To: Rob Herring
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi
In-Reply-To: <CAL_JsqKKBjurY7ZrScayvkTijR-F6GWBofry48xoPFBFi55u4w@mail.gmail.com>
On Fri, Jan 16, 2026 at 08:19:07AM -0600, Rob Herring wrote:
> On Thu, Jan 15, 2026 at 4:42 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Wed, Jan 14, 2026 at 11:45:42AM -0600, Rob Herring wrote:
> > > On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > >
> > > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote:
> > > > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote:
> > > > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
> > > > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
> > > > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the
> > > > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
> > > > > > devices. Spec also provides an optional interface to connect the UIM card,
> > > > > > but that is not covered in this binding.
> > > > > >
> > > > > > The connector provides a primary power supply of 3.3v, along with an
> > > > > > optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
> > > > > > 1.8v sideband signaling.
> > > > > >
> > > > > > The connector also supplies optional signals in the form of GPIOs for fine
> > > > > > grained power management.
> > > > > >
> > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > > ---
> > > > > > .../bindings/connector/pcie-m2-e-connector.yaml | 154 +++++++++++++++++++++
> > > > > > MAINTAINERS | 1 +
> > > > > > 2 files changed, 155 insertions(+)
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > > new file mode 100644
> > > > > > index 000000000000..b65b39ddfd19
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > > @@ -0,0 +1,154 @@
> > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: PCIe M.2 Mechanical Key E Connector
> > > > > > +
> > > > > > +maintainers:
> > > > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > > +
> > > > > > +description:
> > > > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E
> > > > > > + connector. Mechanical Key E connectors are used to connect Wireless
> > > > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host
> > > > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C.
> > > > > > +
> > > > > > +properties:
> > > > > > + compatible:
> > > > > > + const: pcie-m2-e-connector
> > > > > > +
> > > > > > + vpcie3v3-supply:
> > > > > > + description: A phandle to the regulator for 3.3v supply.
> > > > > > +
> > > > > > + vpcie1v8-supply:
> > > > > > + description: A phandle to the regulator for VIO 1.8v supply.
> > > > >
> > > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you
> > > > > may need something in DT to ensure those are powered. However, there's
> > > > > no guarantee that it's a single supply.
> > > > >
> > > >
> > > > 1.8v VIO supply is an optional supply and is only required if the platform
> > > > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in
> > > > the example for completeness.
> > >
> > > My point is that PERST# and WAKE# supplies could be 2 different 1.8V
> > > supplies and those supply the I/O pads of the GPIO pins (and possibly
> > > external pull-ups) that drive them. The 1.8V supply doesn't supply
> > > 1.8V to the slot, so making it a slot/connector property is wrong.
> > >
> >
> > Ok, I get your point that VIO 1.8v supply is just limited to the I/O logic and
> > not the whole card/adapter. But I don't get your multiple supplies concern. Spec
> > says, "A 1.8 V supply pin called VIO 1.8 V is used to supply the on-Adapter I/O
> > buffer circuitry operating at 1.8 V." So it implies that either the single
> > supply available to the card through VIO might be used to power the whole I/O
> > circuit logic or the card can derive its own 1.8v supply from 3.3v supply.
> >
> > So how come the card can have 2 different 1.8v supplies powering the I/O
> > circuitry?
>
> Is there a pin on the connector for 1.8V supply? I don't have the
> spec, but the pinout I found[1] didn't show one. If there's a pin,
> then I have no concern.
>
Oh yes, there is a single VIO pin defined in the spec for multiple Keys. Since
it is optional, it could've been omitted in the design you referenced.
So should I name it as vio1v8-supply or vpcie1v8-supply? I don't see any other
1.8v supplies other than the VIO supply though.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Rob Herring @ 2026-01-16 14:19 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi
In-Reply-To: <gcmm23ji4fkcqeshcyiehuyega7kdbtvmofp4usmol2icwn6gy@i46icelwwqh5>
On Thu, Jan 15, 2026 at 4:42 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Wed, Jan 14, 2026 at 11:45:42AM -0600, Rob Herring wrote:
> > On Wed, Jan 14, 2026 at 10:14 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Tue, Jan 13, 2026 at 11:14:24AM -0600, Rob Herring wrote:
> > > > On Mon, Jan 12, 2026 at 09:56:04PM +0530, Manivannan Sadhasivam wrote:
> > > > > Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
> > > > > in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
> > > > > provides interfaces like PCIe or SDIO to attach the WiFi devices to the
> > > > > host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
> > > > > devices. Spec also provides an optional interface to connect the UIM card,
> > > > > but that is not covered in this binding.
> > > > >
> > > > > The connector provides a primary power supply of 3.3v, along with an
> > > > > optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
> > > > > 1.8v sideband signaling.
> > > > >
> > > > > The connector also supplies optional signals in the form of GPIOs for fine
> > > > > grained power management.
> > > > >
> > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > ---
> > > > > .../bindings/connector/pcie-m2-e-connector.yaml | 154 +++++++++++++++++++++
> > > > > MAINTAINERS | 1 +
> > > > > 2 files changed, 155 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..b65b39ddfd19
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > > @@ -0,0 +1,154 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: PCIe M.2 Mechanical Key E Connector
> > > > > +
> > > > > +maintainers:
> > > > > + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > +
> > > > > +description:
> > > > > + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E
> > > > > + connector. Mechanical Key E connectors are used to connect Wireless
> > > > > + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host
> > > > > + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C.
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + const: pcie-m2-e-connector
> > > > > +
> > > > > + vpcie3v3-supply:
> > > > > + description: A phandle to the regulator for 3.3v supply.
> > > > > +
> > > > > + vpcie1v8-supply:
> > > > > + description: A phandle to the regulator for VIO 1.8v supply.
> > > >
> > > > I don't see any 1.8V supply on the connector. There are 1.8V IOs and you
> > > > may need something in DT to ensure those are powered. However, there's
> > > > no guarantee that it's a single supply.
> > > >
> > >
> > > 1.8v VIO supply is an optional supply and is only required if the platform
> > > supports 1.8v for sideband signals such as PERST#, WAKE#... I can include it in
> > > the example for completeness.
> >
> > My point is that PERST# and WAKE# supplies could be 2 different 1.8V
> > supplies and those supply the I/O pads of the GPIO pins (and possibly
> > external pull-ups) that drive them. The 1.8V supply doesn't supply
> > 1.8V to the slot, so making it a slot/connector property is wrong.
> >
>
> Ok, I get your point that VIO 1.8v supply is just limited to the I/O logic and
> not the whole card/adapter. But I don't get your multiple supplies concern. Spec
> says, "A 1.8 V supply pin called VIO 1.8 V is used to supply the on-Adapter I/O
> buffer circuitry operating at 1.8 V." So it implies that either the single
> supply available to the card through VIO might be used to power the whole I/O
> circuit logic or the card can derive its own 1.8v supply from 3.3v supply.
>
> So how come the card can have 2 different 1.8v supplies powering the I/O
> circuitry?
Is there a pin on the connector for 1.8V supply? I don't have the
spec, but the pinout I found[1] didn't show one. If there's a pin,
then I have no concern.
Rob
[1] https://pinoutguide.com/HD/M.2_NGFF_connector_pinout.shtml
^ permalink raw reply
* Re: [PATCH 14/19] drivers: hwtracing: stm: console.c: Migrate to register_console_force helper
From: Marcos Paulo de Souza @ 2026-01-16 13:54 UTC (permalink / raw)
To: Alexander Shishkin, Richard Weinberger, Anton Ivanov,
Johannes Berg, Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Petr Mladek, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Jiri Slaby, Breno Leitao, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Geert Uytterhoeven, Kees Cook, Tony Luck, Guilherme G. Piccoli,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Andreas Larsson, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor
Cc: linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <83zf6daetu.fsf@black.igk.intel.com>
On Fri, 2026-01-16 at 14:04 +0100, Alexander Shishkin wrote:
> Marcos Paulo de Souza <mpdesouza@suse.com> writes:
>
> > The register_console_force function was introduced to register
> > consoles
> > even on the presence of default consoles, replacing the CON_ENABLE
> > flag
> > that was forcing the same behavior.
> >
> > No functional changes.
> >
> > Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
>
> Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Thanks Alexander!
>
> Should I pick this up or will you send this with the rest of the
> series?
I'll need a v2, since some things will also change in other parts of
the patchset, so I would wait for the next version.
>
> Cheers,
> --
> Alex
^ permalink raw reply
* Re: [PATCH v8] tty: tty_port: add workqueue to flip TTY buffer
From: Greg KH @ 2026-01-16 13:24 UTC (permalink / raw)
To: Xin Zhao; +Cc: jirislaby, linux-kernel, linux-serial, tj, hch
In-Reply-To: <20251230090341.853655-1-jackzxcui1989@163.com>
On Tue, Dec 30, 2025 at 05:03:41PM +0800, Xin Zhao wrote:
> Hi all,
>
> On Tue, 23 Dec 2025 11:48:36 +0800 Xin Zhao <jackzxcui1989@163.com> wrote:
> > On the embedded platform, certain critical data, such as IMU data, is
> > transmitted through UART. The tty_flip_buffer_push() interface in the TTY
> > layer uses system_dfl_wq to handle the flipping of the TTY buffer.
> > Although the unbound workqueue can create new threads on demand and wake
> > up the kworker thread on an idle CPU, it may be preempted by real-time
> > tasks or other high-prio tasks.
> >
> > flush_to_ldisc() needs to wake up the relevant data handle thread. When
> > executing __wake_up_common_lock(), it calls spin_lock_irqsave(), which
> > does not disable preemption but disables migration in RT-Linux. This
> > prevents the kworker thread from being migrated to other cores by CPU's
> > balancing logic, resulting in long delays. The call trace is as follows:
> >
> > ...
>
>
> Are there any other changes needed before the patch is merged?
>
> Jiri has reviewed the patch, and I have made the modifications. :)
I need Jiri to ack it :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] MEDIATEK: serial: 8250_mtk: Add ACPI support
From: Greg KH @ 2026-01-16 13:20 UTC (permalink / raw)
To: Zhiyong Tao
Cc: jirislaby, matthias.bgg, angelogioacchino.delregno, fred2599,
linux-kernel, linux-serial, linux-arm-kernel, linux-mediatek,
Project_Global_Digits_Upstream_Group, liguo.zhang, Vasanth.Reddy,
Yenchia Chen
In-Reply-To: <20260105024103.2027085-2-zhiyong.tao@mediatek.com>
On Mon, Jan 05, 2026 at 10:39:55AM +0800, Zhiyong Tao wrote:
> From: "Zhiyong.Tao" <zhiyong.tao@mediatek.com>
>
> Add ACPI support to 8250_mtk driver. This makes it possible to
> use UART on ARM-based desktops with EDK2 UEFI firmware.
>
> Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com>
> Signed-off-by: Zhiyong.Tao <zhiyong.tao@mediatek.com>
Please use your name, not '.' in it, like your email has. Yenchia did
it properly here.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists
From: Greg Kroah-Hartman @ 2026-01-16 13:16 UTC (permalink / raw)
To: Kendall Willis
Cc: Jiri Slaby, d-gole, vishalm, sebin.francis, msp, khilman, a-kaur,
s-kochidanadu, linux-kernel, linux-serial
In-Reply-To: <20251230-uart-wakeup-v1-1-13f1bb905f14@ti.com>
On Tue, Dec 30, 2025 at 03:24:51PM -0600, Kendall Willis wrote:
> In TI K3 SoCs, I/O daisy chaining is used to allow wakeup from UART when
> the UART controller is off. Set UART device as wakeup capable using
> out-of-band wakeup if the 'wakeup' pinctrl state exists and the device may
> wakeup.
>
> Signed-off-by: Kendall Willis <k-willis@ti.com>
> ---
> Implementation
> --------------
> This patch is intended to be implemented along with the following
> series. This patch has no dependencies on any of the other series:
>
> 1. "pmdomain: ti_sci: handle wakeup constraint for out-of-band wakeup":
> Skips setting constraints for wakeup sources that have out-of-band
> wakeup capability.
> https://github.com/kwillis01/linux/commits/v6.19/uart-daisy-chain/pmdomain
>
> 2. "serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists"
> (this patch): Implements out-of-band wakeup from the UARTs for TI K3
> SoCs
> https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/uart-wakeup
>
> 3. "arm64: dts: ti: k3-am62: Support Main UART wakeup": Implements the
> functionality to wakeup the system from the Main UART
> https://github.com/kwillis01/linux/tree/b4/uart-daisy-chain-dts
How am I to pull any of this into the mainline kernel tree? If this is
dependant on those out-of-tree stuff, there's no need for me to take
this now, please submit this all together properly.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 14/19] drivers: hwtracing: stm: console.c: Migrate to register_console_force helper
From: Alexander Shishkin @ 2026-01-16 13:04 UTC (permalink / raw)
To: Marcos Paulo de Souza, Richard Weinberger, Anton Ivanov,
Johannes Berg, Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Petr Mladek, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Jiri Slaby, Breno Leitao, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Geert Uytterhoeven, Kees Cook, Tony Luck, Guilherme G. Piccoli,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Andreas Larsson, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor
Cc: linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel,
Marcos Paulo de Souza, Alexander Shishkin
In-Reply-To: <20251227-printk-cleanup-part3-v1-14-21a291bcf197@suse.com>
Marcos Paulo de Souza <mpdesouza@suse.com> writes:
> The register_console_force function was introduced to register consoles
> even on the presence of default consoles, replacing the CON_ENABLE flag
> that was forcing the same behavior.
>
> No functional changes.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Should I pick this up or will you send this with the rest of the series?
Cheers,
--
Alex
^ permalink raw reply
* Re: [PATCH 15/19] drivers: tty: serial: mux.c: Migrate to register_console_force helper
From: Petr Mladek @ 2026-01-16 9:59 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, Daniel Thompson,
Douglas Anderson, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Jiri Slaby, Breno Leitao, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Geert Uytterhoeven,
Kees Cook, Tony Luck, Guilherme G. Piccoli, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Andreas Larsson, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Jacky Huang, Shan-Chun Hung, Laurentiu Tudor,
linux-um, linux-kernel, kgdb-bugreport, linux-serial, netdev,
linux-m68k, linux-hardening, linuxppc-dev, sparclinux,
linux-stm32, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20251227-printk-cleanup-part3-v1-15-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:22, Marcos Paulo de Souza wrote:
> The register_console_force function was introduced to register consoles
> even on the presence of default consoles, replacing the CON_ENABLE flag
> that was forcing the same behavior.
>
> --- a/drivers/tty/serial/mux.c
> +++ b/drivers/tty/serial/mux.c
> @@ -390,7 +390,7 @@ static struct console mux_console = {
> .write = mux_console_write,
> .device = uart_console_device,
> .setup = mux_console_setup,
> - .flags = CON_ENABLED | CON_PRINTBUFFER,
> + .flags = CON_PRINTBUFFER,
> .index = 0,
> .data = &mux_driver,
> };
> @@ -547,7 +547,7 @@ static int __init mux_init(void)
> mod_timer(&mux_timer, jiffies + MUX_POLL_DELAY);
>
> #ifdef CONFIG_SERIAL_MUX_CONSOLE
> - register_console(&mux_console);
> + register_console_force(&mux_console);
The situation here is the same as in 16th patch for
ma35d1serial_console().
Also "mux_console" is assigned to
static int __init mux_probe(struct parisc_device *dev)
{
[...]
mux_driver.cons = MUX_CONSOLE;
status = uart_register_driver(&mux_driver);
[...]
status = uart_add_one_port(&mux_driver, port);
[...]
}
So, that it can get registered also by:
+ mux_probe()
+ uart_add_one_port()
+ serial_ctrl_register_port()
+ serial_core_register_port()
+ serial_core_add_one_port()
+ uart_configure_port()
+ register_console()
And we would need to pass the "force" information via CON_FORCE flag.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v5 07/11] arm64: dts: microchip: add LAN969x clock header file
From: claudiu beznea @ 2026-01-16 7:22 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
linusw, olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial
Cc: luka.perkov
In-Reply-To: <20260115114021.111324-8-robert.marko@sartura.hr>
On 1/15/26 13:37, Robert Marko wrote:
> LAN969x uses hardware clock indexes, so document theses in a header to make
> them humanly readable.
>
> Signed-off-by: Robert Marko<robert.marko@sartura.hr>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
^ permalink raw reply
* Re: [PATCH] serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists
From: Dhruva Gole @ 2026-01-16 5:40 UTC (permalink / raw)
To: Kendall Willis
Cc: Greg Kroah-Hartman, Jiri Slaby, vishalm, sebin.francis, msp,
khilman, a-kaur, s-kochidanadu, linux-kernel, linux-serial
In-Reply-To: <20251230-uart-wakeup-v1-1-13f1bb905f14@ti.com>
On Dec 30, 2025 at 15:24:51 -0600, Kendall Willis wrote:
> In TI K3 SoCs, I/O daisy chaining is used to allow wakeup from UART when
> the UART controller is off. Set UART device as wakeup capable using
> out-of-band wakeup if the 'wakeup' pinctrl state exists and the device may
> wakeup.
>
> Signed-off-by: Kendall Willis <k-willis@ti.com>
> ---
> Implementation
> --------------
> This patch is intended to be implemented along with the following
> series. This patch has no dependencies on any of the other series:
>
> 1. "pmdomain: ti_sci: handle wakeup constraint for out-of-band wakeup":
> Skips setting constraints for wakeup sources that have out-of-band
> wakeup capability.
> https://github.com/kwillis01/linux/commits/v6.19/uart-daisy-chain/pmdomain
>
> 2. "serial: 8250: omap: set out-of-band wakeup if wakeup pinctrl exists"
> (this patch): Implements out-of-band wakeup from the UARTs for TI K3
> SoCs
> https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/uart-wakeup
>
> 3. "arm64: dts: ti: k3-am62: Support Main UART wakeup": Implements the
> functionality to wakeup the system from the Main UART
> https://github.com/kwillis01/linux/tree/b4/uart-daisy-chain-dts
>
> Testing
> -------
> Tested on a AM62P SK EVM board with all series and dependencies
> implemented. Suspend/resume verified with the Main UART wakeup source
> by entering a keypress on the console.
>
> This github branch has all the necessary patches to test the series
> using v6.19-rc1:
> https://github.com/kwillis01/linux/tree/v6.19/uart-daisy-chain/all
> ---
> drivers/tty/serial/8250/8250_omap.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 9e49ef48b851bf6cd3b04a77a4d0d7b4e064dc5f..6a5722b722650c1710e79fb76fc1a01cdeccc68f 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -1363,6 +1363,8 @@ static int omap8250_select_wakeup_pinctrl(struct device *dev,
> if (!device_may_wakeup(dev))
> return 0;
>
> + device_set_out_band_wakeup(dev);
> +
Reviewed-by: Dhruva Gole <d-gole@ti.com>
--
Best regards,
Dhruva Gole
Texas Instruments Incorporated
^ 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