Re: Re: Hotplug events during sleep transition

Patrick Mochel
2005-12-23T15:35:49Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3305 bytes --]

On Fri, 23 Dec 2005, Alan Stern wrote:

> On Thu, 22 Dec 2005, Dmitry Torokhov wrote:
>
> > On Thursday 22 December 2005 22:49, Patrick Mochel wrote:
> > >
> > > On Thu, 22 Dec 2005, Alan Stern wrote:
> > >
> > > > I'm not so sure this approach really qualifies as a "hack". If a driver
> > > > doesn't have explicit support for suspend/resume, the best way to quiesce
> > > > it is to unbind it. The only alternative is to fail all of its I/O
> > > > requests, which seems much less reliable.
> > >
> > > Hmm, the best way to queisce it seems to be to fix the driver. Sure, that
> > > doesn't solve your problems now, but that is the ideal solution, no? Until
> > > then, band-aids like unbinding the device from the driver is only a remedy
> > > to a symptom; not a cure..
> > >
> >
> > Quite often unbinding is easiest and also correct way. I would love to be
> > able to just unbind serio port/input device and have it recreated later.
> > Unfortunately X/GPM do not [yet?] support hotplugging of devices so kernel
> > has to compensate.
>
> I agree with Dmitry. Many drivers don't need to do anything special for
> suspend, or only need to cancel an outstanding input request. Rather than
> go through every single driver and add a minimal (and possibly erroneous)
> suspend routine, it's much easier just to unbind these drivers.

So why not fix the subsystems to do the equivalent of an unbinding, from
a tear-down and reinitialization standpoint? That way, you don't have to
force the core to contort itself simply for the fact that you want to push
in a thumbtack with a sledgehammer?

Think about what is happening. It's been discovered that shutting down the
device and reinitializing the device performs all the correct actions to
get the device up and running again after a suspend/resume cycle. All you
have to do for each suspend routine is mimic that effect. It arguably
doesn't require any serious knowledge about the device - it only needs a
copy of the ->probe() and ->remove() routines (or the functional
equivalent for those devices), without the allocation and freeing of data
structures.

In fact, this sounds an awful lot like the ->start() / ->stop() methods
that have been proposed over the years. I would say that it's time to give
that concept some serious thought and start implementing them in drivers.
That way, for devices that don't actually do hardware PM, we can still get
them down and back up again, without having to worry about those scary
->suspend()/->resume() methods. :-)

I don't find justification to your argument in avoiding to fix drivers. We
don't change the core when it means the impact would be to change every
driver. And, we shouldn't change the core to avoid fixing a subset of
drivers. The number of drivers that it affects should not be 100% of them.

And, as I mentioned before, it should be +/- simple, and without any of
the (unknown) side-effects of binding/unbinding. You said 'possibly
erroneous', but I fail to see how this would be any more dangerous than
unbinding/binding.

If these drivers are maintained, then the maintainers should have no
problem doing what's mentioned above. In fact, some janitors could
probably do it. If the drivers are unmaintained, then perhaps they don't
belong in the kernel anyway?

Thanks,

Patrick