netdev - Incompatible phys driven by Marvell phy driver?

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>] [day] [month] [year] [list]

Date:	Fri, 13 Dec 2013 11:06:04 +0000
From:	Ian Campbell <ijc@...lion.org.uk>
To:	netdev@...r.kernel.org
Cc:	Michal Simek <michal.simek@...inx.com>,
	Stef van Os <stef.van.os@...drive.nl>,
	Rick Hoover <RHoover@...ilentinc.com>,
	Steven Wang <steven.wang@...ilentinc.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	"David S. Miller" <davem@...emloft.net>, 723177@...s.debian.org
Subject: Incompatible phys driven by Marvell phy driver?

Hi,

In Debian bug #723177[0] Lennert Buytenhek reports[1] that the Marvell
phy driver tries to driver some Marvell phys which have differing
register layouts:
        
        The problem here was that the Marvell PHY driver at some point supported
        one or two specific Marvell ethernet PHY models, and people then started
        blindly adding new PHY IDs to it without checking whether the already
        supported PHYs and the PHYs for which support was being added had common
        register layouts (and they didn't).
        
        The result is that on some of the very common Marvell PHYs that this
        driver claims to support, the driver does sequences of register writes
        that have entirely different effects than the intended ones, causing
        various unintended side effects, including complete link failure, and
        e.g. on the quad ethernet PHY on some of the mv78xx0 development
        boards, having the Marvell PHY driver enabled causes link to flap on
        the other three ports if you plug/unplug one of the ports because the
        driver thinks it's a good idea to hard reset the whole chip under
        these circumstances...
        
        What needs to be done is that someone with access to the relevant
        Marvell datasheets fix the driver to behave according to which chip
        it's being used on.  It's quite a bit of work to sort out this mess,
        easily several tens of hours -- I started looking into it when I was
        still at Marvell, but didn't get it done before leaving.

I've tried to look into this but apparently most of the data sheets are
not publicly available, so I cannot even determine which phy's are being
driven incorrectly, let alone propose a fix. From my PoV it would be
sufficient to remove the incorrect PHYs from the phy table until they
are fixed properly.

I've CCd a bunch of people who have touched the driver, especially those
adding new Phys in the last couple of years. Do any of you have
sufficient access to datasheets to at least identify which PHYs might be
driven incorrectly?

Thanks,
Ian.

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723177
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723177#50

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html