linux-kernel - Re: [PATCH v3 04/21] dt-bindings: reset: renesas,rzv2h-usb2phy: Document VBUS

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: <20251112-launch-overcoat-18c3924b9b3f@spud>
Date: Wed, 12 Nov 2025 18:48:16 +0000
From: Conor Dooley <conor@...nel.org>
To: Rob Herring <robh@...nel.org>
Cc: Tommaso Merciai <tommaso.merciai.xr@...renesas.com>,
	tomm.merciai@...il.com, linux-renesas-soc@...r.kernel.org,
	biju.das.jz@...renesas.com, Vinod Koul <vkoul@...nel.org>,
	Kishon Vijay Abraham I <kishon@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Peter Rosin <peda@...ntia.se>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Magnus Damm <magnus.damm@...il.com>, Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-phy@...ts.infradead.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 04/21] dt-bindings: reset: renesas,rzv2h-usb2phy:
 Document VBUS_SEL mux

On Wed, Nov 12, 2025 at 10:37:12AM -0600, Rob Herring wrote:
> On Tue, Nov 11, 2025 at 05:49:24PM +0000, Conor Dooley wrote:
> > Tommaso, Rob,
> > 
> > On Mon, Nov 10, 2025 at 11:43:37PM +0100, Tommaso Merciai wrote:
> > > Hi Conor,
> > > Thanks for your comment!
> > > 
> > > On Mon, Nov 10, 2025 at 06:56:31PM +0000, Conor Dooley wrote:
> > > > On Mon, Nov 10, 2025 at 01:08:04PM +0100, Tommaso Merciai wrote:
> > > > > Document the 'mux-controller' child node in the Renesas RZ/V2H(P)
> > > > > USB2PHY reset binding to support describing the USB VBUS_SEL
> > > > > multiplexer as a mux-controller.
> > > > > 
> > > > > This is required to properly configure the USB PHY VBUS source on
> > > > > RZ/V2H(P), RZ/G3E SoCs.
> > > > > 
> > > > > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@...renesas.com>
> > > > > ---
> > > > > v2->v3:
> > > > >  - Manipulate mux-controller as an internal node.
> > > > 
> > > > Why is it a child node, rather than just putting the cell in the parent
> > > > reset node?
> > > 
> > > Getting "make dt_binding_check errors" [1] in v2
> > > Adding #mux-state-cells = <1> into:
> > > 
> > > 	usb20phyrst: reset-controller@...30000
> > > 	usb21phyrst: reset-controller@...40000
> > > 
> > > Nodes.
> > > 
> > > Please correct me if I'm wrong.
> > 
> > I think that that binding is not working as intended. Why require a
> > node-name pattern, when it matches on other things too:
> > select:
> >   anyOf:
> >     - properties:
> >         $nodename:
> >           pattern: '^mux-controller'
> >     - required:
> >         - '#mux-control-cells'
> >     - required:
> >         - '#mux-state-cells'
> > if the node name always contained mux-controller, the second two here
> > would not be needed. Looks to me like the intention was for it to allow
> > putting these control/state-cells properties into mfd type nodes.
> > 
> > I'd delete the node name property tbh. Rob, you converted this to
> > schema, what do you think?
> 
> Yeah, I'd probably just comment it out and drop the select.

Is dropping the select okay to do, or should just the nodename portion
go? I think there's a couple users that would need to be fixed up if the
whole thing gets removed. E.g. gpio-mux and reg-mux bot rely on the
schema being applied automagically AFAICT, and maybe there's some others.
Although, 99% of mux-controllers seem to use gpio-mux, reg-mux and
mmio-mux which are covered by those two files.

> I'm not sure what to do here in general. Matching on node names was 
> useful early on, but that becomes less useful as we have schemas for 
> everything. I'd still like to document standard node names in schemas 
> somehow, but obviously we can't require a certain name when a node is 
> multiple providers. Ideally, every node name in the list in the DT spec 
> would be in schemas and we could generate that list.
> 
> Rob

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)