[PATCH net v4 1/3] dt-bindings: add SFF vendor prefix

[PATCH net v4 1/3] dt-bindings: add SFF vendor prefix

[Baruch Siach]

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v4: No change

v3: Add Rob's ack

v2: New patch in this series
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4e72012928b4..12b5808b82f2 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -289,6 +289,7 @@ schindler	Schindler
 seagate	Seagate Technology PLC
 semtech	Semtech Corporation
 sensirion	Sensirion AG
+sff	Small Form Factor Committee
 sgx	SGX Sensortech
 sharp	Sharp Corporation
 si-en	Si-En Technology Ltd.
-- 
2.14.1

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

[Baruch Siach]

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-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
---
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
+
+- mod-def0-gpios : GPIO phandle and a specifier of the MOD-DEF0 (AKA Mod_ABS)
+  module presence input gpio signal, active (module absent) high
+
+- los-gpios : GPIO phandle and a specifier of the Receiver Loss of Signal
+  Indication input gpio signal, active (signal lost) high
+
+- tx-fault-gpios : GPIO phandle and a specifier of the Module Transmitter
+  Fault input gpio signal, active (fault condition) high
+
+- tx-disable-gpios : GPIO phandle and a specifier of the Transmitter Disable
+  output gpio signal, active (Tx disable) high
+
+- rate-select0-gpios : GPIO phandle and a specifier of the Rx Signaling Rate
+  Select (AKA RS0) output gpio signal, low: low Rx rate, high: high Rx rate
+
+- rate-select1-gpios : GPIO phandle and a specifier of the Tx Signaling Rate
+  Select (AKA RS1) output gpio signal (SFP+ only), low: low Tx rate, high:
+  high Tx rate
+
+Example #1: Direct serdes to SFP connection
+
+sfp_eth3: sfp-eth3 {
+	compatible = "sff,sfp";
+	i2c-bus = <&sfp_1g_i2c>;
+	los-gpios = <&cpm_gpio2 22 GPIO_ACTIVE_HIGH>;
+	mod-def0-gpios = <&cpm_gpio2 21 GPIO_ACTIVE_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&cpm_sfp_1g_pins &cps_sfp_1g_pins>;
+	tx-disable-gpios = <&cps_gpio1 24 GPIO_ACTIVE_HIGH>;
+	tx-fault-gpios = <&cpm_gpio2 19 GPIO_ACTIVE_HIGH>;
+};
+
+&cps_emac3 {
+	phy-names = "comphy";
+	phys = <&cps_comphy5 0>;
+	sfp = <&sfp_eth3>;
+};
+
+Example #2: Serdes to PHY to SFP connection
+
+sfp_eth0: sfp-eth0 {
+	compatible = "sff,sfp";
+	i2c-bus = <&sfpp0_i2c>;
+	los-gpios = <&cps_gpio1 28 GPIO_ACTIVE_HIGH>;
+	mod-def0-gpios = <&cps_gpio1 27 GPIO_ACTIVE_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&cps_sfpp0_pins>;
+	tx-disable-gpios = <&cps_gpio1 29 GPIO_ACTIVE_HIGH>;
+	tx-fault-gpios  = <&cps_gpio1 26 GPIO_ACTIVE_HIGH>;
+};
+
+p0_phy: ethernet-phy@0 {
+	compatible = "ethernet-phy-ieee802.3-c45";
+	pinctrl-names = "default";
+	pinctrl-0 = <&cpm_phy0_pins &cps_phy0_pins>;
+	reg = <0>;
+	interrupt = <&cpm_gpio2 18 IRQ_TYPE_EDGE_FALLING>;
+	sfp = <&sfp_eth0>;
+};
+
+&cpm_eth0 {
+	phy = <&p0_phy>;
+	phy-mode = "10gbase-kr";
+};
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net v4 3/3] net: phy: sfp: rename dt properties to match the binding

[Baruch Siach]

Make the Rx rate select control gpio property name match the documented
binding. This would make the addition of 'rate-select1-gpios' for SFP+
support more natural.

Also, make the MOD-DEF0 gpio property name match the documentation.

Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
---
v4: Rename also MOD-DEF0

v3: No change

v2: New patch in this series
---
 drivers/net/phy/sfp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index fb2cf4342f48..baee371bf767 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -58,11 +58,11 @@ enum {
 };
 
 static const char *gpio_of_names[] = {
-	"moddef0",
+	"mod-def0",
 	"los",
 	"tx-fault",
 	"tx-disable",
-	"rate-select",
+	"rate-select0",
 };
 
 static const enum gpiod_flags gpio_flags[] = {
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net v4 1/3] dt-bindings: add SFF vendor prefix

[David Miller]

From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
Date: Thu,  7 Sep 2017 12:25:48 +0300

> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>

Applied.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Miller]

From: Baruch Siach <baruch@tkos.co.il>
Date: Thu,  7 Sep 2017 12:25:49 +0300

> 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@tkos.co.il>

Applied.

Re: [PATCH net v4 3/3] net: phy: sfp: rename dt properties to match the binding

[David Miller]

From: Baruch Siach <baruch@tkos.co.il>
Date: Thu,  7 Sep 2017 12:25:50 +0300

> Make the Rx rate select control gpio property name match the documented
> binding. This would make the addition of 'rate-select1-gpios' for SFP+
> support more natural.
> 
> Also, make the MOD-DEF0 gpio property name match the documentation.
> 
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>

Applied.

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

[Florian Fainelli]

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-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Russell King - ARM Linux]

On Mon, Oct 30, 2017 at 08:13:42PM -0700, Florian Fainelli wrote:
> Hi Baruch,
> 
> On 09/07/2017 02:25 AM, Baruch Siach wrote:
> > 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.

Here's what I said about this exact subject in August:

  What reg= value would you use to identify it?  There's no particular
  I2C bus address.  There's an EEPROM on the actual module, and there
  may be a PHY on the I2C bus (some PHYs include I2C as an alternative
  way to speak to them other than MDIO.)

  I2C couldn't probe these as they are effectively hotplugged.

  However, there's also the question about why it should be a child of
  the I2C bus - the I2C bus is just a means of communicating with and
  identifying the module.  You could equally argue that it should be
  a child of the GPIO controller, because that's how it's controlled.
  You could also argue that it should be a child of the ethernet
  interface, since that's the main data path.

The SFP support is basically a driver for a socket which has a
hot-pluggable device, which may be empty at the time of probing.
If it's empty, it just has an I2C bus, a bunch of GPIOs and a
couple of serdes lanes routed to it, which appear on pins on the
socket.  There is no device that can be detected or probed.

There is no I2C bus address of an empty socket.

When a module is plugged in, then we get some I2C devices appearing.
These can take one or more I2C bus addresses.  The I2C device
binding requires that all I2C child nodes specify the bus address
of their device.  Which address do you choose?

Bear in mind that when the socket is empty, as there's no devices
present, there wouldn't be a device for a driver to bind to, so
this driver, which deals with the hot-plugging of the socket has
no device to bind with.

Think of the "sff,sfp" driver as a driver for the /socket/ rather
than the /module/ in the socket.  The SFF specifications give the
requirements for the signals at the /socket/ and the driver
implements those requirements.

If drivers are required for the modules (because they have a PHY
on them) the normal Linux PHY drivers get used for that.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html