From: Oleksij Rempel <o.rempel@pengutronix.de>
To: "Köry Maincent" <kory.maincent@bootlin.com>
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 15:21:47 +0100 [thread overview]
Message-ID: <20231205142147.GL981228@pengutronix.de> (raw)
In-Reply-To: <20231205143123.703589c8@kmaincent-XPS-13-7390>
On Tue, Dec 05, 2023 at 02:31:23PM +0100, Köry Maincent wrote:
> 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!
Why?
> A 8P8C node should be the consumer.
PHY is not actual consumer of this regulator. State of the Ethernet PHY
is not related to the power supply. We should deliver power independent
of network interface state. There is no other local consumer we can
use in this case.
> > > 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?
In case different PSE suppliers are linked withing the PHY node, we
loose most of information needed for PSE functionality. For example how
we will know if our log_port supports PoE4 and PoE2 mode, or only PoE2.
This information is vital for proper PSE configuration, this is why I
suggested to have logica-ports subnodes. With the price of hawing huge
DT on a switch with 48 ports.
--
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 |
next prev parent reply other threads:[~2023-12-05 14:22 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
2023-12-05 14:21 ` Oleksij Rempel [this message]
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=20231205142147.GL981228@pengutronix.de \
--to=o.rempel@pengutronix.de \
--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=kory.maincent@bootlin.com \
--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=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).