Re: Totally broken PCI PM calls

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

On Monday 11 October 2004 9:09 pm, Dmitry Torokhov wrote:
> On Monday 11 October 2004 10:00 pm, David Brownell wrote:

> > OHCI has to do this when the controller loses power during suspend;
> > which includes many suspend-to-disk cases.  It marks the devices dead,
> > kills the I/O queues, and then makes khubd do all the work.
> >
> 
> Yes, I see that. But so far every bus implements it in its own way - USB,
> IEEE1394, serio, pcmcia... It would be nice if there was a standard
> mechanism to deal with that situation. And actually a standard way of
> pruning part of the device tree which is useful for other things as well.

Certainly.  It _shouldn't_ be too tricky adding that to the PM core,
but there are issues including how to get the locking right when
tasks are concurrently walking the device tree.  The issue comes
up with PCI/Cardbus hotplugging too, so it's not really offtopic ... ;) 


> > USB decided against the extra argument; drivers don't much care
> > at that point.  And anyway, they can tell the device is gone by looking
> > at status codes returned by URB completion or submission.
> > 
> 
> It really depends on the bus I think... I do not know USB well enough but
> does status code gives you enough information to determine that the device
> is gone or it's just not responding for mose reason?

There's a window between "unplug" and "khubd notices unplug"
where requests give controller-specific status reports, some of which
translate directly to "not responding".  The driver's fault recovery
mechanism will eventually start seeing "device gone", once khubd
notices.  Other than network drivers, most drivers usually see the
"gone" status first, or disconnect() if they had no pending URBs.

That's much the same as PCMCIA/Cardbus:  register reads will
return ~0 for a while before disconnect notification.

- Dave