Benjamin Herrenschmidt wrote:

On Thu, 2005-03-10 at 23:01 +0000, James Chapman wrote:

quoted

Hi Andy,

Can you elaborate on why this phy abstraction is needed?

In your original post, you mentioned that you were going to post a
patch to show how your code would be hooked up in an existing net
driver. Did I miss it? It would help in understanding the pros and cons
of using genphy over using plain old mii.c.

btw, I recently posted a patch to add GigE support to mii.c which is
in Jeff's netdev-2.6 queue. Some register definitions were added in
mii.h that will collide with yours.

A variety of PHY chips require special cases that aren't handled by the
generic mii code. The PHY driver layer allows to plug PHY specific
drivers, with genphy just being the "default" for sane chips.

Also, I think Andy added more to the PHY layer than what mii does, like
support for the interrupt or timer based link management etc... which
tend to be the same in a lot of drivers.

Nod.

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.

	Jeff