| Message ID | 5b46343b543ad1d2ebbc5be9871def7f92c4dbd8.1504776350.git.baruch@tkos.co.il |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | [net,v4,1/3] dt-bindings: add SFF vendor prefix | expand |
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.
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@tkos.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!
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.
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"; +};
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> --- 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