[Top] [All Lists]

Re: RFC: PHY Abstraction Layer II

To: Jeff Garzik <jgarzik@xxxxxxxxx>
Subject: Re: RFC: PHY Abstraction Layer II
From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 11 Mar 2005 10:27:47 +1100
Cc: James Chapman <jchapman@xxxxxxxxxxx>, Andy Fleming <afleming@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, "David S. Miller" <davem@xxxxxxxxxxxxx>, linuxppc-embedded@xxxxxxxxxx
In-reply-to: <4230D7F4.8060900@xxxxxxxxx>
References: <1107b64b01fb8e9a6c84359bb56881a6@xxxxxxxxxxxxx> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@xxxxxxxxxxxxx> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@xxxxxxxxxxxxx> <4230D1AC.5070506@xxxxxxxxxxx> <1110495992.32525.290.camel@gaston> <4230D7F4.8060900@xxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Thu, 2005-03-10 at 18:27 -0500, Jeff Garzik wrote:

> I haven't had time to review the phy abstraction layer, but my gut 
> feeling is that there are several common code patterns which could be 
> abstracted out, to save code.
> Typically there will be one or more phy-specific functions in each 
> 10/100 or GigE driver, falling back to a default 'genphy' driver when 
> things are completely MII/GMII-compatible.

Exactly. One thing for which i usually need PHY specific functions
(pretty much all the time) is PHY init (thanks Broadcom) and suspend.


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