linux-kernel - Re: [PATCH net-next v2 8/8] net: pse-pd: Add PD692x0 PSE controller driver

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: <20231221174246.GI1697233@pengutronix.de>
Date: Thu, 21 Dec 2023 18:42:46 +0100
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Mark Brown <broonie@...nel.org>
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>,
	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>,
	Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH net-next v2 8/8] net: pse-pd: Add PD692x0 PSE controller
 driver

On Thu, Dec 21, 2023 at 04:20:10PM +0000, Mark Brown wrote:
> On Thu, Dec 21, 2023 at 05:10:00PM +0100, Köry Maincent wrote:
> > Mark Brown <broonie@...nel.org> wrote:
> > > On Thu, Dec 21, 2023 at 04:36:10PM +0100, Köry Maincent wrote:
> > > > Mark Brown <broonie@...nel.org> wrote:  
> 
> > > > > OK...  I mean, if they're not using the regulator framework I'm not sure
> > > > > it has much impact - there are plenty of internal regulators in devices
> > > > > already so it wouldn't be *too* unusual other than the fact that AFAICT
> > > > > this is somewhat split between devices within the subsystem?  Neither of
> > > > > the messages was super clear.  
> 
> > > > PSE Power Interface (which is kind of the RJ45 in PSE world) have similar
> > > > functionalities as regulators. We wondered if registering a regulator for
> > > > each PSE PI (RJ45 ports) is a good idea. The point is that the PSE
> > > > controller driver will be its own regulator consumer.
> > > > I can't find any example in Linux with such a case of a driver being a
> > > > provider and a consumer of its own regulator. This idea of a regulator
> > > > biting its own tail seems weird to me. Maybe it is better to implement the
> > > > PSE functionalities even if they are like the regulator functionalities.  
> 
> > > Is it at all plausible that a system (perhaps an embedded one) might use
> > > something other than PSE?
> 
> > Do you mean to supply power to a RJ45 port?
> 
> Whatever it is that PSE does.
> 
> > This can be done with a simple regulator. In that case we use the pse_regulator
> > driver which is a regulator consumer.
> > I don't know about other cases. Oleksij do you?
> 
> In that case it sounds like you need the split to allow people to
> substitute in a non-PSE supply, and everything ought to be doing the
> consumer thing?

I decided and suggested to use regulator framework for following
reasons:
- The PSE is never a standalone controller. It is part of the system
  which includes Power Supply, which is providing power to the SoC and
  PSE.
- One system may contain multiple PSEs, we need to use some framework
  outside of PSE to regulate consumer priorities based on available
  power budget.
- a complex design may contain multiple hot swappable power supplies, we need
  to manage them and regulate power budget between multiple PSEs.
- in many cases PSE is kind of PMIC with multiple channels and some
  extras: prioritization, classification of attached devices. I suggest
  to represent every channel as a regulator, since it allow us to reuse
  existing diagnostic interfaces.

Since everything power related on a embedded system we already handle
with regulator framework, so why not use it within PSE too?

Here is an example of more or less complex system:

  +----------------------------------------------------------------+
  |                        Ethernet Switch                         |
  |                                                                |
  |  +-----------------+  +-----------------+  +-----------------+ |
  |  | Power Supply 1  |  | Power Supply 2  |  | removed Supply 3| |
  |  +--------+--------+  +--------+--------+  +--------+--------+ |
  |           |                    |-------------------.           |
  |  +--------v--------+  +--------v--------+  +--------v--------+ |
  |  | PSE Controller  |  | PSE Controller  |  | PSE Controller  | |
  |  |       #1        |  |       #2        |  |       #3        | |
  |  +----+++++--------+  +--------+--------+  +--------+--------+ |
  |       |||||                    |                    |          |
  +-------|||||--------------------|--------------------|----------+
          |||||                    |                    |            
          |||||                    |                    |            
  +-------....v--------------------v--------------------v---------+
  |                         Powered Devices                       |
  |                                                               |
  |  +--------+  +--------+  +--------+         +--------+  +-----+
  |  | Sensor |  | Sensor |  | Sensor |  ...    | Motor  |  | ... |
  |  +--------+  +--------+  +--------+         +--------+  +-----+
  |                                                               |
  +---------------------------------------------------------------+

How a PD reserves/communicates power budget on PSE PI (Power Interfaces)?

There are 3 ways to reserve power budget for PD:
- Level 1 classification. Done by PSE in cooperation with PD by firmware or
  can be done by Linux. Linux variant is currently not implemented.
- Done over Link Layer Discovery Protocol (LLDP). In this case some user
  space application (lldp daemon) will tell kernel to reserve power on some
  specific port (PSE PI).
- Set by user if all other ways fail or not implemented

PD side may have similar kind of challenges. For example, if PSE
notifies PD about reducing power budge for PD, PD may decide to reduce
consumption by keeping system alive - turn of the motor, but keep
sensors enabled. 

The main question is - how to represent a remote consumer (Powered
Device)? It looks for me like having a dummy regulator consumer for each
(PSE PI) withing the PSE framework is the simplest thing to do. User
should enable this dummy consumer from user space by using already
existing interface in case of PoDL - ETHTOOL_A_PODL_PSE_ADMIN_CONTROL
or new interface for Clause 33 PSE.

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 |