[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d707abea-a9eb-74d0-841f-1ff1fe4153a8@gmail.com>
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
Powered by blists - more mailing lists