[PATCH v1 0/2] Add support for StarFive JHB100 UART Routing

[PATCH v1 0/2] Add support for StarFive JHB100 UART Routing

[Changhuang Liang]

StarFive JHB100 UART Routing allows dynamic routing of inputs between
built-in UARTs and physical serial I/O ports, enabling use cases such
as Host <-> BMC communication via UARTs.

This series has been tested on the EVB1 board.

This series depends on the series:
https://lore.kernel.org/all/20260828095608.19955-1-changhuang.liang@starfivetech.com/

Changhuang Liang (2):
  dt-bindings: soc: starfive: Add JHB100 UART routing controller
  soc: starfive: Add JHB100 UART Routing driver

 .../sysfs-driver-starfive-jhb100-uart-routing |  45 +++
 .../starfive,jhb100-uart-routing.yaml         |  46 +++
 MAINTAINERS                                   |   7 +
 drivers/soc/starfive/Kconfig                  |   1 +
 drivers/soc/starfive/Makefile                 |   1 +
 drivers/soc/starfive/uart-routing/Kconfig     |  14 +
 drivers/soc/starfive/uart-routing/Makefile    |   2 +
 .../uart-routing/jhb100-uart-routing.c        | 262 ++++++++++++++++++
 8 files changed, 378 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
 create mode 100644 Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-uart-routing.yaml
 create mode 100644 drivers/soc/starfive/uart-routing/Kconfig
 create mode 100644 drivers/soc/starfive/uart-routing/Makefile
 create mode 100644 drivers/soc/starfive/uart-routing/jhb100-uart-routing.c

--
2.25.1

[PATCH v1 1/2] dt-bindings: soc: starfive: Add JHB100 UART routing controller

[Changhuang Liang]

Add device tree bindings for the StarFive JHB100 UART routing controller.
This controller allows dynamic routing of inputs between built-in UARTs
and physical serial I/O ports, enabling use cases such as Host <-> BMC
communication via UARTs.

The clocks property exists in the hardware, but the driver does not use
it.

Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
---
 .../starfive,jhb100-uart-routing.yaml         | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-uart-routing.yaml

diff --git a/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-uart-routing.yaml b/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-uart-routing.yaml
new file mode 100644
index 000000000000..6719ae59b9dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-uart-routing.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/starfive/starfive,jhb100-uart-routing.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JHB100 UART Routing Controller
+
+maintainers:
+  - Changhuang Liang <changhuang.liang@starfivetech.com>
+
+description: >
+  The StarFive JHB100 UART routing controller allows dynamic routing of the
+  inputs for the built-in UARTs and the physical serial I/O ports.
+
+  This allows, for example, connecting the output of one UART to another
+  UART, which can be used to enable Host <-> BMC communication over UARTs,
+  e.g. to give the BMC access to the Host's serial console.
+
+properties:
+  compatible:
+    const: starfive,jhb100-uart-routing
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+    uart-routing@11a42a00 {
+        compatible = "starfive,jhb100-uart-routing";
+        reg = <0x11a42a00 0x100>;
+        resets = <&per0crg 74>;
+    };
-- 
2.25.1

[PATCH v1 2/2] soc: starfive: Add JHB100 UART Routing driver

[Changhuang Liang]

Add driver support for JHB100 UART Routing control, allowing runtime
configuration of RX muxes between UART controllers and I/O pins.

A sysfs interface is provided for easy checking and updating of routing
paths.

Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
---
 .../sysfs-driver-starfive-jhb100-uart-routing |  45 +++
 MAINTAINERS                                   |   7 +
 drivers/soc/starfive/Kconfig                  |   1 +
 drivers/soc/starfive/Makefile                 |   1 +
 drivers/soc/starfive/uart-routing/Kconfig     |  14 +
 drivers/soc/starfive/uart-routing/Makefile    |   2 +
 .../uart-routing/jhb100-uart-routing.c        | 262 ++++++++++++++++++
 7 files changed, 332 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
 create mode 100644 drivers/soc/starfive/uart-routing/Kconfig
 create mode 100644 drivers/soc/starfive/uart-routing/Makefile
 create mode 100644 drivers/soc/starfive/uart-routing/jhb100-uart-routing.c

diff --git a/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
new file mode 100644
index 000000000000..2844133bea1b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
@@ -0,0 +1,45 @@
+What:		/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/uart\*
+Date:		August 2026
+Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
+Description:	Selects the RX source of the UARTx device.
+
+		When read, each file shows the list of available options with currently
+		selected option marked by brackets "[]". The list of available options
+		depends on the selected file.
+
+		e.g.
+		cat /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routing/uart1
+		io0 [io1] io2 io3 io4 io5 io6 io7 io8 io9 io10 io11 io12 io13 io14 uart0 uart1
+		uart2 uart3 uart4 uart5 uart6 uart7 uart8 uart9 uart10 uart11 uart12 uart13 uart14
+
+		In this case, UART1 gets its input from IO1 (physical serial port 1).
+
+		To switch the RX source of UART1 to UART2, write the desired source to the file:
+		echo uart2 > /sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routing/uart1
+
+		This indicates that UART1 now receives its input from UART2.
+
+Users:		OpenBMC.  Proposed changes should be mailed to
+		openbmc@lists.ozlabs.org
+
+What:		/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/io\*
+Date:		August 2026
+Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
+Description:	Selects the RX source of IOx serial port. The current selection
+		will be marked by brackets "[]". The list of available options
+		depends on the selected file.
+
+		e.g.
+		cat /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routing/io9
+		uart0 uart1 uart2 uart3 uart4 uart5 uart6 uart7 uart8 [uart9] uart10 uart11 uart12
+		uart13 uart14 io0 io1 io2 io3 io4 io5 io6 io7 io8 io9 io10 io11 io12 io13 io14
+
+		In this case, IO9 (physical serial port 9) gets its input from UART9.
+
+		To switch the RX source of IO9 to UART10, write the desired source to the file:
+		echo uart10 > /sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routing/io9
+
+		This indicates that IO9 now receives its input from UART10.
+
+Users:		OpenBMC.  Proposed changes should be mailed to
+		openbmc@lists.ozlabs.org
diff --git a/MAINTAINERS b/MAINTAINERS
index 90919c672d4d..1583e988d8b0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26105,6 +26105,13 @@ M:	Changhuang Liang <changhuang.liang@starfivetech.com>
 S:	Maintained
 F:	Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-syscon.yaml
 
+STARFIVE JHB100 UART ROUTING DRIVER
+M:	Changhuang Liang <changhuang.liang@starfivetech.com>
+S:	Maintained
+F:	Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
+F:	Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-uart-routing.yaml
+F:	drivers/soc/starfive/uart-routing/
+
 STATIC BRANCH/CALL
 M:	Peter Zijlstra <peterz@infradead.org>
 M:	Josh Poimboeuf <jpoimboe@kernel.org>
diff --git a/drivers/soc/starfive/Kconfig b/drivers/soc/starfive/Kconfig
index 04b020083d3e..f45e6ddc49df 100644
--- a/drivers/soc/starfive/Kconfig
+++ b/drivers/soc/starfive/Kconfig
@@ -2,5 +2,6 @@
 menu "StarFive SoC (System On Chip) specific Drivers"
 
 source "drivers/soc/starfive/socinfo/Kconfig"
+source "drivers/soc/starfive/uart-routing/Kconfig"
 
 endmenu
diff --git a/drivers/soc/starfive/Makefile b/drivers/soc/starfive/Makefile
index ca1e609b8104..ead286caecfa 100644
--- a/drivers/soc/starfive/Makefile
+++ b/drivers/soc/starfive/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-y += socinfo/
+obj-y += uart-routing/
diff --git a/drivers/soc/starfive/uart-routing/Kconfig b/drivers/soc/starfive/uart-routing/Kconfig
new file mode 100644
index 000000000000..6a8fb28fbc23
--- /dev/null
+++ b/drivers/soc/starfive/uart-routing/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+config STARFIVE_JHB100_UART_ROUTING
+	tristate "StarFive JHB100 uart routing control"
+	depends on ARCH_STARFIVE || COMPILE_TEST
+	depends on HAS_IOMEM
+	select REGMAP_MMIO
+	help
+	  Provides a driver to control the UART routing paths, allowing
+	  users to perform runtime configuration of the RX muxes among
+	  the UART controllers and I/O pins.
+
+	  If M is selected, the module will be called
+	  jhb100-uart-routing.
diff --git a/drivers/soc/starfive/uart-routing/Makefile b/drivers/soc/starfive/uart-routing/Makefile
new file mode 100644
index 000000000000..b0df03c8501b
--- /dev/null
+++ b/drivers/soc/starfive/uart-routing/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_STARFIVE_JHB100_UART_ROUTING)	+= jhb100-uart-routing.o
diff --git a/drivers/soc/starfive/uart-routing/jhb100-uart-routing.c b/drivers/soc/starfive/uart-routing/jhb100-uart-routing.c
new file mode 100644
index 000000000000..7cf29741593a
--- /dev/null
+++ b/drivers/soc/starfive/uart-routing/jhb100-uart-routing.c
@@ -0,0 +1,262 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * StarFive JHB100 UART Routing driver
+ *
+ * Derived from drivers/soc/aspeed/aspeed-uart-routing.c
+ *
+ * Copyright (c) 2018 Google LLC
+ * Copyright (c) 2021 Aspeed Technology Inc.
+ * Copyright (C) 2026 StarFive Technology Co., Ltd
+ */
+
+#include <linux/bits.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <linux/sysfs.h>
+
+#define STARFIVE_ROUTING_SEL(uart_sel)	((uart_sel) * 0x04)
+#define ROUTING_TX_SHIFT		0
+#define ROUTING_TX_MASK			GENMASK(4, ROUTING_TX_SHIFT)
+#define ROUTING_RX_SHIFT		8
+#define ROUTING_RX_MASK			GENMASK(12, ROUTING_RX_SHIFT)
+
+#define MAX_UART_PORTS			15	/* UART0-UART14 */
+#define MAX_IO_PINS			15	/* IO0-IO14 */
+#define TOTAL_TARGETS			(MAX_UART_PORTS + MAX_IO_PINS)
+
+struct starfive_uart_routing {
+	struct regmap *regmap;
+};
+
+struct starfive_routing_attr {
+	struct device_attribute dev_attr;
+	u8 ch;
+	u8 shift;
+	u32 mask;
+	bool io_order;		/* options table orientation */
+};
+
+#define to_routing_attr(_dev_attr) \
+	container_of(_dev_attr, struct starfive_routing_attr, dev_attr)
+
+static const char * const routing_targets[TOTAL_TARGETS] = {
+	"io0",  "io1",  "io2",  "io3",  "io4",
+	"io5",  "io6",  "io7",  "io8",  "io9",
+	"io10", "io11", "io12", "io13", "io14",
+	"uart0", "uart1", "uart2", "uart3", "uart4",
+	"uart5", "uart6", "uart7", "uart8", "uart9",
+	"uart10", "uart11", "uart12", "uart13", "uart14",
+};
+
+static ssize_t starfive_uart_routing_show(struct device *dev,
+					  struct device_attribute *attr,
+					  char *buf)
+{
+	struct starfive_uart_routing *priv = dev_get_drvdata(dev);
+	struct starfive_routing_attr *rattr = to_routing_attr(attr);
+	u32 val;
+	unsigned int pos;
+	int len = 0;
+	int ret;
+
+	ret = regmap_read(priv->regmap, STARFIVE_ROUTING_SEL(rattr->ch), &val);
+	if (ret)
+		return ret;
+
+	val = (val >> rattr->shift) & (rattr->mask >> rattr->shift);
+
+	/* Show all available options with current one highlighted */
+	if (rattr->io_order) {
+		/* For io* files: 0-14 -> uart0-uart14, 15-29 -> io0-io14 */
+		for (pos = 0; pos < TOTAL_TARGETS; pos++) {
+			const char *target;
+
+			target = routing_targets[(pos + MAX_UART_PORTS) % TOTAL_TARGETS];
+
+			if (pos == val)
+				len += sysfs_emit_at(buf, len, "[%s] ", target);
+			else
+				len += sysfs_emit_at(buf, len, "%s ", target);
+		}
+	} else {
+		/* For uart* files: 0-14 -> io0-io14, 15-29 -> uart0-uart14 */
+		for (pos = 0; pos < TOTAL_TARGETS; pos++) {
+			if (pos == val)
+				len += sysfs_emit_at(buf, len, "[%s] ", routing_targets[pos]);
+			else
+				len += sysfs_emit_at(buf, len, "%s ", routing_targets[pos]);
+		}
+	}
+
+	if (val >= TOTAL_TARGETS)
+		len += sysfs_emit_at(buf, len, "[unknown(%u)]", val);
+
+	len += sysfs_emit_at(buf, len, "\n");
+
+	return len;
+}
+
+static ssize_t starfive_uart_routing_store(struct device *dev,
+					   struct device_attribute *attr,
+					   const char *buf, size_t count)
+{
+	struct starfive_uart_routing *priv = dev_get_drvdata(dev);
+	struct starfive_routing_attr *rattr = to_routing_attr(attr);
+	int val;
+	int ret;
+
+	val = sysfs_match_string(routing_targets, buf);
+	if (val < 0)
+		return val;
+
+	/* For io* files, reverse the mapping */
+	if (rattr->io_order)
+		val = (val + MAX_IO_PINS) % TOTAL_TARGETS;
+
+	ret = regmap_update_bits(priv->regmap, STARFIVE_ROUTING_SEL(rattr->ch),
+				 rattr->mask, val << rattr->shift);
+
+	return ret ? : count;
+}
+
+/* Static attribute definitions using macros */
+#define ROUTING_ATTR(_name, _ch, _shift, _mask, _io)			\
+	static struct starfive_routing_attr routing_attr_##_name = {	\
+		.dev_attr = __ATTR(_name, 0644,				\
+				   starfive_uart_routing_show,		\
+				   starfive_uart_routing_store),	\
+		.ch = (_ch), .shift = (_shift),				\
+		.mask = (_mask), .io_order = (_io),			\
+	}
+
+/* UART selectors (uart0-uart14) - each UART routes to a target */
+ROUTING_ATTR(uart0, 0, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart1, 1, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart2, 2, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart3, 3, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart4, 4, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart5, 5, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart6, 6, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart7, 7, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart8, 8, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart9, 9, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart10, 10, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart11, 11, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart12, 12, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart13, 13, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+ROUTING_ATTR(uart14, 14, ROUTING_RX_SHIFT, ROUTING_RX_MASK, false);
+
+/* IO selectors (io0-io14) - each IO routes to a target */
+ROUTING_ATTR(io0, 0, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io1, 1, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io2, 2, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io3, 3, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io4, 4, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io5, 5, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io6, 6, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io7, 7, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io8, 8, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io9, 9, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io10, 10, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io11, 11, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io12, 12, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io13, 13, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+ROUTING_ATTR(io14, 14, ROUTING_TX_SHIFT, ROUTING_TX_MASK, true);
+
+static struct attribute *starfive_routing_attrs[] = {
+	&routing_attr_uart0.dev_attr.attr,
+	&routing_attr_uart1.dev_attr.attr,
+	&routing_attr_uart2.dev_attr.attr,
+	&routing_attr_uart3.dev_attr.attr,
+	&routing_attr_uart4.dev_attr.attr,
+	&routing_attr_uart5.dev_attr.attr,
+	&routing_attr_uart6.dev_attr.attr,
+	&routing_attr_uart7.dev_attr.attr,
+	&routing_attr_uart8.dev_attr.attr,
+	&routing_attr_uart9.dev_attr.attr,
+	&routing_attr_uart10.dev_attr.attr,
+	&routing_attr_uart11.dev_attr.attr,
+	&routing_attr_uart12.dev_attr.attr,
+	&routing_attr_uart13.dev_attr.attr,
+	&routing_attr_uart14.dev_attr.attr,
+	&routing_attr_io0.dev_attr.attr,
+	&routing_attr_io1.dev_attr.attr,
+	&routing_attr_io2.dev_attr.attr,
+	&routing_attr_io3.dev_attr.attr,
+	&routing_attr_io4.dev_attr.attr,
+	&routing_attr_io5.dev_attr.attr,
+	&routing_attr_io6.dev_attr.attr,
+	&routing_attr_io7.dev_attr.attr,
+	&routing_attr_io8.dev_attr.attr,
+	&routing_attr_io9.dev_attr.attr,
+	&routing_attr_io10.dev_attr.attr,
+	&routing_attr_io11.dev_attr.attr,
+	&routing_attr_io12.dev_attr.attr,
+	&routing_attr_io13.dev_attr.attr,
+	&routing_attr_io14.dev_attr.attr,
+	NULL,
+};
+
+ATTRIBUTE_GROUPS(starfive_routing);
+
+static const struct regmap_config starfive_routing_regmap_cfg = {
+	.reg_bits	= 32,
+	.reg_stride	= 4,
+	.val_bits	= 32,
+	.max_register	= STARFIVE_ROUTING_SEL(MAX_UART_PORTS - 1),
+};
+
+static int starfive_uart_routing_probe(struct platform_device *pdev)
+{
+	struct starfive_uart_routing *priv;
+	struct device *dev = &pdev->dev;
+	struct reset_control *rst;
+	void __iomem *reg_base;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	reg_base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(reg_base))
+		return dev_err_probe(dev, PTR_ERR(reg_base),
+				     "Unable to map IO resources\n");
+
+	rst = devm_reset_control_get_exclusive_deasserted(dev, NULL);
+	if (IS_ERR(rst))
+		return dev_err_probe(dev, PTR_ERR(rst),
+				     "Unable to get and deassert reset control\n");
+
+	priv->regmap = devm_regmap_init_mmio(dev, reg_base,
+					     &starfive_routing_regmap_cfg);
+	if (IS_ERR(priv->regmap))
+		return PTR_ERR(priv->regmap);
+
+	dev_set_drvdata(dev, priv);
+
+	return 0;
+}
+
+static const struct of_device_id starfive_uart_routing_match[] = {
+	{ .compatible = "starfive,jhb100-uart-routing" },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, starfive_uart_routing_match);
+
+static struct platform_driver starfive_uart_routing_driver = {
+	.probe = starfive_uart_routing_probe,
+	.driver	= {
+		.name = "starfive-jhb100-uart-routing",
+		.of_match_table = starfive_uart_routing_match,
+		.dev_groups = starfive_routing_groups,
+	},
+};
+
+module_platform_driver(starfive_uart_routing_driver);
+
+MODULE_AUTHOR("Changhuang Liang <changhuang.liang@starfivetech.com>");
+MODULE_DESCRIPTION("StarFive JHB100 UART Routing driver");
+MODULE_LICENSE("GPL");
-- 
2.25.1

Re: [PATCH v1 2/2] soc: starfive: Add JHB100 UART Routing driver

[Krzysztof Kozlowski]

On 30/08/2026 08:51, Changhuang Liang wrote:
> Add driver support for JHB100 UART Routing control, allowing runtime
> configuration of RX muxes between UART controllers and I/O pins.
> 
> A sysfs interface is provided for easy checking and updating of routing
> paths.
> 
> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> ---
>  .../sysfs-driver-starfive-jhb100-uart-routing |  45 +++
>  MAINTAINERS                                   |   7 +
>  drivers/soc/starfive/Kconfig                  |   1 +
>  drivers/soc/starfive/Makefile                 |   1 +
>  drivers/soc/starfive/uart-routing/Kconfig     |  14 +
>  drivers/soc/starfive/uart-routing/Makefile    |   2 +
>  .../uart-routing/jhb100-uart-routing.c        | 262 ++++++++++++++++++
>  7 files changed, 332 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
>  create mode 100644 drivers/soc/starfive/uart-routing/Kconfig
>  create mode 100644 drivers/soc/starfive/uart-routing/Makefile
>  create mode 100644 drivers/soc/starfive/uart-routing/jhb100-uart-routing.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
> new file mode 100644
> index 000000000000..2844133bea1b
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
> @@ -0,0 +1,45 @@
> +What:		/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/uart\*
> +Date:		August 2026
> +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
> +Description:	Selects the RX source of the UARTx device.
> +
> +		When read, each file shows the list of available options with currently
> +		selected option marked by brackets "[]". The list of available options
> +		depends on the selected file.
> +
> +		e.g.
> +		cat /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routing/uart1
> +		io0 [io1] io2 io3 io4 io5 io6 io7 io8 io9 io10 io11 io12 io13 io14 uart0 uart1
> +		uart2 uart3 uart4 uart5 uart6 uart7 uart8 uart9 uart10 uart11 uart12 uart13 uart14
> +
> +		In this case, UART1 gets its input from IO1 (physical serial port 1).
> +
> +		To switch the RX source of UART1 to UART2, write the desired source to the file:
> +		echo uart2 > /sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routing/uart1
> +
> +		This indicates that UART1 now receives its input from UART2.
> +
> +Users:		OpenBMC.  Proposed changes should be mailed to
> +		openbmc@lists.ozlabs.org
> +
> +What:		/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/io\*
> +Date:		August 2026
> +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
> +Description:	Selects the RX source of IOx serial port. The current selection
> +		will be marked by brackets "[]". The list of available options
> +		depends on the selected file.
> +
> +		e.g.
> +		cat /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routing/io9
> +		uart0 uart1 uart2 uart3 uart4 uart5 uart6 uart7 uart8 [uart9] uart10 uart11 uart12
> +		uart13 uart14 io0 io1 io2 io3 io4 io5 io6 io7 io8 io9 io10 io11 io12 io13 io14
> +
> +		In this case, IO9 (physical serial port 9) gets its input from UART9.
> +
> +		To switch the RX source of IO9 to UART10, write the desired source to the file:
> +		echo uart10 > /sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routing/io9
> +
> +		This indicates that IO9 now receives its input from UART10.
> +
> +Users:		OpenBMC.  Proposed changes should be mailed to
> +		openbmc@lists.ozlabs.org

drivers/soc/ should not define user-space interfaces. This is not the
place for them. You need to route user-spaces interfaces only through
one of other approved subsystems, after their review.

This looks like pin multiplexing interface.

Best regards,
Krzysztof

Re: [PATCH v1 2/2] soc: starfive: Add JHB100 UART Routing driver

[Changhuang Liang]

Hi, Krzysztof

Thanks for the review.

> On 30/08/2026 08:51, Changhuang Liang wrote:
> > Add driver support for JHB100 UART Routing control, allowing runtime
> > configuration of RX muxes between UART controllers and I/O pins.
> >
> > A sysfs interface is provided for easy checking and updating of
> > routing paths.
> >
> > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > ---
> >  .../sysfs-driver-starfive-jhb100-uart-routing |  45 +++
> >  MAINTAINERS                                   |   7 +
> >  drivers/soc/starfive/Kconfig                  |   1 +
> >  drivers/soc/starfive/Makefile                 |   1 +
> >  drivers/soc/starfive/uart-routing/Kconfig     |  14 +
> >  drivers/soc/starfive/uart-routing/Makefile    |   2 +
> >  .../uart-routing/jhb100-uart-routing.c        | 262
> ++++++++++++++++++
> >  7 files changed, 332 insertions(+)
> >  create mode 100644
> > Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
> >  create mode 100644 drivers/soc/starfive/uart-routing/Kconfig
> >  create mode 100644 drivers/soc/starfive/uart-routing/Makefile
> >  create mode 100644
> > drivers/soc/starfive/uart-routing/jhb100-uart-routing.c
> >
> > diff --git
> > a/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
> > b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
> > new file mode 100644
> > index 000000000000..2844133bea1b
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-rout
> > +++ ing
> > @@ -0,0 +1,45 @@
> > +What:
> 	/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/uart\*
> > +Date:		August 2026
> > +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
> > +Description:	Selects the RX source of the UARTx device.
> > +
> > +		When read, each file shows the list of available options with
> currently
> > +		selected option marked by brackets "[]". The list of available options
> > +		depends on the selected file.
> > +
> > +		e.g.
> > +		cat
> /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routing/uart1
> > +		io0 [io1] io2 io3 io4 io5 io6 io7 io8 io9 io10 io11 io12 io13 io14 uart0
> uart1
> > +		uart2 uart3 uart4 uart5 uart6 uart7 uart8 uart9 uart10 uart11
> > +uart12 uart13 uart14
> > +
> > +		In this case, UART1 gets its input from IO1 (physical serial port 1).
> > +
> > +		To switch the RX source of UART1 to UART2, write the desired
> source to the file:
> > +		echo uart2 >
> > +/sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routing
> > +/uart1
> > +
> > +		This indicates that UART1 now receives its input from UART2.
> > +
> > +Users:		OpenBMC.  Proposed changes should be mailed to
> > +		openbmc@lists.ozlabs.org
> > +
> > +What:		/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/io\*
> > +Date:		August 2026
> > +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
> > +Description:	Selects the RX source of IOx serial port. The current
> selection
> > +		will be marked by brackets "[]". The list of available options
> > +		depends on the selected file.
> > +
> > +		e.g.
> > +		cat
> /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routing/io9
> > +		uart0 uart1 uart2 uart3 uart4 uart5 uart6 uart7 uart8 [uart9] uart10
> uart11 uart12
> > +		uart13 uart14 io0 io1 io2 io3 io4 io5 io6 io7 io8 io9 io10 io11
> > +io12 io13 io14
> > +
> > +		In this case, IO9 (physical serial port 9) gets its input from UART9.
> > +
> > +		To switch the RX source of IO9 to UART10, write the desired source
> to the file:
> > +		echo uart10 >
> > +/sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routing
> > +/io9
> > +
> > +		This indicates that IO9 now receives its input from UART10.
> > +
> > +Users:		OpenBMC.  Proposed changes should be mailed to
> > +		openbmc@lists.ozlabs.org
> 
> drivers/soc/ should not define user-space interfaces. This is not the place for
> them. You need to route user-spaces interfaces only through one of other
> approved subsystems, after their review.
> 
> This looks like pin multiplexing interface.

I may have misunderstood something，please correct me if I'm wrong:

I have found two subsystems related to multiplexing so far:

/drivers/pinctrl and /drivers/mux. However, neither of them seems to provide a 
user-space interface for switching multiplexing values.

Do you have any suggestions on this?

Also, could you confirm whether the implementation in drivers/soc/aspeed/aspeed-uart-routing.c 
is there for historical reasons?

Best Regards,
Changhuang

Re: [PATCH v1 2/2] soc: starfive: Add JHB100 UART Routing driver

[Krzysztof Kozlowski]

On 31/08/2026 03:35, Changhuang Liang wrote:
> Hi, Krzysztof
> 
> Thanks for the review.
> 
>> On 30/08/2026 08:51, Changhuang Liang wrote:
>>> Add driver support for JHB100 UART Routing control, allowing runtime
>>> configuration of RX muxes between UART controllers and I/O pins.
>>>
>>> A sysfs interface is provided for easy checking and updating of
>>> routing paths.
>>>
>>> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
>>> ---
>>>  .../sysfs-driver-starfive-jhb100-uart-routing |  45 +++
>>>  MAINTAINERS                                   |   7 +
>>>  drivers/soc/starfive/Kconfig                  |   1 +
>>>  drivers/soc/starfive/Makefile                 |   1 +
>>>  drivers/soc/starfive/uart-routing/Kconfig     |  14 +
>>>  drivers/soc/starfive/uart-routing/Makefile    |   2 +
>>>  .../uart-routing/jhb100-uart-routing.c        | 262
>> ++++++++++++++++++
>>>  7 files changed, 332 insertions(+)
>>>  create mode 100644
>>> Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
>>>  create mode 100644 drivers/soc/starfive/uart-routing/Kconfig
>>>  create mode 100644 drivers/soc/starfive/uart-routing/Makefile
>>>  create mode 100644
>>> drivers/soc/starfive/uart-routing/jhb100-uart-routing.c
>>>
>>> diff --git
>>> a/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
>>> b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
>>> new file mode 100644
>>> index 000000000000..2844133bea1b
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-rout
>>> +++ ing
>>> @@ -0,0 +1,45 @@
>>> +What:
>> 	/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/uart\*
>>> +Date:		August 2026
>>> +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
>>> +Description:	Selects the RX source of the UARTx device.
>>> +
>>> +		When read, each file shows the list of available options with
>> currently
>>> +		selected option marked by brackets "[]". The list of available options
>>> +		depends on the selected file.
>>> +
>>> +		e.g.
>>> +		cat
>> /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routing/uart1
>>> +		io0 [io1] io2 io3 io4 io5 io6 io7 io8 io9 io10 io11 io12 io13 io14 uart0
>> uart1
>>> +		uart2 uart3 uart4 uart5 uart6 uart7 uart8 uart9 uart10 uart11
>>> +uart12 uart13 uart14
>>> +
>>> +		In this case, UART1 gets its input from IO1 (physical serial port 1).
>>> +
>>> +		To switch the RX source of UART1 to UART2, write the desired
>> source to the file:
>>> +		echo uart2 >
>>> +/sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routing
>>> +/uart1
>>> +
>>> +		This indicates that UART1 now receives its input from UART2.
>>> +
>>> +Users:		OpenBMC.  Proposed changes should be mailed to
>>> +		openbmc@lists.ozlabs.org
>>> +
>>> +What:		/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/io\*
>>> +Date:		August 2026
>>> +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
>>> +Description:	Selects the RX source of IOx serial port. The current
>> selection
>>> +		will be marked by brackets "[]". The list of available options
>>> +		depends on the selected file.
>>> +
>>> +		e.g.
>>> +		cat
>> /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routing/io9
>>> +		uart0 uart1 uart2 uart3 uart4 uart5 uart6 uart7 uart8 [uart9] uart10
>> uart11 uart12
>>> +		uart13 uart14 io0 io1 io2 io3 io4 io5 io6 io7 io8 io9 io10 io11
>>> +io12 io13 io14
>>> +
>>> +		In this case, IO9 (physical serial port 9) gets its input from UART9.
>>> +
>>> +		To switch the RX source of IO9 to UART10, write the desired source
>> to the file:
>>> +		echo uart10 >
>>> +/sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routing
>>> +/io9
>>> +
>>> +		This indicates that IO9 now receives its input from UART10.
>>> +
>>> +Users:		OpenBMC.  Proposed changes should be mailed to
>>> +		openbmc@lists.ozlabs.org
>>
>> drivers/soc/ should not define user-space interfaces. This is not the place for
>> them. You need to route user-spaces interfaces only through one of other
>> approved subsystems, after their review.
>>
>> This looks like pin multiplexing interface.
> 
> I may have misunderstood something，please correct me if I'm wrong:
> 
> I have found two subsystems related to multiplexing so far:
> 
> /drivers/pinctrl and /drivers/mux. However, neither of them seems to provide a 
> user-space interface for switching multiplexing values.
> 
> Do you have any suggestions on this?

pinctrl has some interface, not sure if writable, though. If interface
is missing, it should be added via such subsystem.

> 
> Also, could you confirm whether the implementation in drivers/soc/aspeed/aspeed-uart-routing.c 
> is there for historical reasons?

I supposed sneaked in without SoC maintainers noticing.

> 
> Best Regards,
> Changhuang


Best regards,
Krzysztof

Re: [PATCH v1 2/2] soc: starfive: Add JHB100 UART Routing driver

[Changhuang Liang]

Hi, Krzysztof

Thanks for the review.

> On 31/08/2026 03:35, Changhuang Liang wrote:
> > Hi, Krzysztof
> >
> > Thanks for the review.
> >
> >> On 30/08/2026 08:51, Changhuang Liang wrote:
> >>> Add driver support for JHB100 UART Routing control, allowing runtime
> >>> configuration of RX muxes between UART controllers and I/O pins.
> >>>
> >>> A sysfs interface is provided for easy checking and updating of
> >>> routing paths.
> >>>
> >>> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> >>> ---
> >>>  .../sysfs-driver-starfive-jhb100-uart-routing |  45 +++
> >>>  MAINTAINERS                                   |   7 +
> >>>  drivers/soc/starfive/Kconfig                  |   1 +
> >>>  drivers/soc/starfive/Makefile                 |   1 +
> >>>  drivers/soc/starfive/uart-routing/Kconfig     |  14 +
> >>>  drivers/soc/starfive/uart-routing/Makefile    |   2 +
> >>>  .../uart-routing/jhb100-uart-routing.c        | 262
> >> ++++++++++++++++++
> >>>  7 files changed, 332 insertions(+)
> >>>  create mode 100644
> >>> Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
> >>>  create mode 100644 drivers/soc/starfive/uart-routing/Kconfig
> >>>  create mode 100644 drivers/soc/starfive/uart-routing/Makefile
> >>>  create mode 100644
> >>> drivers/soc/starfive/uart-routing/jhb100-uart-routing.c
> >>>
> >>> diff --git
> >>> a/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routin
> >>> g
> >>> b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routin
> >>> g
> >>> new file mode 100644
> >>> index 000000000000..2844133bea1b
> >>> --- /dev/null
> >>> +++ b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-ro
> >>> +++ ut
> >>> +++ ing
> >>> @@ -0,0 +1,45 @@
> >>> +What:
> >> 	/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/uart\*
> >>> +Date:		August 2026
> >>> +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
> >>> +Description:	Selects the RX source of the UARTx device.
> >>> +
> >>> +		When read, each file shows the list of available options with
> >> currently
> >>> +		selected option marked by brackets "[]". The list of available
> options
> >>> +		depends on the selected file.
> >>> +
> >>> +		e.g.
> >>> +		cat
> >> /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routin
> >> g/uart1
> >>> +		io0 [io1] io2 io3 io4 io5 io6 io7 io8 io9 io10 io11 io12 io13
> >>> +io14 uart0
> >> uart1
> >>> +		uart2 uart3 uart4 uart5 uart6 uart7 uart8 uart9 uart10 uart11
> >>> +uart12 uart13 uart14
> >>> +
> >>> +		In this case, UART1 gets its input from IO1 (physical serial port
> 1).
> >>> +
> >>> +		To switch the RX source of UART1 to UART2, write the desired
> >> source to the file:
> >>> +		echo uart2 >
> >>> +/sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routi
> >>> +ng
> >>> +/uart1
> >>> +
> >>> +		This indicates that UART1 now receives its input from UART2.
> >>> +
> >>> +Users:		OpenBMC.  Proposed changes should be mailed to
> >>> +		openbmc@lists.ozlabs.org
> >>> +
> >>> +What:
> 	/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/io\*
> >>> +Date:		August 2026
> >>> +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
> >>> +Description:	Selects the RX source of IOx serial port. The current
> >> selection
> >>> +		will be marked by brackets "[]". The list of available options
> >>> +		depends on the selected file.
> >>> +
> >>> +		e.g.
> >>> +		cat
> >> /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routin
> >> g/io9
> >>> +		uart0 uart1 uart2 uart3 uart4 uart5 uart6 uart7 uart8 [uart9]
> >>> +uart10
> >> uart11 uart12
> >>> +		uart13 uart14 io0 io1 io2 io3 io4 io5 io6 io7 io8 io9 io10 io11
> >>> +io12 io13 io14
> >>> +
> >>> +		In this case, IO9 (physical serial port 9) gets its input from
> UART9.
> >>> +
> >>> +		To switch the RX source of IO9 to UART10, write the desired
> >>> +source
> >> to the file:
> >>> +		echo uart10 >
> >>> +/sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routi
> >>> +ng
> >>> +/io9
> >>> +
> >>> +		This indicates that IO9 now receives its input from UART10.
> >>> +
> >>> +Users:		OpenBMC.  Proposed changes should be mailed to
> >>> +		openbmc@lists.ozlabs.org
> >>
> >> drivers/soc/ should not define user-space interfaces. This is not the
> >> place for them. You need to route user-spaces interfaces only through
> >> one of other approved subsystems, after their review.
> >>
> >> This looks like pin multiplexing interface.
> >
> > I may have misunderstood something，please correct me if I'm wrong:
> >
> > I have found two subsystems related to multiplexing so far:
> >
> > /drivers/pinctrl and /drivers/mux. However, neither of them seems to
> > provide a user-space interface for switching multiplexing values.
> >
> > Do you have any suggestions on this?
> 
> pinctrl has some interface, not sure if writable, though. If interface is missing,
> it should be added via such subsystem.

Okay, this needs a bit more time for deeper research.

> 
> >
> > Also, could you confirm whether the implementation in
> > drivers/soc/aspeed/aspeed-uart-routing.c
> > is there for historical reasons?
> 
> I supposed sneaked in without SoC maintainers noticing.
> 
> >
> > Best Regards,
> > Changhuang
> 
> 
> Best regards,
> Krzysztof

Best Regards,
Changhuang

Re: [PATCH v1 2/2] soc: starfive: Add JHB100 UART Routing driver

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 6295 bytes --]

+CC Linus, linux-gpio,

On Mon, Aug 31, 2026 at 06:01:43AM +0000, Changhuang Liang wrote:
> Hi, Krzysztof
> 
> Thanks for the review.
> 
> > On 31/08/2026 03:35, Changhuang Liang wrote:
> > > Hi, Krzysztof
> > >
> > > Thanks for the review.
> > >
> > >> On 30/08/2026 08:51, Changhuang Liang wrote:
> > >>> Add driver support for JHB100 UART Routing control, allowing runtime
> > >>> configuration of RX muxes between UART controllers and I/O pins.
> > >>>
> > >>> A sysfs interface is provided for easy checking and updating of
> > >>> routing paths.
> > >>>
> > >>> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > >>> ---
> > >>>  .../sysfs-driver-starfive-jhb100-uart-routing |  45 +++
> > >>>  MAINTAINERS                                   |   7 +
> > >>>  drivers/soc/starfive/Kconfig                  |   1 +
> > >>>  drivers/soc/starfive/Makefile                 |   1 +
> > >>>  drivers/soc/starfive/uart-routing/Kconfig     |  14 +
> > >>>  drivers/soc/starfive/uart-routing/Makefile    |   2 +
> > >>>  .../uart-routing/jhb100-uart-routing.c        | 262
> > >> ++++++++++++++++++
> > >>>  7 files changed, 332 insertions(+)
> > >>>  create mode 100644
> > >>> Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routing
> > >>>  create mode 100644 drivers/soc/starfive/uart-routing/Kconfig
> > >>>  create mode 100644 drivers/soc/starfive/uart-routing/Makefile
> > >>>  create mode 100644
> > >>> drivers/soc/starfive/uart-routing/jhb100-uart-routing.c
> > >>>
> > >>> diff --git
> > >>> a/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routin
> > >>> g
> > >>> b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-routin
> > >>> g
> > >>> new file mode 100644
> > >>> index 000000000000..2844133bea1b
> > >>> --- /dev/null
> > >>> +++ b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-ro
> > >>> +++ ut
> > >>> +++ ing
> > >>> @@ -0,0 +1,45 @@
> > >>> +What:
> > >> 	/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/uart\*
> > >>> +Date:		August 2026
> > >>> +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
> > >>> +Description:	Selects the RX source of the UARTx device.
> > >>> +
> > >>> +		When read, each file shows the list of available options with
> > >> currently
> > >>> +		selected option marked by brackets "[]". The list of available
> > options
> > >>> +		depends on the selected file.
> > >>> +
> > >>> +		e.g.
> > >>> +		cat
> > >> /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routin
> > >> g/uart1
> > >>> +		io0 [io1] io2 io3 io4 io5 io6 io7 io8 io9 io10 io11 io12 io13
> > >>> +io14 uart0
> > >> uart1
> > >>> +		uart2 uart3 uart4 uart5 uart6 uart7 uart8 uart9 uart10 uart11
> > >>> +uart12 uart13 uart14
> > >>> +
> > >>> +		In this case, UART1 gets its input from IO1 (physical serial port
> > 1).
> > >>> +
> > >>> +		To switch the RX source of UART1 to UART2, write the desired
> > >> source to the file:
> > >>> +		echo uart2 >
> > >>> +/sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routi
> > >>> +ng
> > >>> +/uart1
> > >>> +
> > >>> +		This indicates that UART1 now receives its input from UART2.
> > >>> +
> > >>> +Users:		OpenBMC.  Proposed changes should be mailed to
> > >>> +		openbmc@lists.ozlabs.org
> > >>> +
> > >>> +What:
> > 	/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/io\*
> > >>> +Date:		August 2026
> > >>> +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
> > >>> +Description:	Selects the RX source of IOx serial port. The current
> > >> selection
> > >>> +		will be marked by brackets "[]". The list of available options
> > >>> +		depends on the selected file.
> > >>> +
> > >>> +		e.g.
> > >>> +		cat
> > >> /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-routin
> > >> g/io9
> > >>> +		uart0 uart1 uart2 uart3 uart4 uart5 uart6 uart7 uart8 [uart9]
> > >>> +uart10
> > >> uart11 uart12
> > >>> +		uart13 uart14 io0 io1 io2 io3 io4 io5 io6 io7 io8 io9 io10 io11
> > >>> +io12 io13 io14
> > >>> +
> > >>> +		In this case, IO9 (physical serial port 9) gets its input from
> > UART9.
> > >>> +
> > >>> +		To switch the RX source of IO9 to UART10, write the desired
> > >>> +source
> > >> to the file:
> > >>> +		echo uart10 >
> > >>> +/sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-routi
> > >>> +ng
> > >>> +/io9
> > >>> +
> > >>> +		This indicates that IO9 now receives its input from UART10.
> > >>> +
> > >>> +Users:		OpenBMC.  Proposed changes should be mailed to
> > >>> +		openbmc@lists.ozlabs.org
> > >>
> > >> drivers/soc/ should not define user-space interfaces. This is not the
> > >> place for them. You need to route user-spaces interfaces only through
> > >> one of other approved subsystems, after their review.
> > >>
> > >> This looks like pin multiplexing interface.
> > >
> > > I may have misunderstood something，please correct me if I'm wrong:
> > >
> > > I have found two subsystems related to multiplexing so far:
> > >
> > > /drivers/pinctrl and /drivers/mux. However, neither of them seems to
> > > provide a user-space interface for switching multiplexing values.
> > >
> > > Do you have any suggestions on this?
> > 
> > pinctrl has some interface, not sure if writable, though. If interface is missing,
> > it should be added via such subsystem.
> 
> Okay, this needs a bit more time for deeper research.
> 
> > 
> > >
> > > Also, could you confirm whether the implementation in
> > > drivers/soc/aspeed/aspeed-uart-routing.c
> > > is there for historical reasons?
> > 
> > I supposed sneaked in without SoC maintainers noticing.


My first reaction when this flew by over the weekend was whether it
should be in the pinctrl subsystem. I know there's no sysfs interface
there, but I don't even see an explanation for why changing this at
runtime is a requirement.

I'd have thought that each BMC would only have one host, and so since
you've got like 12 uarts there'd be enough for a permanent routing.

Even without a permanent routing, the driver consuming the pinctrl should
be able perform the switching (uart in this case) whenever it was
needed?

Cheers,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 2/2] soc: starfive: Add JHB100 UART Routing driver

[Changhuang Liang]

Hi, Conor

Thanks for the review.

> +CC Linus, linux-gpio,
> 
> On Mon, Aug 31, 2026 at 06:01:43AM +0000, Changhuang Liang wrote:
> > Hi, Krzysztof
> >
> > Thanks for the review.
> >
> > > On 31/08/2026 03:35, Changhuang Liang wrote:
> > > > Hi, Krzysztof
> > > >
> > > > Thanks for the review.
> > > >
> > > >> On 30/08/2026 08:51, Changhuang Liang wrote:
> > > >>> Add driver support for JHB100 UART Routing control, allowing
> > > >>> runtime configuration of RX muxes between UART controllers and I/O
> pins.
> > > >>>
> > > >>> A sysfs interface is provided for easy checking and updating of
> > > >>> routing paths.
> > > >>>
> > > >>> Signed-off-by: Changhuang Liang
> > > >>> <changhuang.liang@starfivetech.com>
> > > >>> ---
> > > >>>  .../sysfs-driver-starfive-jhb100-uart-routing |  45 +++
> > > >>>  MAINTAINERS                                   |   7 +
> > > >>>  drivers/soc/starfive/Kconfig                  |   1 +
> > > >>>  drivers/soc/starfive/Makefile                 |   1 +
> > > >>>  drivers/soc/starfive/uart-routing/Kconfig     |  14 +
> > > >>>  drivers/soc/starfive/uart-routing/Makefile    |   2 +
> > > >>>  .../uart-routing/jhb100-uart-routing.c        | 262
> > > >> ++++++++++++++++++
> > > >>>  7 files changed, 332 insertions(+)  create mode 100644
> > > >>> Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-rout
> > > >>> ing  create mode 100644
> > > >>> drivers/soc/starfive/uart-routing/Kconfig
> > > >>>  create mode 100644 drivers/soc/starfive/uart-routing/Makefile
> > > >>>  create mode 100644
> > > >>> drivers/soc/starfive/uart-routing/jhb100-uart-routing.c
> > > >>>
> > > >>> diff --git
> > > >>> a/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-ro
> > > >>> utin
> > > >>> g
> > > >>> b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uart-ro
> > > >>> utin
> > > >>> g
> > > >>> new file mode 100644
> > > >>> index 000000000000..2844133bea1b
> > > >>> --- /dev/null
> > > >>> +++ b/Documentation/ABI/testing/sysfs-driver-starfive-jhb100-uar
> > > >>> +++ t-ro
> > > >>> +++ ut
> > > >>> +++ ing
> > > >>> @@ -0,0 +1,45 @@
> > > >>> +What:
> > > >> 	/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/uart\*
> > > >>> +Date:		August 2026
> > > >>> +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
> > > >>> +Description:	Selects the RX source of the UARTx device.
> > > >>> +
> > > >>> +		When read, each file shows the list of available options with
> > > >> currently
> > > >>> +		selected option marked by brackets "[]". The list of
> > > >>> +available
> > > options
> > > >>> +		depends on the selected file.
> > > >>> +
> > > >>> +		e.g.
> > > >>> +		cat
> > > >> /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-ro
> > > >> utin
> > > >> g/uart1
> > > >>> +		io0 [io1] io2 io3 io4 io5 io6 io7 io8 io9 io10 io11 io12 io13
> > > >>> +io14 uart0
> > > >> uart1
> > > >>> +		uart2 uart3 uart4 uart5 uart6 uart7 uart8 uart9 uart10 uart11
> > > >>> +uart12 uart13 uart14
> > > >>> +
> > > >>> +		In this case, UART1 gets its input from IO1 (physical serial
> > > >>> +port
> > > 1).
> > > >>> +
> > > >>> +		To switch the RX source of UART1 to UART2, write the desired
> > > >> source to the file:
> > > >>> +		echo uart2 >
> > > >>> +/sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-r
> > > >>> +outi
> > > >>> +ng
> > > >>> +/uart1
> > > >>> +
> > > >>> +		This indicates that UART1 now receives its input from UART2.
> > > >>> +
> > > >>> +Users:		OpenBMC.  Proposed changes should be mailed to
> > > >>> +		openbmc@lists.ozlabs.org
> > > >>> +
> > > >>> +What:
> > > 	/sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/io\*
> > > >>> +Date:		August 2026
> > > >>> +Contact:	Changhuang Liang <changhuang.liang@starfivetech.com>
> > > >>> +Description:	Selects the RX source of IOx serial port. The current
> > > >> selection
> > > >>> +		will be marked by brackets "[]". The list of available options
> > > >>> +		depends on the selected file.
> > > >>> +
> > > >>> +		e.g.
> > > >>> +		cat
> > > >> /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*.uart-ro
> > > >> utin
> > > >> g/io9
> > > >>> +		uart0 uart1 uart2 uart3 uart4 uart5 uart6 uart7 uart8 [uart9]
> > > >>> +uart10
> > > >> uart11 uart12
> > > >>> +		uart13 uart14 io0 io1 io2 io3 io4 io5 io6 io7 io8 io9 io10
> > > >>> +io11
> > > >>> +io12 io13 io14
> > > >>> +
> > > >>> +		In this case, IO9 (physical serial port 9) gets its input
> > > >>> +from
> > > UART9.
> > > >>> +
> > > >>> +		To switch the RX source of IO9 to UART10, write the desired
> > > >>> +source
> > > >> to the file:
> > > >>> +		echo uart10 >
> > > >>> +/sys/bus/platform/drivers/starfive-jhb100-uart-routing/*.uart-r
> > > >>> +outi
> > > >>> +ng
> > > >>> +/io9
> > > >>> +
> > > >>> +		This indicates that IO9 now receives its input from UART10.
> > > >>> +
> > > >>> +Users:		OpenBMC.  Proposed changes should be mailed to
> > > >>> +		openbmc@lists.ozlabs.org
> > > >>
> > > >> drivers/soc/ should not define user-space interfaces. This is not
> > > >> the place for them. You need to route user-spaces interfaces only
> > > >> through one of other approved subsystems, after their review.
> > > >>
> > > >> This looks like pin multiplexing interface.
> > > >
> > > > I may have misunderstood something，please correct me if I'm wrong:
> > > >
> > > > I have found two subsystems related to multiplexing so far:
> > > >
> > > > /drivers/pinctrl and /drivers/mux. However, neither of them seems
> > > > to provide a user-space interface for switching multiplexing values.
> > > >
> > > > Do you have any suggestions on this?
> > >
> > > pinctrl has some interface, not sure if writable, though. If
> > > interface is missing, it should be added via such subsystem.
> >
> > Okay, this needs a bit more time for deeper research.
> >
> > >
> > > >
> > > > Also, could you confirm whether the implementation in
> > > > drivers/soc/aspeed/aspeed-uart-routing.c
> > > > is there for historical reasons?
> > >
> > > I supposed sneaked in without SoC maintainers noticing.
> 
> 
> My first reaction when this flew by over the weekend was whether it should
> be in the pinctrl subsystem. I know there's no sysfs interface there, but I don't
> even see an explanation for why changing this at runtime is a requirement.
> 
> I'd have thought that each BMC would only have one host, and so since you've
> got like 12 uarts there'd be enough for a permanent routing.
> 
> Even without a permanent routing, the driver consuming the pinctrl should be
> able perform the switching (uart in this case) whenever it was needed?

I can give you an example:

BMC typically has a use case like this.

When some customers use our SoC to design their own baseboards, in order to save 
I/O resources, they usually reserve only one pin, IO6, which by default routes UART6 
to IO6 for the BMC console. However, sometimes when they want to check the data 
from the Host UART (UART0), they need a user interface to route UART0 to IO6 so 
that they can view the UART0 data.

Best Regards,
Changhuang

Re: [PATCH v1 2/2] soc: starfive: Add JHB100 UART Routing driver

[Krzysztof Kozlowski]

On Tue, Sep 01, 2026 at 01:38:15AM +0000, Changhuang Liang wrote:
> > > > > I may have misunderstood something，please correct me if I'm wrong:
> > > > >
> > > > > I have found two subsystems related to multiplexing so far:
> > > > >
> > > > > /drivers/pinctrl and /drivers/mux. However, neither of them seems
> > > > > to provide a user-space interface for switching multiplexing values.
> > > > >
> > > > > Do you have any suggestions on this?
> > > >
> > > > pinctrl has some interface, not sure if writable, though. If
> > > > interface is missing, it should be added via such subsystem.
> > >
> > > Okay, this needs a bit more time for deeper research.
> > >
> > > >
> > > > >
> > > > > Also, could you confirm whether the implementation in
> > > > > drivers/soc/aspeed/aspeed-uart-routing.c
> > > > > is there for historical reasons?
> > > >
> > > > I supposed sneaked in without SoC maintainers noticing.
> > 
> > 
> > My first reaction when this flew by over the weekend was whether it should
> > be in the pinctrl subsystem. I know there's no sysfs interface there, but I don't
> > even see an explanation for why changing this at runtime is a requirement.
> > 
> > I'd have thought that each BMC would only have one host, and so since you've
> > got like 12 uarts there'd be enough for a permanent routing.
> > 
> > Even without a permanent routing, the driver consuming the pinctrl should be
> > able perform the switching (uart in this case) whenever it was needed?
> 
> I can give you an example:
> 
> BMC typically has a use case like this.
> 
> When some customers use our SoC to design their own baseboards, in order to save 
> I/O resources, they usually reserve only one pin, IO6, which by default routes UART6 
> to IO6 for the BMC console. However, sometimes when they want to check the data 
> from the Host UART (UART0), they need a user interface to route UART0 to IO6 so 
> that they can view the UART0 data.

So the pin is physically multiplexed and user wants to change it only
form time to time? IOW, users accept that they will loos the BMC console
logs or host console logs the moment they switch the UART?

Anyway, as you pointed out there is already one code like this - Aspeed
- thus this is a second one and that makes it reasonable to make a
proper common user-space API.

Just like in entire rest of kernel development - we do not multiple
interfaces or frameworks per each driver, but use a common part. That
de-duplication is the biggest difference comparing to downstream
approaches and comparing to all the people tried to send us with
arguments "but I want to solve my problem" (if you disagree, then please
watch old Greg's talk: I don't want your code).


Best regards,
Krzysztof

Re: [PATCH v1 2/2] soc: starfive: Add JHB100 UART Routing driver

[Changhuang Liang]

Hi, Krzysztof

Thanks for the review.

> On Tue, Sep 01, 2026 at 01:38:15AM +0000, Changhuang Liang wrote:
> > > > > > I may have misunderstood something，please correct me if I'm
> wrong:
> > > > > >
> > > > > > I have found two subsystems related to multiplexing so far:
> > > > > >
> > > > > > /drivers/pinctrl and /drivers/mux. However, neither of them
> > > > > > seems to provide a user-space interface for switching multiplexing
> values.
> > > > > >
> > > > > > Do you have any suggestions on this?
> > > > >
> > > > > pinctrl has some interface, not sure if writable, though. If
> > > > > interface is missing, it should be added via such subsystem.
> > > >
> > > > Okay, this needs a bit more time for deeper research.
> > > >
> > > > >
> > > > > >
> > > > > > Also, could you confirm whether the implementation in
> > > > > > drivers/soc/aspeed/aspeed-uart-routing.c
> > > > > > is there for historical reasons?
> > > > >
> > > > > I supposed sneaked in without SoC maintainers noticing.
> > >
> > >
> > > My first reaction when this flew by over the weekend was whether it
> > > should be in the pinctrl subsystem. I know there's no sysfs
> > > interface there, but I don't even see an explanation for why changing this
> at runtime is a requirement.
> > >
> > > I'd have thought that each BMC would only have one host, and so
> > > since you've got like 12 uarts there'd be enough for a permanent routing.
> > >
> > > Even without a permanent routing, the driver consuming the pinctrl
> > > should be able perform the switching (uart in this case) whenever it was
> needed?
> >
> > I can give you an example:
> >
> > BMC typically has a use case like this.
> >
> > When some customers use our SoC to design their own baseboards, in
> > order to save I/O resources, they usually reserve only one pin, IO6,
> > which by default routes UART6 to IO6 for the BMC console. However,
> > sometimes when they want to check the data from the Host UART (UART0),
> > they need a user interface to route UART0 to IO6 so that they can view the
> UART0 data.
> 
> So the pin is physically multiplexed and user wants to change it only form time
> to time? IOW, users accept that they will loos the BMC console logs or host
> console logs the moment they switch the UART?

Yes, typically they are used in time-sharing mode. After switching to the host UART, 
you need to switch back to the BMC console, usually via the network SSH console.

> Anyway, as you pointed out there is already one code like this - Aspeed
> - thus this is a second one and that makes it reasonable to make a proper
> common user-space API.
> 
> Just like in entire rest of kernel development - we do not multiple interfaces
> or frameworks per each driver, but use a common part. That de-duplication is
> the biggest difference comparing to downstream approaches and comparing
> to all the people tried to send us with arguments "but I want to solve my
> problem" (if you disagree, then please watch old Greg's talk: I don't want your
> code).
> 

Got it. I need to spend some time looking into it.

Best Regards,
Changhuang