linux-kernel - Re: [PATCH 1/1] IBM PPC EMAC driver:improved support for PHY configuration

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: <1177633116.14873.271.camel@localhost.localdomain>
Date:	Fri, 27 Apr 2007 10:18:36 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Jeff Haran <jharan@...cade.COM>
Cc:	ebs@...home.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] IBM PPC EMAC driver:improved support for PHY
	configuration

On Thu, 2007-04-26 at 16:18 -0700, Jeff Haran wrote:
> From: Jeff Haran  <jharan@...cade.com>
> 
> This patch fixes some problems I found while debugging the IBM EMAC
> driver for PPC32 systems.
> The first problem was in the function that configures the PHY for
> autonegotiation, genmii_setup_aneg(). The original code does a
> read/modify/write of the autonegotiation advertizement register (reg 4),
> followed by a read/modify/write of the control register (reg 0). While
> the original code follows the proper procedure as per reading the IEEE
> specs, what I found is that on at least one PHY model (National DP83843)
> the read of the control register comes back with the soft reset bit set
> (bit 15).

Good catch ! I've seen that behaviour in the past too. Note that sungem
has this problem too.

 .../...

> The second problem was in the function that configures the PHY for
> forced operation, genmii_setup_forced(). The original code initiates a
> software reset operation via a write of a 1 to bit 15 of the control
> register (reg 0), but then proceeds to do a second write to that same
> register without waiting until that reset bit is cleared by the PHY
> itself (which according to the IEEE specs indicates that the PHY reset
> is complete). This is a violation of how one is supposed to use this
> software reset feature of these PHYs and I believe was the cause of
> mysterious, difficult to reproduce link failures that we've observed on
> some of our systems that use this driver. The fix is to modify the
> function so that it spins waiting for the reset bit to clear after doing
> the soft reset and before doing the subsequent write. Since this
> modification, we haven't seen the mysterious link failures, though they
> were so rare its difficult to say at this point whether this was the
> cause.

This is also a bug inherited from sungem (thus my fault).

> I also added some error handling and reporting for the abnormal case
> where the reset bit never clears from the soft reset operation.
> Applied to kernel version 2.6.21.

Your patch appears to have been line wrapped by your mailer though...

Cheers,
Ben.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/