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

["Marek Behún" <kabel@kernel.org>]

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.