* Re: [PATCH v4 0/9] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Hans de Goede @ 2026-01-15 10:30 UTC (permalink / raw)
To: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Ilpo Järvinen,
Mark Pearson, Derek J. Clark, Manivannan Sadhasivam,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski
Cc: 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,
Bartosz Golaszewski
In-Reply-To: <20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com>
Hi Mani,
On 12-Jan-26 17:25, Manivannan Sadhasivam via B4 Relay wrote:
> Hi,
>
> This series is the continuation of the series [1] that added the initial support
> for the PCIe M.2 connectors. This series extends it by adding support for Key E
> connectors. These connectors are used to connect the Wireless Connectivity
> devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> interfaces are left for future improvements.
Thank you for your work on this.
I've tested this on a ThinkPad T14s gen 6 together with your DTS changes
for the T14s.
I started out with CONFIG_POWER_SEQUENCING_PCIE_M2=m and that does not work.
I think it might be easiest to just change that option to a boolean option.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Regards,
Hans
> Serdev device support for BT
> ============================
>
> Adding support for the PCIe interface was mostly straightforward and a lot
> similar to the previous Key M connector. But adding UART interface has proved to
> be tricky. This is mostly because of the fact UART is a non-discoverable bus,
> unlike PCIe which is discoverable. So this series relied on the PCI notifier to
> create the serdev device for UART/BT. This means the PCIe interface will be
> brought up first and after the PCIe device enumeration, the serdev device will
> be created by the pwrseq driver. This logic is necessary since the connector
> driver and DT node don't describe the device, but just the connector. So to make
> the connector interface Plug and Play, the connector driver uses the PCIe device
> ID to identify the card and creates the serdev device. This logic could be
> extended in the future to support more M.2 cards. Even if the M.2 card uses SDIO
> interface for connecting WLAN, a SDIO notifier could be added to create the
> serdev device.
>
> Open questions
> ==============
>
> Though this series adds the relevant functionality for handling the M.2 Key M
> connectors, there are still a few open questions exists on the design.
>
> 1. Created a dynamic 'bluetooth' node with the compatible property matching the
> WCN7850 device and attached it to the serdev device. This allowed reusing the
> existing OF based BT driver without much modifications.
>
> 2. PCIe client drivers of some M.2 WLAN cards like the Qcom QCA6390, rely on
> the PCIe device DT node to extract properties such as
> 'qcom,calibration-variant', 'firmware-name', etc... For those drivers, should we
> add the PCIe DT node in the Root Port in conjunction with the Port node as
> below?
>
> pcie@0 {
> wifi@0 {
> compatible = "pci17cb,1103";
> ...
> qcom,calibration-variant = "LE_X13S";
> };
>
> port {
> pcie4_port0_ep: endpoint {
> remote-endpoint = <&m2_e_pcie_ep>;
> };
> };
> };
>
> This will also require marking the PMU supplies optional in the relevant ath
> bindings for M.2 cards.
>
> 3. Some M.2 cards require specific power up sequence like delays between
> regulator/GPIO and such. For instance, the WCN7850 card supported in this series
> requires 50ms delay between powering up an interface and driving it. I've just
> hardcoded the delay in the driver, but it is a pure hack. Since the pwrseq
> driver doesn't know anything about the device it is dealing with before powering
> it ON, how should it handle the device specific power requirements? Should we
> hardcode the device specific property in the connector node? But then, it will
> no longer become a generic M.2 connector and sort of defeats the purpose of the
> connector binding.
>
> I hope to address these questions with the help of the relevant subsystem
> maintainers and the community.
>
> Testing
> =======
>
> This series, together with the devicetree changes [2] was tested on the
> Qualcomm X1e based Lenovo Thinkpad T14s Laptop which has the WCN7850 WLAN/BT
> 1620 LGA card connected over PCIe and UART.
>
> Dependency
> ==========
>
> This series is dependent on the M.2 Key M series [1] on top of v6.19-rc1.
>
> [1] https://lore.kernel.org/linux-pci/20260107-pci-m2-v5-0-8173d8a72641@oss.qualcomm.com
> [2] https://github.com/Mani-Sadhasivam/linux/commit/753033861360171f2af1fdd56e8985ff916e1ac2
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> Changes in v4:
> - Switched to dynamic OF node for serdev instead of swnode and dropped all
> swnode related patches
> - Link to v3: https://lore.kernel.org/r/20260110-pci-m2-e-v3-0-4faee7d0d5ae@oss.qualcomm.com
>
> Changes in v3:
> - Switched to swnode for the serdev device and dropped the custom
> serdev_device_id related patches
> - Added new swnode APIs to match the swnode with existing of_device_id
> - Incorporated comments in the bindings patch
> - Dropped the UIM interface from binding since it is not clear how it should get
> wired
> - Incorporated comments in the pwrseq driver patch
> - Splitted the pwrseq patch into two
> - Added the 1620 LGA compatible with Key E fallback based on Stephan's finding
> - Link to v2: https://lore.kernel.org/r/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com
>
> Changes in v2:
> - Used '-' for GPIO names in the binding and removed led*-gpios properties
> - Described the endpoint nodes for port@0 and port@1 nodes
> - Added the OF graph port to the serial binding
> - Fixed the hci_qca driver to return err if devm_pwrseq_get() fails
> - Incorporated various review comments in pwrseq driver
> - Collected Ack
> - Link to v1: https://lore.kernel.org/r/20251112-pci-m2-e-v1-0-97413d6bf824@oss.qualcomm.com
>
> ---
> Manivannan Sadhasivam (9):
> serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
> serdev: Add an API to find the serdev controller associated with the devicetree node
> serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
> dt-bindings: serial: Document the graph port
> dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
> dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
> Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq
> power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
> power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth
>
> .../bindings/connector/pcie-m2-e-connector.yaml | 161 ++++++++++++
> .../devicetree/bindings/serial/serial.yaml | 3 +
> MAINTAINERS | 1 +
> drivers/bluetooth/hci_qca.c | 9 +
> drivers/power/sequencing/Kconfig | 1 +
> drivers/power/sequencing/pwrseq-pcie-m2.c | 278 ++++++++++++++++++++-
> drivers/tty/serdev/core.c | 25 +-
> include/linux/serdev.h | 24 +-
> 8 files changed, 482 insertions(+), 20 deletions(-)
> ---
> base-commit: cb6649f6217c0331b885cf787f1d175963e2a1d2
> change-id: 20251112-pci-m2-e-94695ac9d657
> prerequisite-message-id: 20251125-pci-m2-v3-0-c528042aea47@oss.qualcomm.com
> prerequisite-patch-id: 58778d8eb97ab86008cd48fb5d28ed6cc0bbbc1b
> prerequisite-patch-id: 2dd7d793a67f59ef6e6b5137e69436896198b965
> prerequisite-patch-id: 8ccaa5fdd95e64e69cd942f93c26e89b827d0453
> prerequisite-patch-id: 3d3e1bb7959ab1e140c5024acdd8655e7a7e99ef
>
> Best regards,
^ permalink raw reply
* Re: [PATCH 09/19] m68k: emu: nfcon.c: Migrate to register_console_force helper
From: Petr Mladek @ 2026-01-15 10:26 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, 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-9-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:16, 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.
>
> No functional changes.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
LGTM, nice cleanup!
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 08/19] debug: debug_core: Migrate to register_console_force helper
From: Petr Mladek @ 2026-01-15 10:20 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-8-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:15, 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.
>
> No functional changes.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
LGTM, nice cleanup!
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 07/19] drivers: netconsole: Migrate to register_console_force helper
From: Petr Mladek @ 2026-01-15 10:16 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, 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-7-21a291bcf197@suse.com>
On Sat 2025-12-27 09:16:14, 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.
I would add "No functional changes." like you did in the other
similar patches ;-)
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Nice clean up!
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* [PATCH v5 7/7] riscv: dts: spacemit: add K3 Pico-ITX board support
From: Guodong Xu @ 2026-01-15 6:51 UTC (permalink / raw)
To: 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,
Thomas Gleixner
Cc: Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Anup Patel, Andrew Jones, devicetree,
linux-riscv, linux-kernel, spacemit, linux-serial, Guodong Xu
In-Reply-To: <20260115-k3-basic-dt-v5-0-6990ac9f4308@riscstar.com>
K3 Pico-ITX is a 2.5-inch single-board computer equipted with a SpacemiT
K3 SoC.
This minimal device tree enables booting into a serial console with UART
output.
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v5: Update the commit message subject per Yixun's suggestion.
Remove the unused aliases.
Update the copyright year to 2026.
v4: No change.
v3: No change.
v2: Add aliases node in this board DT.
Update the memory node to reflect the hardware truth. Address
starts at 0x100000000 (4G) boundary.
---
arch/riscv/boot/dts/spacemit/Makefile | 1 +
arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 29 ++++++++++++++++++++++++++++
2 files changed, 30 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
index 95889e7269d1..7e2b87702571 100644
--- a/arch/riscv/boot/dts/spacemit/Makefile
+++ b/arch/riscv/boot/dts/spacemit/Makefile
@@ -4,3 +4,4 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
+dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
diff --git a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
new file mode 100644
index 000000000000..b691304d4b74
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
@@ -0,0 +1,29 @@
+// 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 "k3.dtsi"
+
+/ {
+ model = "SpacemiT K3 Pico-ITX";
+ compatible = "spacemit,k3-pico-itx", "spacemit,k3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0";
+ };
+
+ memory@100000000 {
+ device_type = "memory";
+ reg = <0x1 0x00000000 0x4 0x00000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v5 6/7] riscv: dts: spacemit: add initial support for K3 SoC
From: Guodong Xu @ 2026-01-15 6:51 UTC (permalink / raw)
To: 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,
Thomas Gleixner
Cc: Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Anup Patel, Andrew Jones, devicetree,
linux-riscv, linux-kernel, spacemit, linux-serial, Guodong Xu
In-Reply-To: <20260115-k3-basic-dt-v5-0-6990ac9f4308@riscstar.com>
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";
+ 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";
+ };
+ };
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v5 5/7] dt-bindings: riscv: spacemit: add K3 and Pico-ITX board bindings
From: Guodong Xu @ 2026-01-15 6:51 UTC (permalink / raw)
To: 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,
Thomas Gleixner
Cc: Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Anup Patel, Andrew Jones, devicetree,
linux-riscv, linux-kernel, spacemit, linux-serial, Guodong Xu,
Conor Dooley
In-Reply-To: <20260115-k3-basic-dt-v5-0-6990ac9f4308@riscstar.com>
Add DT binding documentation for the SpacemiT K3 SoC and the board Pico-ITX
which is a 2.5-inch single-board computer.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Yixun Lan <dlan@gentoo.org>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v5: Add Reviewed-by from Yixun.
Add Acked-by from Conor.
v4: Adjust maintainers list in alphabetic order.
Declare spacemit,k3-pico-itx as an enum, which can save future
code change when adding new boards.
v3: No change.
v2: Use one-blank-space between name and email address.
---
Documentation/devicetree/bindings/riscv/spacemit.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml
index 9c49482002f7..b958b94a924d 100644
--- a/Documentation/devicetree/bindings/riscv/spacemit.yaml
+++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml
@@ -7,6 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: SpacemiT SoC-based boards
maintainers:
+ - Guodong Xu <guodong@riscstar.com>
- Yangyu Chen <cyy@cyyself.name>
- Yixun Lan <dlan@gentoo.org>
@@ -26,6 +27,10 @@ properties:
- xunlong,orangepi-r2s
- xunlong,orangepi-rv2
- const: spacemit,k1
+ - items:
+ - enum:
+ - spacemit,k3-pico-itx
+ - const: spacemit,k3
additionalProperties: true
--
2.43.0
^ permalink raw reply related
* [PATCH v5 4/7] dt-bindings: interrupt-controller: add SpacemiT K3 IMSIC
From: Guodong Xu @ 2026-01-15 6:51 UTC (permalink / raw)
To: 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,
Thomas Gleixner
Cc: Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Anup Patel, Andrew Jones, devicetree,
linux-riscv, linux-kernel, spacemit, linux-serial, Guodong Xu,
Krzysztof Kozlowski
In-Reply-To: <20260115-k3-basic-dt-v5-0-6990ac9f4308@riscstar.com>
Add compatible string for SpacemiT K3 IMSIC.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v5: No change.
v4: No change.
v3: Add Acked-by from Krzysztof.
v2: Fix the order to keep things alphabetically.
---
Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
index c23b5c09fdb9..feec122bddde 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
@@ -48,6 +48,7 @@ properties:
items:
- enum:
- qemu,imsics
+ - spacemit,k3-imsics
- const: riscv,imsics
reg:
--
2.43.0
^ permalink raw reply related
* [PATCH v5 3/7] dt-bindings: interrupt-controller: add SpacemiT K3 APLIC
From: Guodong Xu @ 2026-01-15 6:51 UTC (permalink / raw)
To: 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,
Thomas Gleixner
Cc: Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Anup Patel, Andrew Jones, devicetree,
linux-riscv, linux-kernel, spacemit, linux-serial, Guodong Xu,
Conor Dooley
In-Reply-To: <20260115-k3-basic-dt-v5-0-6990ac9f4308@riscstar.com>
Add compatible string for SpacemiT K3 APLIC.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v5: No change.
v4: No change.
v3: No change.
v2: Add Conor's Acked-by.
---
Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
index bef00521d5da..0718071444d2 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
@@ -28,6 +28,7 @@ properties:
items:
- enum:
- qemu,aplic
+ - spacemit,k3-aplic
- const: riscv,aplic
reg:
--
2.43.0
^ permalink raw reply related
* [PATCH v5 2/7] dt-bindings: timer: add SpacemiT K3 CLINT
From: Guodong Xu @ 2026-01-15 6:51 UTC (permalink / raw)
To: 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,
Thomas Gleixner
Cc: Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Anup Patel, Andrew Jones, devicetree,
linux-riscv, linux-kernel, spacemit, linux-serial, Guodong Xu,
Conor Dooley
In-Reply-To: <20260115-k3-basic-dt-v5-0-6990ac9f4308@riscstar.com>
Add compatible string for SpacemiT K3 CLINT.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v5: No change.
v4: No change.
v3: No change.
v2: Add Conor's Acked-by.
---
Documentation/devicetree/bindings/timer/sifive,clint.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index 0d3b8dc362ba..3bab40500df9 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -33,6 +33,7 @@ properties:
- eswin,eic7700-clint # ESWIN EIC7700
- sifive,fu540-c000-clint # SiFive FU540
- spacemit,k1-clint # SpacemiT K1
+ - spacemit,k3-clint # SpacemiT K3
- starfive,jh7100-clint # StarFive JH7100
- starfive,jh7110-clint # StarFive JH7110
- starfive,jh8100-clint # StarFive JH8100
--
2.43.0
^ permalink raw reply related
* [PATCH v5 1/7] dt-bindings: riscv: add SpacemiT X100 CPU compatible
From: Guodong Xu @ 2026-01-15 6:51 UTC (permalink / raw)
To: 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,
Thomas Gleixner
Cc: Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Anup Patel, Andrew Jones, devicetree,
linux-riscv, linux-kernel, spacemit, linux-serial, Guodong Xu,
Krzysztof Kozlowski, Heinrich Schuchardt
In-Reply-To: <20260115-k3-basic-dt-v5-0-6990ac9f4308@riscstar.com>
Add compatible string for the SpacemiT X100 core. [1]
The X100 is a 64-bit RVA23-compliant RISC-V core from SpacemiT. X100
supports the RISC-V vector and hypervisor extensions and all mandatory
extersions as required by the RVA23U64 and RVA23S64 profiles, per the
definition in 'RVA23 Profile, Version 1.0'. [2]
From a microarchieture viewpoint, the X100 features a 4-issue
out-of-order pipeline.
X100 is used in SpacemiT K3 SoC.
Acked-by: Paul Walmsley <pjw@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://www.spacemit.com/en/spacemit-x100-core/ [1]
Link: https://docs.riscv.org/reference/profiles/rva23/_attachments/rva23-profile.pdf [2]
Reviewed-by: Yixun Lan <dlan@gentoo.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v5: Added Acked-by from Paul.
v4: No change.
v3: Added Acked-by from Krzysztof.
v2: Fixed alphanumeric sorting of compatible strings, put x100 before x60,
as per Krzysztof's feedback.
Added reviewed-by from Yixun and Heinrich.
Updated the commit message to provide more information about X100.
---
Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index d733c0bd534f..5feeb2203050 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -61,6 +61,7 @@ properties:
- sifive,u7
- sifive,u74
- sifive,u74-mc
+ - spacemit,x100
- spacemit,x60
- thead,c906
- thead,c908
--
2.43.0
^ permalink raw reply related
* [PATCH v5 0/7] riscv: spacemit: Add SpacemiT K3 SoC and K3 Pico-ITX board
From: Guodong Xu @ 2026-01-15 6:51 UTC (permalink / raw)
To: 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,
Thomas Gleixner
Cc: Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Anup Patel, Andrew Jones, devicetree,
linux-riscv, linux-kernel, spacemit, linux-serial, Guodong Xu,
Krzysztof Kozlowski, Heinrich Schuchardt, Conor Dooley
This series introduces basic support for the SpacemiT K3 SoC and the
K3 Pico-ITX evaluation board.
In v5, patches 6-9 (dt-bindings) have been dropped as they were accepted
by Conor and applied to riscv-dt-for-next.
The series has been rebased on linux-next tag: next-20260114.
The SpacemiT K3 is an SoC featuring 8 SpacemiT X100 RISC-V cores.
The X100 is a 4-issue, out-of-order core compliant with the RVA23
profile, targeting high-performance scenarios. [1]
The K3 Pico-ITX is an evaluation board built around the K3 SoC.
From an RVA23 profile compliance perspective, the X100 supports all
mandatory extensions required by RVA23U64 and RVA23S64.
Link: https://www.spacemit.com/en/spacemit-x100-core/ [1]
Changes in v5:
- Patch 1:
Add Acked-by from Paul.
- Patch 5:
Add Reviewed-by from Yixun, add Acked-by from Conor.
- Patch 6 (Patch 10 in v4):
Update the copyright year to 2026.
Update the commit message.
Set M-mode maplic and mimsic status to "reserved".
In maplic node, use riscv,delegation to match kernel binding. OpenSBI
accepts both delegate and delgation, but the binding documents only
riscv,delegation.
- Patch 7 (Patch 11 in v4):
Update the commit message subject line.
Remove the unused aliases.
Update the copyright year to 2026.
- Link to v4: https://lore.kernel.org/r/20260110-k3-basic-dt-v4-0-d492f3a30ffa@riscstar.com
Changes in v4:
- Patch 5:
Adjust maintainers list in alphabetic order.
Declare spacemit,k3-pico-itx as an enum, which could save future
code change when adding new boards.
- Patch 10:
Fix missing blank space after comma in simsic compatible.
Add m-mode imsic and aplic nodes, per suggestion received from Samuel
Holland.
Adjust node properties order in nodes simsic, saplic, mimsic, maplic to
follow the DTS coding style.
- Link to v3: https://lore.kernel.org/r/20260108-k3-basic-dt-v3-0-ed99eb4c3ad3@riscstar.com
Other Changes in v3 include:
- Patch 1:
Acked-by: Krzysztof Kozlowski
- Patch 4:
Acked-by: Krzysztof Kozlowski
- Dropped Patch 5 "dt-bindings: serial: 8250: add SpacemiT K3 UART compatible"
as it has been applied to tty-next.
- Link to v2: https://lore.kernel.org/r/20251222-k3-basic-dt-v2-0-3af3f3cd0f8a@riscstar.com
Changes in v2:
- Patch 1:
Fixed alphanumeric sorting order of compatible strings (swapped x100 and
x60) as per Krzysztof's feedback.
Update commit message with more information about X100 featurs per
Yixun's feedback.
- Patch 4:
Fixed the order to keep things alphabetically.
- Patch 6:
Use "one blank space" between name and email address.
- Patch 7 ~ 11:
New patches. Add description of RVA23 mandatory extensions into riscv
binding YAML file.
- Patch 12 (Patch 7 in v1):
Removed aliases node.
Updated 'riscv,isa-extensions' with new extension strings available
- Patch 13 (Patch 8 in v1):
Updated the memory address to the hardware truth.
Added aliases node in board dts.
- Patch 1,2,3,5: Add Reviewed-by and Acked-by collected.
Link to v1: https://lore.kernel.org/r/20251216-k3-basic-dt-v1-0-a0d256c9dc92@riscstar.com
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
Guodong Xu (7):
dt-bindings: riscv: add SpacemiT X100 CPU compatible
dt-bindings: timer: add SpacemiT K3 CLINT
dt-bindings: interrupt-controller: add SpacemiT K3 APLIC
dt-bindings: interrupt-controller: add SpacemiT K3 IMSIC
dt-bindings: riscv: spacemit: add K3 and Pico-ITX board bindings
riscv: dts: spacemit: add initial support for K3 SoC
riscv: dts: spacemit: add K3 Pico-ITX board support
.../bindings/interrupt-controller/riscv,aplic.yaml | 1 +
.../interrupt-controller/riscv,imsics.yaml | 1 +
Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
.../devicetree/bindings/riscv/spacemit.yaml | 5 +
.../devicetree/bindings/timer/sifive,clint.yaml | 1 +
arch/riscv/boot/dts/spacemit/Makefile | 1 +
arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 29 +
arch/riscv/boot/dts/spacemit/k3.dtsi | 590 +++++++++++++++++++++
8 files changed, 629 insertions(+)
---
base-commit: 78ffa9bb137071c00eec2d4afc247ef92d5c0b90
change-id: 20251216-k3-basic-dt-cd9540061989
Best regards,
--
Guodong Xu <guodong@riscstar.com>
^ permalink raw reply
* Re: [PATCH v3 10/11] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC
From: Heinrich Schuchardt @ 2026-01-15 6:19 UTC (permalink / raw)
To: Samuel Holland, 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, Thomas Gleixner, Anup Patel, Greg Kroah-Hartman,
Jiri Slaby, Lubomir Rintel, Yangyu Chen
In-Reply-To: <fd95c2f2-9292-483c-9613-4adf3c65c500@sifive.com>
Am 15. Januar 2026 00:57:04 MEZ schrieb Samuel Holland <samuel.holland@sifive.com>:
>Hi Guodong,
>
>On 2026-01-09 3:58 AM, Guodong Xu wrote:
>> Hi, Samuel
>>
>> On Fri, Jan 9, 2026 at 2:19 AM Samuel Holland <samuel.holland@sifive.com> wrote:
>>>
>>> On 2026-01-08 6:26 AM, Guodong Xu wrote:
>>>> SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
>>>> Add nodes of uarts, timer and interrupt-controllers.
>>>>
>>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>>> ---
>>>> 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 | 548 +++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 548 insertions(+)
>>>>
>>>> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>>> new file mode 100644
>>>> index 0000000000000000000000000000000000000000..be9335fba32cb9e81915b2b91cf08c55a5e96809
>>>> --- /dev/null
>>>> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>>> [...]
>>>> + reg = <0x0 0xe0400000 0x0 0x00200000>;
>>>> + interrupt-controller;
>>>> + #interrupt-cells = <0>;
>>>> + msi-controller;
>>>> + #msi-cells = <0>;
>>>> + 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>;
>>>> + riscv,num-ids = <511>;
>>>> + riscv,num-guest-ids = <511>;
>>>> + riscv,hart-index-bits = <4>;
>>>> + riscv,guest-index-bits = <6>;
>>>> + };
>>>> +
>>>> + saplic: interrupt-controller@e0804000 {
>>>> + compatible = "spacemit,k3-aplic", "riscv,aplic";
>>>> + reg = <0x0 0xe0804000 0x0 0x4000>;
>>>> + msi-parent = <&simsic>;
>>>> + #interrupt-cells = <2>;
>>>> + interrupt-controller;
>>>> + riscv,num-sources = <512>;
>>>> + };
>>>
>>> Does the chip also have M-mode IMSIC and APLIC instances? Those need to be
>>> represented in the devicetree as well, for M-mode firmware to access them, just
>>> like the CLINT below.
>>
>> Yes, the K3 chip does have M-mode IMSIC and APLIC instances. Currently, the
>> boot firmware (U-Boot) transfers information about these nodes to OpenSBI.
>> However, you are correct that they should be properly described in the DT.
>>
>> In the next version, I will add the M-mode APLIC (maplic) and IMSIC (mimsic)
>> nodes to k3.dtsi, for topology representation and potential firmware usage.
>> I will set their status to "disabled" because exposing them as "okay" to Linux
>> causes access faults during driver probing.
>>
>> Please let me know if this approach (adding them but keeping them disabled)
>> looks okay to you.
>
>I think this is a reasonable compromise.
>
>Personally, I think of the DTS files in the Linux repository as the "static"
>devicetree, which should describe a "complete" view of the hardware--that is, as
>seen from the highest privilege level. Then it is the responsibility of that
>highly-privileged software to modify the FDT as needed to provide a limited view
>of the hardware to lower-privileged software. And this modification is exactly
>what OpenSBI does before it passes the FDT to U-Boot. So the "static" devicetree
>would not disable these M-mode-only devices.
>
>However, I recognize that people want to use the DTB files generated by the
>Linux build process with Linux directly, ignoring the firmware-provided FDT. In
>that cases the M-mode-only devices need to be disabled. And then you need a
>-u-boot.dtsi file to set `status = "okay"` for the firmware build. I think
U-Boot offers the EFI_DT_FIXUP_PROTOCOL (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) to adjust device-trees loaded by systemd-boot or GRUB.
The disabling should be done there to avoid having different device-trees in firmware and Linux code.
A pull request for providing the protocol in EDK II is pending.
Best regards
Heinrich
>that's a reasonable compromise to make the "static" devicetree as complete as
>possible while still being usable directly in S-mode in some cases. (It still
>breaks if some peripheral is assigned to a different supervisor domain, or some
>DRAM is reserved by M-mode, etc., which is why I really recommend using the
>firmware FDT and not a file.)
>
>Regards,
>Samuel
>
^ permalink raw reply
* Re: [PATCH v3 10/11] riscv: dts: spacemit: add initial device tree of SpacemiT K3 SoC
From: Samuel Holland @ 2026-01-14 23:57 UTC (permalink / raw)
To: Guodong Xu
Cc: Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
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,
Thomas Gleixner, Anup Patel, Greg Kroah-Hartman, Jiri Slaby,
Lubomir Rintel, Yangyu Chen
In-Reply-To: <CAH1PCMZ5rKbG8xEbB9jt6TqyB28T5aLgRtf3iJ8Gt6Fk+3XFhQ@mail.gmail.com>
Hi Guodong,
On 2026-01-09 3:58 AM, Guodong Xu wrote:
> Hi, Samuel
>
> On Fri, Jan 9, 2026 at 2:19 AM Samuel Holland <samuel.holland@sifive.com> wrote:
>>
>> On 2026-01-08 6:26 AM, Guodong Xu wrote:
>>> SpacemiT K3 is equipped with 8 X100 cores, which are RVA23 compliant.
>>> Add nodes of uarts, timer and interrupt-controllers.
>>>
>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>> ---
>>> 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 | 548 +++++++++++++++++++++++++++++++++++
>>> 1 file changed, 548 insertions(+)
>>>
>>> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..be9335fba32cb9e81915b2b91cf08c55a5e96809
>>> --- /dev/null
>>> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
>>> [...]
>>> + reg = <0x0 0xe0400000 0x0 0x00200000>;
>>> + interrupt-controller;
>>> + #interrupt-cells = <0>;
>>> + msi-controller;
>>> + #msi-cells = <0>;
>>> + 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>;
>>> + riscv,num-ids = <511>;
>>> + riscv,num-guest-ids = <511>;
>>> + riscv,hart-index-bits = <4>;
>>> + riscv,guest-index-bits = <6>;
>>> + };
>>> +
>>> + saplic: interrupt-controller@e0804000 {
>>> + compatible = "spacemit,k3-aplic", "riscv,aplic";
>>> + reg = <0x0 0xe0804000 0x0 0x4000>;
>>> + msi-parent = <&simsic>;
>>> + #interrupt-cells = <2>;
>>> + interrupt-controller;
>>> + riscv,num-sources = <512>;
>>> + };
>>
>> Does the chip also have M-mode IMSIC and APLIC instances? Those need to be
>> represented in the devicetree as well, for M-mode firmware to access them, just
>> like the CLINT below.
>
> Yes, the K3 chip does have M-mode IMSIC and APLIC instances. Currently, the
> boot firmware (U-Boot) transfers information about these nodes to OpenSBI.
> However, you are correct that they should be properly described in the DT.
>
> In the next version, I will add the M-mode APLIC (maplic) and IMSIC (mimsic)
> nodes to k3.dtsi, for topology representation and potential firmware usage.
> I will set their status to "disabled" because exposing them as "okay" to Linux
> causes access faults during driver probing.
>
> Please let me know if this approach (adding them but keeping them disabled)
> looks okay to you.
I think this is a reasonable compromise.
Personally, I think of the DTS files in the Linux repository as the "static"
devicetree, which should describe a "complete" view of the hardware--that is, as
seen from the highest privilege level. Then it is the responsibility of that
highly-privileged software to modify the FDT as needed to provide a limited view
of the hardware to lower-privileged software. And this modification is exactly
what OpenSBI does before it passes the FDT to U-Boot. So the "static" devicetree
would not disable these M-mode-only devices.
However, I recognize that people want to use the DTB files generated by the
Linux build process with Linux directly, ignoring the firmware-provided FDT. In
that cases the M-mode-only devices need to be disabled. And then you need a
-u-boot.dtsi file to set `status = "okay"` for the firmware build. I think
that's a reasonable compromise to make the "static" devicetree as complete as
possible while still being usable directly in S-mode in some cases. (It still
breaks if some peripheral is assigned to a different supervisor domain, or some
DRAM is reserved by M-mode, etc., which is why I really recommend using the
firmware FDT and not a file.)
Regards,
Samuel
^ permalink raw reply
* Re: [PATCH v4 01/11] dt-bindings: riscv: add SpacemiT X100 CPU compatible
From: Paul Walmsley @ 2026-01-14 23:27 UTC (permalink / raw)
To: Guodong Xu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan,
Daniel Lezcano, Thomas Gleixner, Samuel Holland, Anup Patel,
Greg Kroah-Hartman, Jiri Slaby, Lubomir Rintel, Yangyu Chen,
Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Andrew Jones, devicetree, linux-riscv,
linux-kernel, spacemit, linux-serial, Krzysztof Kozlowski,
Heinrich Schuchardt
In-Reply-To: <20260110-k3-basic-dt-v4-1-d492f3a30ffa@riscstar.com>
On Sat, 10 Jan 2026, Guodong Xu wrote:
> Add compatible string for the SpacemiT X100 core. [1]
>
> The X100 is a 64-bit RVA23-compliant RISC-V core from SpacemiT. X100
> supports the RISC-V vector and hypervisor extensions and all mandatory
> extersions as required by the RVA23U64 and RVA23S64 profiles, per the
> definition in 'RVA23 Profile, Version 1.0'. [2]
>
> >From a microarchieture viewpoint, the X100 features a 4-issue
> out-of-order pipeline.
>
> X100 is used in SpacemiT K3 SoC.
>
> Link: https://www.spacemit.com/en/spacemit-x100-core/ [1]
> Link: https://docs.riscv.org/reference/profiles/rva23/_attachments/rva23-profile.pdf [2]
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Reviewed-by: Yixun Lan <dlan@gentoo.org>
> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
(just for completeness, since I acked the older version)
Acked-by: Paul Walmsley <pjw@kernel.org>
- Paul
^ permalink raw reply
* Re: [PATCH v3 01/11] dt-bindings: riscv: add SpacemiT X100 CPU compatible
From: Paul Walmsley @ 2026-01-14 23:17 UTC (permalink / raw)
To: Guodong Xu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan,
Daniel Lezcano, Thomas Gleixner, Samuel Holland, Anup Patel,
Greg Kroah-Hartman, Jiri Slaby, Lubomir Rintel, Yangyu Chen,
Paul Walmsley, Conor Dooley, Heinrich Schuchardt,
Kevin Meng Zhang, Andrew Jones, devicetree, linux-riscv,
linux-kernel, spacemit, linux-serial, Krzysztof Kozlowski,
Heinrich Schuchardt
In-Reply-To: <20260108-k3-basic-dt-v3-1-ed99eb4c3ad3@riscstar.com>
On Thu, 8 Jan 2026, Guodong Xu wrote:
> Add compatible string for the SpacemiT X100 core. [1]
>
> The X100 is a 64-bit RVA23-compliant RISC-V core from SpacemiT. X100
> supports the RISC-V vector and hypervisor extensions and all mandatory
> extersions as required by the RVA23U64 and RVA23S64 profiles, per the
> definition in 'RVA23 Profile, Version 1.0'. [2]
>
> >From a microarchieture viewpoint, the X100 features a 4-issue
> out-of-order pipeline.
>
> X100 is used in SpacemiT K3 SoC.
>
> Link: https://www.spacemit.com/en/spacemit-x100-core/ [1]
> Link: https://docs.riscv.org/reference/profiles/rva23/_attachments/rva23-profile.pdf [2]
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Reviewed-by: Yixun Lan <dlan@gentoo.org>
> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
I think Yixun Lan is going to pick this up, so
Acked-by: Paul Walmsley <pjw@kernel.org>
- Paul
^ permalink raw reply
* Re: (subset) [PATCH v4 0/6] dt-bindings: goldfish: Convert to DT schema
From: Mark Brown @ 2026-01-14 21:36 UTC (permalink / raw)
To: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
lgirdwood, Kuan-Wei Chiu
Cc: jserv, dri-devel, devicetree, linux-kernel, linux-input, linux-pm,
linux-serial, linux-sound, Yu-Chun Lin
In-Reply-To: <20260113092602.3197681-1-visitorckw@gmail.com>
On Tue, 13 Jan 2026 09:25:56 +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish emulator platform bindings from text
> format to DT schema.
>
> Most of these bindings are currently located in
> Documentation/devicetree/bindings/goldfish/. Move them to the
> appropriate subsystem directories (serial, input, power, sound, misc)
> to align with the kernel directory structure.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[5/6] dt-bindings: sound: google,goldfish-audio: Convert to DT schema
commit: 10303b32519f52a5afd40593a507543143c8ec6a
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v4 2/6] dt-bindings: misc: google,android-pipe: Convert to DT schema
From: Rob Herring (Arm) @ 2026-01-14 20:27 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: broonie, lgirdwood, conor+dt, linux-serial, simona,
maarten.lankhorst, eleanor15x, airlied, linux-pm, tzimmermann,
dri-devel, mripard, Krzysztof Kozlowski, linux-sound, gregkh,
jserv, krzk+dt, dmitry.torokhov, devicetree, jirislaby,
linux-input, linux-kernel, sre
In-Reply-To: <20260113092602.3197681-3-visitorckw@gmail.com>
On Tue, 13 Jan 2026 09:25:58 +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish QEMU Pipe binding to DT schema format.
> Move the file to the misc directory as it represents a miscellaneous
> communication device.
> Update the example node name to 'pipe' to comply with generic node
> naming standards and fix the mismatch between unit address and reg
> property in the original example.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> Changes in v4:
> - Use decimal format for interrupts in the example.
>
> .../devicetree/bindings/goldfish/pipe.txt | 17 ---------
> .../bindings/misc/google,android-pipe.yaml | 38 +++++++++++++++++++
> 2 files changed, 38 insertions(+), 17 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/goldfish/pipe.txt
> create mode 100644 Documentation/devicetree/bindings/misc/google,android-pipe.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 00/11] riscv: spacemit: Add SpacemiT K3 SoC and K3 Pico-ITX board
From: Rob Herring @ 2026-01-14 20:26 UTC (permalink / raw)
To: Yixun Lan
Cc: Conor Dooley, Paul Walmsley, Guodong Xu, Krzysztof Kozlowski,
Conor Dooley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Daniel Lezcano, Thomas Gleixner, Samuel Holland, Anup Patel,
Greg Kroah-Hartman, Jiri Slaby, Lubomir Rintel, Yangyu Chen,
Paul Walmsley, Heinrich Schuchardt, Kevin Meng Zhang,
Andrew Jones, devicetree, linux-riscv, linux-kernel, spacemit,
linux-serial, Krzysztof Kozlowski, Heinrich Schuchardt,
Conor Dooley
In-Reply-To: <20260114021405-GYB25466@gentoo.org>
On Wed, Jan 14, 2026 at 10:14:05AM +0800, Yixun Lan wrote:
>
> On 22:17 Tue 13 Jan , Conor Dooley wrote:
> > On Tue, Jan 13, 2026 at 08:21:23AM +0800, Yixun Lan wrote:
> > > Hi Conor,
> > >
> > > On 21:45 Mon 12 Jan , Conor Dooley wrote:
> > > > On Sat, Jan 10, 2026 at 01:18:12PM +0800, Guodong Xu wrote:
> > > >
> > > > > Hi, Conor
> > > > >
> > > > > For the binding riscv/extensions.ymal, here's what changed in v3 (no
> > > > > change in v4):
> > > > >
> > > > > 1. Dropped the patch of adding "supm" into extensions.yaml. At the same
> > > > > time, I will start another patchset which implements the strategy
> > > > > outlined by Conor in Link [2] and by Samuel in Link [3].
> > > >
> > > > Okay, that seems reasonable to separate out.
> > > >
> > > > >
> > > > > 2. Dropped the dependency checks for "sha" on "h", "shcounterenw", and
> > > > > 6 others. "sha" implies these extensions, and it should be allowed
> > > > > to be declared independently. Like "a" implies "zaamo" and "zalrsc".
> > > > >
> > > > > 3. Enchanced the dependency check of "ziccamoa" on "a". Specifically,
> > > > > - added the dependency check of "ziccamoa" on "zaamo" or on "a".
> > > > > - added the dependency check of "za64rs" on "zalrsc" or on "a".
> > > > > - added the dependency check of "ziccrse" on "zalrsc" or "a".
> > > > > The commit message of this patch is updated too, to better explain the
> > > > > relationship between "ziccamoa", "za64rs", "ziccrse" and "a".
> > > > >
> > > > > 4. Enhanced checking dependency of "b" and "zba", "zbb", "zbs", making the
> > > > > dependency check in both directions, as discussed in [4]. Since "b"
> > > > > was ratified much later than its component extensions (zba/zbb/zbs),
> > > > > existing software and kernels expect these explicit strings. This
> > > > > bidirectional check ensures cores declaring "b" remain compatible
> > > > > with older software that only recognizes zba/zbb/zbs.
> > > >
> > > > This I asked about in the relevant patch, I would like to know what your
> > > > plan for adding the "b"s is.
> > > >
> > > ..
> > > > Spacemit folks, I assume you weren't planning on taking the
> > > > extensions.yaml stuff via your tree? If you weren't, I'll grab it once
> > > > the question about b is answered.
> > >
> > > sure, please take extension stuff which are patches 6-9, for 1-5, it's
> > > all about adding support for SpacemiT K3 SoC, to avoid petential conflicts,
> > > I wouldn't mind if you also taking them? then I can handle the rest 10,11 for DT
> >
> > Stuff for spacemit is either for you or for the relevant subsystem
> > maintainers. You're probably safe enough taking the
> > timer/interrupt-controller stuff if the maintainers don't apply it in a
> > reasonable period, it's not abnormal for those in particular to go via
> > the platform maintainer in my experience. Just be clear that you have
> > done so. I'm only interested in taking 6-9.
> Hi Conor,
> Ok, I got, thank you!
>
> Hi Paul Walmsley,
> I assume you're responsible for more general riscv stuff with your
> effective maintainer hat, so do you mind if I take patches 1-5 via SpacemiT
> SoC tree? I think the potential conflicts should be low and easy to fix.
> Or, in the other hand, just let me know which patches you would like
> to take, then I will handle the rest. Thanks
Paul would generally only ever take patch 1. You can take 1-5. The timer
and interrupt-controller bindings tend to not get picked up by the
subsystem unless there are driver changes too.
Rob
^ permalink raw reply
* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Rob Herring @ 2026-01-14 17:45 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: <xyttom64ht5hrrp5hecjqehnyfgsv4mfl2t36e2sveu44ccpjl@lkzquse2kqsx>
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.
This isn't exactly a new issue. It could be an issue on any binding
with GPIOs. Perhaps this needs to be handled within GPIO or pinctrl.
> > > +
> > > + oneOf:
> > > + - required:
> > > + - port@0
> > > +
> > > + clocks:
> > > + description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to
> > > + the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for
> > > + more details.
> > > + maxItems: 1
> > > +
> > > + w-disable1-gpios:
> > > + description: GPIO input to W_DISABLE1# signal. This signal is used by the
> > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> > > + Specification r4.0, sec 3.1.12.3 for more details.
> > > + maxItems: 1
> > > +
> > > + w-disable2-gpios:
> > > + description: GPIO input to W_DISABLE2# signal. This signal is used by the
> > > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> > > + Specification r4.0, sec 3.1.12.3 for more details.
> > > + maxItems: 1
> > > +
> > > + viocfg-gpios:
> > > + description: GPIO output to IO voltage configuration (VIO_CFG) signal. This
> > > + signal is used by the M.2 card to indicate to the host system that the
> > > + card supports an independent IO voltage domain for the sideband signals.
> > > + Refer, PCI Express M.2 Specification r4.0, sec 3.1.15.1 for more details.
> > > + maxItems: 1
> >
> > What about SDIO and UART WAKE, SDIO RESET, and vendor defined signals?
> >
>
> Not sure about vendor defined signals as they can be either GPIO or interface
> signals. How should them be defined?
That kind of breaks any notion of this being a generic slot/connector.
How's the host supposed to know how to connect them? What if a card
required them to be driven a certain way before you can discover the
card? If they can be GPIOs and can be hooked up to the host system
GPIOs, then you should define GPIOs for them. If they aren't GPIOs on
a host, then you omit them.
Rob
^ permalink raw reply
* Re: [PATCH 00/19] printk cleanup - part 3
From: Daniel Thompson @ 2026-01-14 16:38 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Daniel Thompson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Greg Kroah-Hartman, Jason Wessel, 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, 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: <89409a0f48e6998ff6dd2245691b9954f0e1e435.camel@suse.com>
On Tue, Jan 13, 2026 at 09:32:33PM -0300, Marcos Paulo de Souza wrote:
> I talked with Petr Mladek and it would need to rework the way that we
> register a console, and he's already working on it. For now I believe
> that we could take a look in all the patches besides the last one that
> currently breaks the earlycon with kgdb and maybe other usecases.
>
> Sorry for not catching this issue before. I'll use kgdb next time to
> make sure that it keeps working :)
As I understood things the bug was in earlycon rather then kgdb.
It was picked up by the kgdbtest suite since kgdb does some cool things
with earlycon (thanks to Doug Anderson) so I added a few earlycon tests
to the kgdbtest suite. However it wasn't kgdb itself that failed here.
So... if you want to run https://gitlab.com/daniel-thompson/kgdbtest
then certainly feel free but its probably less effort just to include
a couple of earlycon checks in your testing.
Daniel.
^ permalink raw reply
* Re: [PATCH v4 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Manivannan Sadhasivam @ 2026-01-14 16:14 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: <20260113171424.GA3925312-robh@kernel.org>
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.
> > +
> > + ports:
> > + $ref: /schemas/graph.yaml#/properties/ports
> > + description: OF graph bindings modeling the interfaces exposed on the
> > + connector. Since a single connector can have multiple interfaces, every
> > + interface has an assigned OF graph port number as described below.
> > +
> > + properties:
> > + port@0:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: Connector interfaces for Wi-Fi
> > +
> > + properties:
> > + endpoint@0:
> > + $ref: /schemas/graph.yaml#/properties/endpoint
> > + description: PCIe interface
> > +
> > + endpoint@1:
> > + $ref: /schemas/graph.yaml#/properties/endpoint
> > + description: SDIO interface
>
> I think I already said this, but multiple endpoints are generally for
> something that's muxed. Looking at the connector pinout, PCIe and SDIO
> are not muxed. So these 2 should be 2 port nodes.
>
Sorry, I didn't know that you were asking for 2 port nodes. Will switch to it.
> > +
> > + anyOf:
> > + - required:
> > + - endpoint@0
> > + - required:
> > + - endpoint@1
> > +
> > + port@1:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: Connector interfaces for BT
> > +
> > + properties:
> > + endpoint@0:
> > + $ref: /schemas/graph.yaml#/properties/endpoint
> > + description: USB 2.0 interface
> > +
> > + endpoint@1:
> > + $ref: /schemas/graph.yaml#/properties/endpoint
> > + description: UART interface
>
> And UART and USB are not muxed either.
>
Ack.
>
> > +
> > + anyOf:
> > + - required:
> > + - endpoint@0
> > + - required:
> > + - endpoint@1
> > +
> > + port@2:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: PCM/I2S interface
> > +
> > + i2c-parent:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description: I2C interface
>
> Move out of 'ports'.
>
Ack.
> > +
> > + oneOf:
> > + - required:
> > + - port@0
> > +
> > + clocks:
> > + description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to
> > + the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for
> > + more details.
> > + maxItems: 1
> > +
> > + w-disable1-gpios:
> > + description: GPIO input to W_DISABLE1# signal. This signal is used by the
> > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> > + Specification r4.0, sec 3.1.12.3 for more details.
> > + maxItems: 1
> > +
> > + w-disable2-gpios:
> > + description: GPIO input to W_DISABLE2# signal. This signal is used by the
> > + system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
> > + Specification r4.0, sec 3.1.12.3 for more details.
> > + maxItems: 1
> > +
> > + viocfg-gpios:
> > + description: GPIO output to IO voltage configuration (VIO_CFG) signal. This
> > + signal is used by the M.2 card to indicate to the host system that the
> > + card supports an independent IO voltage domain for the sideband signals.
> > + Refer, PCI Express M.2 Specification r4.0, sec 3.1.15.1 for more details.
> > + maxItems: 1
>
> What about SDIO and UART WAKE, SDIO RESET, and vendor defined signals?
>
Not sure about vendor defined signals as they can be either GPIO or interface
signals. How should them be defined?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 3/9] serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
From: Manivannan Sadhasivam @ 2026-01-14 16:02 UTC (permalink / raw)
To: Andy Shevchenko
Cc: manivannan.sadhasivam, Rob Herring, 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, 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,
Bartosz Golaszewski
In-Reply-To: <aWVKTnatLTGwmNVh@smile.fi.intel.com>
On Mon, Jan 12, 2026 at 09:23:58PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 12, 2026 at 09:56:02PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>
> > If an external connector like M.2 is connected to the serdev controller
> > in DT, then the serdev devices may be created dynamically by the connector
> > driver. So do not return -ENODEV from of_serdev_register_devices() if the
> > static nodes are not found and the graph node is used.
>
> ...
>
> > + if (!found && !of_graph_is_present(ctrl->dev.of_node))
>
> dev_of_node()
>
Ack.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Manivannan Sadhasivam @ 2026-01-14 16:00 UTC (permalink / raw)
To: Hans de Goede
Cc: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, 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: <2a44e967-ebae-4641-88d7-ccb4536ee3b7@kernel.org>
On Wed, Jan 14, 2026 at 03:01:51PM +0100, Hans de Goede wrote:
> Hi Mani,
>
> Thank you for your work in this.
>
> On 12-Jan-26 17:26, Manivannan Sadhasivam via B4 Relay wrote:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> >
> > Add of_find_serdev_controller_by_node() API to find the serdev controller
> > device associated with the devicetree node.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> > drivers/tty/serdev/core.c | 16 ++++++++++++++++
> > include/linux/serdev.h | 9 +++++++++
> > 2 files changed, 25 insertions(+)
> >
> > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> > index b33e708cb245..25382c2d63e6 100644
> > --- a/drivers/tty/serdev/core.c
> > +++ b/drivers/tty/serdev/core.c
> > @@ -504,6 +504,22 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
> > }
> > EXPORT_SYMBOL_GPL(serdev_controller_alloc);
> >
> > +/**
> > + * of_find_serdev_controller_by_node() - Find the serdev controller associated
> > + * with the devicetree node
> > + * @node: Devicetree node
> > + *
> > + * Return: Pointer to the serdev controller associated with the node. NULL if
> > + * the controller is not found.
> > + */
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> > +{
> > + struct device *dev = bus_find_device_by_of_node(&serdev_bus_type, node);
> > +
> > + return (dev && dev->type == &serdev_ctrl_type) ? to_serdev_controller(dev) : NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(of_find_serdev_controller_by_node);
> > +
>
> This new of_find_serdev_controller_by_node() function needs:
>
> #ifdef CONFIG_OF ... #endif
>
> around it, to match the stubbing you are doing in serdev.h
>
Ack.
> > static int of_serdev_register_devices(struct serdev_controller *ctrl)
> > {
> > struct device_node *node;
> > diff --git a/include/linux/serdev.h b/include/linux/serdev.h
> > index ecde0ad3e248..db9bfaba0662 100644
> > --- a/include/linux/serdev.h
> > +++ b/include/linux/serdev.h
> > @@ -333,4 +333,13 @@ static inline bool serdev_acpi_get_uart_resource(struct acpi_resource *ares,
> > }
> > #endif /* CONFIG_ACPI */
> >
> > +#ifdef CONFIG_OF
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node);
> > +#else
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> > +{
> > + return NULL;
> > +}
>
> stubs like this one should be static inline to avoid warnings like this one:
>
> In file included from drivers/tty/serdev/core.c:21:
> ./include/linux/serdev.h:339:27: warning: no previous prototype for ‘of_find_serdev_controller_by_node’ [-Wmissing-prototypes]
> 339 | struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
Darn... Will fix it. Thanks for spotting!
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Manivannan Sadhasivam @ 2026-01-14 15:57 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: manivannan.sadhasivam, Rob Herring, 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,
Manivannan Sadhasivam via B4 Relay, 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: <CAMRc=McDvQoqfH0Gy-wzbcEGvNCZACSACCcviwpCc4YNSpKYrw@mail.gmail.com>
On Tue, Jan 13, 2026 at 08:54:55AM -0500, Bartosz Golaszewski wrote:
> On Mon, 12 Jan 2026 17:26:01 +0100, Manivannan Sadhasivam via B4 Relay
> <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> said:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> >
> > Add of_find_serdev_controller_by_node() API to find the serdev controller
> > device associated with the devicetree node.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> > drivers/tty/serdev/core.c | 16 ++++++++++++++++
> > include/linux/serdev.h | 9 +++++++++
> > 2 files changed, 25 insertions(+)
> >
> > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> > index b33e708cb245..25382c2d63e6 100644
> > --- a/drivers/tty/serdev/core.c
> > +++ b/drivers/tty/serdev/core.c
> > @@ -504,6 +504,22 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
> > }
> > EXPORT_SYMBOL_GPL(serdev_controller_alloc);
> >
> > +/**
> > + * of_find_serdev_controller_by_node() - Find the serdev controller associated
> > + * with the devicetree node
> > + * @node: Devicetree node
> > + *
> > + * Return: Pointer to the serdev controller associated with the node. NULL if
> > + * the controller is not found.
> > + */
>
> Please also say that the caller is responsible for calling
> serdev_controller_put() on the returned object.
>
Ack.
- Mani
> Bart
>
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> > +{
> > + struct device *dev = bus_find_device_by_of_node(&serdev_bus_type, node);
> > +
> > + return (dev && dev->type == &serdev_ctrl_type) ? to_serdev_controller(dev) : NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(of_find_serdev_controller_by_node);
> > +
> > static int of_serdev_register_devices(struct serdev_controller *ctrl)
> > {
> > struct device_node *node;
> > diff --git a/include/linux/serdev.h b/include/linux/serdev.h
> > index ecde0ad3e248..db9bfaba0662 100644
> > --- a/include/linux/serdev.h
> > +++ b/include/linux/serdev.h
> > @@ -333,4 +333,13 @@ static inline bool serdev_acpi_get_uart_resource(struct acpi_resource *ares,
> > }
> > #endif /* CONFIG_ACPI */
> >
> > +#ifdef CONFIG_OF
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node);
> > +#else
> > +struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
> > +{
> > + return NULL;
> > +}
> > +#endif /* CONFIG_OF */
> > +
> > #endif /*_LINUX_SERDEV_H */
> >
> > --
> > 2.48.1
> >
> >
> >
--
மணிவண்ணன் சதாசிவம்
^ 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