devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Rob Herring <robh@kernel.org>,
	Kory Maincent <kory.maincent@bootlin.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Russ Weight <russ.weight@linux.dev>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, devicetree@vger.kernel.org,
	Dent Project <dentproject@linuxfoundation.org>
Subject: Re: [PATCH net-next v3 14/17] dt-bindings: net: pse-pd: Add bindings for PD692x0 PSE controller
Date: Fri, 16 Feb 2024 08:47:14 +0100	[thread overview]
Message-ID: <Zc8TAojumif1irE-@pengutronix.de> (raw)
In-Reply-To: <65099b67-b7dc-4d78-ba42-d550aae2c31e@lunn.ch>

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 |

  reply	other threads:[~2024-02-16  7:47 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-08 13:08 [PATCH net-next v3 00/17] net: Add support for Power over Ethernet (PoE) Kory Maincent
2024-02-08 13:08 ` [PATCH net-next v3 01/17] MAINTAINERS: net: Add Oleksij to pse-pd maintainers Kory Maincent
2024-02-14 17:13   ` Andrew Lunn
2024-02-15  8:19     ` Oleksij Rempel
2024-02-08 13:08 ` [PATCH net-next v3 02/17] of: property: Add fw_devlink support for pse parent Kory Maincent
2024-02-14 17:17   ` Andrew Lunn
2024-02-08 13:08 ` [PATCH net-next v3 03/17] net: pse-pd: Rectify and adapt the naming of admin_cotrol member of struct pse_control_config Kory Maincent
2024-02-08 13:08 ` [PATCH net-next v3 04/17] ethtool: Expand Ethernet Power Equipment with c33 (PoE) alongside PoDL Kory Maincent
2024-02-08 13:08 ` [PATCH net-next v3 05/17] net: pse-pd: Introduce PSE types enumeration Kory Maincent
2024-02-14 17:18   ` Andrew Lunn
2024-02-08 13:08 ` [PATCH net-next v3 06/17] net: ethtool: pse-pd: Expand pse commands with the PSE PoE interface Kory Maincent
2024-02-14 17:21   ` Andrew Lunn
2024-02-08 13:08 ` [PATCH net-next v3 07/17] netlink: specs: Modify pse attribute prefix Kory Maincent
2024-02-14 17:22   ` Andrew Lunn
2024-02-08 13:08 ` [PATCH net-next v3 08/17] netlink: specs: Expand the pse netlink command with PoE interface Kory Maincent
2024-02-14 17:22   ` Andrew Lunn
2024-02-08 13:08 ` [PATCH net-next v3 09/17] MAINTAINERS: Add myself to pse networking maintainer Kory Maincent
2024-02-14 17:23   ` Andrew Lunn
2024-02-08 13:08 ` [PATCH net-next v3 10/17] dt-bindings: net: pse-pd: Add another way of describing several PSE PIs Kory Maincent
2024-02-08 15:51   ` Rob Herring
2024-02-09 14:43   ` Rob Herring
2024-02-14 13:13     ` Köry Maincent
2024-02-14 15:41       ` Köry Maincent
2024-02-15 13:51         ` Rob Herring
2024-02-15 14:01           ` Andrew Lunn
2024-02-15 14:33             ` Köry Maincent
2024-02-08 13:08 ` [PATCH net-next v3 11/17] net: pse-pd: Add support for " Kory Maincent
2024-02-08 13:08 ` [PATCH net-next v3 12/17] net: pse-pd: Add support for setup_pi_matrix callback Kory Maincent
2024-02-08 13:08 ` [PATCH net-next v3 13/17] net: pse-pd: Use regulator framework within PSE framework Kory Maincent
2024-02-08 13:08 ` [PATCH net-next v3 14/17] dt-bindings: net: pse-pd: Add bindings for PD692x0 PSE controller Kory Maincent
2024-02-09 14:57   ` Rob Herring
2024-02-11  9:32     ` Oleksij Rempel
2024-02-14 17:41       ` Andrew Lunn
2024-02-15  8:17         ` Oleksij Rempel
2024-02-15 10:41           ` Köry Maincent
2024-02-15 12:04             ` Oleksij Rempel
2024-02-15 17:51           ` Andrew Lunn
2024-02-16  7:47             ` Oleksij Rempel [this message]
2024-02-17  6:46               ` Oleksij Rempel
2024-02-19 14:31               ` Köry Maincent
2024-02-19 16:07                 ` Oleksij Rempel
2024-02-08 13:08 ` [PATCH net-next v3 15/17] net: pse-pd: Add PD692x0 PSE controller driver Kory Maincent
2024-02-08 13:08 ` [PATCH net-next v3 16/17] dt-bindings: net: pse-pd: Add bindings for TPS23881 PSE controller Kory Maincent
2024-02-08 15:51   ` Rob Herring
2024-02-09 11:26   ` Köry Maincent
2024-02-08 13:08 ` [PATCH net-next v3 17/17] net: pse-pd: Add TI TPS23881 PSE controller driver Kory Maincent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zc8TAojumif1irE-@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=andrew@lunn.ch \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=dentproject@linuxfoundation.org \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=kory.maincent@bootlin.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mcgrof@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=russ.weight@linux.dev \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).