From: James Chapman <jchapman@katalix.com>
To: Andy Fleming <afleming@freescale.com>
Cc: linuxppc-embedded@ozlabs.org,
"David S. Miller" <davem@davemloft.net>,
netdev@oss.sgi.com
Subject: Re: RFC: PHY Abstraction Layer II
Date: Thu, 10 Mar 2005 23:01:00 +0000 [thread overview]
Message-ID: <4230D1AC.5070506@katalix.com> (raw)
In-Reply-To: <57a429f8eb807987d88b06129861d507@freescale.com>
Hi Andy,
Can you elaborate on why this phy abstraction is needed?
In your original post, you mentioned that you were going to post a
patch to show how your code would be hooked up in an existing net
driver. Did I miss it? It would help in understanding the pros and cons
of using genphy over using plain old mii.c.
btw, I recently posted a patch to add GigE support to mii.c which is
in Jeff's netdev-2.6 queue. Some register definitions were added in
mii.h that will collide with yours.
/james
Andy Fleming wrote:
>
> On Mar 8, 2005, at 21:50, Benjamin Herrenschmidt wrote:
>
>> On Tue, 2005-03-08 at 19:42 -0800, David S. Miller wrote:
>>
>>> On Wed, 09 Mar 2005 13:14:16 +1100
>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>>>
>>>> I'll have a closer look when I find some time, see if it makes sense to
>>>> adapt sungem or not.
>>>
>>>
>>> Especially because of the Broadcom PHYs I bet it doesn't.
>>>
>>> Too many chips have to reset the MAC, or do other fancy stuff
>>> when programming the PHY to make this genphy thing very useful.
>>
>>
>> Oh, I think genphy is just a generic driver, but his layer has hooks for
>> other PHY drivers (wasn't it based on sungem_phy in the first place ?)
>
>
> Definitely. Much of this code was culled from the sungem and ibm_emac
> drivers, with some input from mii.c. The genphy driver is just one of
> the 6 PHY drivers in the patch I sent (the others are Marvell, Davicom,
> Cicada, QS, LXT). Actually, several of those files have multiple
> drivers in them. The genphy driver is the fallback driver. It exists
> for those PHYs which never get a driver, but don't need special attention.
>
>>
>> I discussed several steps of the design with Andy, the idea was to have
>> something a bit like sungem_phy.c with addditional common library for
>> doing the link polling & fallback stuff etc... that could be easily
>> shared by drivers.
>
>
> Yup. I look forward to your input on how well the code meshes with what
> people need for their drivers.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
WARNING: multiple messages have this Message-ID (diff)
From: James Chapman <jchapman@katalix.com>
To: Andy Fleming <afleming@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
netdev@oss.sgi.com, "David S. Miller" <davem@davemloft.net>,
linuxppc-embedded@ozlabs.org
Subject: Re: RFC: PHY Abstraction Layer II
Date: Thu, 10 Mar 2005 23:01:00 +0000 [thread overview]
Message-ID: <4230D1AC.5070506@katalix.com> (raw)
In-Reply-To: <57a429f8eb807987d88b06129861d507@freescale.com>
Hi Andy,
Can you elaborate on why this phy abstraction is needed?
In your original post, you mentioned that you were going to post a
patch to show how your code would be hooked up in an existing net
driver. Did I miss it? It would help in understanding the pros and cons
of using genphy over using plain old mii.c.
btw, I recently posted a patch to add GigE support to mii.c which is
in Jeff's netdev-2.6 queue. Some register definitions were added in
mii.h that will collide with yours.
/james
Andy Fleming wrote:
>
> On Mar 8, 2005, at 21:50, Benjamin Herrenschmidt wrote:
>
>> On Tue, 2005-03-08 at 19:42 -0800, David S. Miller wrote:
>>
>>> On Wed, 09 Mar 2005 13:14:16 +1100
>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>>>
>>>> I'll have a closer look when I find some time, see if it makes sense to
>>>> adapt sungem or not.
>>>
>>>
>>> Especially because of the Broadcom PHYs I bet it doesn't.
>>>
>>> Too many chips have to reset the MAC, or do other fancy stuff
>>> when programming the PHY to make this genphy thing very useful.
>>
>>
>> Oh, I think genphy is just a generic driver, but his layer has hooks for
>> other PHY drivers (wasn't it based on sungem_phy in the first place ?)
>
>
> Definitely. Much of this code was culled from the sungem and ibm_emac
> drivers, with some input from mii.c. The genphy driver is just one of
> the 6 PHY drivers in the patch I sent (the others are Marvell, Davicom,
> Cicada, QS, LXT). Actually, several of those files have multiple
> drivers in them. The genphy driver is the fallback driver. It exists
> for those PHYs which never get a driver, but don't need special attention.
>
>>
>> I discussed several steps of the design with Andy, the idea was to have
>> something a bit like sungem_phy.c with addditional common library for
>> doing the link polling & fallback stuff etc... that could be easily
>> shared by drivers.
>
>
> Yup. I look forward to your input on how well the code meshes with what
> people need for their drivers.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
next prev parent reply other threads:[~2005-03-10 23:01 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-09 1:47 RFC: PHY Abstraction Layer II Andy Fleming
2005-03-09 1:47 ` Andy Fleming
2005-03-09 2:14 ` Benjamin Herrenschmidt
2005-03-09 3:42 ` David S. Miller
2005-03-09 3:42 ` David S. Miller
2005-03-09 3:50 ` Benjamin Herrenschmidt
2005-03-09 3:50 ` Benjamin Herrenschmidt
2005-03-09 17:24 ` Andy Fleming
2005-03-10 23:01 ` James Chapman [this message]
2005-03-10 23:01 ` James Chapman
2005-03-10 23:06 ` Benjamin Herrenschmidt
2005-03-10 23:06 ` Benjamin Herrenschmidt
2005-03-10 23:27 ` Jeff Garzik
2005-03-10 23:27 ` Jeff Garzik
2005-03-10 23:27 ` Benjamin Herrenschmidt
2005-03-10 23:27 ` Benjamin Herrenschmidt
2005-03-15 0:41 ` Andy Fleming
2005-03-15 0:41 ` Andy Fleming
2005-03-15 19:18 ` James Chapman
2005-03-15 19:18 ` James Chapman
2005-03-18 23:14 ` Andy Fleming
2005-03-18 23:14 ` Andy Fleming
2005-03-24 21:48 ` Andy Fleming
2005-03-24 21:48 ` Andy Fleming
2005-03-25 22:56 ` Andy Fleming
2005-03-25 22:56 ` Andy Fleming
2005-03-28 23:45 ` Kumar Gala
2005-03-28 23:45 ` Kumar Gala
2005-03-29 4:11 ` Problem when accessing variables Hiep Tran
2005-04-17 13:00 ` RFC: PHY Abstraction Layer II James Chapman
2005-05-10 17:04 ` Andy Fleming
2005-05-10 17:04 ` Andy Fleming
2005-05-12 6:08 ` Pantelis Antoniou
2005-05-25 23:00 ` Kumar Gala
2005-05-25 23:00 ` Kumar Gala
2005-03-09 17:17 ` Andy Fleming
2005-05-26 18:32 ` Stephen Hemminger
2005-05-26 18:45 ` Andy Fleming
2005-05-31 17:59 ` Stephen Hemminger
2005-06-01 20:45 ` Andy Fleming
2005-06-01 21:19 ` Stephen Hemminger
2005-06-01 22:42 ` Andy Fleming
2005-06-01 21:41 ` Stephen Hemminger
2005-06-01 22:36 ` Andy Fleming
2005-06-05 20:29 ` Glen Turner
2005-06-09 21:32 ` Andy Fleming
2005-06-28 6:38 ` Glen Turner
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=4230D1AC.5070506@katalix.com \
--to=jchapman@katalix.com \
--cc=afleming@freescale.com \
--cc=davem@davemloft.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.