linux-mips
[Top] [All Lists]

Re: RFC: au1000_etc.c phylib rewrite

To: ppopov@embeddedalley.com, Herbert Valerio Riedel <hvr@gnu.org>
Subject: Re: RFC: au1000_etc.c phylib rewrite
From: Mark Schank <mschank@dcbnet.com>
Date: Mon, 01 May 2006 15:09:15 -0500
Cc: sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, jgarzik@pobox.com
In-reply-to: <1146510945.21947.44.camel@localhost.localdomain>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1146510542.16643.10.camel@localhost.localdomain> <1146510542.16643.10.camel@localhost.localdomain>
Sender: linux-mips-bounce@linux-mips.org
The Cogent CSB655 used the Broadcom Dual Phy. They eventually redesigned the board and switched to two single Broadcom phys, but they continued to control both phys through MAC0, which is the actual purpose of the dual-phy hack. I am a user of the CSB655, so I sort of care.

Will the new PHY framework allow a second PHY for a second MAC (MAC1) be controlled from the first MAC's (MAC0) mdio interface?

Yes, I acknowledge this was a bad design, but its what I am stuck with.

-Mark

At 12:15 PM 5/1/06 -0700, Pete Popov wrote:
On Mon, 2006-05-01 at 21:09 +0200, Herbert Valerio Riedel wrote:
> hello *,
>
> I've started to rewrite the au1000_eth.c driver to make use of the new
> PHY framework in 2.6.x; see the attached patch for the current work in
> progress state;
>
> I'm a bit unsure what to do about those workarounds/hacks that are in
> the original au1000_eth.c driver (e.g. for the broadcom dual PHY);

Maybe you should dump that bcm dual phy support. I can't remember what
board it was on and whether that board is even supported still.

> any comments/ideas? shall I continue work on this au1xxx-eth
> phylib-rewrite, or is it of no use?

Seems like a good idea to me.

Pete



<Prev in Thread] Current Thread [Next in Thread>