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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 |




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux