netdev
[Top] [All Lists]

Re: RFC: PHY Abstraction Layer II

To: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
Subject: Re: RFC: PHY Abstraction Layer II
From: Andy Fleming <afleming@xxxxxxxxxxxxx>
Date: Wed, 9 Mar 2005 11:17:54 -0600
Cc: Netdev <netdev@xxxxxxxxxxx>, Embedded PPC Linux list <linuxppc-embedded@xxxxxxxxxx>
In-reply-to: <1110334456.32556.21.camel@gaston>
References: <1107b64b01fb8e9a6c84359bb56881a6@xxxxxxxxxxxxx> <1110334456.32556.21.camel@gaston>
Sender: netdev-bounce@xxxxxxxxxxx

On Mar 8, 2005, at 20:14, Benjamin Herrenschmidt wrote:

On Tue, 2005-03-08 at 19:47 -0600, Andy Fleming wrote:
I've finally gotten all of ebs's suggestions into the PHY code.  Here
is the new version.  It has the following improvements:

* All PHYs now determine speed,duplex, etc using the same generic code,
rather than PHY-specific registers.

Some PHY are doing a better job with PHY specific registers I think ...
The gigabit for example isn't standard, and some PHYs sort-of manage to
deal with non-autoneg hubs in such a way that the "normal" aneg doesn't
succeeds, but the phy specific stuff does work. At least from stuff I've
been told a while ago, I have no direct experience here.

Ah, I should have been a little more clear. All the currently implemented PHY drivers are just using the generic read_status function. Different PHYs can assign their read_status function to be PHY-specific


* The genphy driver works for gigabit PHYs now, as well. In theory, if your PHY isn't broken in some way (I've encountered a number that are),
you should be able to just use genphy.

Isn't the speed reporting of gigabit an implementation specific bit in
lots of PHYs ?

Well, it looks like there are some standard bits which say whether the PHY supports gigabit. I used those.

Andy


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