netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).