From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andy Fleming <afleming@freescale.com>
Cc: jason.mcmullan@timesys.com, netdev@oss.sgi.com,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] MII bus API for PHY devices
Date: Fri, 19 Nov 2004 10:26:31 +1100 [thread overview]
Message-ID: <1100820391.25521.14.camel@gaston> (raw)
In-Reply-To: <9B0D9272-398A-11D9-96F6-000393C30512@freescale.com>
On Thu, 2004-11-18 at 11:52 -0600, Andy Fleming wrote:
> 1) How should we pass initialization information from the system to the
> bus. Information like which irq to use for each PHY, and what the
> address space for the bus's controls is. I would like to enforce
> encapsulation so that the ethernet drivers don't need to know this
> information, or pass it to the bus.
Unfortunately, this is all quite platform specific and the ethernet
driver may be the only one to know what to do here... add to that
various special cases of the way the PHY is wired or controlled, I think
we can't completely avoid special casing...
> 2) How should we reflect the dependency of the ethernet driver on the
> mii bus driver?
The ethernet driver can instanciate the PHYs at it's childs, though the
case of several MACs sharing PHYs will be difficult to represent...
> 3) How should we bind ethernet drivers to PHY drivers?
I would have them instanciated by the ethernet driver. Besides, the PHY
driver will need to be able to identify it's "parent" driver in some
ways to deal with special cases. It would be nice to have a library of
utility code to independently deal with link tracking (basically what
drivers like sungem do independently), with a callback to the ethernet
driver to inform it of actual changes (notifier ?). MACs often have
autopoll features and PHY often have interrupts, but from experience,
that's not very useful and a good old timer based polling tend to do a
better job most of the time.
> Oh, and a 4th side-issue:
> Should each PHY have its own file? Or should we dump all the PHY
> drivers in one file? And if so, should THAT file be separate from the
> mii bus implementation file?
I'd put all bcm5xxx in the same file ... they can be put together by
families...
Also,
next prev parent reply other threads:[~2004-11-18 23:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <069B6F33-341C-11D9-9652-000393DBC2E8@freescale.com>
2004-11-18 17:52 ` [PATCH] MII bus API for PHY devices Andy Fleming
2004-11-18 19:34 ` Jason McMullan
2004-11-18 19:50 ` Andy Fleming
2004-11-18 21:00 ` Jason McMullan
2004-11-18 23:26 ` Benjamin Herrenschmidt [this message]
2004-11-19 16:41 ` Jason McMullan
2004-11-19 21:18 ` Andy Fleming
2004-11-19 22:43 ` Benjamin Herrenschmidt
2004-11-20 0:04 ` Andy Fleming
2004-11-23 18:18 ` Jason McMullan
2004-12-02 18:29 ` [PATCH] MII bus API for PHY devices Rev 2.0 Jason McMullan
2004-11-19 20:18 [PATCH] MII bus API for PHY devices Manfred Spraul
2004-11-19 21:01 ` 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=1100820391.25521.14.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=afleming@freescale.com \
--cc=jason.mcmullan@timesys.com \
--cc=linux-kernel@vger.kernel.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).