On Mon, 9 May 2005, Adam Belay wrote:
> > You're taking this too far. "Disable", as in "do not use me", really
> > requires nothing more than that the device be suspended (with remote
> > wakeup turned off) and that the driver respond to requests with an error.
> >
> > What you describe is more like "do your best to pretend this device
> > doesn't exist at all"! I don't see any need to unregister anything,
> > unload drivers, or take other special action.
>
> Really this is an implementation detail. The point I was trying to make is
> that we don't currently have a way of even suspending devices without wakeup.
With David's new (or to be more accurate, old) patch we do!
> However, "pretend this device doesn't exist" seems logical to me, it frees
> memory and removes clutter.
But that's a separate notion from disabling the device. In theory either
of {suspend, forget about} can be done without the other.
> > But even if we didn't know, it wouldn't matter much. The driver would
> > encounter a rash of errors as it tried to communicate with the missing
> > device, and they would end abruptly when we learned that the device had
> > been disconnected.
>
> Most drivers aren't this smart, and not every bus will be happy with drivers
> tearing through the remains of previously removed hardware.
No intelligence is required in the driver. All it has to know is that
when its ->disconnect() callback is invoked it should unbind from the
device. Every driver for a hotpluggable bus is already aware of that.
As for the remains of previously-removed hardware -- I shouldn't think it
matters very much what anybody tries to do to a piece of hardware, once
that hardware has been removed from the system!
The problem arises with buses which nominally are not hotpluggable -- like
PCI -- but from which devices can be removed or added while the system is
asleep. My feeling is users simply shouldn't do that. A hardware
reconfiguration that involves opening up the computer's case should always
be followed by a clean restart.
> > In any case, isn't it up to the bus to detect new devices and removals?
> > Why should removal during suspend be treated any differently from removal
> > at any other time when the device is not in use?
>
> It's a very different situation. Take PCI as an example... If the device has
> been removed while suspended, the goal changes from "restore this device" to
> "free up this saved state information and unregister stuff".
>
> Notice how surprise removal is connected and related with manual device
> disabling. We need to have unregistration infustructure anyway, why not
> handle device disabling completely?
I suppose adding a "forget about this device" API to a hotpluggable bus
would not require much new code. But I also don't see much advantage to
it. If someone could point out a situation where it would be a clear win,
I would change my mind.
> Also, there is no way to ensure that a removal will not occur during a reduced
> power state (dynamic power management) that wasn't invoked by suspend. So, in
> short, hotplug drivers will need to be really robust. I think the PM
> subsystem should try to be helpful here when it can.
>
> Finally, we need to have device resume routines rescan for child devices.
I don't know about other hotpluggable subsystems, but USB handles all this
very well already.
Alan Stern
