netdev
[Top] [All Lists]

Re: RFC: PHY Abstraction Layer II

To: Andy Fleming <afleming@xxxxxxxxxxxxx>
Subject: Re: RFC: PHY Abstraction Layer II
From: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Wed, 1 Jun 2005 14:41:23 -0700
Cc: Netdev <netdev@xxxxxxxxxxx>, Embedded PPC Linux list <linuxppc-embedded@xxxxxxxxxx>, Kumar Gala <kumar.gala@xxxxxxxxxxxxx>
In-reply-to: <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com>
Organization: Open Source Development Lab
References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com>
Sender: netdev-bounce@xxxxxxxxxxx
On Wed, 1 Jun 2005 15:45:26 -0500
Andy Fleming <afleming@xxxxxxxxxxxxx> 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 may sleep implication in comment.
> >       since you are holding phy spin lock it better not!!
> 

On a different note, I am not sure that using sysfs/kobject bus object
is the right thing for this object.  Isn't the phy instance really just
an kobject whose parent is the network device?  I can't see a 1 to N
relationship between phy bus and phy objects existing. 

The main use I can see for being a driver object is to catch suspend/resume,
and wouldn't you want that to be tied to the network device.

<Prev in Thread] Current Thread [Next in Thread>