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