netdev - Re: [RFC PATCH] 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:   Wed, 23 Aug 2017 15:10:51 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Baruch Siach <baruch@...s.co.il>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Russell King <rmk+kernel@....linux.org.uk>,
        netdev <netdev@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [RFC PATCH] dt-binding: net: sfp binding documentation

On Wed, Aug 23, 2017 at 03:16:53PM +0300, Baruch Siach wrote:
> Hi Rob,
> 
> On Mon, Aug 21, 2017 at 02:10:33PM -0500, Rob Herring wrote:
> > On Sun, Aug 20, 2017 at 5:28 AM, Baruch Siach <baruch@...s.co.il> 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>
> > > ---
> > >
> > > The SFP driver is on net-next.
> 
> [...]
> 
> > > +Optional Properties:
> > > +
> > > +- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial
> > > +  interface
> > 
> > Why not a child of the i2c bus it is on? IOW, what should this be a child of?
> 
> As I understand form the code the ID of the SFP i2c slave is derived from the 
> Ethernet PHY 'reg' property. The PHY node's 'sfp' property points to a phandle 
> of the sff,sfp node.

Hi Rob

The SFP module uses multiple addresses on the i2c bus. 0x50 is
something like an EEPROM, but some of the content is
dynamic. Depending of the version of the standard, it can also use
0x51 for additional information. If the SPF module contains a copper
PHY, it also uses another address on the i2c bus for the standard
copper PHY registers.

An SFP module does not fit the usual I2C client model, since it is a
collection of interconnected i2c clients in one package.

	   Andrew