netdev - Re: [PATCH net-next v5 13/17] net: pse-pd: Use regulator framework within PSE framework

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: <ZeXZWAq1QwqCUJAm@pengutronix.de>
Date: Mon, 4 Mar 2024 15:23:20 +0100
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: Köry Maincent <kory.maincent@...tlin.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Jonathan Corbet <corbet@....net>,
	Luis Chamberlain <mcgrof@...nel.org>,
	Russ Weight <russ.weight@...ux.dev>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>, Mark Brown <broonie@...nel.org>,
	Frank Rowand <frowand.list@...il.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, devicetree@...r.kernel.org,
	Dent Project <dentproject@...uxfoundation.org>
Subject: Re: [PATCH net-next v5 13/17] net: pse-pd: Use regulator framework
 within PSE framework

On Mon, Mar 04, 2024 at 02:53:54PM +0100, Andrew Lunn wrote:
> On Mon, Mar 04, 2024 at 02:39:08PM +0100, Oleksij Rempel wrote:
> > On Mon, Mar 04, 2024 at 02:32:50PM +0100, Andrew Lunn wrote:
> > > > > > +	psec = dev_find_pse_control(&phy->mdio.dev);
> > > > > > +	if (IS_ERR(psec)) {
> > > > > > +		rc = PTR_ERR(psec);
> > > > > > +		goto unregister_phy;
> > > > > > +	}
> > > > > > +  
> > > > > 
> > > > > I do not think it is a good idea to make PSE controller depend on
> > > > > phy->mdio.dev. The only reason why we have fwnode_find_pse_control()
> > > > > here was the missing port abstraction.
> > > > 
> > > > I totally agree that having port abstraction would be more convenient.
> > > > Maxime Chevallier is currently working on this and will post it after his
> > > > multi-phy series get merged.
> > > > Meanwhile, we still need a device pointer for getting the regulator. The
> > > > phy->mdio.dev is the only one I can think of as a regulator consumer.
> > > > Another idea?
> > > 
> > > Sorry, i've not been keeping up...
> > > 
> > > Doesn't the device tree binding determine this? Where is the consumer
> > > in the tree?
> > 
> > The real consumer is outside of the system.
> 
> The device on the other end of the cable?

yes.

> > Withing the system, it would be the RJ45 port, but we have no
> > abstraction for ports so far.
> 
> A Linux regulator is generally used in a producer/consumer pair. If
> there is no consumer device, why have a producer? What is going to use
> the consumer API?

We already consulted Mark Brown in precious iterations of this patch
series and got his OK. I also described all advantages of using
regulator framework within the PSE subsystem. I need to search it. Short answer,
it is relatively common to have open-ended regulator with consumer outside of
the system. A PSE system can be relatively complex, representing all
supply dependencies from power supplies (one or multiple) to the ports
will help to provide needed diagnostic information and power saving
if port are disabled. Some functionality is currently not supported by
the regulator framework, but need to be extended - power budged,
priorities and reservation. All of this are not exclusive PSE
challenges. So, using regulator framework seems to be a straightforward 
decision.

> When we have a port representor, do we expect it to have active
> elements? Something which will consume this regulator?

Not in a usual sense. There are two levels of PSE control:
- autodetected by PSE controller
- fine tuned by using LLDP wich may respond to PD requests by allocating
  more or reducing/disabling power.

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |