| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20240406213714.0ae64623@kmaincent-XPS-13-7390> Date: Sat, 6 Apr 2024 21:37:14 +0200 From: Kory Maincent <kory.maincent@...tlin.com> To: Rob Herring <robh@...nel.org> 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>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, Oleksij Rempel <o.rempel@...gutronix.de>, Mark Brown <broonie@...nel.org>, Frank Rowand <frowand.list@...il.com>, Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>, 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>, Maxime Chevallier <maxime.chevallier@...tlin.com> Subject: Re: [PATCH net-next v6 11/17] dt-bindings: net: pse-pd: Add another way of describing several PSE PIs On Thu, 4 Apr 2024 10:38:54 +0200 Kory Maincent <kory.maincent@...tlin.com> wrote: > On Wed, 3 Apr 2024 09:31:42 -0500 > Rob Herring <robh@...nel.org> wrote: > > > On Wed, Apr 03, 2024 at 11:15:48AM +0200, Kory Maincent wrote: > > > On Tue, 2 Apr 2024 08:26:37 -0500 > > > Rob Herring <robh@...nel.org> wrote: > > > > > > > > + pairset-names: > > > > > + $ref: /schemas/types.yaml#/definitions/string-array > > > > > + description: > > > > > + Names of the pairsets as per IEEE 802.3-2022, Section > > > > > 145.2.4. > > > > > + Valid values are "alternative-a" and "alternative-b". > > > > > Each name > > > > > > > > Don't state constraints in prose which are defined as schema > > > > constraints. > > > > > > Ok, I will remove the line. > > > > > > > > + pairsets: > > > > > + $ref: /schemas/types.yaml#/definitions/phandle-array > > > > > + description: > > > > > + List of phandles, each pointing to the power supply for > > > > > the > > > > > + corresponding pairset named in 'pairset-names'. This > > > > > property > > > > > + aligns with IEEE 802.3-2022, Section 33.2.3 and > > > > > 145.2.4. > > > > > + PSE Pinout Alternatives (as per IEEE 802.3-2022 Table > > > > > 145\u20133) > > > > > + > > > > > |-----------|---------------|---------------|---------------|---------------| > > > > > + | Conductor | Alternative A | Alternative A | > > > > > Alternative B | Alternative B | > > > > > + | | (MDI-X) | (MDI) | (X) > > > > > | (S) | > > > > > + > > > > > |-----------|---------------|---------------|---------------|---------------| > > > > > + | 1 | Negative VPSE | Positive VPSE | \u2014 > > > > > | \u2014 | > > > > > + | 2 | Negative VPSE | Positive VPSE | \u2014 > > > > > | \u2014 | > > > > > + | 3 | Positive VPSE | Negative VPSE | \u2014 > > > > > | \u2014 | > > > > > + | 4 | \u2014 | \u2014 | > > > > > Negative VPSE | Positive VPSE | > > > > > + | 5 | \u2014 | \u2014 | > > > > > Negative VPSE | Positive VPSE | > > > > > + | 6 | Positive VPSE | Negative VPSE | \u2014 > > > > > | \u2014 | > > > > > + | 7 | \u2014 | \u2014 | > > > > > Positive VPSE | Negative VPSE | > > > > > + | 8 | \u2014 | \u2014 | > > > > > Positive VPSE | Negative VPSE | > > > > > + minItems: 1 > > > > > + maxItems: 2 > > > > > > > > "pairsets" does not follow the normal design pattern of foos, > > > > foo-names, and #foo-cells. You could add #foo-cells I suppose, but what > > > > would cells convey? I don't think it's a good fit for what you need. > > > > > > > > The other oddity is the number of entries and the names are fixed. That > > > > is usually defined per consumer. > > > > > > Theoretically if the RJ45 port binding was supported it would make more > > > sense, but in reality it's not feasible as the PSE controller need this > > > information in its init process. > > > The PSE controller reset all its port to apply a configuration so we can't > > > do it when the consumer (RJ45) probe. It would reset the other ports if > > > one consumer is probed later in the process. > > > > There is no reason other than convenience that all information some > > driver needs has to be in one node or one hierarchy of nodes. You can > > fetch anything from anywhere in the DT. It does feel like some of this > > belongs in a connector node. We often haven't described connectors in DT > > and stick connector properties in the controller node associated with > > the connector. Then as things get more complicated, it becomes a mess. > > Right, we could indeed put all the informations of the pse_pi node in the > future RJ45 port abstraction node. Then, this series will be put aside until > we manage to have the port abstraction get merged. > I am not glad about this as it will stuck my work until then, but indeed > removing this pse_pi wrapper node which is between the pse_controller node and > the connector node seems cleaner. After some new thought, I thinks it is quite similar on the devicetree side to have it in a pse_pi node or in the connector node. Here are my agruments to continue using this pse_pi binding description: - The connector abstraction is in its early work and won't really see a v1 soon while the PoE series got mainly all reviewed-by thanks to Andrew. This would stuck the PoE series until maybe one or two Linux version. - It allows to use the "Power Interface" name like described in the standards. - Even if this is in the PSE controller node, it is generic to all PSEs so it shouldn't become a mess. - It allows to have the PSE controller and Power Interfaces parameters grouped together and it will be easier to read. May not really be an argument! ;) - It will keep the logic of PoDL with the PHY using a single reference to the PSE PI through the pses parameter. Is it okay for you to continue with it? Regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
Powered by blists - more mailing lists