netdev - Re: [PATCH net-next v3 14/17] dt-bindings: net: pse-pd: Add bindings for PD692x0 PSE controller

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdBWWXSgFIDSgn7P@pengutronix.de>
Date: Sat, 17 Feb 2024 07:46:49 +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

Hi Kory,

Can you please integrated this new insights to the PSE PI documentation.
Instead of 1000BaseT only, please use 1000/2.5G/5G/10GBASE-T as
documented in the spec.

On Fri, Feb 16, 2024 at 08:47:14AM +0100, Oleksij Rempel wrote:
> 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 |

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