netdev - Re: [PATCH net v4 2/3] dt-binding: net: sfp binding documentation

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, 30 Oct 2017 20:13:42 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Baruch Siach <baruch@...s.co.il>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        Russell King <rmk+kernel@....linux.org.uk>
Cc:     netdev@...r.kernel.org, devicetree@...r.kernel.org,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        Antoine Tenart <antoine.tenart@...e-electrons.com>
Subject: Re: [PATCH net v4 2/3] dt-binding: net: sfp binding documentation

Hi Baruch,

On 09/07/2017 02:25 AM, Baruch Siach wrote:
> Add device-tree binding documentation SFP transceivers. Support for SFP
> transceivers has been recently introduced (drivers/net/phy/sfp.c).
> 
> Signed-off-by: Baruch Siach <baruch@...s.co.il>
> ---
> v4:
>   Remove redundant 'single' from the gpio specifier
>   Rename 'moddef0-gpios' property to 'mod-def0-gpios'
>   Remove 'phy-mode' property from the example; SFP determines the mode
> 
> v3:
>   Mention gpios phandle and specifier
>   Mention the polarity of each gpio
>   Fix example property names
> 
> v2:
>   Rename -gpio properties to -gpios
>   Rename the rate-select-gpio property to rate-select0-gpios
>   Add the rate-select1-gpios property
>   Add examples
> ---
>  Documentation/devicetree/bindings/net/sff,sfp.txt | 76 +++++++++++++++++++++++
>  1 file changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/sff,sfp.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/sff,sfp.txt b/Documentation/devicetree/bindings/net/sff,sfp.txt
> new file mode 100644
> index 000000000000..60e970ce10ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/sff,sfp.txt
> @@ -0,0 +1,76 @@
> +Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP)
> +Transceiver
> +
> +Required properties:
> +
> +- compatible : must be "sff,sfp"
> +
> +Optional Properties:
> +
> +- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial
> +  interface

What was the reasoning behind using this property instead of making the
SFP a child of the i2c bus directly? Were you thinking that there could
be systems where the SFP is not i2c-addresable, but another 2-wire
protocol is used instead? This is not particularly wrong per-se I guess,
but usually, the parent/child relationship should make that more obvious.

Right now, we have to have a series of platform devices matching
sff,sfp, so that puts some constraints on where these devices can be
within a Device Tree.

Sorry for catching up on this so late...

Thanks!
-- 
Florian