Re: [PATCH v4 2/4] soc: aspeed: Move UART routing driver to drivers/uart-routing

[Changhuang Liang]

Hi, Andrew

> On Mon, 2026-10-19 at 03:06 -0700, Changhuang Liang wrote:
> > The Aspeed UART routing driver is not really a SoC driver: it only
> > exposes a serial crossbar through sysfs, and the same hardware block
> > exists on SoCs from other vendors. Move it to drivers/uart-routing/
> > and convert it to the common framework living there.
> >
> > The register layout description, that is the list of selectors with
> > their register offset, bit position, field mask and routing targets,
> > is kept as it is; only the surrounding sysfs plumbing is dropped in
> > favour of the framework. The per selector option lists become separate
> > arrays because the framework refers to them by pointer instead of
> > embedding them in the selector.
> >
> > The Kconfig symbol and the platform driver name are unchanged, so the
> > sysfs paths documented in
> > Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing stay valid
> > and existing configurations keep working.
> >
> > Also update MAINTAINERS to add entries for aspeed-uart-routing.c based
> > on the file authors, as the file currently lacks maintainers.
> >
> > Signed-off-by: Changhuang Liang <changhuang.liang@xxxxxxxxxxxxxxxx>
> > ---
> >  MAINTAINERS                                |  10 +
> >  drivers/soc/aspeed/Kconfig                 |  10 -
> >  drivers/soc/aspeed/Makefile                |   1 -
> >  drivers/soc/aspeed/aspeed-uart-routing.c   | 601
> > ---------------------
> >  drivers/uart-routing/Kconfig               |  16 +
> >  drivers/uart-routing/Makefile              |   2 +
> >  drivers/uart-routing/aspeed-uart-routing.c | 415 ++++++++++++++
> >  7 files changed, 443 insertions(+), 612 deletions(-)
> >  delete mode 100644 drivers/soc/aspeed/aspeed-uart-routing.c
> >  create mode 100644 drivers/uart-routing/aspeed-uart-routing.c
> >
> 
> I'm certainly in favour of moving code out of drivers/soc/aspeed, and having a
> small subsystem to handle this is fine, but it's not clear what happened to the
> direction of doing this by designing a user ABI for pinctrl?
> 
> https://lore.kernel.org/all/CAD++jLm7hQnCHACsZH0LVnXuCJm0dZ6Bq0hAyO
> TvVomy6WVRug@xxxxxxxxxxxxxx/
> 
> Existing code would need to be converted, but motivating that with the
> JHB100 support would seem sensible?

I'm not currently pursuing the pinctrl direction anymore, because I don't have a 
good way to implement that direction at the moment. So I'm proceeding with this 
series in the current way, and the main benefit is that it doesn't affect the Aspeed
test commands.

Best Regards,
Changhuang