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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD++jLnH2vLNxTLj8Lw8RnOHxfitwi3G_8WCBtu+_=XL3ryH_w@mail.gmail.com>
Date: Sun, 4 Jan 2026 12:44:47 +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

On Sat, Dec 27, 2025 at 3:46 AM Ye Zhang <ye.zhang@...k-chips.com> 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