On Wed, 21 Oct 2009, Matthew Dharm wrote: > To me, it seems that the problem is that we're approaching this > backwards.... > > We're trying to get a low-level driver to determine if the upper-levels are > done with a physical device so we can autosuspend. No matter what we come > up with, we're never going to get it right; consider what would happen if a > userspace application was messing with a /dev/sgX node arbitrarily. > > What we need to do is turn this around. The upper layers need to signal > the lower layers when it is safe to autosuspend. > > For example, consider a device with a mounted filesystem. The filesystem > needs to flush dirty buffers and then signal that it's in a "safe" state. > The block layers need to pass that through to sd_mod, which in turn needs > to write the data, do a cache flush, spin-down the disk, and signal to SCSI > core that it is "safe" for autosuspend. SCSI core then passes that on to > the HCD, which in this case is usb-storage. > > If you open a /dev/sgX node, then sg_mod signals via SCSI core that the > underlying device is unsafe for suspend. This is probably some sort of > reference counter type thing. An "advanced" use app such as HAL could use > an ioctl to make sg_mod signal that it is safe to suspend the device, if > all it's doing is a periodic check for media. > > I guess this just reminds me of some debates we had a few years ago about > how the code figures out how much data there is to transfer. We had a pile > of heuristics and lookup tables which constantly caused problems. The > right answer there was to make the upper layers explicitly signal what they > wanted. > > Just like that case, here the only modules which have all the knowledge to > make an informed decision are the upper layer modules. This is, of course, correct. But the infrastructure for the higher layers to signal us isn't in place yet. I was wondering if in the meantime, we could implement a stopgap approach that wouldn't be 100% right but would be better than nothing. Or should I just forget about it and work on implementing support for the new runtime PM framework in both USB and SCSI? 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
