netdev - Re: [PATCH net-next 10/17] net: sfp: eliminate mdelay() from PHY probe

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:   Sun, 10 Nov 2019 19:59:16 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 10/17] net: sfp: eliminate mdelay() from PHY
 probe

On Sun, Nov 10, 2019 at 08:37:19PM +0100, Andrew Lunn wrote:
> On Sun, Nov 10, 2019 at 02:06:59PM +0000, Russell King wrote:
> > Rather than using mdelay() to wait before probing the PHY (which holds
> > several locks, including the rtnl lock), add an extra wait state to
> > the state machine to introduce the 50ms delay without holding any
> > locks.
> 
> Hi Russell
> 
> Is this 50ms part of the standard? Or did you find that empirically?

>From what I'm aware, there is no standard for copper SFPs.

It's something that I found works with the Source Photonics module I
have, and after feedback via Jon Nettleton from folk using the SolidRun
platforms.

Hence, it's something I'm preserving in the kernel at the moment, as
we know it works for most people so far.  We can increase it within
reason if necessary (see my reply to your 00/17 reply.)

>From what I can tell, accessing the PHY on I2C address 0x56 just
happens to work for many of the modules because most SFPs use the
Marvell 88E1111 - but there are modules out there (Mikrotik S-RJ01)
that have an Atheros AR8033 PHY which is inaccessible from the host
(and hence the results of the negotiation can't be fully known.)

However, I have a 10M/100M/1G/10G copper SFP+ which uses a Broadcom
Clause 45 PHY which is also accessible (via a slightly different I2C
protocol from the Clause 22 variety) via address 0x56, and there are
other copper SFP+ modules that I've found online that use the same
protocol - but with a delay between the I2C write and I2C read to
read a Clause 45 register.  So, 0x56 *appears* to be some kind of
informally agreed I2C address for SFP PHYs.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up