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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 22 Mar 2021 21:11:47 +0000
From:   Marek Behún <kabel@...nel.org>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
        "David S . Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org
Subject: Re: [RFC net-next 2/2] dt-bindings: ethernet-phy: define
 `unsupported-mac-connection-types` property

On Mon, 22 Mar 2021 19:56:05 +0000
Russell King - ARM Linux admin <linux@...linux.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.