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

[David Brownell <david-b@pacbell.net>]

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

On Thursday 12 May 2005 3:06 pm, Adam Belay wrote:
> 
> 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.

Users haven't yet needed it ... or sysadmins either.  I don't see
why this should need any policy decisions at all.  If unused/idle
devices would just stay in low power modes all the time, then the
only issue would be buggy hardware ... and buggy hardware calls for
hardware-specific workarounds, always.  (Either in infrastructure
quirk code, or in the devices' drivers.)

For example, lots of ARM chips (in embedded hardware) leave most
things unclocked, and where relevant also powered down, until they're
needed.  That's just the way things are ... reset powers things
down, the bootloader (maybe something like U-Boot) turns on enough
to get Linux started, and then Linux turns on other things as
needed.

Many PCI devices could do the same thing, and stay in D3hot state
until some more active mode is needed.


> 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.

Drivers are expected to initialize using the current hardware state.
If they can't, it's a driver bug.  They normally leave PCI config
space alone.

- Dave

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