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

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