netdev - Re: [PATCH net-next v4 1/4] net: phy: mdio-i2c: support I2C MDIO protocol for RollBall SFP modules

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]

Message-ID: <20210118121338.lzbit6ad2uem2gcq@pali>
Date:   Mon, 18 Jan 2021 13:13:38 +0100
From:   Pali Rohár <pali@...nel.org>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Marek Behún <kabel@...nel.org>,
        netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
        Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net
Subject: Re: [PATCH net-next v4 1/4] net: phy: mdio-i2c: support I2C MDIO
 protocol for RollBall SFP modules

On Tuesday 12 January 2021 19:22:33 Russell King - ARM Linux admin wrote:
> On Tue, Jan 12, 2021 at 09:42:56AM +0100, Heiner Kallweit wrote:
> > On 11.01.2021 06:00, Marek Behún wrote:
> > > Some multigig SFPs from RollBall and Hilink do not expose functional
> > > MDIO access to the internal PHY of the SFP via I2C address 0x56
> > > (although there seems to be read-only clause 22 access on this address).
> > > 
> > > Instead these SFPs PHY can be accessed via I2C via the SFP Enhanced
> > > Digital Diagnostic Interface - I2C address 0x51. The SFP_PAGE has to be
> > > selected to 3 and the password must be filled with 0xff bytes for this
> > > PHY communication to work.
> > > 
> > > This extends the mdio-i2c driver to support this protocol by adding a
> > > special parameter to mdio_i2c_alloc function via which this RollBall
> > > protocol can be selected.
> > > 
> > I'd think that mdio-i2c.c is for generic code. When adding a
> > vendor-specific protocol, wouldn't it make sense to use a dedicated
> > source file for it?
> 
> There is nothing in the SFP MSAs about how to access an on-board PHY
> on a SFP. This is something that vendors choose to do (or in some
> cases, not do.)
> 
> mdio-i2c currently implements the access protocol for Marvell 88E1111
> PHYs which have an I2C mode. It was extended to support the DM7052
> module which has a Broadcom Clause 45 PHY and either a microcontroller
> or FPGA to convert I2C cycles to MDIO cycles - and sensibly performs
> clock stretching.

Just to note that there is also another Marvell way how to access Clause
45 registers via existing Marvell PHY Clause 22 I2C mode:

https://www.ieee802.org/3/efm/public/nov02/oam/pannell_oam_1_1102.pdf

Clause 45 registers are accessed via Clause 22 regs 13 and 14.

> There are modules that the clause 45 PHY is accessible via exactly the
> same I2C address, using exactly the same data accesses, but do not
> do the clock stretching thing, instead telling you that you must wait
> N microseconds between the bus transactions. We don't yet support
> these.
> 
> Then there is Marek's module, where the PHY is accessible via a page
> in the diagnostic address - which is another entirely reasonable
> implementation. The solution we have here is one that I've worked with
> Marek for a few months now.
> 
> I don't think we should grow lots of separate mdio-i2c-vendorfoo.c
> drivers - at least not yet. Maybe if we get lots of different access
> methods, it may make sense in the future.
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!