aboutsummaryrefslogtreecommitdiff
path: root/drivers/bluetooth
diff options
context:
space:
mode:
authorEugene Surovegin <ebs@ebshome.net>2007-05-16 11:59:48 -0700
committerJeff Garzik <jeff@garzik.org>2007-05-17 20:43:14 -0400
commit5bb96e9f2434b49a5b8f135f2a384974aa73db51 (patch)
treed7dd01739b93f709114add365e558550f48817e6 /drivers/bluetooth
parent0ec6d95053885055a50d973b3a3906905a78a8bf (diff)
ibm_emac: improved PHY support
Original patch is from Jeff Haran <jharan@brocade.com> with my minor style fixes. His comments follow: 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). Because of the read/modify/write operation, this causes the write to write a 1 back to the reset bit, which initiates a software reset of the PHY. This software reset causes the PHY to return to its power up state which advertizes all modes of operation, thus negating the write to the autoneg advertizement register. The modification is to spin reading the control register until the soft reset bit is clear before doing the modify/write. 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. Signed-off-by: Jeff Haran <jharan@brocade.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Eugene Surovegin <ebs@ebshome.net> Signed-off-by: Jeff Garzik <jeff@garzik.org>
Diffstat (limited to 'drivers/bluetooth')
0 files changed, 0 insertions, 0 deletions