linux-kernel - Re: [PATCH net-next v4 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 20 Feb 2024 12:05:17 +0100
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Köry Maincent <kory.maincent@...tlin.com>
Cc: "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>,
	Rob Herring <robh+dt@...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>, Andrew Lunn <andrew@...n.ch>,
	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 v4 14/17] dt-bindings: net: pse-pd: Add bindings
 for PD692x0 PSE controller

On Tue, Feb 20, 2024 at 11:40:29AM +0100, Köry Maincent wrote:
> On Sat, 17 Feb 2024 13:14:29 +0100
> Oleksij Rempel <o.rempel@...gutronix.de> wrote:
> 
> > On Thu, Feb 15, 2024 at 05:02:55PM +0100, Kory Maincent wrote:
> > > Add the PD692x0 I2C Power Sourcing Equipment controller device tree
> > > bindings documentation.
> > > 
> > > This patch is sponsored by Dent Project <dentproject@...uxfoundation.org>.
> > > 
> > > Signed-off-by: Kory Maincent <kory.maincent@...tlin.com>
> > > ---  
> > ...
> > > +        pse_pis {
> > > +          #address-cells = <1>;
> > > +          #size-cells = <0>;
> > > +
> > > +          pse_pi0: pse_pi@0 {
> > > +            reg = <0>;
> > > +            #pse-cells = <0>;
> > > +            pairset-names = "alternative-a", "alternative-b";
> > > +            pairsets = <&phys0>, <&phys1>;
> > > +          };
> > > +          pse_pi1: pse_pi@1 {
> > > +            reg = <1>;
> > > +            #pse-cells = <0>;
> > > +            pairset-names = "alternative-a";
> > > +            pairsets = <&phys2>;  
> > 
> > According to latest discussions, PSE PI nodes will need some
> > additional, board specific, information:
> > - this controller do not implements polarity switching, we need to know
> >   what polarity is implemented on this board. The 802.3 spec provide not
> >   really consistent names for polarity configurations:
> >   - Alternative A MDI-X
> >   - Alternative A MDI
> >   - Alternative B X
> >   - Alternative B S
> >   The board may implement one of polarity configurations per alternative
> >   or have additional helpers to switch them without using PSE
> >   controller.
> >   Even if specification explicitly say:
> >   "The PD shall be implemented to be insensitive to the polarity of the power
> >    supply and shall be able to operate per the PD Mode A column and the PD
> >    Mode B column in Table 33–13"
> >   it is possible to find reports like this:
> >   https://community.ui.com/questions/M5-cant-take-reversed-power-polarity-/d834d9a8-579d-4f08-80b1-623806cc5070
> > 
> >   Probably this kind of property is a good fit:
> >   polarity-supported = "MDI-X", "MDI", "X", "S";
> 
> This property should be on the PD side.

Probably. Right now we are on PSE side.

> Isn't it better to name it "polarity-provided" for each PSE PIs binding? What
> do you think?

Yes, this suggestion was directed for PSE PI nodes.

In the PHY world, we use "supported" capabilities for what HW can
actually do and "advertised" for how the HW is configured.

If we use word "provided", i would interpret it as subset of
"supported", which at the end is a user space policy.

Since I'm not native englisch speaker, my feeling can be wrong. So, any
one with stronger opinion may have here other preferences.

> We agreed that it is mainly for ethtool to show the polarity of a PI, right?

We have two kind of information here:
- polarity supported by HW. PSE PI may support more then one.
- actually configured polarity.

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 |