On 09/29/2012 10:29 PM, Alan Stern wrote: > On Sat, 29 Sep 2012, Aaron Lu wrote: > >>> I don't think this is a good idea, quite frankly. sr seems to be a too >>> generic place for that. >> >> Does this mean sr can only have code that is useful to all devices it >> manages? i.e. If a piece of code enables a feature for a special kind of >> ODD(like the sata based ZPODD), it shouldn't be done in sr? > > Drivers are allowed to have special features and quirks that apply only > to some devices. I think SATA based zero power capable ODDs are the "some devices". > >> There is nothing in theory stopping us from doing this in ata layer. >> For the loading mechanism, we can always send an ATAPI command to figure >> it out. >> >> So gentlemen, I need your opinions on where this ZPODD code should live >> before I can continue this work, thanks. > > Can arbitrary SCSI devices be ZP, or does this notion apply only to > ATAPI-based drives? That's the key question, and the answer determines > where the ZP support belongs. I don't know if arbitrary SCSI devices can be ZP or not, the SPC spec doesn't seem to define such a power state. ZPODD is defined for sata based ATAPI ODD which supports device attention, but doesn't specify how the ODD is powered off and how the device attention pin notifies OS. On x86 systems, these are implemented by ACPI. Though SCSI devices may not have a general notion of ZP, the fact that ZPODD are managed by sr driver is enough to make the decision that ZPODD code can live in sr? > > On the other hand, the sr driver certainly deserves to have some form > of runtime PM support, even for devices that aren't ZP. Agree. And the following codes need to find a home: - Code used to handle ACPI wake notification(currently done in ATA, but causes the "annoying" need_eject flag in scsi_device); - Code to check if the ODD is ready to be powered off per the ZPODD spec. Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
