diff mbox series

[RFC,net-next,2/2] dt-bindings: ethernet-phy: define `unsupported-mac-connection-types` property

Message ID 20210322195001.28036-2-kabel@kernel.org (mailing list archive)
State RFC
Delegated to: Netdev Maintainers
Headers show
Series [RFC,net-next,1/2] dt-bindings: ethernet-controller: create a type for PHY interface modes | expand

Checks

Context Check Description
netdev/cover_letter success Link
netdev/fixes_present success Link
netdev/patch_count success Link
netdev/tree_selection success Clearly marked for net-next
netdev/subject_prefix success Link
netdev/cc_maintainers warning 3 maintainers not CCed: robh+dt@kernel.org linux@armlinux.org.uk kuba@kernel.org
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 26 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/header_inline success Link

Commit Message

Marek Behún March 22, 2021, 7:49 p.m. UTC
An ethernet PHY may support PHY interface modes that are not wired on a
specific board (or are broken for some other reason). In order for the
kernel to know that these modes should not be used, we need to specify
this in device tree.

Define a new ethernet PHY property `unsupported-mac-connection-types`,
which lists these unsupported modes.

Signed-off-by: Marek Behún <kabel@kernel.org>
---

As in the previous patch: we allow both `phy-connection-type` and
`phy-mode` to define PHY interface mode. Should we call this new
property as it is proposed by this patch, or something different,
like `unsupported-mac-phy-modes`?

Also, some PHYs (marvell10g for example) also multiple units (host
unit for connecting to the MAC, fiber unit for connecting for example
via a SFP). Should we also add `unsupported-fiber-connection-types`
property?

Moreover should this property be a member of PHY's node, or the
ethernet controller's node? Were it a member of ethernet controller's
node, we wouldn't need to $ref a definition from another file's $defs
(which Rob Herring says that so far is done only in withing single
file).
On the other hand `unsupported-fiber-connection-types` property should
be a member of PHY's node, if we will add this in the future.

---
 .../devicetree/bindings/net/ethernet-phy.yaml     | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

Comments

Russell King (Oracle) March 22, 2021, 7:56 p.m. UTC | #1
On Mon, Mar 22, 2021 at 08:49:59PM +0100, Marek Behún wrote:
> diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> index 2766fe45bb98..4c5b8fabbec3 100644
> --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> @@ -136,6 +136,20 @@ properties:
>        used. The absence of this property indicates the muxers
>        should be configured so that the external PHY is used.
>  
> +  unsupported-mac-connection-types:
> +    $ref: "ethernet-controller.yaml#/$defs/phy-connection-type-array"
> +    description:
> +      The PHY device may support different interface types for
> +      connecting the Ethernet MAC device to the PHY device (i.e.
> +      rgmii, sgmii, xaui, ...), but not all of these interface
> +      types must necessarily be supported for a specific board
> +      (either not all of them are wired, or there is a known bug
> +      for a specific mode).
> +      This property specifies a list of interface modes are not
> +      supported on the board.

I think this needs to be clearer. "This property specifies a list
of interface modes supported by the PHY hardware but are not
supported on the board."

I would also suggest having a think about a PHY that supports some
interface types that we don't have support in the kernel for, but
which also are not part of the board. Should these be listed
somehow as well? If not, how do we deal with the kernel later gaining
support for those interface modes, potentially the PHY driver as well,
and then having a load of boards not listing this?

My feeling is that listing negative properties presents something of
a problem, and we ought to stick with boards specifying what they
support, rather than what they don't.
Marek Behún March 22, 2021, 9:11 p.m. UTC | #2
On Mon, 22 Mar 2021 19:56:05 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:

> On Mon, Mar 22, 2021 at 08:49:59PM +0100, Marek Behún wrote:
> > diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > index 2766fe45bb98..4c5b8fabbec3 100644
> > --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> > @@ -136,6 +136,20 @@ properties:
> >        used. The absence of this property indicates the muxers
> >        should be configured so that the external PHY is used.
> >  
> > +  unsupported-mac-connection-types:
> > +    $ref: "ethernet-controller.yaml#/$defs/phy-connection-type-array"
> > +    description:
> > +      The PHY device may support different interface types for
> > +      connecting the Ethernet MAC device to the PHY device (i.e.
> > +      rgmii, sgmii, xaui, ...), but not all of these interface
> > +      types must necessarily be supported for a specific board
> > +      (either not all of them are wired, or there is a known bug
> > +      for a specific mode).
> > +      This property specifies a list of interface modes are not
> > +      supported on the board.  
> 
> I think this needs to be clearer. "This property specifies a list
> of interface modes supported by the PHY hardware but are not
> supported on the board."
> 
> I would also suggest having a think about a PHY that supports some
> interface types that we don't have support in the kernel for, but
> which also are not part of the board. Should these be listed
> somehow as well? If not, how do we deal with the kernel later gaining
> support for those interface modes, potentially the PHY driver as well,
> and then having a load of boards not listing this?
> 
> My feeling is that listing negative properties presents something of
> a problem, and we ought to stick with boards specifying what they
> support, rather than what they don't.

That is a good point. And if this alternative `supported-modes` property
is missing, we can just assume that all modes are supported, in order
to be backward compatible.
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index 2766fe45bb98..4c5b8fabbec3 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -136,6 +136,20 @@  properties:
       used. The absence of this property indicates the muxers
       should be configured so that the external PHY is used.
 
+  unsupported-mac-connection-types:
+    $ref: "ethernet-controller.yaml#/$defs/phy-connection-type-array"
+    description:
+      The PHY device may support different interface types for
+      connecting the Ethernet MAC device to the PHY device (i.e.
+      rgmii, sgmii, xaui, ...), but not all of these interface
+      types must necessarily be supported for a specific board
+      (either not all of them are wired, or there is a known bug
+      for a specific mode).
+      This property specifies a list of interface modes are not
+      supported on the board.
+    minItems: 1
+    maxItems: 128
+
   resets:
     maxItems: 1
 
@@ -196,5 +210,6 @@  examples:
             reset-gpios = <&gpio1 4 1>;
             reset-assert-us = <1000>;
             reset-deassert-us = <2000>;
+            unsupported-mac-connection-types = "xaui", "rxaui";
         };
     };