| 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@xxxxxxxxxxxxx> |
| Organization: | Open Source Development Lab |
| References: | <1107b64b01fb8e9a6c84359bb56881a6@xxxxxxxxxxxxx> <20050531105939.7486e071@xxxxxxxxxxxxxxxxx> <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@xxxxxxxxxxxxx> |
| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] ieee80211: Update generic definitions to latest specs., Stephen Hemminger |
|---|---|
| Next by Date: | Re: Locking model for NAPI drivers, David S. Miller |
| Previous by Thread: | Re: RFC: PHY Abstraction Layer II, Andy Fleming |
| Next by Thread: | Re: RFC: PHY Abstraction Layer II, Andy Fleming |
| Indexes: | [Date] [Thread] [Top] [All Lists] |