On Tue, 25 Mar 2008, Oliver Neukum wrote: > Am Dienstag, 25. März 2008 14:06:15 schrieb Rafael J. Wysocki: > > On Tuesday, 25 of March 2008, Oliver Neukum wrote: > > > > A device that cannot wake up is unusable. Shouldn't the pm core disconnect() > > > such a device? It's not safe for the PM core to do such things unilaterally. The decision to unregister a device should be made by the driver or the subsystem. (The only problem is that it's impossible to unregister a device from within its suspend or resume methods. Perhaps there should be a way for the driver to tell the PM core that the core should unregister the device as soon as the method returns. I don't know if such a facility would get used...) > > Well, if ->resume() returns an error, the driver already knows there's a > > problem and it can act upon that, at least in principle. > > Then why return an error? If a driver returns an error I would assume that > to indicate an irrecoverable error. The PM core prints a warning in the system log whenever an error is returned. There isn't much more it can do. > > However, the PM core probably shouldn't try to resume the children of a failing > > device. Also, if ->resume_noirq() fails, it probably is not a good idea to > > call ->resume() and ->complete() for the same device and for it's children. > > Exactly. But we need to define what happens in these cases. If we simply > ignore the errors, the drivers must be able to deal with IO to half suspended > devices. Just so -- it's up to the drivers to deal with this sort of thing. The PM core can't know the details of what should be done in each case. For example, if a USB hub can't be resumed then usbcore marks all of its descendants with USB_STATE_NOTATTACHED. When the children's resume methods are called, they return without trying to do anything. Later on khubd takes care of unregistering everything. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
