On Tuesday 25 September 2012 22:46:06 Aaron Lu wrote:

On 09/25/2012 10:23 PM, Oliver Neukum wrote:

quoted

quoted

BTW, if sr_suspend should be generic, that would suggest I shouldn't
write any ZPODD related code there, right? Any suggestion where these
code should go then?

libata. Maybe some generic hooks can be called in sr_suspend().

Thanks for the suggestion.
The problem is, I need to know whether the door is closed and if there
is a medium inside. I've no way of getting such information in libata.

Hooks can be called with the necessary parameters. I suggest
a triplett of medium presence, tray state and door lock state.
That should cover most types of drives.

quoted

PS: Are you sure sr_suspend() handles DVD-RAMs correctly?

No. Is there a spec for it?

Mount Fuji I presume.

Considering there are many different drives sr handle, is it possible to
write a generic sr_suspend?

There are two different issues. sr handles some different devices:
CD/DVD/BD-ROMs, -writers and -RAMs. For those you can have different
code paths in sr. That is no problem at all.

In addition devices can be attached by different hardware. In fact
the same drive can be attached in a USB enclosure or by SATA.

From the perspective of power management they are no longer

the same device.

Those are best handled in callbacks and limited use of special cases in
sr.

Maybe your suggestion of callback is the way to go.
What about this idea, if we find this is a ZPODD capable drive, we
enable runtime suspend for it and write a suspend callback according to
ZPODD spec. For other drives that does not have a suspend callback, we
do not enable runtime suspend.
Does this sound reasonable?

No. It would badly harm usb-storage.
You need to leave paths open for other device types.

	Regards
		Oliver