[PATCH 0/5] pinctrl: Add generic pinctrl for board-level mux chips

Frank Li posted 5 patches 1 month, 1 week ago
There is a newer version of this series
.../bindings/pinctrl/pinctrl-multiplexer.yaml      |  54 +++++
.../devicetree/bindings/pinctrl/pinctrl.yaml       |   2 +-
arch/arm64/boot/dts/freescale/Makefile             |   4 +
.../boot/dts/freescale/imx8mp-evk-flexcan2.dtso    |  15 ++
arch/arm64/boot/dts/freescale/imx8mp-evk.dts       |  23 ++-
drivers/mux/core.c                                 |  40 ++--
drivers/pinctrl/Kconfig                            |   9 +
drivers/pinctrl/Makefile                           |   1 +
drivers/pinctrl/pinctrl-generic-mux.c              | 222 +++++++++++++++++++++
include/linux/mux/consumer.h                       |  16 +-
10 files changed, 363 insertions(+), 23 deletions(-)
[PATCH 0/5] pinctrl: Add generic pinctrl for board-level mux chips
Posted by Frank Li 1 month, 1 week ago
Add a generic pinctrl binding for board-level pinmux chips that are
controlled through the multiplexer subsystem.

On some boards, especially development boards, external mux chips are used
to switch SoC signals between different peripherals (e.g. MMC and UART).
The mux select lines are often driven by a GPIO expander over I2C,
as illustrated below:

        ┌──────┐      ┌─────┐
        │ SOC  │      │     │    ┌───────┐
        │      │      │     │───►│ MMC   │
        │      │      │ MUX │    └───────┘
        │      ├─────►│     │    ┌───────┐
        │      │      │     │───►│ UART  │
        │      │      └─────┘    └───────┘
        │      │         ▲
        │      │    ┌────┴──────────────┐
        │ I2C  ├───►│ GPIO Expander     │
        └──────┘    └───────────────────┘

Traditionally, gpio-hog is used to configure the onboard mux at boot.
However, the GPIO expander may probe later than consumer devices such as
MMC. As a result, the MUX might not be configured when the peripheral
driver probes, leading to initialization failures or data transfer errors.

Introduce a generic pinctrl binding that models the board-level MUX as a
pin control provider and builds proper device links between the MUX, its
GPIO controller, and peripheral devices. This ensures correct probe
ordering and reliable mux configuration.

The implementation leverages the standard multiplexer subsystem, which
provides broad support for onboard mux controllers and avoids the need for
per-driver custom MUX handling

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Frank Li (5):
      mux: add devm_mux_control_get_from_np() to get mux from child node
      dt-bindings: pinctrl: Add generic pinctrl for board-level mux chips
      pinctrl: add generic board-level pinctrl driver using mux framework
      arm64: dts: imx8mp-evk: add board-level mux for CAN2 and MICFIL
      arm64: dts: imx8mp-evk: add flexcan2 overlay file

 .../bindings/pinctrl/pinctrl-multiplexer.yaml      |  54 +++++
 .../devicetree/bindings/pinctrl/pinctrl.yaml       |   2 +-
 arch/arm64/boot/dts/freescale/Makefile             |   4 +
 .../boot/dts/freescale/imx8mp-evk-flexcan2.dtso    |  15 ++
 arch/arm64/boot/dts/freescale/imx8mp-evk.dts       |  23 ++-
 drivers/mux/core.c                                 |  40 ++--
 drivers/pinctrl/Kconfig                            |   9 +
 drivers/pinctrl/Makefile                           |   1 +
 drivers/pinctrl/pinctrl-generic-mux.c              | 222 +++++++++++++++++++++
 include/linux/mux/consumer.h                       |  16 +-
 10 files changed, 363 insertions(+), 23 deletions(-)
---
base-commit: ff76d257e86235eb07ef33db8644a517c48d1c3f
change-id: 20260213-pinctrl-mux-df9c5b661540

Best regards,
--
Frank Li <Frank.Li@nxp.com>

Re: [PATCH 0/5] pinctrl: Add generic pinctrl for board-level mux chips
Posted by Linus Walleij 1 month, 1 week ago
Hi Frank,

On Thu, Feb 19, 2026 at 11:24 PM Frank Li <Frank.Li@nxp.com> wrote:

> Add a generic pinctrl binding for board-level pinmux chips that are
> controlled through the multiplexer subsystem.
>
> On some boards, especially development boards, external mux chips are used
> to switch SoC signals between different peripherals (e.g. MMC and UART).
> The mux select lines are often driven by a GPIO expander over I2C,
> as illustrated below:
>
>         ┌──────┐      ┌─────┐
>         │ SOC  │      │     │    ┌───────┐
>         │      │      │     │───►│ MMC   │
>         │      │      │ MUX │    └───────┘
>         │      ├─────►│     │    ┌───────┐
>         │      │      │     │───►│ UART  │
>         │      │      └─────┘    └───────┘
>         │      │         ▲
>         │      │    ┌────┴──────────────┐
>         │ I2C  ├───►│ GPIO Expander     │
>         └──────┘    └───────────────────┘
>
> Traditionally, gpio-hog is used to configure the onboard mux at boot.
> However, the GPIO expander may probe later than consumer devices such as
> MMC. As a result, the MUX might not be configured when the peripheral
> driver probes, leading to initialization failures or data transfer errors.
>
> Introduce a generic pinctrl binding that models the board-level MUX as a
> pin control provider and builds proper device links between the MUX, its
> GPIO controller, and peripheral devices. This ensures correct probe
> ordering and reliable mux configuration.
>
> The implementation leverages the standard multiplexer subsystem, which
> provides broad support for onboard mux controllers and avoids the need for
> per-driver custom MUX handling
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>

I kind of like what I see here. :)

This makes a lot of sense: it uses muxes, and it muxes pins.
So that is the appropriate description, pinmuxes using
muxes (in turn controlled by GPIOs).

I just need to have buy-in from DT binding
maintainers and the authors of the mux core that this is a good
idea.

Yours,
Linus Walleij