linux-kernel - Re: [linux-pm] 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:	Thu, 14 Aug 2008 11:40:26 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Oliver Neukum <oneukum@...e.de>
cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	Pavel Machek <pavel@...e.cz>,
	Linux-pm mailing list <linux-pm@...ts.osdl.org>,
	kernel list <linux-kernel@...r.kernel.org>, <teheo@...ell.com>
Subject: Re: [linux-pm] Power management for SCSI

On Thu, 14 Aug 2008, Oliver Neukum wrote:

> > > I dispute that USB in general has this property.
> > 
> > How can you dispute that?  You said it yourself, in the top quote
> > above: "All children that are USB must be powered down."
> 
> But the children are SCSI, not USB.

Oh, I see.  All right, yes.  However USB in general _does_ have the
property that child devices might not be able to accomplish much while
the USB link is suspended, particularly if they are bus-powered.  This 
includes draining caches.

> > Oliver, you can't have it both ways.  Either we do spin down disks and
> > drain device caches before autosuspending usb-storage or we don't.
> 
> That is true.
> 
> > For safety's sake, obviously we should.  The overhead is minimal since
> > this happens only after the idle timeout has expired.  And for devices
> > that don't support it (like flash storage), sd skips the spin-down
> > command anway.
> 
> But you cannot make the conclusion that the ultimate children should have
> any autosuspend attributes. We can implement autosuspend in usb storage
> and propagate the suspend calls down the tree without SCSI knowing about
> autosuspend.

The way I designed the autosuspend framework, you _can't_ do that.  In
my framework autosuspend and autoresume events propagate _up_ the
device tree, not _down_.  This means an autosuspend has to be initiated
by the child SCSI layer, not by the USB layer.  Which is as it should
be, since the USB layer doesn't know when it is appropriate for a SCSI
device to autosuspend.

> Such a system would have it drawbacks, but it'd be a lot simpler.

It would be a layering violation.

Alan Stern

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