linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Köry 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
Date: Tue, 5 Dec 2023 14:31:23 +0100	[thread overview]
Message-ID: <20231205143123.703589c8@kmaincent-XPS-13-7390> (raw)
In-Reply-To: <20231205111501.43f80846@kmaincent-XPS-13-7390>

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

> On Tue, 5 Dec 2023 07:36:06 +0100
> Oleksij Rempel <o.rempel@pengutronix.de> wrote:
 
> > I would expect a devicetree like this:
> > 
> >         ethernet-pse@3c {
> > 	  // controller compatible should be precise
> >           compatible = "microchip,pd69210";
> >           reg = <0x3c>;
> >           #pse-cells = <1>;
> >           
> > 	  managers {
> > 	    manager@0 {
> > 	      // manager compatible should be included, since we are
> > 	      // able to campare it with communication results
> > 	      compatible = "microchip,pd69208t4"
> > 	      // addressing corresponding to the chip select addressing
> > 	      reg = <0>;
> > 
> > 	      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 = <0>;
> > 		};
> > 	        phys1: port@1 {
> > 		  reg = <1>;
> > 		};
> > 	        phys2: port@2 {
> > 		  reg = <2>;
> > 		};
> > 
> >                ...
> > 	      }
> > 
> >           // port matrix can be calculated by using this information
> >           logical-ports {
> > 	    log_port0: port@0 {
> > 	      // PoE4 port
> > 	      physical-ports = <&phys0, &phys1>;
> > 	    };
> > 	    log_port1: port@1 {
> > 	      // PoE2 port
> > 	      physical-ports = <&phys2>;
> > 	    };
> > 	  };
> > 
> > ....
> >    ethernet-phy@1 {
> >      reg = <1>;
> >      pses = <&log_port0>;
> >    }
> >    ethernet-phy@2 {
> >      reg = <2>;
> >      pses = <&log_port1>;
> >    }  

In fact if we want to really fit the PoE architecture topology we should wait
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 = "microchip,pd69210";
          reg = <0x3c>;
          #pse-cells = <1>;
          
	  managers {
	    manager@0 {
	      // manager compatible should be included, since we are
	      // able to compare it with communication results
	      compatible = "microchip,pd69208t4"
	      // addressing corresponding to the chip select addressing
	      reg = <0>;

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

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

....
  rj45_0:8p8c@0 {
    pses = <&phy_port0, &phy_port1>;
  };
  rj45_1:8p8c@1 {
    pses = <&phy_port2>;
  };
  ethernet-phy@1 {
    reg = <1>;
    connector = <&rj45_0>;
  };
  ethernet-phy@2 {
    reg = <2>;
    connector = <&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 = <1>;
     pses = <&phy_port0, &phy_port1>;
   }
   ethernet-phy@2 {
     reg = <2>;
     pses = <&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,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

  reply	other threads:[~2023-12-05 13:31 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-01 17:10 [PATCH net-next v2 0/8] net: Add support for Power over Ethernet (PoE) Kory Maincent
2023-12-01 17:10 ` [PATCH net-next v2 1/8] net: pse-pd: Rectify and adapt the naming of admin_cotrol member of struct pse_control_config Kory Maincent
2023-12-03 18:19   ` Andrew Lunn
2023-12-04 12:19   ` Oleksij Rempel
2023-12-01 17:10 ` [PATCH net-next v2 2/8] ethtool: Expand Ethernet Power Equipment with c33 (PoE) alongside PoDL Kory Maincent
2023-12-03 18:27   ` Andrew Lunn
2023-12-04 12:27   ` Oleksij Rempel
2023-12-06  2:45   ` Bagas Sanjaya
2023-12-06  8:35     ` Köry Maincent
2023-12-06  4:23   ` kernel test robot
2023-12-01 17:10 ` [PATCH net-next v2 3/8] net: pse-pd: Introduce PSE types enumeration Kory Maincent
2023-12-03 18:31   ` Andrew Lunn
2023-12-04 12:43     ` Oleksij Rempel
2023-12-03 18:38   ` Andrew Lunn
2023-12-04 14:00     ` Köry Maincent
2023-12-04 12:51   ` Oleksij Rempel
2023-12-04 13:55     ` Köry Maincent
2023-12-01 17:10 ` [PATCH net-next v2 4/8] net: ethtool: pse-pd: Expand pse commands with the PSE PoE interface Kory Maincent
2023-12-03 18:45   ` Andrew Lunn
2023-12-04 15:28     ` Köry Maincent
2023-12-04 15:29     ` Oleksij Rempel
2023-12-06  4:18   ` Bagas Sanjaya
2023-12-01 17:10 ` [PATCH net-next v2 5/8] netlink: specs: Modify pse attribute prefix Kory Maincent
2023-12-01 17:10 ` [PATCH net-next v2 6/8] netlink: specs: Expand the pse netlink command with PoE interface Kory Maincent
2023-12-01 17:10 ` [PATCH net-next v2 7/8] dt-bindings: net: pse-pd: Add bindings for PD692x0 PSE controller Kory Maincent
2023-12-04 23:08   ` Oleksij Rempel
2023-12-05  6:36     ` Oleksij Rempel
2023-12-05 10:15       ` Köry Maincent
2023-12-05 13:31         ` Köry Maincent [this message]
2023-12-05 14:21           ` Oleksij Rempel
2023-12-05 15:23             ` Köry Maincent
2023-12-08  9:06               ` Köry Maincent
2023-12-05 12:54       ` Mark Brown
2023-12-01 17:10 ` [PATCH net-next v2 8/8] net: pse-pd: Add PD692x0 PSE controller driver Kory Maincent
2023-12-03 19:34   ` Andrew Lunn
2024-01-16  9:49     ` Köry Maincent
2024-01-16 13:18       ` Andrew Lunn
2024-01-16 14:12         ` Köry Maincent
2023-12-03 21:11   ` Christophe JAILLET
2023-12-04 22:16     ` Köry Maincent
2023-12-05 18:01       ` Christophe JAILLET
2023-12-06  8:41         ` Köry Maincent
2023-12-04 22:59   ` Oleksij Rempel
2023-12-05  6:45     ` Oleksij Rempel
2023-12-05 12:55       ` Mark Brown
2023-12-05 14:02         ` Oleksij Rempel
2023-12-05 15:57           ` Mark Brown
2023-12-21 15:36             ` Köry Maincent
2023-12-21 15:43               ` Mark Brown
2023-12-21 16:10                 ` Köry Maincent
2023-12-21 16:20                   ` Mark Brown
2023-12-21 17:19                     ` Köry Maincent
2023-12-21 17:34                       ` Mark Brown
2023-12-21 17:42                     ` Oleksij Rempel
2023-12-21 18:05                       ` Mark Brown
2023-12-22  7:54                         ` Oleksij Rempel
2023-12-05 21:35   ` kernel test robot

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=20231205143123.703589c8@kmaincent-XPS-13-7390 \
    --to=kory.maincent@bootlin.com \
    --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=gregkh@linuxfoundation.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=rafael@kernel.org \
    --cc=robh+dt@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).