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. > 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. On the other hand, the sr driver certainly deserves to have some form of runtime PM support, even for devices that aren't ZP. Alan Stern -- 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
