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: <a2f5c2b3-2168-41b4-917f-183ab72a4499@rock-chips.com>
Date: Thu, 8 Jan 2026 20:13:51 +0800
From: Ye Zhang <ye.zhang@...k-chips.com>
To: Linus Walleij <linusw@...nel.org>
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

在 2026/1/4 19:44, Linus Walleij 写道:
> 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.
Hi Linus,

We have discussed this internally, and we fully agree with your suggestion:
the driver should be modified to *additionally* support the standard
bindings, allowing us to eventually deprecate the old `rockchip,pins`.

**Regarding the RMIO support in this series:**
I am willing to implement the standard `pinmux` binding for the
**RMIO** part immediately in this v5. This ensures that the new feature
starts with the correct, standard binding.

**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? 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.

Best regards,
Ye Zhang