[net-next,v4,14/17] dt-bindings: net: pse-pd: Add bindings for PD692x0 PSE controller
Message ID | 20240215-feature_poe-v4-14-35bb4c23266c@bootlin.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-67274-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:b825:b0:106:860b:bbdd with SMTP id da37csp504222dyb; Thu, 15 Feb 2024 08:10:32 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVfpELMbOrGhZy37hYzvKYcoMmlVxViQfmWHG1u89PZBCUa8NRUIh4w+z738O+/sVsUdjFg1/7lM0BTlSw94rmEqcKltQ== X-Google-Smtp-Source: AGHT+IGm8uehMr5Bv4yynQylY3ZKVpTP7maj55nw0aQimpuNi2pItgHKID2oZNIv0fJS7jsw7hbg X-Received: by 2002:a19:385a:0:b0:511:7a72:6524 with SMTP id d26-20020a19385a000000b005117a726524mr1447217lfj.15.1708013432381; Thu, 15 Feb 2024 08:10:32 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708013432; cv=pass; d=google.com; s=arc-20160816; b=ZoR1cF6wT6VUVnR5RlsE6eXoMP+7dNulTXZFogxXVTgwxT/JignBFYYrIWKZPhBkAR nIhX/OqJ9qZyVadZaCrpyZeXQMDC0CxcKK+SvuRBzvx1xj6+cFSgelcqL+tNQmcA4+0F Gs9i4H+VHR9qFPe3c0w9ZgXydLAAc2h4AuNyfkb/JUgX/eOIbp7Pas6Rks+mT+2r8Ho8 olxEIMb/HZP7wmwjEVRhP8WS6SnAsylDO8VctiuZEupeLfhG5O3oXYPamjbHEcQaL6QG q8rd9FSxvttMAQpP/wChychO3FDSV3RBkJwFIl4IX+3jenFZwMvqIweXiDBkK1xLzLwQ rSRA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :subject:date:from:dkim-signature; bh=NHfOXmGaUCWGvL2tmiJ7L4fx51c194weRPAzEE++XMs=; fh=7S+YztZcCxZKIOm2mMOwIzm96FjMcKQ7LjGMKaNLlnQ=; b=Eep1jX90tR53vAhbVKserfVa9IvKOwXyWFSImH0IFYuSFTfFjdJ5QG7HzzMQn6xXgI iva3W+YJB0qJoVRmQwoKpcQB/JKkuGW7N2Ms5EbzPHsaMpz+j0pwU3GHuRVBft8TVXwR 0cUPZbyOkXP50GpAMfoJXqp5zzsU78xmeH93Tl9dmtxH5ZC1vY618XuTlu64z5WziStu XCpcRiGgWvh4hUT6E0un3D/AOlu16GAkBbSnuw5aQZIAi4Fd1bgzlg8hqLmR0seYLaub JdAyc8827LfSOEvbZbYXLHi9M71L61ZC6VMuy2Ep6/rV7NpN1VfEK6tNkXMZNasvDnas vMcg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=T7feUJSj; arc=pass (i=1 spf=pass spfdomain=bootlin.com dkim=pass dkdomain=bootlin.com dmarc=pass fromdomain=bootlin.com); spf=pass (google.com: domain of linux-kernel+bounces-67274-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-67274-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id b25-20020a170906039900b00a3d1e75ce59si784188eja.218.2024.02.15.08.10.32 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 08:10:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-67274-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=T7feUJSj; arc=pass (i=1 spf=pass spfdomain=bootlin.com dkim=pass dkdomain=bootlin.com dmarc=pass fromdomain=bootlin.com); spf=pass (google.com: domain of linux-kernel+bounces-67274-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-67274-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id CC2D91F2C466 for <ouuuleilei@gmail.com>; Thu, 15 Feb 2024 16:10:31 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C9EFD13DB8A; Thu, 15 Feb 2024 16:03:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="T7feUJSj" Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2697513A882; Thu, 15 Feb 2024 16:03:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.200 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708013022; cv=none; b=r63QWj/cq8SIyo52J7PZBm2qRBqtzDuPI3K19c6Re0zs8wa2imMZze+w5iAT1GlnGXJxS8wO8R2fJaN78Zx6XhAIOkLaa4e+yCazpsU9ShI3yjZhGhyHJwrgqcHU7yKlvyAKwmmiceRIxDxVfg7ose/9IA9Dh2bXMpzPcDdj3zE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708013022; c=relaxed/simple; bh=Jzpc1GKKoqjXi9b6bn2FrwbTlzztHUETCpzTsZPNZBY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=P3UBZGs4Su8kGWTUoS0e8ETuNGtBU5OWGRuAnT2xchrQPA5dgQKF0aIsOtUMjhBPLPQ0Ak/VQEWtFIniMXhxeZwbTdd49/p3ebv1P8/8s/7w0Kx2HfdNQCphMz0Itwv2lRPV1pjZ9nMi83hHZeKwOBfP+KhyCMM2lDUARWkyBlY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=T7feUJSj; arc=none smtp.client-ip=217.70.183.200 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id 5321920012; Thu, 15 Feb 2024 16:03:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1708013018; 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=NHfOXmGaUCWGvL2tmiJ7L4fx51c194weRPAzEE++XMs=; b=T7feUJSjQB2S3OypsCjoQf14hxPed/lww184A28E/zZk5ZHdvRIthgak1+/gmzfjKF32H9 iO5PF+2L+1Mf+jQ0yTAtoQJgIze9Xmv14JEkMwckkHjdd6l9QxXypCj2pcEQ1khgcvV3wq xlOQWQ7kKCHYidStI1kSTrPbHue+FgdK2vrIGUlAqtP8cXj5A4SylCTSJvi9iVfDBsTUBq ica3U9eodnTDa/DVCU3s89nka+qPStDUnm3Ih9rWZrb6eS3+cXXfz8QtWMRWEHsb0zMNIV 4mc1+V8X1gaPcm6D6myZANCfEQoXlH5V+7S3rhEa+vqcKq5oo3gJle3FKEISHw== From: Kory Maincent <kory.maincent@bootlin.com> Date: Thu, 15 Feb 2024 17:02:55 +0100 Subject: [PATCH net-next v4 14/17] dt-bindings: net: pse-pd: Add bindings for PD692x0 PSE controller Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240215-feature_poe-v4-14-35bb4c23266c@bootlin.com> References: <20240215-feature_poe-v4-0-35bb4c23266c@bootlin.com> In-Reply-To: <20240215-feature_poe-v4-0-35bb4c23266c@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>, Mark Brown <broonie@kernel.org>, Frank Rowand <frowand.list@gmail.com>, Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>, Russell King <linux@armlinux.org.uk> 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-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790981893139568896 X-GMAIL-MSGID: 1790981893139568896 |
Series |
net: Add support for Power over Ethernet (PoE)
|
|
Commit Message
Köry Maincent
Feb. 15, 2024, 4:02 p.m. UTC
Add the PD692x0 I2C Power Sourcing Equipment controller device tree
bindings documentation.
This patch is 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.
Changes in v3:
- Remove ports-matrix parameter.
- Add description of all physical ports and managers.
- Add pse_pis subnode moving to the API of pse-controller binding.
- Remove the MAINTAINERS section for this driver as I will be maintaining
all pse-pd subsystem.
---
.../bindings/net/pse-pd/microchip,pd692x0.yaml | 157 +++++++++++++++++++++
1 file changed, 157 insertions(+)
Comments
On Thu, Feb 15, 2024 at 05:02:55PM +0100, Kory Maincent wrote: > Add the PD692x0 I2C Power Sourcing Equipment controller device tree > bindings documentation. > > This patch is sponsored by Dent Project <dentproject@linuxfoundation.org>. > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> > --- .. > + pse_pis { > + #address-cells = <1>; > + #size-cells = <0>; > + > + pse_pi0: pse_pi@0 { > + reg = <0>; > + #pse-cells = <0>; > + pairset-names = "alternative-a", "alternative-b"; > + pairsets = <&phys0>, <&phys1>; > + }; > + pse_pi1: pse_pi@1 { > + reg = <1>; > + #pse-cells = <0>; > + pairset-names = "alternative-a"; > + pairsets = <&phys2>; According to latest discussions, PSE PI nodes will need some additional, board specific, information: - this controller do not implements polarity switching, we need to know what polarity is implemented on this board. The 802.3 spec provide not really consistent names for polarity configurations: - Alternative A MDI-X - Alternative A MDI - Alternative B X - Alternative B S The board may implement one of polarity configurations per alternative or have additional helpers to switch them without using PSE controller. Even if specification explicitly say: "The PD shall be implemented to be insensitive to the polarity of the power supply and shall be able to operate per the PD Mode A column and the PD Mode B column in Table 33–13" it is possible to find reports like this: https://community.ui.com/questions/M5-cant-take-reversed-power-polarity-/d834d9a8-579d-4f08-80b1-623806cc5070 Probably this kind of property is a good fit: polarity-supported = "MDI-X", "MDI", "X", "S"; - Except of polarity, we have alternative-b variant with direct or phantom feeding (No idea if it is proper description). Theoretically, this difference would affect electrical rating specifications. For example direct path for alternate-b (10/100Mbit only), would have higher rating as the path over coils/magnetics. Practically, vendors do not make different ratings for this paths, so no need to care about it for now until someone will be able to provide good reason. Here is example of RJ45 connector with integrated magnetics with PoE support where alternative-a feed over magnetics and alternative-b is feed directly: https://www.te.com/commerce/DocumentDelivery/DDEController?Action=srchrtrv&DocNm=5-2337992-4&DocType=Customer+Drawing&DocLang=English&PartCntxt=5-2337992-4&DocFormat=pdf (the last topic is more an answer to my self and for archive :))
On 15/02/2024 17:02, Kory Maincent wrote: > Add the PD692x0 I2C Power Sourcing Equipment controller device tree > bindings documentation. > > This patch is 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. > > Changes in v3: > - Remove ports-matrix parameter. > - Add description of all physical ports and managers. > - Add pse_pis subnode moving to the API of pse-controller binding. > - Remove the MAINTAINERS section for this driver as I will be maintaining > all pse-pd subsystem. > --- > .../bindings/net/pse-pd/microchip,pd692x0.yaml | 157 +++++++++++++++++++++ > 1 file changed, 157 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..57ba5365157c > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml > @@ -0,0 +1,157 @@ > +# 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 > + > + managers: > + $ref: "#/$defs/managers" > + description: > + List of the PD69208T4/PD69204T4/PD69208M PSE managers. Each manager > + have 4 or 8 physical ports according to the chip version. No need to > + specify the SPI chip select as it is automatically detected by the > + PD692x0 PSE controller. The PSE managers have to be described from > + the lowest chip select to the greatest one, which is the detection > + behavior of the PD692x0 PSE controller. The PD692x0 support up to > + 12 PSE managers which can expose up to 96 physical ports. All > + physical ports available on a manager have to be described in the > + incremental order even if they are not used. > + > +required: > + - compatible > + - reg > + - pse_pis > + > +$defs: Why do you need defs for it? You use it only in one place. .. > + > + pse_pis { Again... no underscores in node names. > + #address-cells = <1>; > + #size-cells = <0>; > + > + pse_pi0: pse_pi@0 { Just compile your DTS with W=2. Best regards, Krzysztof
On Sat, 17 Feb 2024 13:14:29 +0100 Oleksij Rempel <o.rempel@pengutronix.de> wrote: > On Thu, Feb 15, 2024 at 05:02:55PM +0100, Kory Maincent wrote: > > Add the PD692x0 I2C Power Sourcing Equipment controller device tree > > bindings documentation. > > > > This patch is sponsored by Dent Project <dentproject@linuxfoundation.org>. > > > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> > > --- > ... > > + pse_pis { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + pse_pi0: pse_pi@0 { > > + reg = <0>; > > + #pse-cells = <0>; > > + pairset-names = "alternative-a", "alternative-b"; > > + pairsets = <&phys0>, <&phys1>; > > + }; > > + pse_pi1: pse_pi@1 { > > + reg = <1>; > > + #pse-cells = <0>; > > + pairset-names = "alternative-a"; > > + pairsets = <&phys2>; > > According to latest discussions, PSE PI nodes will need some > additional, board specific, information: > - this controller do not implements polarity switching, we need to know > what polarity is implemented on this board. The 802.3 spec provide not > really consistent names for polarity configurations: > - Alternative A MDI-X > - Alternative A MDI > - Alternative B X > - Alternative B S > The board may implement one of polarity configurations per alternative > or have additional helpers to switch them without using PSE > controller. > Even if specification explicitly say: > "The PD shall be implemented to be insensitive to the polarity of the power > supply and shall be able to operate per the PD Mode A column and the PD > Mode B column in Table 33–13" > it is possible to find reports like this: > https://community.ui.com/questions/M5-cant-take-reversed-power-polarity-/d834d9a8-579d-4f08-80b1-623806cc5070 Mmh not sure we want to support broken cases that does not follow the spec. Should we? Regards,
> Mmh not sure we want to support broken cases that does not follow the spec. > Should we? We should specify the properties a device following the spec should use. These are the common properties we expect all devices should be using. Broken devices can however have additional properties, defined in their own binding. And if we see a pattern for broken properties, we could pull them out into a -broken.yaml binding, which the broken devices could share. Andrew
On Sat, 17 Feb 2024 13:14:29 +0100 Oleksij Rempel <o.rempel@pengutronix.de> wrote: > On Thu, Feb 15, 2024 at 05:02:55PM +0100, Kory Maincent wrote: > > Add the PD692x0 I2C Power Sourcing Equipment controller device tree > > bindings documentation. > > > > This patch is sponsored by Dent Project <dentproject@linuxfoundation.org>. > > > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> > > --- > ... > > + pse_pis { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + pse_pi0: pse_pi@0 { > > + reg = <0>; > > + #pse-cells = <0>; > > + pairset-names = "alternative-a", "alternative-b"; > > + pairsets = <&phys0>, <&phys1>; > > + }; > > + pse_pi1: pse_pi@1 { > > + reg = <1>; > > + #pse-cells = <0>; > > + pairset-names = "alternative-a"; > > + pairsets = <&phys2>; > > According to latest discussions, PSE PI nodes will need some > additional, board specific, information: > - this controller do not implements polarity switching, we need to know > what polarity is implemented on this board. The 802.3 spec provide not > really consistent names for polarity configurations: > - Alternative A MDI-X > - Alternative A MDI > - Alternative B X > - Alternative B S > The board may implement one of polarity configurations per alternative > or have additional helpers to switch them without using PSE > controller. > Even if specification explicitly say: > "The PD shall be implemented to be insensitive to the polarity of the power > supply and shall be able to operate per the PD Mode A column and the PD > Mode B column in Table 33–13" > it is possible to find reports like this: > https://community.ui.com/questions/M5-cant-take-reversed-power-polarity-/d834d9a8-579d-4f08-80b1-623806cc5070 > > Probably this kind of property is a good fit: > polarity-supported = "MDI-X", "MDI", "X", "S"; This property should be on the PD side. Isn't it better to name it "polarity-provided" for each PSE PIs binding? What do you think? We agreed that it is mainly for ethtool to show the polarity of a PI, right? Regards,
On Tue, Feb 20, 2024 at 11:40:29AM +0100, Köry Maincent wrote: > On Sat, 17 Feb 2024 13:14:29 +0100 > Oleksij Rempel <o.rempel@pengutronix.de> wrote: > > > On Thu, Feb 15, 2024 at 05:02:55PM +0100, Kory Maincent wrote: > > > Add the PD692x0 I2C Power Sourcing Equipment controller device tree > > > bindings documentation. > > > > > > This patch is sponsored by Dent Project <dentproject@linuxfoundation.org>. > > > > > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> > > > --- > > ... > > > + pse_pis { > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + pse_pi0: pse_pi@0 { > > > + reg = <0>; > > > + #pse-cells = <0>; > > > + pairset-names = "alternative-a", "alternative-b"; > > > + pairsets = <&phys0>, <&phys1>; > > > + }; > > > + pse_pi1: pse_pi@1 { > > > + reg = <1>; > > > + #pse-cells = <0>; > > > + pairset-names = "alternative-a"; > > > + pairsets = <&phys2>; > > > > According to latest discussions, PSE PI nodes will need some > > additional, board specific, information: > > - this controller do not implements polarity switching, we need to know > > what polarity is implemented on this board. The 802.3 spec provide not > > really consistent names for polarity configurations: > > - Alternative A MDI-X > > - Alternative A MDI > > - Alternative B X > > - Alternative B S > > The board may implement one of polarity configurations per alternative > > or have additional helpers to switch them without using PSE > > controller. > > Even if specification explicitly say: > > "The PD shall be implemented to be insensitive to the polarity of the power > > supply and shall be able to operate per the PD Mode A column and the PD > > Mode B column in Table 33–13" > > it is possible to find reports like this: > > https://community.ui.com/questions/M5-cant-take-reversed-power-polarity-/d834d9a8-579d-4f08-80b1-623806cc5070 > > > > Probably this kind of property is a good fit: > > polarity-supported = "MDI-X", "MDI", "X", "S"; > > This property should be on the PD side. Probably. Right now we are on PSE side. > Isn't it better to name it "polarity-provided" for each PSE PIs binding? What > do you think? Yes, this suggestion was directed for PSE PI nodes. In the PHY world, we use "supported" capabilities for what HW can actually do and "advertised" for how the HW is configured. If we use word "provided", i would interpret it as subset of "supported", which at the end is a user space policy. Since I'm not native englisch speaker, my feeling can be wrong. So, any one with stronger opinion may have here other preferences. > We agreed that it is mainly for ethtool to show the polarity of a PI, right? We have two kind of information here: - polarity supported by HW. PSE PI may support more then one. - actually configured polarity. Regards, Oleksij
On Sat, Feb 17, 2024 at 01:14:29PM +0100, Oleksij Rempel wrote: > On Thu, Feb 15, 2024 at 05:02:55PM +0100, Kory Maincent wrote: > > Add the PD692x0 I2C Power Sourcing Equipment controller device tree > > bindings documentation. > > > > This patch is sponsored by Dent Project <dentproject@linuxfoundation.org>. > > > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> > > --- > ... > > + pse_pis { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + pse_pi0: pse_pi@0 { > > + reg = <0>; > > + #pse-cells = <0>; > > + pairset-names = "alternative-a", "alternative-b"; > > + pairsets = <&phys0>, <&phys1>; > > + }; > > + pse_pi1: pse_pi@1 { > > + reg = <1>; > > + #pse-cells = <0>; > > + pairset-names = "alternative-a"; > > + pairsets = <&phys2>; > > According to latest discussions, PSE PI nodes will need some > additional, board specific, information: > - this controller do not implements polarity switching, we need to know > what polarity is implemented on this board. The 802.3 spec provide not > really consistent names for polarity configurations: > - Alternative A MDI-X > - Alternative A MDI > - Alternative B X > - Alternative B S > The board may implement one of polarity configurations per alternative > or have additional helpers to switch them without using PSE > controller. > Even if specification explicitly say: > "The PD shall be implemented to be insensitive to the polarity of the power > supply and shall be able to operate per the PD Mode A column and the PD > Mode B column in Table 33–13" > it is possible to find reports like this: > https://community.ui.com/questions/M5-cant-take-reversed-power-polarity-/d834d9a8-579d-4f08-80b1-623806cc5070 > > Probably this kind of property is a good fit: > polarity-supported = "MDI-X", "MDI", "X", "S"; Where does that live? Looks like a property of the consumers defined in the provider. Generally, that's not the right way for DT. I'll say it again, I think you should be expanding #pse-cells (>1), not getting rid of them (==0). Rob
On Wed, Feb 21, 2024 at 07:41:35AM -0700, Rob Herring wrote: > On Sat, Feb 17, 2024 at 01:14:29PM +0100, Oleksij Rempel wrote: > > On Thu, Feb 15, 2024 at 05:02:55PM +0100, Kory Maincent wrote: > > > Add the PD692x0 I2C Power Sourcing Equipment controller device tree > > > bindings documentation. > > > > > > This patch is sponsored by Dent Project <dentproject@linuxfoundation.org>. > > > > > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> > > > --- > > ... > > > + pse_pis { > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + pse_pi0: pse_pi@0 { > > > + reg = <0>; > > > + #pse-cells = <0>; > > > + pairset-names = "alternative-a", "alternative-b"; > > > + pairsets = <&phys0>, <&phys1>; > > > + }; > > > + pse_pi1: pse_pi@1 { > > > + reg = <1>; > > > + #pse-cells = <0>; > > > + pairset-names = "alternative-a"; > > > + pairsets = <&phys2>; > > > > According to latest discussions, PSE PI nodes will need some > > additional, board specific, information: > > - this controller do not implements polarity switching, we need to know > > what polarity is implemented on this board. The 802.3 spec provide not > > really consistent names for polarity configurations: > > - Alternative A MDI-X > > - Alternative A MDI > > - Alternative B X > > - Alternative B S > > The board may implement one of polarity configurations per alternative > > or have additional helpers to switch them without using PSE > > controller. > > Even if specification explicitly say: > > "The PD shall be implemented to be insensitive to the polarity of the power > > supply and shall be able to operate per the PD Mode A column and the PD > > Mode B column in Table 33–13" > > it is possible to find reports like this: > > https://community.ui.com/questions/M5-cant-take-reversed-power-polarity-/d834d9a8-579d-4f08-80b1-623806cc5070 > > > > Probably this kind of property is a good fit: > > polarity-supported = "MDI-X", "MDI", "X", "S"; > > Where does that live? Looks like a property of the consumers defined in > the provider. Generally, that's not the right way for DT. This is property of PSE PI (Power Interface) Ethernet PHY --\ PSE (provider) ----> PSE PI (consumer of multiple PSE's) ----> Physial port PSE - provides power lines. PSE PI - switches (or not) power lines in different configurations. This is different part of the board/system. PSE PI can have combination or one of following configurations: "MDI-X", "MDI", "X", "S"; This is not something what PSE actually do. PSE PI and PSE are described in IEEE802.3 specification. > I'll say it > again, I think you should be expanding #pse-cells (>1), not getting rid > of them (==0). Did you took time to read my last explanation? Sorry for making it long description, this topic is a bit complex. Regards, Oleksij
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..57ba5365157c --- /dev/null +++ b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml @@ -0,0 +1,157 @@ +# 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 + + managers: + $ref: "#/$defs/managers" + description: + List of the PD69208T4/PD69204T4/PD69208M PSE managers. Each manager + have 4 or 8 physical ports according to the chip version. No need to + specify the SPI chip select as it is automatically detected by the + PD692x0 PSE controller. The PSE managers have to be described from + the lowest chip select to the greatest one, which is the detection + behavior of the PD692x0 PSE controller. The PD692x0 support up to + 12 PSE managers which can expose up to 96 physical ports. All + physical ports available on a manager have to be described in the + incremental order even if they are not used. + +required: + - compatible + - reg + - pse_pis + +$defs: + manager: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + reg: + maxItems: 1 + + patternProperties: + '^port@[0-7]$': + type: object + required: + - reg + + required: + - reg + + managers: + type: object + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^manager@0[0-9]|1[0-2]$": + $ref: "#/$defs/manager" + + required: + - "#address-cells" + - "#size-cells" + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-pse@3c { + compatible = "microchip,pd69200"; + reg = <0x3c>; + + managers { + #address-cells = <1>; + #size-cells = <0>; + + manager@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + phys0: port@0 { + reg = <0>; + }; + + phys1: port@1 { + reg = <1>; + }; + + phys2: port@2 { + reg = <2>; + }; + + phys3: port@3 { + reg = <3>; + }; + }; + + manager@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + phys4: port@0 { + reg = <0>; + }; + + phys5: port@1 { + reg = <1>; + }; + + phys6: port@2 { + reg = <2>; + }; + + phys7: port@3 { + reg = <3>; + }; + }; + }; + + pse_pis { + #address-cells = <1>; + #size-cells = <0>; + + pse_pi0: pse_pi@0 { + reg = <0>; + #pse-cells = <0>; + pairset-names = "alternative-a", "alternative-b"; + pairsets = <&phys0>, <&phys1>; + }; + pse_pi1: pse_pi@1 { + reg = <1>; + #pse-cells = <0>; + pairset-names = "alternative-a"; + pairsets = <&phys2>; + }; + }; + }; + };