On Thu, 27 Sep 2007, Oliver Neukum wrote: > > Oliver, I'm surprised at you! This patch is a big hack, not to mention > > a layering violation and an inversion of the proper calling sequence. > > Well, > > 1. autosuspend should not be specific to USB Correct. Which means support for it should be added to the SCSI drivers. SCSI autosuspend shouldn't be kluged into usb-storage in a way that basically ignores what the SCSI layer is doing. > 2. I like to view the generic SCSI code as a library That viewpoint might work out okay in some cases, but I don't think it's tenable when dealing with high-level drivers like sd and sr. > 3. The low level drivers will have to decide whether to suspend devices, > as the generic code doesn't know whether the bus is shared. I'm having trouble understanding this; it's a bit ambiguous. Does "devices" mean "SCSI devices", "host adapter devices", or both? Does "generic code" refer to the SCSI core, the high-level SCSI drivers, or something else? When you say the bus is "shared", do you mean there are multiple SCSI devices attached to it or do you mean something else? (I assume you mean something else, as the SCSI core certainly does know when multiple SCSI devices are attached to a SCSI bus.) In any case, that's not how I would put it. The SCSI core and high-level drivers will have to decide when they are not using SCSI devices and the devices can be suspended. When all the devices the SCSI core knows about are suspended, it should tell the LLD. Then the LLD can suspend the bus and the host adapter, whatever is appropriate, based on its own private knowledge. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
