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

  Add the PD692x0 I2C Power Sourcing Equipment controller device tree
bindings documentation.

Sponsored-by: Dent Project <dentproject@linuxfoundation.org>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---

Changes in v2:
- Enhance ports-matrix description.
- Replace additionalProperties by unevaluatedProperties.
- Drop i2c suffix.

Changes in v3:
- Remove ports-matrix parameter.
- Add description of all physical ports and managers.
- Add pse_pis subnode moving to the API of pse-controller binding.
- Remove the MAINTAINERS section for this driver as I will be maintaining
  all pse-pd subsystem.
---
 .../bindings/net/pse-pd/microchip,pd692x0.yaml     | 157 +++++++++++++++++++++
 1 file changed, 157 insertions(+)
  

On Thu, Feb 08, 2024 at 02:08:51PM +0100, Kory Maincent wrote:
> Add the PD692x0 I2C Power Sourcing Equipment controller device tree
> bindings documentation.
> 
> Sponsored-by: Dent Project <dentproject@linuxfoundation.org>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> ---
> 
> Changes in v2:
> - Enhance ports-matrix description.
> - Replace additionalProperties by unevaluatedProperties.
> - Drop i2c suffix.
> 
> Changes in v3:
> - Remove ports-matrix parameter.
> - Add description of all physical ports and managers.
> - Add pse_pis subnode moving to the API of pse-controller binding.
> - Remove the MAINTAINERS section for this driver as I will be maintaining
>   all pse-pd subsystem.
> ---
>  .../bindings/net/pse-pd/microchip,pd692x0.yaml     | 157 +++++++++++++++++++++
>  1 file changed, 157 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml
> new file mode 100644
> index 000000000000..57ba5365157c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml
> @@ -0,0 +1,157 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/pse-pd/microchip,pd692x0.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip PD692x0 Power Sourcing Equipment controller
> +
> +maintainers:
> +  - Kory Maincent <kory.maincent@bootlin.com>
> +
> +allOf:
> +  - $ref: pse-controller.yaml#
> +
> +properties:
> +  compatible:
> +    enum:
> +      - microchip,pd69200
> +      - microchip,pd69210
> +      - microchip,pd69220
> +
> +  reg:
> +    maxItems: 1
> +
> +  managers:
> +    $ref: "#/$defs/managers"
> +    description:
> +      List of the PD69208T4/PD69204T4/PD69208M PSE managers. Each manager
> +      have 4 or 8 physical ports according to the chip version. No need to
> +      specify the SPI chip select as it is automatically detected by the
> +      PD692x0 PSE controller. The PSE managers have to be described from
> +      the lowest chip select to the greatest one, which is the detection
> +      behavior of the PD692x0 PSE controller. The PD692x0 support up to
> +      12 PSE managers which can expose up to 96 physical ports. All
> +      physical ports available on a manager have to be described in the
> +      incremental order even if they are not used.

Looks to me like you just need 3 PSE cells: <manager> <port> <A|B>

Really, no need for each piece of data to its own cell, so it could be 
merged into 1 or 2 cells.

But cell data is generally supposed to be meaningful to the provider and 
opaque to the consumer. It's not clear to me who needs to know 
alternative A vs. B. That seems more like a property of the PHY than the 
power provider? 

Rob
  

On Fri, Feb 09, 2024 at 02:57:27PM +0000, Rob Herring wrote:
> On Thu, Feb 08, 2024 at 02:08:51PM +0100, Kory Maincent wrote:
> > Add the PD692x0 I2C Power Sourcing Equipment controller device tree
> > bindings documentation.
> > 
> > Sponsored-by: Dent Project <dentproject@linuxfoundation.org>
> > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> > ---
> > 
> > Changes in v2:
> > - Enhance ports-matrix description.
> > - Replace additionalProperties by unevaluatedProperties.
> > - Drop i2c suffix.
> > 
> > Changes in v3:
> > - Remove ports-matrix parameter.
> > - Add description of all physical ports and managers.
> > - Add pse_pis subnode moving to the API of pse-controller binding.
> > - Remove the MAINTAINERS section for this driver as I will be maintaining
> >   all pse-pd subsystem.
> > ---
> >  .../bindings/net/pse-pd/microchip,pd692x0.yaml     | 157 +++++++++++++++++++++
> >  1 file changed, 157 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml
> > new file mode 100644
> > index 000000000000..57ba5365157c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml
> > @@ -0,0 +1,157 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/pse-pd/microchip,pd692x0.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Microchip PD692x0 Power Sourcing Equipment controller
> > +
> > +maintainers:
> > +  - Kory Maincent <kory.maincent@bootlin.com>
> > +
> > +allOf:
> > +  - $ref: pse-controller.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - microchip,pd69200
> > +      - microchip,pd69210
> > +      - microchip,pd69220
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  managers:
> > +    $ref: "#/$defs/managers"
> > +    description:
> > +      List of the PD69208T4/PD69204T4/PD69208M PSE managers. Each manager
> > +      have 4 or 8 physical ports according to the chip version. No need to
> > +      specify the SPI chip select as it is automatically detected by the
> > +      PD692x0 PSE controller. The PSE managers have to be described from
> > +      the lowest chip select to the greatest one, which is the detection
> > +      behavior of the PD692x0 PSE controller. The PD692x0 support up to
> > +      12 PSE managers which can expose up to 96 physical ports. All
> > +      physical ports available on a manager have to be described in the
> > +      incremental order even if they are not used.
> 
> Looks to me like you just need 3 PSE cells: <manager> <port> <A|B>
> 
> Really, no need for each piece of data to its own cell, so it could be 
> merged into 1 or 2 cells.
> 
> But cell data is generally supposed to be meaningful to the provider and 
> opaque to the consumer. It's not clear to me who needs to know 
> alternative A vs. B. That seems more like a property of the PHY than the 
> power provider? 

This is a bit complex question, so I decided to answer it with freshly
created documentation which should be included to this patch set:

PSE Power Interface (PSE PI) Documentation
==========================================

The Power Sourcing Equipment Power Interface (PSE PI) plays a pivotal role in
the architecture of Power over Ethernet (PoE) systems. It is essentially a
blueprint that outlines how one or multiple power sources are connected to the
eight-pin modular jack, commonly known as the Ethernet RJ45 port. This
connection scheme is crucial for enabling the delivery of power alongside data
over Ethernet cables.

Documentation and Standards
---------------------------

The IEEE 802.3 standard provides detailed documentation on the PSE PI.
Specifically:

- Section "33.2.3 PI pin assignments" covers the pin assignments for PoE
  systems that utilize two pairs for power delivery.
- Section "145.2.4 PSE PI" addresses the configuration for PoE systems that
  deliver power over all four pairs of an Ethernet cable.

PSE PI and Single Pair Ethernet
-------------------------------

Single Pair Ethernet (SPE) represents a different approach to Ethernet
connectivity, utilizing just one pair of conductors for both data and power
transmission. Unlike the configurations detailed in the PSE PI for standard
Ethernet, which can involve multiple power sourcing arrangements across four or
two pairs of wires, SPE operates on a simpler model due to its single-pair
design. As a result, the complexities of choosing between alternative pin
assignments for power delivery, as described in the PSE PI for multi-pair
Ethernet, are not applicable to SPE.

Understanding PSE PI
--------------------

The Power Sourcing Equipment Power Interface (PSE PI) is a framework defining
how Power Sourcing Equipment (PSE) delivers power to Powered Devices (PDs) over
Ethernet cables. It details two main configurations for power delivery, known
as Alternative A and Alternative B, which are distinguished not only by their
method of power transmission but also by the implications for polarity and data
transmission direction.

Alternative A and B Overview
----------------------------

- **Alternative A:** Utilizes the data-carrying pairs for power transmission in
  10/100BaseT networks. The power delivery's polarity in this alternative can
  vary based on the MDI (Medium Dependent Interface) or MDI-X (Medium Dependent
  Interface Crossover) configuration.

- **Alternative B:** Delivers power over the spare pairs not used for data in
  10/100BaseT networks. Unlike Alternative A, Alternative B's method separates
  power from data lines within the cable. Though it is less influenced by data
  transmission direction, Alternative B includes two configurations with
  different polarities, known as variant X and variant S, to accommodate
  different network requirements and device specifications.

Table 145–3—PSE Pinout Alternatives
-----------------------------------

The following table outlines the pin configurations for both Alternative A and
Alternative B.

+------------+-------------------+-----------------+-----------------+-----------------+
| Conductor  | Alternative A     | Alternative A   | Alternative B   | Alternative B   |
|            |    (MDI-X)        |      (MDI)      |        (X)      |        (S)      |
+============+===================+=================+=================+=================+
| 1          | Negative V        | Positive V      | -               | -               |
+------------+-------------------+-----------------+-----------------+-----------------+
| 2          | Negative V        | Positive V      | -               | -               |
+------------+-------------------+-----------------+-----------------+-----------------+
| 3          | Positive V        | Negative V      | -               | -               |
+------------+-------------------+-----------------+-----------------+-----------------+
| 4          | -                 | -               | Negative V      | Positive V      |
+------------+-------------------+-----------------+-----------------+-----------------+
| 5          | -                 | -               | Negative V      | Positive V      |
+------------+-------------------+-----------------+-----------------+-----------------+
| 6          | Positive V        | Negative V      | -               | -               |
+------------+-------------------+-----------------+-----------------+-----------------+
| 7          | -                 | -               | Positive V      | Negative V      |
+------------+-------------------+-----------------+-----------------+-----------------+
| 8          | -                 | -               | Positive V      | Negative V      |
+------------+-------------------+-----------------+-----------------+-----------------+

. note::
    - "Positive V" and "Negative V" indicate the voltage polarity for each pin.
    - "-" indicates that the pin is not used for power delivery in that
      specific configuration.

PSE Power Interface (PSE PI) Connection Diagram
------------------------------------------------

The diagram below illustrates the connection architecture between the RJ45
port, the Ethernet PHY (Physical Layer), and the PSE PI (Power Sourcing
Equipment Power Interface), demonstrating how power and data are delivered
simultaneously through an Ethernet cable. The RJ45 port serves as the physical
interface for these connections, with each of its eight pins connected to both
the Ethernet PHY for data transmission and the PSE PI for power delivery.

. code-block::

    +--------------------------+
    |                          |
    |          RJ45 Port       |
    |                          |
    +--+--+--+--+--+--+--+--+--+                +-------------+
      1| 2| 3| 4| 5| 6| 7| 8|                   |             |
       |  |  |  |  |  |  |  o-------------------+             |
       |  |  |  |  |  |  o--|-------------------+             +<--- PSE 1
       |  |  |  |  |  o--|--|-------------------+             |
       |  |  |  |  o--|--|--|-------------------+             |
       |  |  |  o--|--|--|--|-------------------+  PSE PI     |
       |  |  o--|--|--|--|--|-------------------+             |
       |  o--|--|--|--|--|--|-------------------+             +<--- PSE 2 (optional)
       o--|--|--|--|--|--|--|-------------------+             |
       |  |  |  |  |  |  |  |                   |             |
    +--+--+--+--+--+--+--+--+--+                +-------------+
    |                          |
    |       Ethernet PHY       |
    |                          |
    +--------------------------+

Simple PSE PI Configuration for Alternative A
---------------------------------------------

The diagram below illustrates a straightforward PSE PI (Power Sourcing
Equipment Power Interface) configuration designed to support the Alternative A
setup for Power over Ethernet (PoE). This implementation is tailored to provide
power delivery through the data-carrying pairs of an Ethernet cable, suitable
for either MDI or MDI-X configurations, albeit supporting one variation at a
time.

. code-block::

         +-------------+
         |    PSE PI   |
 8  -----+                             +-------------+
 7  -----+                    Rail 1   |             
 6  -----+------+----------------------+             
 5  -----+      |                      |             
 4  -----+     /              Rail 2   |  PSE 1       
 3  -----+----´          +-------------+             
 2  -----+----+---------´              |             
 1  -----+---´                         +-------------+
         |                                           
         +-------------+                            

In this configuration:

- Pins 1 and 2, as well as pins 3 and 6, are utilized for power delivery in
  addition to data transmission. This aligns with the standard wiring for
  10/100BaseT Ethernet networks where these pairs are used for data.
- Rail 1 and Rail 2 represent the positive and negative voltage rails, with
  Rail 1 connected to pins 1 and 2, and Rail 2 connected to pins 3 and 6.
  More advanced PSE PI configurations may include integrated or external
  switches to change the polarity of the voltage rails, allowing for
  compatibility with both MDI and MDI-X configurations.

More complex PSE PI configurations may include additional components, to support
Alternative B, or to provide additional features such as power management, or
additional power delivery capabilities such as 2-pair or 4-pair power delivery.

. code-block::

         +-------------+
         |    PSE PI   |
         |        +---+
 8  -----+--------+   |                 +-------------+
 7  -----+--------+   |       Rail 1   |             
 6  -----+--------+   +-----------------+             
 5  -----+--------+   |                |             
 4  -----+--------+   |       Rail 2   |  PSE 1       
 3  -----+--------+   +----------------+             
 2  -----+--------+   |                |             
 1  -----+--------+   |                 +-------------+
         |        +---+                               
         +-------------+                            

Device Tree Configuration: Describing PSE PI Configurations
------------------------------------------------------------

The necessity for a separate PSE PI node in the device tree is influenced by
the intricacy of the Power over Ethernet (PoE) system's setup. Here are
descriptions of both simple and complex PSE PI configurations to illustrate
this decision-making process:

**Simple PSE PI Configuration:**
In a straightforward scenario, the PSE PI setup involves a direct, one-to-one
connection between a single PSE controller and an Ethernet port. This setup
typically supports basic PoE functionality without the need for dynamic
configuration or management of multiple power delivery modes. For such simple
configurations, detailing the PSE PI within the existing PSE controller's node
may suffice, as the system does not encompass additional complexity that
warrants a separate node. The primary focus here is on the clear and direct
association of power delivery to a specific Ethernet port.

**Complex PSE PI Configuration:**
Contrastingly, a complex PSE PI setup may encompass multiple PSE controllers or
auxiliary circuits that collectively manage power delivery to one Ethernet
port. Such configurations might support a range of PoE standards and require
the capability to dynamically configure power delivery based on the operational
mode (e.g., PoE2 versus PoE4) or specific requirements of connected devices. In
these instances, a dedicated PSE PI node becomes essential for accurately
documenting the system architecture. This node would serve to detail the
interactions between different PSE controllers, the support for various PoE
modes, and any additional logic required to coordinate power delivery across
the network infrastructure.

**Guidance:**

For simple PSE setups, including PSE PI information in the PSE controller node
might suffice due to the straightforward nature of these systems. However,
complex configurations, involving multiple components or advanced PoE features,
benefit from a dedicated PSE PI node. This method adheres to IEEE 802.3
specifications, improving documentation clarity and ensuring accurate
representation of the PoE system's complexity.

PSE PI Node: Essential Information
----------------------------------

The PSE PI (Power Sourcing Equipment Power Interface) node in a device tree can
include several key pieces of information critical for defining the power
delivery capabilities and configurations of a PoE (Power over Ethernet) system.
Below is a list of such information, along with explanations for their
necessity and reasons why they might not be found within a PSE controller node:

1. **Powered Pairs Configuration**
   - *Description:* Identifies the pairs used for power delivery in the
     Ethernet cable.
   - *Necessity:* Essential to ensure the correct pairs are powered according
     to the board's design.
   - *PSE Controller Node:* Typically lacks details on physical pair usage,
     focusing on power regulation.

2. **Polarity of Powered Pairs**
   - *Description:* Specifies the polarity (positive or negative) for each
     powered pair.
   - *Necessity:* Critical for safe and effective power transmission to PDs.
   - *PSE Controller Node:* Polarity management may exceed the standard
     functionalities of PSE controllers.

3. **PSE Cells Association**
   - *Description:* Details the association of PSE cells with Ethernet ports or
     pairs in multi-cell configurations.
   - *Necessity:* Allows for optimized power resource allocation in complex
     systems.
   - *PSE Controller Node:* Controllers may not manage cell associations
     directly, focusing instead on power flow regulation.

4. **Support for PoE Standards**
   - *Description:* Lists the PoE standards and configurations supported by the
     system.
   - *Necessity:* Ensures system compatibility with various PDs and adherence
     to industry standards.
   - *PSE Controller Node:* Specific capabilities may depend on the overall PSE
     PI design rather than the controller alone. Multiple PSE cells per PI
     do not necessarily imply support for multiple PoE standards.

5. **Protection Mechanisms**
   - *Description:* Outlines additional protection mechanisms, such as
     overcurrent protection and thermal management.
   - *Necessity:* Provides extra safety and stability, complementing PSE
     controller protections.
   - *PSE Controller Node:* Some protections may be implemented via
     board-specific hardware or algorithms external to the controller.


Regards,
Oleksij
  

> Alternative A and B Overview
> ----------------------------
> 
> - **Alternative A:** Utilizes the data-carrying pairs for power transmission in
>   10/100BaseT networks. The power delivery's polarity in this alternative can
>   vary based on the MDI (Medium Dependent Interface) or MDI-X (Medium Dependent
>   Interface Crossover) configuration.
> 
> - **Alternative B:** Delivers power over the spare pairs not used for data in
>   10/100BaseT networks. Unlike Alternative A, Alternative B's method separates
>   power from data lines within the cable. Though it is less influenced by data
>   transmission direction, Alternative B includes two configurations with
>   different polarities, known as variant X and variant S, to accommodate
>   different network requirements and device specifications.

Thanks for this documentation.

It might be worth pointing out that RJ-45 supports up to 4
pairs. However, 10/100BaseT only makes use of two pairs for data
transfer from the four. 1000BaseT and above make use of all four pairs
for data transfer. If you don't know this, it is not so obvious what
'data-carrying pairs' and 'spare pairs' mean.

And what happens for 1000BaseT when all four pairs are in use?

    Andrew
  

On Wed, Feb 14, 2024 at 06:41:54PM +0100, Andrew Lunn wrote:
> > Alternative A and B Overview
> > ----------------------------
> > 
> > - **Alternative A:** Utilizes the data-carrying pairs for power transmission in
> >   10/100BaseT networks. The power delivery's polarity in this alternative can
> >   vary based on the MDI (Medium Dependent Interface) or MDI-X (Medium Dependent
> >   Interface Crossover) configuration.
> > 
> > - **Alternative B:** Delivers power over the spare pairs not used for data in
> >   10/100BaseT networks. Unlike Alternative A, Alternative B's method separates
> >   power from data lines within the cable. Though it is less influenced by data
> >   transmission direction, Alternative B includes two configurations with
> >   different polarities, known as variant X and variant S, to accommodate
> >   different network requirements and device specifications.
> 
> Thanks for this documentation.
> 
> It might be worth pointing out that RJ-45 supports up to 4
> pairs. However, 10/100BaseT only makes use of two pairs for data
> transfer from the four. 1000BaseT and above make use of all four pairs
> for data transfer. If you don't know this, it is not so obvious what
> 'data-carrying pairs' and 'spare pairs' mean.

@Kory, can you please update it.

> And what happens for 1000BaseT when all four pairs are in use?

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.
  

On Thu, 15 Feb 2024 09:17:48 +0100
Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> On Wed, Feb 14, 2024 at 06:41:54PM +0100, Andrew Lunn wrote:
> > > Alternative A and B Overview
> > > ----------------------------
> > > 
> > > - **Alternative A:** Utilizes the data-carrying pairs for power
> > > transmission in 10/100BaseT networks. The power delivery's polarity in
> > > this alternative can vary based on the MDI (Medium Dependent Interface)
> > > or MDI-X (Medium Dependent Interface Crossover) configuration.
> > > 
> > > - **Alternative B:** Delivers power over the spare pairs not used for
> > > data in 10/100BaseT networks. Unlike Alternative A, Alternative B's
> > > method separates power from data lines within the cable. Though it is
> > > less influenced by data transmission direction, Alternative B includes
> > > two configurations with different polarities, known as variant X and
> > > variant S, to accommodate different network requirements and device
> > > specifications.  
> > 
> > Thanks for this documentation.
> > 
> > It might be worth pointing out that RJ-45 supports up to 4
> > pairs. However, 10/100BaseT only makes use of two pairs for data
> > transfer from the four. 1000BaseT and above make use of all four pairs
> > for data transfer. If you don't know this, it is not so obvious what
> > 'data-carrying pairs' and 'spare pairs' mean.  
> 
> @Kory, can you please update it.
> 
> > And what happens for 1000BaseT when all four pairs are in use?  
> 
> 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.

Oleksij how did you get the definition of Alternative A uses the "data-carrying"
pairs for power transmission and Alternative B Delivers power over the "spare
pairs"?

On my understanding of the 2022 standard the definition is: 
- Alternative A is for pinout conductors 1, 2, 3 and 6
- Alternative B is for pinout conductors 4, 5, 7, 8.

Then indeed if we are in 10/100BaseT Alternative A are "data-carrying
pairs" and Alternative B are "spare pairs" but that's not the case on
1000BaseT.

You can see it in the figures in the paragraph 145.2.3.

Regards,
  

On Thu, Feb 15, 2024 at 11:41:23AM +0100, Köry Maincent wrote:
> On Thu, 15 Feb 2024 09:17:48 +0100
> Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> 
> > On Wed, Feb 14, 2024 at 06:41:54PM +0100, Andrew Lunn wrote:
> > > > Alternative A and B Overview
> > > > ----------------------------
> > > > 
> > > > - **Alternative A:** Utilizes the data-carrying pairs for power
> > > > transmission in 10/100BaseT networks. The power delivery's polarity in
> > > > this alternative can vary based on the MDI (Medium Dependent Interface)
> > > > or MDI-X (Medium Dependent Interface Crossover) configuration.
> > > > 
> > > > - **Alternative B:** Delivers power over the spare pairs not used for
> > > > data in 10/100BaseT networks. Unlike Alternative A, Alternative B's
> > > > method separates power from data lines within the cable. Though it is
> > > > less influenced by data transmission direction, Alternative B includes
> > > > two configurations with different polarities, known as variant X and
> > > > variant S, to accommodate different network requirements and device
> > > > specifications.  
> > > 
> > > Thanks for this documentation.
> > > 
> > > It might be worth pointing out that RJ-45 supports up to 4
> > > pairs. However, 10/100BaseT only makes use of two pairs for data
> > > transfer from the four. 1000BaseT and above make use of all four pairs
> > > for data transfer. If you don't know this, it is not so obvious what
> > > 'data-carrying pairs' and 'spare pairs' mean.  
> > 
> > @Kory, can you please update it.
> > 
> > > And what happens for 1000BaseT when all four pairs are in use?  
> > 
> > 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.
> 
> Oleksij how did you get the definition of Alternative A uses the "data-carrying"
> pairs for power transmission and Alternative B Delivers power over the "spare
> pairs"?
> 
> On my understanding of the 2022 standard the definition is: 
> - Alternative A is for pinout conductors 1, 2, 3 and 6
> - Alternative B is for pinout conductors 4, 5, 7, 8.
> 
> Then indeed if we are in 10/100BaseT Alternative A are "data-carrying
> pairs" and Alternative B are "spare pairs" but that's not the case on
> 1000BaseT.
> 
> You can see it in the figures in the paragraph 145.2.3.

Please, re-read my answer :)

Autoneg for 1000Mbit is not done on all 4 pairs. The only MDI/-X
dependent transfer processes only on one pair is autoneg. Every thing
else is extrapolated out of it.
  

> 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'm not sure the second solution will actually fly. This was being
tested with Marvell Prestera switch. I doubt it even has any Fast
Ethernet ports.

	Andrew
  

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
  

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 |
  

On Fri, 16 Feb 2024 08:47:14 +0100
Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> >
> > 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).
> 
> 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
>            |
> +---------+---------------+-------------------+---------------------+--------------------+

Maybe we could remove the polarity column on this table as it does not bring
more information. It is also already explained on the PI pinout alternatives
table.

Also we should document that a 4pairs PSE supporting only 10/100BaseT (which
mean no magnetics on pinout AlternativeB) may not be compatible with a 4pairs
1GBaseT PD.

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

Yes.

Regards,
  

On Mon, Feb 19, 2024 at 03:31:06PM +0100, Köry Maincent wrote:
> On Fri, 16 Feb 2024 08:47:14 +0100
> Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> > >
> > > 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).
> > 
> > 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
> >            |
> > +---------+---------------+-------------------+---------------------+--------------------+
> 
> Maybe we could remove the polarity column on this table as it does not bring
> more information. It is also already explained on the PI pinout alternatives
> table.

Ack. I'm still not sure if "Phantom" is correct description.

> 
> Also we should document that a 4pairs PSE supporting only 10/100BaseT (which
> mean no magnetics on pinout AlternativeB) may not be compatible with a 4pairs
> 1GBaseT PD.

Ack. s/may not/is not/ :) and 4pairs PSE is not always compatible with
PoE4 as well. I assume this  kind of knowledge we will get from PSE
driver.

Regards,
Oleksij