Hi Ye,

thanks for agreeing on using standard bindings for
RMIO, we are making progress!

On Thu, Jan 8, 2026 at 1:19 PM Ye Zhang [off-list ref] wrote:

**Regarding the primary IOMUX:**
However, the RK3506 pinctrl support is built upon the existing
`pinctrl-rockchip` driver infrastructure, which was originally designed
around
the `rockchip,pins` property. Refactoring the driver to support the standard
`pinmux` binding (and the suggested nested node structure) is a significant
undertaking that involves core logic changes and regression risks for older
SoCs. Mandating this refactoring as a prerequisite for RK3506 support
would effectively block this SoC from being supported upstream for a
long time.

Could we allow RK3506 to follow the existing driver's style for now to
ensure
consistency and timely support?

"timely support" is of lesser concern to the kernel and DT
bindings which are more concerned with maintainability and long-term
longevity. The ambition is to work predictably and impersonal, such
as like the planets, or the plants.

We agree that migrating to standard pinmux
bindings is the right direction, but we believe it should be handled as a
separate, dedicated project in the future rather than part of this
enablement series.

Hi Heiko,
Do you agree with this?
1.        Use standard `pinmux` for RMIO in this series.
2.        Keep `rockchip,pins` for the primary IOMUX for now.
3.        Plan a future refactoring to migrate the primary IOMUX to
standard bindings.

My main concern is this:

foo {
    rockchip,pins = <...>; // For IOMUX
    pinmux = <...>; /// for RMIO
};

I don't want to see this, because that will be *hopeless* to migrate
to both controllers using pinmux = <...>; how should you decide
which one to pick for each?

In that case it is better to do:

foo {
    rockchip,pins = <...>;
    rmio {
        pinmux = <....>;
    };
};

Because then you can later migrate to:

foo {
    iomux {
        pinmux = <....>;
    };
    rmio {
        pinmux = <...>;
    };
};

Yours,
Linus Walleij