linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Andy Fleming <afleming@freescale.com>,
	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: Fri, 14 Jan 2005 16:49:51 +0100	[thread overview]
Message-ID: <20050114154951.GC21418@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <20050114152518.GB23768@gate.ebshome.net>

On Fri, 14 January 2005 07:25:18 -0800, Eugene Surovegin wrote:
> On Fri, Jan 14, 2005 at 03:55:18PM +0100, J?rn Engel wrote:
> > Wrt. the proposed PHY lib, I agree.  Didn't even bother to look at the
> > code, it's mere size said enough.
> > 
> > But an abstraction different from drivers/net/mii.c is needed to
> > handle the 5325 chip.  Or, you could have the special cases all over
> > in your code, but that's a) ugly and b) more code.  I used to have
> > such a mess and after doing the proper abstraction, it line count went
> > down.
> 
> Well, I still fail to see what is so _special_ about this chip that it 
> needs "proper abstraction". Could you elaborate, please?
> 
> The way I handled this in my drivers was clean and simple - 
> "there-is-no-PHY". And this wasn't in any case chip-specific and was 
> set up through OCP in board support code. So I'm kinda puzzled what 
> "ugliness and more code" you are talking about.
> 
> We can also make a fake PHY which will always indicate link, will have 
> fixed speed/duplex capabilities and will not support autoneg. If you 
> think this is more elegant, OK, I might even agree with you :).

Exactly.  You need link status, speed and duplex status at the least.
Put query functions for those three into a struct phy_ops or whatever
it may be called and you're done.

Depending on your hardware, you may also need something more
complicated for various fixups, etc.  But it's mostly those three
functions.

> Please, note that wrt current discussion we are interested only in CPU 
> port, not other 5 ports which aren't connected to the CPU at all. This 
> is completely different stuff and yes, if we want to expose them in 
> some way we need another abstraction. But abstraction of switch chips 
> is a big and complex thing - they are very different, and frankly this 
> one you mentioned is quite "feature-challenged" and will not make 
> a good "model" chip IMHO :).

Well, it's one of the few I've had to worry about so far.  I'm a big
non-believer in abstractions I just don't need yet.  The one outlined
above I already needed.

Jörn

-- 
To announce that there must be no criticism of the President, or that we
are to stand by the President, right or wrong, is not only unpatriotic
and servile, but is morally treasonable to the American public.
-- Theodore Roosevelt, Kansas City Star, 1918

  reply	other threads:[~2005-01-14 15:49 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
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 [this message]
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=20050114154951.GC21418@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --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).