linux-kernel - Re: Power management for SCSI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 Aug 2008 18:14:28 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Oliver Neukum <oneukum@...e.de>, Pavel Machek <pavel@...e.cz>,
	kernel list <linux-kernel@...r.kernel.org>,
	Linux-pm mailing list <linux-pm@...ts.osdl.org>,
	James.Bottomley@...senpartnership.com, teheo@...ell.com
Subject: Re: Power management for SCSI

Alan Stern wrote:
> On Wed, 13 Aug 2008, Oliver Neukum wrote:
>> Am Mittwoch 13 August 2008 16:59:23 schrieb Alan Stern:
>> > Is the USB transport unique in its requirement that all the child
>> > devices must be suspended before the link can be powered down?  Maybe
>> 
>> All children that are USB must be powered down. We know in fact that most
>> drives don't care that the device is suspended. The problem was drive
>> enclosures that cut power upon suspension losing cached data.
> 
> You misunderstood my question.  Are there SCSI transports other than
> USB sharing the requirement that all child devices must be suspended
> before the link can be powered down?

Yes in case of FireWire; it's necessary there too (but not sufficient).

(It's a bad example though since I have no good idea whether power
management beyond (a) system suspend and (b) disk spindown is feasible
in reality at all.)

[...]
>> So do we really want to do autosuspend on the device level? Or do we work
>> on hosts and just use the suspend()/resume() support of the sd, sr, ... etc?
> 
> For transports which are like USB, we should do autosuspend at the
> target (not device) level.  This means invoking the suspend/resume 
> routines of the ULDs like sd and sr.  The transport gets notified when 
> all of the targets are suspended.  (Or maybe the host driver gets 
> notified instead; there probably isn't any advantage to using the 
> transport class here.)
> 
> For other transports, we should only do idle-timeout detection.  The
> transport gets notified when any target has been idle for sufficiently 
> long, so that it can power down the link.  The ULDs are not involved.
> 
> Does that sound okay?

Minor correction:  The ULD suspend/resume methods necessarily work on
logical units, not targets.
-- 
Stefan Richter
-=====-==--- =--- -==-=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/