netdev - Re: [PATCH net-next 2/9] ethtool: Expand Ethernet Power Equipment with PoE alongside PoDL

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: <20231120111008.GC590719@pengutronix.de>
Date: Mon, 20 Nov 2023 12:10:08 +0100
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Köry Maincent <kory.maincent@...tlin.com>
Cc: Andrew Lunn <andrew@...n.ch>, "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
Subject: Re: [PATCH net-next 2/9] ethtool: Expand Ethernet Power Equipment
 with PoE alongside PoDL

Köry,

On Mon, Nov 20, 2023 at 11:09:44AM +0100, Köry Maincent wrote:
> +Oleksij
> 
> Sorry forgot to CC you the series.
> Maybe you should add yourself to the MAINTAINERS of pse-pd drivers subsystem?

ack, i'll take a look at this.

> On Sat, 18 Nov 2023 18:38:43 +0100
> Andrew Lunn <andrew@...n.ch> wrote:
> 
> > On Thu, Nov 16, 2023 at 03:01:34PM +0100, Kory Maincent wrote:
> > > In the current PSE interface for Ethernet Power Equipment, support is
> > > limited to PoDL. This patch extends the interface to accommodate the
> > > objects specified in IEEE 802.3-2022 145.2 for Power sourcing
> > > Equipment (PSE).  
> > 
> > Sorry for taking a while getting to these patches. Plumbers and other
> > patches have been keeping me busy.
> 
> Don't worry you are doing a great job as a net maintainer and I won't raise any
> remarks on delay considering how you are doing your job.
> Thanks again for your review!!
> 
> > I'm trying to get my head around naming... Is there some sort of
> > hierarchy? Is PSE the generic concept for putting power down the
> > cable? Then you have the sub-type PoDL, and the sub-type PoE?
> 
> In fact as we discussed with Oleksij I decided to keep the naming as close as
> possible to the IEEE 802.3 standard.
> On the standard the PODL is naming like this aPoDLPSE* (ex: aPoDLPSEAdminState)
> and the PSE is naming like this aPSE* (ex: aPSEAdminState) without any PoE
> prefix. Maybe it is due to PoE being supported before PoDL and they didn't
> expect the PoDL part.

"PoE" (initially Power via MDI?) and PoDL have kind of different technologies.
They use different negotiation and need different physical implementation.
IEEE 802.3 standard is trying to be backwards and kind of forwards compatible
for PoE. But not compatible between PoE and PoDL.

In general, it is not just about enabling or disabling power.
"admin_state" == enable is other way to say - "do the right thing".
And the "right thing" may include some kind of communication between PSE
(Power Source Equipment) and PD (Powered Device).

Since, some variants of  Single Pair Ethernet (SPE) are using same
auto negotiation protocol as not SPE variants. I can imagine, that some
day we will see a hybrid (SPE+nonSPE) devices. Wich will need to
support both: PoE and PoDL. I assume, in that case, we wont to be able
to control both variants separately.

This is why I prefer to have mapping of IEEE 802.3 specification to the
user space as close as possible.

> > >  struct pse_control_config {
> > >  	enum ethtool_podl_pse_admin_state podl_admin_control;
> > > +	enum ethtool_pse_admin_state admin_control;  
> > 
> > When i look at this, it seems to me admin_control should be generic
> > across all schemes which put power down the cable, and
> > podl_admin_control is specific to how PoDL puts power down the cable.
> >
> > Since you appear to be adding support for a second way to put power
> > down the cable, i would expect something like poe_admin_control being
> > added here. But maybe that is in a later patch?
> 
> No as said above admin_control is for PoE and podl_admin_control is for PoDL.
> Maybe you prefer to use poe_admin_control, and add poe prefix in the poe
> variables. It will differ a bit from the IEEE standard naming but I agreed that
> it would be more understandable in the development part.

Official name for "PoE" is "Power via Media Dependent Interface". PoE is
not used in the IEEE 802.3-2018. Using names not used in the specification,
make development even harder :)
Especially since there are even more marketing names (names not used in the
specification) for different PoE variants:
- 802.3af (802.3at Type 1), PoE
- 802.3at Type 2, PoE+
- 802.3bt Type 3, 4PPoE or PoE++
- 802.3bt Type 4, 4PPoE or PoE++

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 |