Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Date:   Tue, 5 Dec 2023 14:31:23 +0100
From:   =?UTF-8?B?S8O2cnk=?= Maincent <kory.maincent@bootlin.com>
To:     Oleksij Rempel <o.rempel@pengutronix.de>
Cc:     "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>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        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>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH net-next v2 7/8] dt-bindings: net: pse-pd: Add bindings
 for PD692x0 PSE controller
Message-ID: <20231205143123.703589c8@kmaincent-XPS-13-7390>
In-Reply-To: <20231205111501.43f80846@kmaincent-XPS-13-7390>
References: <20231201-feature_poe-v2-0-56d8cac607fa@bootlin.com>
 <20231201-feature_poe-v2-7-56d8cac607fa@bootlin.com>
 <20231204230845.GH981228@pengutronix.de>
 <20231205063606.GI981228@pengutronix.de>
 <20231205111501.43f80846@kmaincent-XPS-13-7390>
Organization: bootlin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, 5 Dec 2023 11:15:01 +0100
K=C3=B6ry Maincent <kory.maincent@bootlin.com> wrote:

> On Tue, 5 Dec 2023 07:36:06 +0100
> Oleksij Rempel <o.rempel@pengutronix.de> wrote:
=20
> > I would expect a devicetree like this:
> >=20
> >         ethernet-pse@3c {
> > 	  // controller compatible should be precise
> >           compatible =3D "microchip,pd69210";
> >           reg =3D <0x3c>;
> >           #pse-cells =3D <1>;
> >          =20
> > 	  managers {
> > 	    manager@0 {
> > 	      // manager compatible should be included, since we are
> > 	      // able to campare it with communication results
> > 	      compatible =3D "microchip,pd69208t4"
> > 	      // addressing corresponding to the chip select addressing
> > 	      reg =3D <0>;
> >=20
> > 	      physical-ports {
> > 	        phys0: port@0 {
> > 		  // each of physical ports is actually a regulator

If this phys0 is a regulator, which device will be the consumer of this
regulator? log_port0 as the phys0 regulator consumer seems a bit odd!
A 8P8C node should be the consumer.

> > 		  reg =3D <0>;
> > 		};
> > 	        phys1: port@1 {
> > 		  reg =3D <1>;
> > 		};
> > 	        phys2: port@2 {
> > 		  reg =3D <2>;
> > 		};
> >=20
> >                ...
> > 	      }
> >=20
> >           // port matrix can be calculated by using this information
> >           logical-ports {
> > 	    log_port0: port@0 {
> > 	      // PoE4 port
> > 	      physical-ports =3D <&phys0, &phys1>;
> > 	    };
> > 	    log_port1: port@1 {
> > 	      // PoE2 port
> > 	      physical-ports =3D <&phys2>;
> > 	    };
> > 	  };
> >=20
> > ....
> >    ethernet-phy@1 {
> >      reg =3D <1>;
> >      pses =3D <&log_port0>;
> >    }
> >    ethernet-phy@2 {
> >      reg =3D <2>;
> >      pses =3D <&log_port1>;
> >    } =20

In fact if we want to really fit the PoE architecture topology we should wa=
it
for the support of 8P8C connector from Maxime. Then it will look like that:
SoC  --- i2c/uart --> controller -- spi --> manager0 -- phys_port0 --> 8P8C=
_connector0 (PoE4)
                                         |           \- phys_port1 --> 8P8C=
_connector0 (PoE4)
					 |	     \- phys_port2 --> 8P8C_connector1 (PoE2)
					 |	     \- phys_port3 --> 8P8C_connector2 (PoE2)
                                         \- manager1 -- phys_port0 ..

With this type of devicetree:
        ethernet-pse@3c {
	  // controller compatible should be precise
          compatible =3D "microchip,pd69210";
          reg =3D <0x3c>;
          #pse-cells =3D <1>;
         =20
	  managers {
	    manager@0 {
	      // manager compatible should be included, since we are
	      // able to compare it with communication results
	      compatible =3D "microchip,pd69208t4"
	      // addressing corresponding to the chip select addressing
	      reg =3D <0>;

	      physical-ports {
	        phys_port0: port@0 {
		  // each of physical ports is actually a regulator
		  reg =3D <0>;
		};
	        phy_port1: port@1 {
		  reg =3D <1>;
		};
	        phy_port2: port@2 {
		  reg =3D <2>;
		};

               ...
	      }
	    manager@1 {
            ...
            };
          };
	};

....
  rj45_0:8p8c@0 {
    pses =3D <&phy_port0, &phy_port1>;
  };
  rj45_1:8p8c@1 {
    pses =3D <&phy_port2>;
  };
  ethernet-phy@1 {
    reg =3D <1>;
    connector =3D <&rj45_0>;
  };
  ethernet-phy@2 {
    reg =3D <2>;
    connector =3D <&rj45_1>;
  }


The drawback is that I don't really know for now, how port matrix can be
calculated with this. Maybe by adding a "conf_pse_cell()" callback, call
in the of_pse_control_get() for each ports.

For now 8p8c connector are not supported, we could keep using pse phandle
in the phy node like you described but for physical port:
   ethernet-phy@1 {
     reg =3D <1>;
     pses =3D <&phy_port0, &phy_port1>;
   }
   ethernet-phy@2 {
     reg =3D <2>;
     pses =3D <&phy_port2>;
   }


Finally, the devicetree would not know the matrix between logical port and
physical port, this would be cleaner.

Did I miss something?

Regards,
--=20
K=C3=B6ry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com