[net-next,v2,7/8] dt-bindings: net: pse-pd: Add bindings for PD692x0 PSE controller
Message ID | 20231201-feature_poe-v2-7-56d8cac607fa@bootlin.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp1278897vqy; Fri, 1 Dec 2023 09:12:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IF11brzGlmljktNXtF/uDTVBaIFZ0FHBT9dSIrpbxWGw7tYfJeXQKhMLxzayylWYE84yw5l X-Received: by 2002:a17:90b:1bcf:b0:286:568e:a47c with SMTP id oa15-20020a17090b1bcf00b00286568ea47cmr2783312pjb.33.1701450750625; Fri, 01 Dec 2023 09:12:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701450750; cv=none; d=google.com; s=arc-20160816; b=tzPny+ElTt7OfO3SJhDhZmr3owH2VQqTTfBNszqWPtIeXB66I3mi4egrUMztE+fU0m pMXm3zb+mUrXKewsKzrJYsXKEOCr5KJQcAPf3NpaT4W5X6HEQCQaxYJ8CrF6qOIgSe1X UtgPc/PUN2cm/29x2AtCkuWN0zX9xM7tTbkMJPpJLZVyEaKqPUVP80wSZA9ZC7Sq8adE rLMlEBTk+gTGlSS+Y9pFcxoRWcGrQxhd6dvVmN/Smyv06HEhoFx1C20Hi+r3xkHLcgMk BG2PRTQoVBQj6dW3G7nF3Q5Ldg5R2I6GfMiFugQ78g8H1XjKnrAjEk0/Vv80a86y4Pcu Adzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=mgST0hNKe0qhK9lhbpBpeQds2KVouuGglu1+ZMwu2Pg=; fh=/uDJtwnpikhDHchW+BU5DaWKtgJ2QqyhTe++6ujbTY0=; b=vTUoM7bmBKcA0eczSH/8iKOlaCRXKdbv8izAAyuEzDfK9nTpKTG0PKY2qZb5r6w+qQ nTWGtOgASw3pfXp8UEnIH0jdVgvD6vg0QymoGvaG0Whmp4xNA8YBuY0Ni/sm5393KAqW gGNgRtahmRbRp17Pd2y6zFywMxffkPqMfAggLQfk2s+2O+BgkzboZBSXrEveM230Ycvv u8d4e50+zQqc5yVUIpOe8SkGWiuljCQYEleYoXTUJiIGHukJEcD8IDF5QhGGeSgnooNh aptM7255gSLOce0DFsqzVkT+exhOBJg8o4P0fS5omovglyPZYvMZcfik16UN94/ZRe7u ap0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=PcRuZpaD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id t15-20020a17090340cf00b001c566ea86eesi3780875pld.177.2023.12.01.09.12.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Dec 2023 09:12:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=PcRuZpaD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id C019281A2073; Fri, 1 Dec 2023 09:12:26 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378886AbjLARL7 (ORCPT <rfc822;ruipengqi7@gmail.com> + 99 others); Fri, 1 Dec 2023 12:11:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33408 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230036AbjLARLi (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 1 Dec 2023 12:11:38 -0500 Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::221]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1536910D; Fri, 1 Dec 2023 09:11:43 -0800 (PST) Received: by mail.gandi.net (Postfix) with ESMTPSA id CE268240008; Fri, 1 Dec 2023 17:11:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1701450702; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mgST0hNKe0qhK9lhbpBpeQds2KVouuGglu1+ZMwu2Pg=; b=PcRuZpaDBqQ/uKhC8W6E3uhr+qrHjuhhKJFAbrdLiLxicIqA7r0Mle5lps7vXD7+mgVBsE 778xp+Zdc8gGMff6Qm+WkyDVD7FXJ4yn0DhxpTb568r/V27aeesQLxq0Cp5U5IhnahW4QU 2swnmysuVvmE93wYHD76AmseuVWGilMLuO7Hr8vqvUwmcdSQKooORIYN70Y9Lncl7/Whj2 6S9zvoBw8i/NWsR8+p/Ok50i8QMh4hmKgAiV18ZuyVTqRUmy9RBf3wgja8UlomyLaETuei FnYU0bp/kAvtUtoy/mO4+lTu9273t1h2bvKQpxbHLQgZYXj5qjnX793NlOZZ3w== From: Kory Maincent <kory.maincent@bootlin.com> Date: Fri, 01 Dec 2023 18:10:29 +0100 Subject: [PATCH net-next v2 7/8] dt-bindings: net: pse-pd: Add bindings for PD692x0 PSE controller MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20231201-feature_poe-v2-7-56d8cac607fa@bootlin.com> References: <20231201-feature_poe-v2-0-56d8cac607fa@bootlin.com> In-Reply-To: <20231201-feature_poe-v2-0-56d8cac607fa@bootlin.com> To: "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>, Oleksij Rempel <o.rempel@pengutronix.de> Cc: 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>, Kory Maincent <kory.maincent@bootlin.com> X-Mailer: b4 0.12.4 X-GND-Sasl: kory.maincent@bootlin.com X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Fri, 01 Dec 2023 09:12:26 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784100422592970185 X-GMAIL-MSGID: 1784100422592970185 |
Series |
net: Add support for Power over Ethernet (PoE)
|
|
Commit Message
Köry Maincent
Dec. 1, 2023, 5:10 p.m. UTC
Add the PD692x0 I2C Power Sourcing Equipment controller device tree
bindings documentation.
Sponsored-by: Dent Project <dentproject@linuxfoundation.org>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Changes in v2:
- Enhance ports-matrix description.
- Replace additionalProperties by unevaluatedProperties.
- Drop i2c suffix.
---
.../bindings/net/pse-pd/microchip,pd692x0.yaml | 77 ++++++++++++++++++++++
MAINTAINERS | 6 ++
2 files changed, 83 insertions(+)
Comments
On Fri, Dec 01, 2023 at 06:10:29PM +0100, Kory Maincent wrote: > Add the PD692x0 I2C Power Sourcing Equipment controller device tree > bindings documentation. > > Sponsored-by: Dent Project <dentproject@linuxfoundation.org> > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> > --- > > Changes in v2: > - Enhance ports-matrix description. > - Replace additionalProperties by unevaluatedProperties. > - Drop i2c suffix. > --- > .../bindings/net/pse-pd/microchip,pd692x0.yaml | 77 ++++++++++++++++++++++ > MAINTAINERS | 6 ++ > 2 files changed, 83 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml > new file mode 100644 > index 000000000000..3ce81cf99215 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml > @@ -0,0 +1,77 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/net/pse-pd/microchip,pd692x0.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Microchip PD692x0 Power Sourcing Equipment controller > + > +maintainers: > + - Kory Maincent <kory.maincent@bootlin.com> > + > +allOf: > + - $ref: pse-controller.yaml# > + > +properties: > + compatible: > + enum: > + - microchip,pd69200 > + - microchip,pd69210 > + - microchip,pd69220 > + > + reg: > + maxItems: 1 > + > + '#pse-cells': > + const: 1 > + > + ports-matrix: > + description: each set of 48 logical ports can be assigned to one or two > + physical ports. Each physical port is wired to a PD69204/8 PoE > + manager. Using two different PoE managers for one RJ45 port > + (logical port) is interesting for temperature dissipation. > + This parameter describes the configuration of the port conversion > + matrix that establishes the relationship between the 48 logical ports > + and the available 96 physical ports. Unspecified logical ports will > + be deactivated. > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > + minItems: 1 > + maxItems: 48 > + items: > + items: > + - description: Logical port number > + minimum: 0 > + maximum: 47 > + - description: Physical port number A (0xff for undefined) > + oneOf: > + - minimum: 0 > + maximum: 95 > + - const: 0xff > + - description: Physical port number B (0xff for undefined) > + oneOf: > + - minimum: 0 > + maximum: 95 > + - const: 0xff > + > +unevaluatedProperties: false > + > +required: > + - compatible > + - reg > + > +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. > + }; > + }; > diff --git a/MAINTAINERS b/MAINTAINERS > index e3fd148d462e..b746684f3fd3 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -14235,6 +14235,12 @@ L: linux-serial@vger.kernel.org > S: Maintained > F: drivers/tty/serial/8250/8250_pci1xxxx.c > > +MICROCHIP PD692X0 PSE DRIVER > +M: Kory Maincent <kory.maincent@bootlin.com> > +L: netdev@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml > + > MICROCHIP POLARFIRE FPGA DRIVERS > M: Conor Dooley <conor.dooley@microchip.com> > R: Vladimir Georgiev <v.georgiev@metrotek.ru> > > -- > 2.25.1 > > >
CC regulator devs here. PSE is a regulator for network devices :) On Tue, Dec 05, 2023 at 12:08:45AM +0100, Oleksij Rempel wrote: > On Fri, Dec 01, 2023 at 06:10:29PM +0100, Kory Maincent wrote: > > Add the PD692x0 I2C Power Sourcing Equipment controller device tree > > bindings documentation. > > > > Sponsored-by: Dent Project <dentproject@linuxfoundation.org> > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> > > --- > > > > Changes in v2: > > - Enhance ports-matrix description. > > - Replace additionalProperties by unevaluatedProperties. > > - Drop i2c suffix. > > --- > > .../bindings/net/pse-pd/microchip,pd692x0.yaml | 77 ++++++++++++++++++++++ > > MAINTAINERS | 6 ++ > > 2 files changed, 83 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml > > new file mode 100644 > > index 000000000000..3ce81cf99215 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml > > @@ -0,0 +1,77 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/net/pse-pd/microchip,pd692x0.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Microchip PD692x0 Power Sourcing Equipment controller > > + > > +maintainers: > > + - Kory Maincent <kory.maincent@bootlin.com> > > + > > +allOf: > > + - $ref: pse-controller.yaml# > > + > > +properties: > > + compatible: > > + enum: > > + - microchip,pd69200 > > + - microchip,pd69210 > > + - microchip,pd69220 > > + > > + reg: > > + maxItems: 1 > > + > > + '#pse-cells': > > + const: 1 > > + > > + ports-matrix: > > + description: each set of 48 logical ports can be assigned to one or two > > + physical ports. Each physical port is wired to a PD69204/8 PoE > > + manager. Using two different PoE managers for one RJ45 port > > + (logical port) is interesting for temperature dissipation. > > + This parameter describes the configuration of the port conversion > > + matrix that establishes the relationship between the 48 logical ports > > + and the available 96 physical ports. Unspecified logical ports will > > + be deactivated. > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > > + minItems: 1 > > + maxItems: 48 > > + items: > > + items: > > + - description: Logical port number > > + minimum: 0 > > + maximum: 47 > > + - description: Physical port number A (0xff for undefined) > > + oneOf: > > + - minimum: 0 > > + maximum: 95 > > + - const: 0xff > > + - description: Physical port number B (0xff for undefined) > > + oneOf: > > + - minimum: 0 > > + maximum: 95 > > + - const: 0xff > > + > > +unevaluatedProperties: false > > + > > +required: > > + - compatible > > + - reg > > + > > +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. 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 :) 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>; }
On Tue, 5 Dec 2023 07:36:06 +0100 Oleksij Rempel <o.rempel@pengutronix.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,
On Tue, Dec 05, 2023 at 07:36:06AM +0100, Oleksij Rempel wrote:
> CC regulator devs here. PSE is a regulator for network devices :)
Is there some question related to regulators here? I couldn't spot one.
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,
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.
On Tue, 5 Dec 2023 15:21:47 +0100 Oleksij Rempel <o.rempel@pengutronix.de> wrote: > 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. Just to be clear, are you saying we should use the regulator framework or is it simply a way of speaking as it behaves like regulator? > > 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. It could be known in the of_pse_control_get() function if there is two phandles in the "pses" parameter. Then we add a new enum c33_pse_mode member in the pse_control struct to store the mode. PoE2 and PoE4 is not a parameter of the logical port, it depends of the number of PSE ports wired to an 8P8C connector. In fact I am also working on the tps23881 driver which aimed to be added to this series soon. In the tps23881 case the logical port can only be configured to one physical port. Two physical ports (which mean two logical ports) can still be used to have PoE4 mode. For PoE4, in the pd692x0 driver we use one logical port (one pse_control->id) configured to two physical ports but in the tps23881 we will need two logical ports (two pse_control->id). So with the tps23881 driver we will need two phandle in the "pses" parameter to have PoE4, that's why my proposition seems relevant. The same goes with your pse-regulator driver, you can't do PoE4 if two regulators is needed for each two pairs group. Regards,
On Tue, 5 Dec 2023 16:23:21 +0100 Köry Maincent <kory.maincent@bootlin.com> wrote: > On Tue, 5 Dec 2023 15:21:47 +0100 > Oleksij Rempel <o.rempel@pengutronix.de> wrote: > > > 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. > > Just to be clear, are you saying we should use the regulator framework or is > it simply a way of speaking as it behaves like regulator? > > > > 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. > > It could be known in the of_pse_control_get() function if there is two > phandles in the "pses" parameter. Then we add a new enum c33_pse_mode member > in the pse_control struct to store the mode. > PoE2 and PoE4 is not a parameter of the logical port, it depends of the number > of PSE ports wired to an 8P8C connector. > > In fact I am also working on the tps23881 driver which aimed to be added to > this series soon. In the tps23881 case the logical port can only be configured > to one physical port. Two physical ports (which mean two logical ports) can > still be used to have PoE4 mode. > For PoE4, in the pd692x0 driver we use one logical port (one pse_control->id) > configured to two physical ports but in the tps23881 we will need two logical > ports (two pse_control->id). > > So with the tps23881 driver we will need two phandle in the "pses" parameter > to have PoE4, that's why my proposition seems relevant. > > The same goes with your pse-regulator driver, you can't do PoE4 if two > regulators is needed for each two pairs group. Oleksij, what your thought for the binding I have proposed in the thread. For the PoE4 we could add a "pses-poe4" bool property alongside the two phandle in "pses" property. Here is the current binding proposition: 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 { ... }; }; }; .... ethernet-phy@1 { reg = <1>; pses-poe4; pses = <&phy_port0, &phy_port1>; }; ethernet-phy@2 { reg = <2>; pses = <&phy_port2>; } Regards,
diff --git a/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml new file mode 100644 index 000000000000..3ce81cf99215 --- /dev/null +++ b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/pse-pd/microchip,pd692x0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip PD692x0 Power Sourcing Equipment controller + +maintainers: + - Kory Maincent <kory.maincent@bootlin.com> + +allOf: + - $ref: pse-controller.yaml# + +properties: + compatible: + enum: + - microchip,pd69200 + - microchip,pd69210 + - microchip,pd69220 + + reg: + maxItems: 1 + + '#pse-cells': + const: 1 + + ports-matrix: + description: each set of 48 logical ports can be assigned to one or two + physical ports. Each physical port is wired to a PD69204/8 PoE + manager. Using two different PoE managers for one RJ45 port + (logical port) is interesting for temperature dissipation. + This parameter describes the configuration of the port conversion + matrix that establishes the relationship between the 48 logical ports + and the available 96 physical ports. Unspecified logical ports will + be deactivated. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + minItems: 1 + maxItems: 48 + items: + items: + - description: Logical port number + minimum: 0 + maximum: 47 + - description: Physical port number A (0xff for undefined) + oneOf: + - minimum: 0 + maximum: 95 + - const: 0xff + - description: Physical port number B (0xff for undefined) + oneOf: + - minimum: 0 + maximum: 95 + - const: 0xff + +unevaluatedProperties: false + +required: + - compatible + - reg + +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>; + }; + }; diff --git a/MAINTAINERS b/MAINTAINERS index e3fd148d462e..b746684f3fd3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14235,6 +14235,12 @@ L: linux-serial@vger.kernel.org S: Maintained F: drivers/tty/serial/8250/8250_pci1xxxx.c +MICROCHIP PD692X0 PSE DRIVER +M: Kory Maincent <kory.maincent@bootlin.com> +L: netdev@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml + MICROCHIP POLARFIRE FPGA DRIVERS M: Conor Dooley <conor.dooley@microchip.com> R: Vladimir Georgiev <v.georgiev@metrotek.ru>