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 19:56:05 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Marek BehĂșn <kabel@...nel.org>
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, 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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ