Received-SPF: pass (google.com: domain of linux-kernel+bounces-130089-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Wed, 3 Apr 2024 17:27:35 +0200
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Rob Herring <robh@kernel.org>
Cc: 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>, Andrew Lunn <andrew@lunn.ch>,
	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 v6 11/17] dt-bindings: net: pse-pd: Add another
 way of describing several PSE PIs
Message-ID: <Zg11Z1kJ42eLhabK@pengutronix.de>
References: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
 <20240326-feature_poe-v6-11-c1011b6ea1cb@bootlin.com>
 <20240402132637.GA3744978-robh@kernel.org>
 <ZgworgDAXXOpf3QV@pengutronix.de>
 <20240403144448.GB3508225-robh@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240403144448.GB3508225-robh@kernel.org>

On Wed, Apr 03, 2024 at 09:44:48AM -0500, Rob Herring wrote:
> On Tue, Apr 02, 2024 at 05:47:58PM +0200, Oleksij Rempel wrote:
> > On Tue, Apr 02, 2024 at 08:26:37AM -0500, Rob Herring wrote:
> > > > +          pairsets:
> > > > +            $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > +            description:
> > > > +              List of phandles, each pointing to the power supply for the
> > > > +              corresponding pairset named in 'pairset-names'. This property
> > > > +              aligns with IEEE 802.3-2022, Section 33.2.3 and 145.2.4.
> > > > +              PSE Pinout Alternatives (as per IEEE 802.3-2022 Table 145\u20133)
> > > > +              |-----------|---------------|---------------|---------------|---------------|
> > > > +              | Conductor | Alternative A | Alternative A | Alternative B | Alternative B |
> > > > +              |           |    (MDI-X)    |     (MDI)     |      (X)      |      (S)      |
> > > > +              |-----------|---------------|---------------|---------------|---------------|
> > > > +              | 1         | Negative VPSE | Positive VPSE | \u2014             | \u2014             |
> > > > +              | 2         | Negative VPSE | Positive VPSE | \u2014             | \u2014             |
> > > > +              | 3         | Positive VPSE | Negative VPSE | \u2014             | \u2014             |
> > > > +              | 4         | \u2014             | \u2014             | Negative VPSE | Positive VPSE |
> > > > +              | 5         | \u2014             | \u2014             | Negative VPSE | Positive VPSE |
> > > > +              | 6         | Positive VPSE | Negative VPSE | \u2014             | \u2014             |
> > > > +              | 7         | \u2014             | \u2014             | Positive VPSE | Negative VPSE |
> > > > +              | 8         | \u2014             | \u2014             | Positive VPSE | Negative VPSE |
> > > > +            minItems: 1
> > > > +            maxItems: 2
> > > 
> > > "pairsets" does not follow the normal design pattern of foos, foo-names, 
> > > and #foo-cells. You could add #foo-cells I suppose, but what would cells 
> > > convey? I don't think it's a good fit for what you need.
> > > 
> > > The other oddity is the number of entries and the names are fixed. That 
> > > is usually defined per consumer. 
> > > 
> > > As each entry is just a power rail, why can't the regulator binding be 
> > > used here?
> > 
> > I'm not against describing it consequent with regulator till the wire
> > end, but right now I have no idea how it should be described by using
> > regulator bindings. There are maximum 2 rails going in to PSE PI on one
> > side and 4 rails with at least 5 combinations supported by standard on
> > other side. Instead of inventing anything new, I suggested to describe
> > supported output combinations by using IEEE 802.3 standard.
> 
> There's 4 combinations above, what's the 5th combination? SPE?

The 5th combination is PoE4 where two rails are supplying power at same
time.

First 4 variants for PoE: one or two positive rails are attached (but
only one is used at same time) to pairs 1-2 or 3-4, or 5-6, or 7-8. Or
support all of combinations if some advanced PSE PI is present. PSE PI
is kind of MUX for regulators.

One more variant in case of PoE4: two positive rail are attached at same
time, one to 1-2, second to 5-6. May be one more variant with opposite
polarity, this will be the 6th combination.

> Seems to me you just describe the 2 rails going to the connector and 
> then describe all the variations the connector supports. The PSE 
> (h/w) has little to do with which variations are supported, right?

No. In case of mutli-channel PSE, it needs to know if channels are
attached to one port or to different ports. PSE is not only responsible
to enable the power, it runs classification of devices attached to the
port, so it will decide, which rail should be enabled.

> For example, MDI-X vs. MDI support is determined by the PHY, right?

Yes and No. Until PSE do not start supplying power, PHY will not be able to
start communication with the remote PHY, so it will not be able to
detect MDI/X configuration.

Polarity configuration is important for user space or user to get
information about supported pin configuration and if possible,
change the configuration.

> Or it has to be supported by both the PHY and PSE?

In most cases PSE and PHY work independently from each other, they just
share same port. Potential exception are:
- in case data line should not be shared with power lines, we need to
  know what pins are used for power, this information would help to
  provide PHY configuration.
- in case PHY autoneg signals disturb PoE classification, we need to
  coordinate PHY and PSE states.

Regards,
Oleksij
-- 
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 |