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!
