Re: [PATCH] libata: device suspend/resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Luben Tuikov wrote:
On 05/24/05 02:53, Jeff Garzik wrote:

You are right about issuing the standby command after flush. I don't think an LLD hook is the proper way to accomplish it, however.

The SCSI layer needs to issue the START STOP UNIT command in response to a suspend event, and libata-scsi will (per SAT spec) translate that into the ATA standby command. Merely following the relevant SCSI+SAT+ATA standards gets us there.


An SSU command may not be viable as the device may be shared
on the domain (i.e. accessed by another initiator).

Yes. Don't worry, both James and I are quite aware of this.


* Bus PM. This is best handled by the transport class driver (need to write for SATA and SAS).


This is tricky.  Kudos to Doug's answer.  One thing to remember is that
this is intricately entangled with host PM.  That is, if a device
is unplugged from the domain -- would one want to computer to come
out of its current power saving mode?  Probably not.

In general, in a class-based system, one can easily see a situation where a host driver would provide "adaptec_sas_transport" class, which does a few host-specific things, then falls back to a generic "sas_transport" class.


That is how to do host-specific stuff, with transport classes.

However, with regards to your specific example: to come out of power-saving mode based on a certain event, the motherboard needs special circuitry. Example of this is wake-on-LAN or wake-on-serial.


* Host PM. This is handled in the obvious manner, using existing PM driver hooks. PCI D0/D3, etc.


Then D3->D0 would be equivalent to reinintialization of the PCI device,

yes


doing domain discovery as usual, etc.

Eventually, yes. At the moment, suspend is rather dumb, and things mostly assume that the devices present at suspend will be present at resume.



I can describe how this will look when libata is divorced from SCSI, if you would like, too...


Please Jeff.

A concern is SATA devices behind SAS HAs (host adapters).  A straightforward
translation provided by libata would be a goal.

No need for translation. The LLD driver would either use the high level libata interface (for SATA devices), or use the high level SCSI interface (for SAS devices).


Even though libata doesn't have an explicit notion of transport classes (it _is_ a transport class, really), this is doable today.

	Jeff


- : 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux