Re: [patch 2.6.12-rc4] remove driver model detach_state

[Adam Belay <ambx1@neo.rr.com>]

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

On Thu, May 12, 2005 at 01:37:05PM -0700, Greg KH wrote:
> On Thu, May 12, 2005 at 03:31:22PM -0400, Alan Stern wrote:
> > On Thu, 12 May 2005, David Brownell wrote:
> > 
> > > This mechanism has never AFAICT been used, and I asked a while back
> > > if anyone knew of uses ... no takers, even though it's been in the
> > > kernel for almost two years by now.
> > > 
> > > Here's a patch to remove the thing.  AFAICT, suitable to merge ASAP;
> > > it reduces sysfs size impact, and is a net code shrink.
> > 
> > Note that for Greg's "driver" tree, some of the changes you made to bus.c 
> > will have to apply to dd.c instead.  Maybe Greg will fix this up by 
> > himself; I still don't know how he manages to juggle multiple conflicting 
> > source trees...
> 
> Don't worry, I can handle it :)
> 
> > On the whole this looks like a good thing to do.
> 
> I agree.  Will apply it later this evening.
> 
> greg k-h

Although I agree with this patch, I think it's important that we don't
forget about the code's original intentions.  When manual driver binding
and unbinding is supported, it would be nice if we could specify a detach
state.  My guess is that this should only include "on" or "off", but not
any intermediate states.

->remove isn't good enough, as the driver developer makes the decision
"let's turn off the device before detaching" or "let's leave it on".
This will vary between implementations. I think it may be better to
allow the user to specify this.

Finally, if the device is disabled, the configuration (e.g. PCI config
space) may need to be restored for the device to work on a future
driver.  This seems like a tricky problem if the driver is removed.

Selective suspend may be a better alternative, in which case, we need to
decide if it will unregister class devices etc. (as I suggested earlier)
or just do a somewhat regular device_suspend().

Driver binding/unbinding and requests to disable a device play an
interesting role in power management.  It would be nice if we could
define some goals for this.

Thanks,
Adam


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]