netdev - Re: [PATCH 3/6] arm: convert pcm037 platform to use smsc911x

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:	Wed, 21 Jan 2009 15:38:37 +0100
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	Mark Brown <broonie@...ena.org.uk>
Cc:	Steve Glendinning <steve.glendinning@...c.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>,
	Russell King <linux@....linux.org.uk>,
	Stanley Miao <stanley.miao@...driver.com>,
	Ian Saturley <ian.saturley@...c.com>
Subject: Re: [PATCH 3/6] arm: convert pcm037 platform to use smsc911x

On Wed, Jan 21, 2009 at 10:58:15AM +0000, Mark Brown wrote:
> On Tue, Jan 20, 2009 at 04:29:51PM +0100, Sascha Hauer wrote:
> 
> > The reason for this is not the driver, it's just that the hardware
> > designers got the direction of the phy detect pin wrong. The pcm037 uses
> > an internal phy, but the detection pin is pulled high :(
> 
> A brief survey of boards I have here suggests that this failure is not
> unique.
> 
> > The old driver worked around this by falling back to the internal phy
> > when no valid phy id is detected. The new driver lacks this fallback.
> 
> > Instead of falling back we could also introduce a
> > SMSC911X_FORCE_INTERNAL_PHY flag.
> 
> If we have the explicit flag in the platform data my concern would be
> that it would get reported back to the hardware designers and they might
> fix the board in subsequent revisions.  That'd cause issues if the
> revision of the board weren't identifiable from software (which wouldn't
> surprise me at all).

That's why I haven't told the hardware designers yet ;)

Anyway, a FORCE_INTERNAL_PHY flag would still do the right thing. At
least as long the hardware designers do not decide to put an external
phy in the next hardware revision.
If we decide to add such a flag we should add an FORCE_EXTERNAL_PHY
aswell for the sake of completeness.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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