On Thu, Jan 13, 2005 at 01:50:31PM -0600, Andy Fleming wrote:
> >I suspect that _all_ XXX_read_status functions for different PHYs in
> >your patch can be easily handled by generic IEEE 802.3 compliant code
> >(you need to update genphy_read_status to properly handle GigE of
> >course).
>
> Ok, I understand this, but a part of me rebels. The "standard"
> procedure is to read the Link Partner Advertisement, AND it with the
> Advertisement, and then find the highest setting that works. It seems
> to me that this is replicating work that is already done by the PHY,
> and I hate to do work that's already been done.
Well, some PHYs have a non-standard way to get this info, some PHYs
don't. I don't understand why do you want to bloat kernel with
knowledge of this PHY-specific registers when there is a standard way
to get this info? In fact I use IBM EMAC with a lot of different PHYs
and never needed this special code, except only PHY initialization
maybe.
> I also have one worry about this technique (though I'm still reading
> the 802.3 spec to see if my worry is valid). Is it possible that the
> PHY would choose a setting which is lower than the highest possible,
> and therefore render the method above inaccurate?
It's a standard, period. If there is a PHY which isn't compliant I
guess it will not work anyway, but in this case, yes, we can use
PHY-specific link detection, but only in this case. I suspect you'll
have a hard time finding such PHY :)
> Yeah, that's not a problem. I just wasn't sure if the bits were
> properly defined on non-gigabit PHYs. I will change this, as long as
> the relevant bits are always correct on 10/100 PHYs
I use ES bit in MII_BMSR register to detect availability of MII_ESR
register. So far it worked OK with number of 10/100 PHYs.
> >4) Pause negotiation/advertising is completely missing.
>
> Sigh... I knew someone would ask for that. I will get right on this.
This is not that difficult, I have example code in NAPI IBM EMAC
driver (http://kernel.ebshome.net).
--
Eugene
|