public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: John Newlin <jnewlin@rawbw.com>
To: Gary Thomas <gary@mlbassoc.com>
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] devs/eth/phy/current/src/eth_phy.c
Date: Wed, 26 May 2004 22:30:00 -0000	[thread overview]
Message-ID: <20040526145728.L37485@shell.rawbw.com> (raw)
In-Reply-To: <1085607010.15478.282.camel@hermes>


> On Wed, 2004-05-26 at 15:28, John Newlin wrote:
> > > On Wed, 2004-05-26 at 15:07, Gary Thomas wrote:
> > > > On Wed, 2004-05-26 at 15:03, John Newlin wrote:
> > > > > I see there looks that there was some attempt at making a generic phy
> > > > > interface, but I don't see that it is used anywhere.  Is this a work in
> > > > > progress, or is there an example of this in use in some other code?
> > > >
> > > > It *is* used - look at the rattler and MOAB packages.
> > >
> > > Also, look at the common ethernet drivers they use
> > >   devs/eth/powerpc/{fec,fcc,ppc405}
> > > to see how the actual PHY interfaces work.
> > >
> >
> > Thanks Gary!
>
> No problem.  Of course, I'm very interested in any feedback you have on
> these interfaces [since, so far, I'm the only one that has used them]

One comment. _eth_phy_init walks through the 32 possible PHY addresses to
locate the PHY.  For a chip with a single MAC interface this is fine.
The chip I am working with has more than 1 MAC, but a single MII
Management interface is used to configure multiple external PHYS.

Maybe instead, have the driver that is supplying eth_phy_access_t, supply
a valid PHY address, and it would just look at that PHY address for the
PHY.  Or it could pass a special value, like -1, to signify that the code
should scan for the PHY.

Alternatively, if the function pointers supplied in eth_phy_access_t took,
eth_phy_access_t as the first parameters, you could stuff some extra data
at the end of that structure, and the called functions could do the
address check.

Do you have another suggestion, surely there are other chips that have
multiple MAC interfaces.  I thought powerquicc had more than 1 mac.

-john


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  reply	other threads:[~2004-05-26 22:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-26 21:10 John Newlin
2004-05-26 21:28 ` Gary Thomas
2004-05-26 21:30   ` Gary Thomas
2004-05-26 22:08     ` John Newlin
2004-05-26 22:11       ` Gary Thomas
2004-05-26 22:30         ` John Newlin [this message]
2004-05-26 22:38           ` Gary Thomas

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=20040526145728.L37485@shell.rawbw.com \
    --to=jnewlin@rawbw.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=gary@mlbassoc.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 read-only IMAP folder(s) and NNTP newsgroup(s).