linux-kernel - Re: [PATCH v3 6/7] dt-bindings: pinctrl: rockchip: Add RMIO controller binding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAD++jLkmieQpkJnAYyr7ys6m+v-=qNZaMoyKCtPFo+qjGwm8DQ@mail.gmail.com>
Date: Fri, 9 Jan 2026 11:19:02 +0100
From: Linus Walleij <linusw@...nel.org>
To: Ye Zhang <ye.zhang@...k-chips.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, Heiko Stuebner <heiko@...ech.de>, 
	Bartosz Golaszewski <brgl@...ev.pl>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-gpio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	tao.huang@...k-chips.com
Subject: Re: [PATCH v3 6/7] dt-bindings: pinctrl: rockchip: Add RMIO
 controller binding

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 <ye.zhang@...k-chips.com> 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