Am Dienstag, 20. Oktober 2009 21:45:30 schrieb Alan Stern: > On Tue, 20 Oct 2009, Oliver Neukum wrote: > > Am Dienstag, 20. Oktober 2009 20:34:36 schrieb Alan Stern: > > > On Tue, 20 Oct 2009, Oliver Neukum wrote: > > > > Am Dienstag, 20. Oktober 2009 18:10:39 schrieb Alan Stern: > > > > > Oliver: > > > > > > > > > > There are a couple of significant differences between the existing > > > > > USB runtime PM code and the new framework. [..] > Would it? I'm not so sure. But it definitely would be inelegant. That usually means trouble. > On the other hand, if we get rid of it then you would have to go back > and change a bunch of drivers. And all new drivers would have to be > careful not to mess up the counter. They have to be careful now, too. Right now you must not touch the counter after disconnect, under the alternate scheme you'd have to balance it. > Which do you prefer? The simpler scheme, even if it means change now. > > [..] > > > > > Quite so. Matt, what do you think? The downside is that people or > > > packages might try to enable autosuspend in cases where they shouldn't, > > > such as drives needing to spin down or needing a SYNCHRONIZE CACHE > > > command before suspend. Unforunately there's no way the kernel can > > > tell the good cases from the bad. > > > > We can however have the storage driver call the scsi devices' suspend > > handlers. > > No, we can't. The SCSI suspend handlers, if they did anything at all, > would try to send commands to the device. This would either abort the > autosuspend or deadlock when trying to acquire the pm_mutex. Can't we quiesce the device and recognise the flushing commands? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
