On Saturday, September 29, 2012, Aaron Lu wrote:

On 09/29/2012 10:29 PM, Alan Stern wrote:

quoted

On Sat, 29 Sep 2012, Aaron Lu wrote:

quoted

quoted

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".

quoted

quoted

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?

Well, only a part of it is handled by sr, the high-level part so to speak.
The low-level handling is done by the ATA layer.  Now, since sr is the
high-level part and is supposed to be generic, I don't think it's appropriate
to make it care about some low-level things specific to ATA (because there is
another layer of code supposed to handle those).

quoted

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);

And quite frankly I'd more and more convinced that this flag isn't really
necessary.

What you really want to achieve is to eject the tray of a tray-type ODD
if the eject is signaled through a GPE.  I don't see anything for sr to
do in that.  Moreover, you probably would like to do that even if the
drive is not powered down, right?

I wonder if this mechanism can be used for user space notification
without polling regardless of whether or not the zero-power feature is
used?

- Code to check if the ODD is ready to be powered off per the ZPODD
  spec.

If that can be done at the ATA level, I'd prefer it too.

Thanks,
Rafael