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: <20090121143837.GF21134@pengutronix.de>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ