On Sat, Dec 27, 2025 at 3:46 AM Ye Zhang [off-list ref] wrote:

I understand your preference for standard bindings.  However, there is a
specific constraint here: the RMIO acts as a secondary layer of muxing,
sitting behind the primary IOMUX controller.

The existing Rockchip pinctrl binding uses the vendor-specific
rockchip,pins property for the primary IOMUX configuration.  If I were
to use the standard pinmux property for RMIO, the node would contain
mixed bindings like this:

node {
     /* Primary IOMUX (existing binding) */
     rockchip,pins = <1 RK_PB1 16 &pcfg_pull_none>;
     /* Secondary RMIO  */
     pinmux = <(RMIO_ID << 16) | (RMIO_PIN << 8) | RMIO_FUNC>;
};

Since this node describes a single hardware pin configuration that
requires two separate hardware settings (Primary Mux + Secondary RMIO),
I thought keeping the secondary config as a vendor-specific property
(rockchip,rmio) alongside rockchip,pins would be more consistent and
less confusing than mixing legacy custom bindings with standard pinmux.

I see the concern but I would say two wrongs doesn't make one right.

The DT binding people will have to say what to do here, but ideally
I would say the primary IOMUX should be modified to *also* *additionally*
support the standard bindings and deprecating the old rockchip,pins,
and then you can consistently use the pinmux=<>; binding in new
trees for both pinmuxes.

I understand that maybe you are only working on this other controller
and might feel that the primary IOMUX is none of your concern,
but someone has to stand up and take the responsibility for the system
as a whole, if no-one else then the Rockchip SoC maintainer, else
we get throw-over-the-wall-engineering.

Yours,
Linus Walleij