[PATCH v1 11/20] dt-bindings: pinctrl: Add starfive,jhb100-per1-pinctrl

[Linus Walleij]

On Tue, Apr 28, 2026 at 8:51 PM Conor Dooley <conor at kernel.org> wrote:
> On Tue, Apr 28, 2026 at 01:28:05AM +0000, Changhuang Liang wrote:

> > We think that implementing this in the pinmux will be relatively simple. It avoids
> > the need to create a large number of mapping relationships in the driver, which
> > simplifies our driver implementation. I'm not sure if you'll find this explanation
> > acceptable.
>
> I don't really see how pins + functions would require lots of "mapping
> relationships". Instead of having
> +/* pinctrl_sys2 pad function selection */
> +#define FUNC_SYS2_UART_CTS                             1
> +#define FUNC_SYS2_UART_RTS                             1
> +#define FUNC_SYS2_UART_DCD                             1
> +#define FUNC_SYS2_UART_DSR                             1
> +#define FUNC_SYS2_UART_DTR                             1
> +#define FUNC_SYS2_UART_RI                              1
> +#define FUNC_SYS2_UART0_TX                             1
> +#define FUNC_SYS2_UART0_RX                             1
> +#define FUNC_SYS2_UART1_TX                             1
> +#define FUNC_SYS2_UART1_RX                             1
> +#define FUNC_SYS2_UART2_TX                             1
> +#define FUNC_SYS2_UART2_RX                             1
> +#define FUNC_SYS2_UART3_TX                             1
> +#define FUNC_SYS2_UART3_RX                             1
> +#define FUNC_SYS2_UART4_TX                             1
> +#define FUNC_SYS2_UART4_RX                             1
> +#define FUNC_SYS2_UART5_TX                             1
> +#define FUNC_SYS2_UART5_RX                             1
> +#define FUNC_SYS2_UART6_TX                             1
> +#define FUNC_SYS2_UART6_RX                             1
> +#define FUNC_SYS2_UART7_TX                             1
> +#define FUNC_SYS2_UART7_RX                             1
> +#define FUNC_SYS2_UART8_TX                             1
> +#define FUNC_SYS2_UART8_RX                             1
> +#define FUNC_SYS2_UART9_TX                             1
> +#define FUNC_SYS2_UART9_RX                             1
> +#define FUNC_SYS2_UART10_TX                            1
> +#define FUNC_SYS2_UART10_RX                            1
> +#define FUNC_SYS2_UART11_TX                            1
> +#define FUNC_SYS2_UART11_RX                            1
> +#define FUNC_SYS2_UART12_TX                            1
> +#define FUNC_SYS2_UART12_RX                            1
> +#define FUNC_SYS2_UART13_TX                            1
> +#define FUNC_SYS2_UART13_RX                            1
> +#define FUNC_SYS2_UART14_TX                            1
> +#define FUNC_SYS2_UART14_RX                            1
> you just define a function called "uart" and have a simple map of
> that string to the number 1. You end up with a single array with the
> relationships, not lots.
>
> Frankly, pinmux just does not seem appropriate to me when it looks like
> 90%+ of the pin mappings for a peripheral share the same function value.
> There appears only to be a rare number of cases where that doesn't
> apply, but that could be handled by having them represented by a
> different group/pins node with a different function.

I share Conors view on the muxing here. Using functions + groups
as strings looks easier for this hardware, and the driver needs many
changes anyway so I would say just get to it.

A common problem among upstream contributors is pushback that seems
to mask the fact that your organization has already decided to use this
scheme before discussing things with the community (based on previous
work and assumptions usually), and I'm not
happy about such situations, so please take this time for an internal
discussion about community work if this is the case.

Yours,
Linus Walleij