linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andy Fleming <afleming@freescale.com>
To: Eugene Surovegin <ebs@ebshome.net>
Cc: 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:50:31 -0600	[thread overview]
Message-ID: <61A37C72-659C-11D9-8D70-000393C30512@freescale.com> (raw)
In-Reply-To: <20050106070245.GA6539@gate.ebshome.net>


On Jan 6, 2005, at 01:02, Eugene Surovegin wrote:

> On Thu, Dec 23, 2004 at 03:00:13PM -0600, Andy Fleming wrote:
>>
>>> Adds a Phy Abstraction Layer which allows ethernet controllers to
>>> manage their PHYs without knowing the details of how the particular
>>> PHY device operates.  This code steals heavily from BenH's  sungem
>>> driver, and got some stuff out of Jason McMullan's patch.
>
> Some random notes from quick look at the code:
>
> 1) IMO if we can extract some info from the PHY using _standard_
> registers we should use them, even if the PHY provides some custom
> ones.
>
> 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.

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?

>
> 2) genphy can be changed to handle GigE speeds as well.

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

>
> 3) I think it's better for the genphy case to _detect_ PHY features
> instead of hard coding PHY_BASIC_FEATURES. In this case you can easily
> handle 10/100 and 10/100/1000 PHYs by genphy code.

Ok, that's easy enough

>
> 4) Pause negotiation/advertising is completely missing.

Sigh... I knew someone would ask for that.  I will get right on this.

  parent reply	other threads:[~2005-01-13 19:50 UTC|newest]

Thread overview: 13+ 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 [this message]
2005-01-13 21:21       ` Eugene Surovegin
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

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=61A37C72-659C-11D9-8D70-000393C30512@freescale.com \
    --to=afleming@freescale.com \
    --cc=ebs@ebshome.net \
    --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).