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
