Re: [PATCH v4 2/4] soc: aspeed: Move UART routing driver to drivers/uart-routing
From: Andrew Jeffery
Date: Fri Oct 23 2026 - 01:30:31 EST
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++jLm7hQnCHACsZH0LVnXuCJm0dZ6Bq0hAyOTvVomy6WVRug@xxxxxxxxxxxxxx/
Existing code would need to be converted, but motivating that with the
JHB100 support would seem sensible?
Andrew