On Mon, 16 Jan 2012, Oliver Neukum wrote: > 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. That's why it would have to be done at the sd level or below. Below is better; otherwise you end up duplicating code for all sorts of different block devices. > > 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? Those are char device drivers, not block, so it doesn't matter. But to answer your question... sg does not use the block layer. st does, to some extent, to manage the request queue. See st_scsi_execute(). > Secondly, how would the block layer know enough? At the time I looked at it (over a year ago, maybe?), the request_queue structure didn't even contain a pointer to the corresponding struct device! That has probably been fixed by now. The block layer doesn't need to know very much. Mainly, just what state the device is currently in (active, suspending, suspended, or resuming). In each state, it can do the right thing when it receives a request that is or is not PM-related, and when it needs to get the next request from the queue. > > > 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? The block layer. The trick is to find the right points at which requests enter and leave the system. It's not easy, because apparently-complete requests can be reused. > > > 2. Do commands need to be marked for relating to PM tasks? > > > > Yes, they do. > > Good. More accurately, request structures need to be marked, since SCSI commands all start life as block-layer requests. In fact, such marks already exist, although not in the form we would like (there are separate flags for REQ_TYPE_PM_SUSPEND and REQ_TYPE_PM_RESUME). They are currently used by the IDE subsystem, which would have to be updated somewhat. The ATA subsystem also has some weird aspects; it uses the SCSI error handler to manage various things while suspending and resuming. 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
