linux-kernel - Re: [PATCH 1/3] net: thunderx: Cleanup PHY probing code.

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: <20160311190627.GC19277@lunn.ch>
Date:	Fri, 11 Mar 2016 20:06:27 +0100
From:	Andrew Lunn <andrew@...n.ch>
To:	David Daney <ddaney@...iumnetworks.com>
Cc:	David Daney <ddaney.cavm@...il.com>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Florian Fainelli <f.fainelli@...il.com>,
	Robert Richter <rric@...nel.org>,
	Sunil Goutham <sgoutham@...ium.com>,
	Kumar Gala <galak@...eaurora.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	Rob Herring <robh+dt@...nel.org>,
	Radha Mohan Chintakuntla <rchintakuntla@...ium.com>,
	linux-kernel@...r.kernel.org, David Daney <david.daney@...ium.com>
Subject: Re: [PATCH 1/3] net: thunderx: Cleanup PHY probing code.

> >I don't see why it should wait around forever. I have boards with
> >Marvell PHYs, yet if i don't build the Marvell driver, the Ethernet
> >driver still loads, because the generic PHY driver is used instead.
> >Why does this not work here?
> 
> As I said before, there is no driver for the device, so
> of_phy_find_device() will always return NULL.

I'm not yet convinced this is true. I really do expect that the
generic PHY driver will bind to it. It might then go horribly wrong,
because it is not standard compliant, but that is a different issue.

The generic driver should probably have a black list for such devices.
This is a PHY issue, not an MDIO issue, and the problem should be
solved in the PHY layer, not in one MDIO driver.

We should also consider what happens when somebody actually writes a
driver for this PHY. Are you not going to use it?

Before this patchset, you did not special case this compatible
string. So at the very least, you need to split this into a separate
patch, so the maintainers can ACK/NACK it, independent of the other
change it is embedded in.

       Andrew