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