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

From: Changhuang Liang

Date: Mon Aug 31 2026 - 21:49:40 EST


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@xxxxxxxxxxxxxxxx>
> > > >>> ---
> > > >>> .../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@xxxxxxxxxxxxxxxx>
> > > >>> +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@xxxxxxxxxxxxxxxx
> > > >>> +
> > > >>> +What:
> > > /sys/bus/platform/drivers/starfive-jhb100-uart-routing/\*/io\*
> > > >>> +Date: August 2026
> > > >>> +Contact: Changhuang Liang <changhuang.liang@xxxxxxxxxxxxxxxx>
> > > >>> +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@xxxxxxxxxxxxxxxx
> > > >>
> > > >> 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