| Message ID | 20220825130211.3730461-2-o.rempel@pengutronix.de |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | add generic PSE support | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/patch-applied | success | |
| robh/dtbs-check | warning | build log |
| robh/dt-meta-schema | success |
> + ieee802.3-pairs: > + $ref: /schemas/types.yaml#/definitions/int8-array > + description: Array of number of twisted-pairs capable to deliver power. > + Since not all circuits are able to support all pair variants, the array of > + supported variants should be specified. > + Note - single twisted-pair PSE is formally know as PoDL PSE. > + items: > + enum: [1, 2, 4] It is not clear to me what you are describing here. It looks like the number of pairs? That does not seem like a hardware property. The controller itself should be able to tell you how many pairs it can feed. A hardware property would be which pairs of the socket are connected to a PSE and so can be used to deliver power. But i'm not sure how that would be useful to know. I suppose a controller capable of powering 4 pair, but connected to a socket only wired to supply 2, can then disable 2 pairs? > + > + ieee802.3-pse-type: > + $ref: /schemas/types.yaml#/definitions/uint8 > + minimum: 1 > + maximum: 2 > + description: PSE Type. Describes classification- and class-capabilities. > + Not compatible with PoDL PSE Type. > + Type 1 - provides a Class 0, 1, 2, or 3 signature during Physical Layer > + classification. > + Type 2 - provides a Class 4 signature during Physical Layer > + classification, understands 2-Event classification, and is capable of > + Data Link Layer classification. Again, the controller should know what class it can support. Why do we need to specify it? What could make sense is we want to limit the controller to a specific type? > + ieee802.3-podl-pse-class: > + $ref: /schemas/types.yaml#/definitions/int8-array > + items: > + enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] > + description: PoDL PSE Class. Array of supported classes by the > + single twisted-pair PoDL PSE. Why? I could understand we might want to limit the higher classes, because the board is not designed for them, but the controller on the board can actually offer them. But if it tries to use them, the board will melt/blow a fuse. So i'm wondering if it should actually be something like: > + ieee802.3-podl-limit-pse-classes: > + $ref: /schemas/types.yaml#/definitions/int8-array > + items: > + enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] > + description: PoDL PSE Class. Limit the PoDL PSE to only these classes, due to hardware design limitations. If not specified, the PoDL PSE will offer all classes its supports. Remember, DT describes the hardware, not software configuration of the hardware. Andrew
On Fri, Aug 26, 2022 at 12:27:51AM +0200, Andrew Lunn wrote: > > + ieee802.3-pairs: > > + $ref: /schemas/types.yaml#/definitions/int8-array > > + description: Array of number of twisted-pairs capable to deliver power. > > + Since not all circuits are able to support all pair variants, the array of > > + supported variants should be specified. > > + Note - single twisted-pair PSE is formally know as PoDL PSE. > > + items: > > + enum: [1, 2, 4] > > It is not clear to me what you are describing here. It looks like the > number of pairs? That does not seem like a hardware property. The > controller itself should be able to tell you how many pairs it can > feed. > > A hardware property would be which pairs of the socket are connected > to a PSE and so can be used to deliver power. Good point, this will be needed as well. But not right now. > But i'm not sure how > that would be useful to know. I suppose a controller capable of > powering 4 pair, but connected to a socket only wired to supply 2, can > then disable 2 pairs? Not only. Here are following reasons: - not all boards use a controller in form of IC. Some boards are the controller. So, there is no other place to describe, what kind of controller this board is. For example - currently there are no known ICs to support PoDL (ieee802.3-pairs == 1), early adopters are implementing it by using MOSFETs coupled with ADCs and some extra logic on CPU side: https://www.ti.com/lit/an/snla395/snla395.pdf - not all ICs provide a way for advanced communication (I2C, SPI, MDIO). Some of them will provide only bootstrapping and some pin status feedback: https://www.analog.com/media/en/technical-documentation/data-sheets/4279fa.pdf - Even if we are able to communicate with the IC, there are still board specific limitations. I hope we can agree that some property is need to tell what kind of PSE specification is used by this node. The next challenge is to name it. We have following options: 1. PoE, PoE+, PoE++, 4PPoE, PoDL 2. 802.3af, 802.3at, 802.bt, 802.3bu, 802.3cg 3. Physical property of this specifications Option 1 is mostly using marketing names, except of PoDL. This names are not used in the ieee 802.3-2018 specification. Systematic research of this marketing names would give following results: - PoE is about delivering power over two twisted pairs and is related to 802.3af and 802.3at specs. - PoE+ is about delivering power over two twisted pairs and is related only to 802.3at. - PoE++ is the same as 4PPoE or power over four twisted pairs and is related to 802.3bt. - PoDL is related to 802.3bu and 802.3cg. Which is power over one twisted pair All of this names combine different properties: number of twisted pairs used to deliver power, maximal supported power by the system and recommendation for digital interface to communicate with the PSE controller (MDIO registers). Since system I currently use do not follow all of this recommendations, it is needed to describe them separately. Option 2 is interesting only for archaeological investigation. Final snapshots of 802.3 specification do not provide mapping of extensions to actual parts of the spec. I assume, no software developer will be able to properly set the devicetree property by using specification extension names. Option 3 provide exact physical property of implementation by using same wording provided by the 802.3-2018 spec. This option is easy to verify by reviewing the board schematics and it is easy to understand without doing historical analysis of 802.3 spec. > > + > > + ieee802.3-pse-type: > > + $ref: /schemas/types.yaml#/definitions/uint8 > > + minimum: 1 > > + maximum: 2 > > + description: PSE Type. Describes classification- and class-capabilities. > > + Not compatible with PoDL PSE Type. > > + Type 1 - provides a Class 0, 1, 2, or 3 signature during Physical Layer > > + classification. > > + Type 2 - provides a Class 4 signature during Physical Layer > > + classification, understands 2-Event classification, and is capable of > > + Data Link Layer classification. > > Again, the controller should know what class it can support. Why do we > need to specify it? What could make sense is we want to limit the > controller to a specific type? If we are using existing controller - yes. But this binding is designed for the system where no special PSE IC is used. This Types and Classes depends on the board implementation and should be provided by the vendor as part of product certification. This information can be used by the system administrators to verify compatibility between PSE and PD, especially if no automatic classification is not implemented on this board. And even if auto classification is implemented by the software, we need to know which classes we should announce. > > + ieee802.3-podl-pse-class: > > + $ref: /schemas/types.yaml#/definitions/int8-array > > + items: > > + enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] > > + description: PoDL PSE Class. Array of supported classes by the > > + single twisted-pair PoDL PSE. > > Why? I could understand we might want to limit the higher classes, > because the board is not designed for them, but the controller on the > board can actually offer them. But if it tries to use them, the board > will melt/blow a fuse. > > So i'm wondering if it should actually be something like: > > > + ieee802.3-podl-limit-pse-classes: > > + $ref: /schemas/types.yaml#/definitions/int8-array > > + items: > > + enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] > > + description: PoDL PSE Class. Limit the PoDL PSE to only these classes, > due to hardware design limitations. If not specified, the PoDL PSE > will offer all classes its supports. Sounds good, this can be an extra property for PSE ICs, not for boards without dedicated ICs. > Remember, DT describes the hardware, not software configuration of the > hardware. Ack, I agree.
On Fri, Aug 26, 2022 at 09:49:40AM +0200, Oleksij Rempel wrote: > On Fri, Aug 26, 2022 at 12:27:51AM +0200, Andrew Lunn wrote: > > > + ieee802.3-pairs: > > > + $ref: /schemas/types.yaml#/definitions/int8-array > > > + description: Array of number of twisted-pairs capable to deliver power. > > > + Since not all circuits are able to support all pair variants, the array of > > > + supported variants should be specified. > > > + Note - single twisted-pair PSE is formally know as PoDL PSE. > > > + items: > > > + enum: [1, 2, 4] > > > > It is not clear to me what you are describing here. It looks like the > > number of pairs? That does not seem like a hardware property. The > > controller itself should be able to tell you how many pairs it can > > feed. > > > > A hardware property would be which pairs of the socket are connected > > to a PSE and so can be used to deliver power. > > Good point, this will be needed as well. But not right now. That is another point. You are adding properties which no driver actually uses. That is unusual. I think i would rename your current driver to regulator. That is all it is, and it only needs one property, the regulator itself. Its yaml description should only have the regulator, and nothing else. When other drivers start to be added, we can think about each property they add, and decided if they are generic, or specific to a driver/board. Generic properties we can add to one shared .yaml file, device/board specific properties get added to that drivers .yaml > > But i'm not sure how > > that would be useful to know. I suppose a controller capable of > > powering 4 pair, but connected to a socket only wired to supply 2, can > > then disable 2 pairs? > > Not only. Here are following reasons: > - not all boards use a controller in form of IC. Some boards are the > controller. So, there is no other place to describe, what kind of > controller this board is. For example - currently there are no known > ICs to support PoDL (ieee802.3-pairs == 1), early adopters are > implementing it by using MOSFETs coupled with ADCs and some extra > logic on CPU side: > https://www.ti.com/lit/an/snla395/snla395.pdf > - not all ICs provide a way for advanced communication (I2C, SPI, MDIO). > Some of them will provide only bootstrapping and some pin status > feedback: > https://www.analog.com/media/en/technical-documentation/data-sheets/4279fa.pdf > - Even if we are able to communicate with the IC, there are still board > specific limitations. I expect each of these will provide some sort of driver. It could be board specific, or it could be MCU specific if the same MCU is used multiple times and each implementation looks the same to Linux. I suppose there could even be a library which implements SCCP via a bit-banging GPIO line, and it has a binding for the two GPIO? And if there is no communication at all with it, you cannot represent it in Linux, so you don't need to worry about it. Each driver should come with its own .yaml file, and we should review it, and decided are the properties common or not. > I hope we can agree that some property is need to tell what kind of PSE > specification is used by this node. > > The next challenge is to name it. We have following options: > 1. PoE, PoE+, PoE++, 4PPoE, PoDL > 2. 802.3af, 802.3at, 802.bt, 802.3bu, 802.3cg > 3. Physical property of this specifications > > Option 1 is mostly using marketing names, except of PoDL. This names are > not used in the ieee 802.3-2018 specification. Systematic research of > this marketing names would give following results: > - PoE is about delivering power over two twisted pairs and is related to > 802.3af and 802.3at specs. > - PoE+ is about delivering power over two twisted pairs and is related > only to 802.3at. > - PoE++ is the same as 4PPoE or power over four twisted pairs and is related > to 802.3bt. > - PoDL is related to 802.3bu and 802.3cg. Which is power over one > twisted pair > > All of this names combine different properties: number of twisted pairs > used to deliver power, maximal supported power by the system and > recommendation for digital interface to communicate with the PSE > controller (MDIO registers). Since system I currently use do not follow > all of this recommendations, it is needed to describe them separately. > > Option 2 is interesting only for archaeological investigation. Final > snapshots of 802.3 specification do not provide mapping of extensions to > actual parts of the spec. I assume, no software developer will be able > to properly set the devicetree property by using specification extension > names. > > Option 3 provide exact physical property of implementation by using same > wording provided by the 802.3-2018 spec. This option is easy to verify > by reviewing the board schematics and it is easy to understand without > doing historical analysis of 802.3 spec. I would go for option 3. We want well defined concepts, and specifications provide that. > > > + > > > + ieee802.3-pse-type: > > > + $ref: /schemas/types.yaml#/definitions/uint8 > > > + minimum: 1 > > > + maximum: 2 > > > + description: PSE Type. Describes classification- and class-capabilities. > > > + Not compatible with PoDL PSE Type. > > > + Type 1 - provides a Class 0, 1, 2, or 3 signature during Physical Layer > > > + classification. > > > + Type 2 - provides a Class 4 signature during Physical Layer > > > + classification, understands 2-Event classification, and is capable of > > > + Data Link Layer classification. > > > > Again, the controller should know what class it can support. Why do we > > need to specify it? What could make sense is we want to limit the > > controller to a specific type? > > If we are using existing controller - yes. But this binding is designed for the > system where no special PSE IC is used. I would expect a discreet implementation to also have a driver. The specific discreet implementation should have a compatible, and a yaml file describing whatever properties it needs. And since the driver is specific to the discreet implementation, it should know what it can do in terms of PSE Type, etc. If the same discrete implementation is used on multiple boards, and there are board specific limitations, then we need properties to limit what it can do. Maybe those limits are then described in the shared .yaml file, since limits like this probably are generic. In general, i expect we will end up with two classes of properties: Hardware controls: I2C bus address, SPI address, gpios for bit banging SCCP, GPIOs for turning power on/off and sensing etc. Board specific limitations: Max class, Max current, max Type etc. Andrew
On Sat, Aug 27, 2022 at 04:48:50PM +0200, Andrew Lunn wrote: > On Fri, Aug 26, 2022 at 09:49:40AM +0200, Oleksij Rempel wrote: > > On Fri, Aug 26, 2022 at 12:27:51AM +0200, Andrew Lunn wrote: > > > > + ieee802.3-pairs: > > > > + $ref: /schemas/types.yaml#/definitions/int8-array > > > > + description: Array of number of twisted-pairs capable to deliver power. > > > > + Since not all circuits are able to support all pair variants, the array of > > > > + supported variants should be specified. > > > > + Note - single twisted-pair PSE is formally know as PoDL PSE. > > > > + items: > > > > + enum: [1, 2, 4] > > > > > > It is not clear to me what you are describing here. It looks like the > > > number of pairs? That does not seem like a hardware property. The > > > controller itself should be able to tell you how many pairs it can > > > feed. > > > > > > A hardware property would be which pairs of the socket are connected > > > to a PSE and so can be used to deliver power. > > > > Good point, this will be needed as well. But not right now. > > That is another point. You are adding properties which no driver > actually uses. That is unusual. > > I think i would rename your current driver to regulator. That is all > it is, and it only needs one property, the regulator itself. Its yaml > description should only have the regulator, and nothing else. > > When other drivers start to be added, we can think about each property > they add, and decided if they are generic, or specific to a > driver/board. Generic properties we can add to one shared .yaml file, > device/board specific properties get added to that drivers .yaml > > > > But i'm not sure how > > > that would be useful to know. I suppose a controller capable of > > > powering 4 pair, but connected to a socket only wired to supply 2, can > > > then disable 2 pairs? > > > > Not only. Here are following reasons: > > - not all boards use a controller in form of IC. Some boards are the > > controller. So, there is no other place to describe, what kind of > > controller this board is. For example - currently there are no known > > ICs to support PoDL (ieee802.3-pairs == 1), early adopters are > > implementing it by using MOSFETs coupled with ADCs and some extra > > logic on CPU side: > > https://www.ti.com/lit/an/snla395/snla395.pdf > > - not all ICs provide a way for advanced communication (I2C, SPI, MDIO). > > Some of them will provide only bootstrapping and some pin status > > feedback: > > https://www.analog.com/media/en/technical-documentation/data-sheets/4279fa.pdf > > - Even if we are able to communicate with the IC, there are still board > > specific limitations. > > I expect each of these will provide some sort of driver. It could be > board specific, or it could be MCU specific if the same MCU is used > multiple times and each implementation looks the same to Linux. I > suppose there could even be a library which implements SCCP via a > bit-banging GPIO line, and it has a binding for the two GPIO? > > And if there is no communication at all with it, you cannot represent > it in Linux, so you don't need to worry about it. > > Each driver should come with its own .yaml file, and we should review > it, and decided are the properties common or not. > > > I hope we can agree that some property is need to tell what kind of PSE > > specification is used by this node. > > > > The next challenge is to name it. We have following options: > > 1. PoE, PoE+, PoE++, 4PPoE, PoDL > > 2. 802.3af, 802.3at, 802.bt, 802.3bu, 802.3cg > > 3. Physical property of this specifications > > > > Option 1 is mostly using marketing names, except of PoDL. This names are > > not used in the ieee 802.3-2018 specification. Systematic research of > > this marketing names would give following results: > > - PoE is about delivering power over two twisted pairs and is related to > > 802.3af and 802.3at specs. > > - PoE+ is about delivering power over two twisted pairs and is related > > only to 802.3at. > > - PoE++ is the same as 4PPoE or power over four twisted pairs and is related > > to 802.3bt. > > - PoDL is related to 802.3bu and 802.3cg. Which is power over one > > twisted pair > > > > All of this names combine different properties: number of twisted pairs > > used to deliver power, maximal supported power by the system and > > recommendation for digital interface to communicate with the PSE > > controller (MDIO registers). Since system I currently use do not follow > > all of this recommendations, it is needed to describe them separately. > > > > Option 2 is interesting only for archaeological investigation. Final > > snapshots of 802.3 specification do not provide mapping of extensions to > > actual parts of the spec. I assume, no software developer will be able > > to properly set the devicetree property by using specification extension > > names. > > > > Option 3 provide exact physical property of implementation by using same > > wording provided by the 802.3-2018 spec. This option is easy to verify > > by reviewing the board schematics and it is easy to understand without > > doing historical analysis of 802.3 spec. > > I would go for option 3. We want well defined concepts, and > specifications provide that. > > > > > + > > > > + ieee802.3-pse-type: > > > > + $ref: /schemas/types.yaml#/definitions/uint8 > > > > + minimum: 1 > > > > + maximum: 2 > > > > + description: PSE Type. Describes classification- and class-capabilities. > > > > + Not compatible with PoDL PSE Type. > > > > + Type 1 - provides a Class 0, 1, 2, or 3 signature during Physical Layer > > > > + classification. > > > > + Type 2 - provides a Class 4 signature during Physical Layer > > > > + classification, understands 2-Event classification, and is capable of > > > > + Data Link Layer classification. > > > > > > Again, the controller should know what class it can support. Why do we > > > need to specify it? What could make sense is we want to limit the > > > controller to a specific type? > > > > If we are using existing controller - yes. But this binding is designed for the > > system where no special PSE IC is used. > > I would expect a discreet implementation to also have a driver. The > specific discreet implementation should have a compatible, and a yaml > file describing whatever properties it needs. And since the driver is > specific to the discreet implementation, it should know what it can do > in terms of PSE Type, etc. > > If the same discrete implementation is used on multiple boards, and > there are board specific limitations, then we need properties to limit > what it can do. Maybe those limits are then described in the shared > .yaml file, since limits like this probably are generic. > > In general, i expect we will end up with two classes of properties: > > Hardware controls: I2C bus address, SPI address, gpios for bit banging > SCCP, GPIOs for turning power on/off and sensing etc. > > Board specific limitations: Max class, Max current, max Type etc. Ok, so current plan is: - rename this driver and binding to pse-regulator - i will integrate the "ieee802.3-pairs" property, since this driver need to know which field it need to fill in the ethtool response (PSE vs PoDL PSE) - compatible will be "ieee802.3-pse-regulator" Correct? Regards, Oleksij
> Ok, so current plan is: > - rename this driver and binding to pse-regulator > - i will integrate the "ieee802.3-pairs" property, since this driver > need to know which field it need to fill in the ethtool response (PSE > vs PoDL PSE) It seems odd to have a property which only purpose is to supply userspace with some information. If all you have is a single regulator, does it even matter if it is PSE vs PoDL PSE? If you think it does matter, i would probably have two compatibles. Andrew
diff --git a/Documentation/devicetree/bindings/net/pse-pd/generic-pse.yaml b/Documentation/devicetree/bindings/net/pse-pd/generic-pse.yaml new file mode 100644 index 0000000000000..ecd226df66f4e --- /dev/null +++ b/Documentation/devicetree/bindings/net/pse-pd/generic-pse.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/pse-pd/generic-pse.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic Power Sourcing Equipment + +maintainers: + - Oleksij Rempel <o.rempel@pengutronix.de> + +description: Generic PSE controller. The device must be referenced by the PHY + node to control power injection to the Ethernet cable. + +properties: + compatible: + const: ieee802.3-pse + + '#pse-cells': + const: 0 + + ieee802.3-pse-supply: + description: Power supply for the PSE controller + + ieee802.3-pairs: + $ref: /schemas/types.yaml#/definitions/int8-array + description: Array of number of twisted-pairs capable to deliver power. + Since not all circuits are able to support all pair variants, the array of + supported variants should be specified. + Note - single twisted-pair PSE is formally know as PoDL PSE. + items: + enum: [1, 2, 4] + + ieee802.3-pse-type: + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 1 + maximum: 2 + description: PSE Type. Describes classification- and class-capabilities. + Not compatible with PoDL PSE Type. + Type 1 - provides a Class 0, 1, 2, or 3 signature during Physical Layer + classification. + Type 2 - provides a Class 4 signature during Physical Layer + classification, understands 2-Event classification, and is capable of + Data Link Layer classification. + + ieee802.3-pse-class: + $ref: /schemas/types.yaml#/definitions/int8-array + items: + enum: [0, 1, 2, 3, 4] + description: PSE Class. Array of supported classes by the 2 and 4 pair PSE. + + ieee802.3-podl-pse-type: + $ref: /schemas/types.yaml#/definitions/string + enum: [a, b, c, d, e] + description: PoDL PSE Type. Describes compatibility to physical Layer + specifications. + Type A - cost optimized for 100BASE-T1 + Type B - cost optimized for 1000BASE-T1 + Type C - works with 100BASE-T1 and 1000BASE-T1 + Type D - optimized for 10BASE-T1S + Type E - optimized for 10BASE-T1L + + ieee802.3-podl-pse-class: + $ref: /schemas/types.yaml#/definitions/int8-array + items: + enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] + description: PoDL PSE Class. Array of supported classes by the + single twisted-pair PoDL PSE. + +additionalProperties: false + +required: + - compatible + - '#pse-cells' + - ieee802.3-pse-supply + +examples: + - | + pse_t1l2: ethernet-pse-1 { + compatible = "ieee802.3-pse"; + ieee802.3-pse-supply = <®_t1l1>; + ieee802.3-podl-pse-type = "e"; + ieee802.3-podl-pse-class = /bits/ 8 <0 1>; + ieee802.3-pairs = /bits/ 8 <1>; + #pse-cells = <0>; + }; + - | + pse_poe: ethernet-pse-2 { + compatible = "ieee802.3-pse"; + ieee802.3-pse-supply = <®_poe>; + ieee802.3-pairs = /bits/ 8 <2 4>; + ieee802.3-pse-type = /bits/ 8 <1>; + ieee802.3-pse-class = /bits/ 8 <0 1>; + #pse-cells = <0>; + };
Add binding for generic Ethernet PSE controller. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> --- changes v2: - rename compatible to more generic "ieee802.3-pse" - add class and type properties for PoDL and PoE variants - add pairs property --- .../bindings/net/pse-pd/generic-pse.yaml | 95 +++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/pse-pd/generic-pse.yaml