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. > [..] > > > I am sure it does not. Under the current rules a driver must not touch > > > the counter after it has been disconnected and there's no reason to > > > touch it as a device is disconnected, because usbcore is about to > > > take charge of it. > > > > True. Well, now there _will_ be a reason to touch it as a device is > > disconnected. > > > > The alternative, of course, is to keep intf->pm_usage_cnt and have > > usbcore mediate the actual changes to the counter in struct device. > > Should we do that? > > In the long run that would be trouble. Would it? I'm not so sure. But it definitely would be inelegant. 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. Which do you prefer? > [..] > > 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. Alan Stern -- 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
