[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231205111501.43f80846@kmaincent-XPS-13-7390>
Date: Tue, 5 Dec 2023 11:15:01 +0100
From: Köry Maincent <kory.maincent@...tlin.com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
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>,
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>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH net-next v2 7/8] dt-bindings: net: pse-pd: Add bindings
for PD692x0 PSE controller
On Tue, 5 Dec 2023 07:36:06 +0100
Oleksij Rempel <o.rempel@...gutronix.de> wrote:
> > > +examples:
> > > + - |
> > > + i2c {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + ethernet-pse@3c {
> > > + compatible = "microchip,pd69200";
> > > + reg = <0x3c>;
> > > + #pse-cells = <1>;
> > > + ports-matrix = <0 2 5
> > > + 1 3 6
> > > + 2 0 0xff
> > > + 3 1 0xff>;
> >
> > Hm... this will probably not scale. PSE is kind of PMIC for ethernet. I
> > has bunch of regulators which can be grouped to one more powerful
> > regulator. Since it is regulators, we will wont to represent them in a
> > system as regulators too. We will probably have physical, board
> > specific limitation, so we will need to describe regulator limits for
> > each separate channel.
>
> After diving a bit deeper to the chip manual and communication protocol
> manual I would recommend to recreate system topology as good as possible
> in the devicetree. The reason is that we actually able to communicate
> with with "manager" behind the "controller" and the "port-matrix" is all
> about the "managers" and physical ports layout.
Ok, but the "managers communication" implementation will be added later as
for now only the basics of the the PSE controller is implemented.
> Typical system architecture looks like this:
>
> SoC --- i2c/uart --> controller -- spi --> manager0 -- phys_port0 -->
> log_port0 (PoE4) | \- phys_port1 -/
> | \- phys_port2 -->
> log_port1 (PoE2) | \- phys_port3 --> log_port2 (PoE2)
> \- manager1 -- phys_port0 ..
> ....
>
> Please include some ASCII topology to the documentation :)
Ok.
> 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
> 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>;
> }
The pse node will become massive (more than 140 subnodes) but indeed this will
fit the real topology architecture.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Powered by blists - more mailing lists