On Jun 1, 2005, at 16:19, Stephen Hemminger wrote:
> Andy Fleming wrote:
>>
>> But not this one. The phy_read and phy_write functions are
>> reading from and writing to a bus. It is a reasonable
>> implementation to have the operation block in the bus driver, and
>> be awoken when an i
On Jun 1, 2005, at 16:41, Stephen Hemminger wrote:
> On Wed, 1 Jun 2005 15:45:26 -0500
> Andy Fleming wrote:
>>
>>> * get rid of bus read may sleep implication in comment.
>>> since you are holding phy spin lock it better not!!
>>>
>>
>>
>
> On a different note, I am not sure that usin
On May 31, 2005, at 12:59, Stephen Hemminger wrote:
> Here are some patches:
> * allow phy's to be modules
> * use driver owner for ref count
> * make local functions static where ever possible
I agree with all these.
> * get rid of bus read may sleep implication in comment.
>
On Wed, 1 Jun 2005 15:45:26 -0500
Andy Fleming wrote:
>
> On May 31, 2005, at 12:59, Stephen Hemminger wrote:
>
> > Here are some patches:
> > * allow phy's to be modules
> > * use driver owner for ref count
> > * make local functions static where ever possible
>
> I agree with all
Andy Fleming wrote:
>
> On May 31, 2005, at 12:59, Stephen Hemminger wrote:
>
>> Here are some patches:
>> * allow phy's to be modules
>> * use driver owner for ref count
>> * make local functions static where ever possible
>
>
> I agree with all these.
>
>> * get rid of bus read m
Here are some patches:
* allow phy's to be modules
* use driver owner for ref count
* make local functions static where ever possible
* get rid of bus read may sleep implication in comment.
since you are holding phy spin lock it better not!!
Untested sinc
On May 26, 2005, at 13:32, Stephen Hemminger wrote:
> I finally got around to looking at this for the new skge driver.
> The Marvell phy code has several issues:
> * hard coded hex values rather than constants
These are hard-coded because it's errata. The errata doesn't name
the registers
I finally got around to looking at this for the new skge driver.
The Marvell phy code has several issues:
* hard coded hex values rather than constants
* doesn't handle restricted autonegotiation
* it doesn't really help the driver that much there are too
many othe
Jeff,
Where do we stand on this. Are there changes you feel need to be made?
Some other issue? It would like to know what we need to do to get
this in post 2.6.12.
thanks
- kumar
On May 10, 2005, at 12:04 PM, Fleming Andy-afleming wrote:
>
>
> On Apr 17, 2005, at 08:00, James Chapman wro
Andy Fleming wrote:
>
> On Apr 17, 2005, at 08:00, James Chapman wrote:
>
>> Andy Fleming wrote:
>>
>>> Ok, here's the new patch with changes suggested by James Chapman:
>>
>>
>> I guess I still have questions about the way interrupts are used.
>>
>> Using an interrupt to schedule a work queue wh
On Apr 17, 2005, at 08:00, James Chapman wrote:
> Andy Fleming wrote:
>> Ok, here's the new patch with changes suggested by James Chapman:
>
> I guess I still have questions about the way interrupts are used.
>
> Using an interrupt to schedule a work queue which then sets a variable
> that is use
Jeff,
I was wondering what the next steps where on getting Andy's PHY
abstraction layer into the kernel.
thanks
- kumar
And here's the patch which converts the gianfar driver to using the PHY
Abstraction Layer:
-- next part --
A non-text attachment was scrubbed...
Name: gfar_03252005.patch
Type: application/octet-stream
Size: 63119 bytes
Desc: not available
Url :
http://ozlabs.org/pipermai
Ok, here's the new patch with changes suggested by James Chapman:
-- next part --
A non-text attachment was scrubbed...
Name: phy_03242005.patch
Type: application/octet-stream
Size: 88433 bytes
Desc: not available
Url :
http://ozlabs.org/pipermail/linuxppc-embedded/attachm
On Mar 15, 2005, at 13:18, James Chapman wrote:
> Hi Andy,
>
> I finally found some time to review your phy abstraction code.
>
> I haven't reviewed the low level MII functions; I focused mostly on
> its API to the net driver and whether it has the necessary hooks to
> handle the various hardware
Hi Andy,
I finally found some time to review your phy abstraction code.
I haven't reviewed the low level MII functions; I focused mostly on
its API to the net driver and whether it has the necessary hooks to
handle the various hardware that I know.
General comment: nice, clean code. No serious s
On Mar 10, 2005, at 17:01, James Chapman wrote:
> 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
On Thu, 2005-03-10 at 18:27 -0500, Jeff Garzik wrote:
> I haven't had time to review the phy abstraction layer, but my gut
> feeling is that there are several common code patterns which could be
> abstracted out, to save code.
>
> Typically there will be one or more phy-specific functions in ea
On Thu, 2005-03-10 at 23:01 +, James Chapman wrote:
> 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 wo
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
Benjamin Herrenschmidt wrote:
> On Thu, 2005-03-10 at 23:01 +, James Chapman wrote:
>
>>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
On Tue, 2005-03-08 at 19:42 -0800, David S. Miller wrote:
> On Wed, 09 Mar 2005 13:14:16 +1100
> Benjamin Herrenschmidt 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.
>
>
On Tue, 2005-03-08 at 19:47 -0600, Andy Fleming wrote:
> I've finally gotten all of ebs's suggestions into the PHY code. Here
> is the new version. It has the following improvements:
>
> * All PHYs now determine speed,duplex, etc using the same generic code,
> rather than PHY-specific register
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 wrote:
>>
>>> I'll have a closer look when I find some time, see if it makes sense
>>> to
>>> adapt sungem or not.
On Mar 8, 2005, at 20:14, Benjamin Herrenschmidt wrote:
> On Tue, 2005-03-08 at 19:47 -0600, Andy Fleming wrote:
>> I've finally gotten all of ebs's suggestions into the PHY code. Here
>> is the new version. It has the following improvements:
>>
>> * All PHYs now determine speed,duplex, etc usi
I've finally gotten all of ebs's suggestions into the PHY code. Here
is the new version. It has the following improvements:
* All PHYs now determine speed,duplex, etc using the same generic code,
rather than PHY-specific registers.
* The genphy driver works for gigabit PHYs now, as well. In
On Wed, 09 Mar 2005 13:14:16 +1100
Benjamin Herrenschmidt 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 programm
27 matches
Mail list logo
