Message-ID: <Zc8TAojumif1irE-@pengutronix.de>
Date: Fri, 16 Feb 2024 08:47:14 +0100
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: Rob Herring <robh@...nel.org>,
	Kory 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>,
	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 v3 14/17] dt-bindings: net: pse-pd: Add bindings
 for PD692x0 PSE controller

On Thu, Feb 15, 2024 at 06:51:55PM +0100, Andrew Lunn wrote:
> > Hm.. good question. I didn't found the answer in the spec. By combining all
> > puzzle parts I assume, different Alternative configurations are designed
> > to handle conflict between "PSE Physical Layer classification" and PHY
> > autoneg.
> > 
> > Here is how multi-pulse Physical Layer classification is done:
> > https://img.electronicdesign.com/files/base/ebm/electronicdesign/image/2020/07/Figure_5.5f2094553a61c.png
> > 
> > this is the source:
> > https://www.electronicdesign.com/technologies/power/whitepaper/21137799/silicon-labs-90-w-power-over-ethernet-explained
> > 
> > To avoid classification conflict with autoneg. Assuming, PHY on PD side
> > will be not powered until classification is completed. The only source
> > of pulses is the PHY on PSE side (if it is not under control of software
> > on PSE side or Midspan PSE is used), so aneg pulses should be send on
> > negative PoE pair? This all is just speculation, I would need to ask
> > some expert or do testing.
> > 
> > If this assumption is correct, PHY framework will need to know exact
> > layout of MDI-X setting and/or silent PHY until PSE classification is done.
> 
> Ideally, we don't want to define a DT binding, and then find it is
> wrong for 1000BaseT and above and we need to change it.
>
> So, either somebody needs to understand 1000BaseT and can say the
> proposed binding works, or we explicitly document the binding is
> limited to 10BaseT and 100BaseT.

I asked the internet and found the answer: Some PSE/PD implementations
are not compatible with 1000BaseT.

See Figure 33–4—10BASE-T/100BASE-TX Endpoint PSE location overview.
Alternative B show a variant where power is injected directly to pairs
without using magnetics as it is done for Alternative A (phantom
delivery - over magnetics).

I assume, the reasoning for this kind of design is simple - price.
Otherwise magnetics will have special requirements:
https://www.coilcraft.com/de-de/edu/series/magnetics-for-power-over-ethernet/

So, we have following variants of 2 pairs PoE:
+---------+---------------+-------------------+---------------------+--------------------+
| Variant | Alternative   | Polarity          | Power Feeding Type  | Compatibility with |
|         | (a/b)         | (Direct/Reverse)  | (Direct/Phantom)    | 1000BaseT          |
+=========+===============+===================+=====================+====================+
| 1       | a             | Direct            | Phantom             | Yes                |
+---------+---------------+-------------------+---------------------+--------------------+
| 2       | a             | Reverse           | Phantom             | Yes                |
+---------+---------------+-------------------+---------------------+--------------------+
| 3       | b             | Direct            | Phantom             | Yes                |
+---------+---------------+-------------------+---------------------+--------------------+
| 4       | b             | Reverse           | Phantom             | Yes                |
+---------+---------------+-------------------+---------------------+--------------------+
| 5       | b             | Direct            | Direct              | No                 |
+---------+---------------+-------------------+---------------------+--------------------+
| 6       | b             | Reverse           | Direct              | No                 |
+---------+---------------+-------------------+---------------------+--------------------+

An advanced PSE may implement range of different variants direct in the PSE
controller or with additional ICs in the PSE PI. The same is about PD.

Let's take as example PD-IM-7608M eval board:
https://www.microchip.com/en-us/development-tool/PD-IM-7608M

According to the schematics:
https://ww1.microchip.com/downloads/en/DeviceDoc/PD-IM-7608M.zip
It supports only Variant 5 - Alternative B, with only one polarity,
and direct feeding without magnetics.

The simple PD may support only one variant:
https://community.fs.com/article/troubleshooting-poe-errors.html
" the power modes of PSE and PD are other factors that may cause PoE
faults. There are three PoE modes: Alternative A, alternative B, and
4-pair delivery. If a PD only supports PoE mode B power delivery, while
a PoE switch is based on Alternative A, as a result, the PD and PoE
switch can not work together."

For this case, it will be good if systems knows supported modes, so user
can get this information  directly. For example with ethtool

-- 
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 |

Powered by blists - more mailing lists