From: Eugene Surovegin <ebs@ebshome.net>
To: Andy Fleming <afleming@freescale.com>
Cc: Kumar Gala <kumar.gala@freescale.com>,
Netdev <netdev@oss.sgi.com>,
Embedded PPC Linux list <linuxppc-embedded@ozlabs.org>
Subject: Re: [RFC] Patch to Abstract Ethernet PHY support (using driver model)
Date: Thu, 13 Jan 2005 13:21:52 -0800 [thread overview]
Message-ID: <20050113212152.GA16041@gate.ebshome.net> (raw)
In-Reply-To: <61A37C72-659C-11D9-8D70-000393C30512@freescale.com>
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
next prev parent reply other threads:[~2005-01-13 21:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-23 19:01 [RFC] Patch to Abstract Ethernet PHY support (using driver model) Andy Fleming
2004-12-23 21:00 ` Andy Fleming
2005-01-06 7:02 ` Eugene Surovegin
2005-01-06 17:13 ` Eugene Surovegin
2005-01-13 19:50 ` Andy Fleming
2005-01-13 21:21 ` Eugene Surovegin [this message]
2005-01-13 21:58 ` Jörn Engel
2005-01-14 1:00 ` Eugene Surovegin
2005-01-14 14:55 ` Jörn Engel
2005-01-14 15:25 ` Eugene Surovegin
2005-01-14 15:49 ` Jörn Engel
2005-01-14 21:00 ` Andy Fleming
2005-01-17 17:17 ` Jörn Engel
2005-01-13 14:45 ` Kumar Gala
2005-01-13 17:02 ` Stephen Hemminger
2005-01-13 18:22 ` Andy Fleming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050113212152.GA16041@gate.ebshome.net \
--to=ebs@ebshome.net \
--cc=afleming@freescale.com \
--cc=kumar.gala@freescale.com \
--cc=linuxppc-embedded@ozlabs.org \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).