Am Montag, 16. Januar 2012, 17:06:13 schrieb Alan Stern: > On Mon, 16 Jan 2012, Oliver Neukum wrote: > > > Hi, > > > > I am working on getting this solved and a couple of questions have arisen: > > This is not an easy thing to do correctly. For example, consider the > fact that suspending a bus-powered rotating disk drive will require > sending commands to write the cache and spin down the disk. And don't That is exactly the problem I had putting it into the storage driver. I must not resume the disk for those commands, but I need to do so for other commands. > forget the fact that many card readers signal a media change when they > resume. Those. Well, they simply cannot cleanly be suspended while they contain a medium. Or we must reset_resume. > When I was thinking about this sort of thing, I came to the conclusion > that the right place to do it would be in the block layer core. SCSI > requests all funnel through there. Hm. Those through sg, st and osst don't, do they? Secondly, how would the block layer know enough? > > 1. who is responsible for resuming a device when a command arives? > > the storage driver or sd? > > If sd the problem is that sd doesn't know when a host can suspend attached disks. > > Currently, nobody is responsible. That's because no commands arrive > unless the device has been opened (except for trivial things like the > initial scanning), and opening the device file causes an autoresume. Well, who ought to be responsible? > > 2. Do commands need to be marked for relating to PM tasks? > > Yes, they do. Good. 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
