Re: RFC: PHY Abstraction Layer II

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.

> * 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 ?

> * The genphy driver now detects what features the PHY has, rather than 
> relying on arbitrarily hard-coded values
> 
> * Pause negotiation and advertising has been added
> 
> * PHY read and write functions now return errors if the bus read/write 
> functions return errors.  These errors are handled properly, and should 
> not cause any problem.  It is the bus's responsibility, however, to 
> make sure that the PHY is started again once the error is cleared.
> 
> This patch contains just the PHY code.  A later email will contain the 
> gianfar driver and 85xx patches, which will serve as an example for how 
> to use the PHY code.
> 
> A note about size:  I did some rough size comparisons, and it looks 
> like this code adds ~10 K to the binary size of the kernel (for PPC 32, 
> 85xx).  However, that's a rough estimate, since my tree includes 
> features added to the gianfar driver (eg: ethtool support for setting 
> speed/duplex).

I'll have a closer look when I find some time, see if it makes sense to
adapt sungem or not.

Ben.