linux-kernel - Re: [PATCH v3 3/4] dt-bindings: usb: microchip,usb2514: add support for port vbus-supply

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: <20250903225734.yfu5gvsclcxr4wge@pengutronix.de>
Date: Thu, 4 Sep 2025 00:57:34 +0200
From: Marco Felsch <m.felsch@...gutronix.de>
To: Rob Herring <robh@...nel.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Fabio Estevam <festevam@...il.com>,
	Matthias Kaehlcke <mka@...omium.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	kernel@...gutronix.de
Subject: Re: [PATCH v3 3/4] dt-bindings: usb: microchip,usb2514: add support
 for port vbus-supply

On 25-08-22, Rob Herring wrote:
> On Fri, Aug 22, 2025 at 12:30:05PM +0200, Marco Felsch wrote:
> > On 25-08-22, Krzysztof Kozlowski wrote:
> > > On Thu, Aug 21, 2025 at 06:31:57PM +0200, Marco Felsch wrote:
> > > > Some PCB designs don't connect the USB hub port power control GPIO and
> > > > instead make use of a host controllable regulator. Add support for this
> > > > use-case by introducing portX-vbus-supply property.
> > > > 
> > > > Signed-off-by: Marco Felsch <m.felsch@...gutronix.de>
> > > > ---
> > > >  Documentation/devicetree/bindings/usb/microchip,usb2514.yaml | 6 ++++++
> > > >  1 file changed, 6 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> > > > index 4e3901efed3fcd4fbbd8cb777f9df4fcadf2ca00..ac1e5f1a5ea2e66c61ce92154385952b15e78e55 100644
> > > > --- a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> > > > +++ b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> > > > @@ -49,6 +49,12 @@ patternProperties:
> > > >      $ref: /schemas/usb/usb-device.yaml
> > > >      additionalProperties: true
> > > >  
> > > > +  "^port[1-7]-vbus-supply$":
> > > > +    type: object
> > > > +    description:
> > > > +      Regulator controlling the USB VBUS on portX. Only required if the host
> > > > +      controls the portX VBUS.
> > > 
> > > Your commit msg should briefly describe status of previous discussion:
> > > why Rob's comment was not applied. Otherwise we repeat: this looks like
> > > property of specific port.
> > 
> > I answered Rob on my v1 but got no feedback. 
> 
> I just read it and don't understand. You don't have to have all 
> properties for a driver in the node associated with the driver. The 
> driver can freely look in the child nodes or anywhere else in the whole 
> tree if needed. Is that what you meant?
> 
> For USB hubs we generally define child nodes for each port. Some of the 
> hub bindings don't because they are incomplete. If you have a per port 
> property, then the DT property belongs in the port's node.

The problem was, that the regulator API didn't supported to search for
regulators which don't belong to its own DT node.

I wasn't sure if this is intented or not. Now I see that, the regulator
API gained the support for this use-case else I would have pinged Mark
if we need to add support for it.

I will change the "vbus-supply" to be specified within the port DT
nodes.

> > My v2 caused an issue found
> > by Rob's test bot. Therefore I thought he is okay and applied the
> > patchset for testing.
> 
> Other way around. If it doesn't pass tests, I don't look at it. (Well, I 
> do, but don't expect a reply.)

Okay, thanks for the clarification.

> > At least to me it's unclear when Rob's test bot is executed.
> 
> When you submit something. It's all automatic, though sometimes the 
> emails are delayed. Results are always in PW within 1-2 hours (unless 
> someone patch bombs us with a large series).

Thanks.

Regards,
  Marco