[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200808141608.13431.oneukum@suse.de>
Date: Thu, 14 Aug 2008 16:08:12 +0200
From: Oliver Neukum <oneukum@...e.de>
To: Pavel Machek <pavel@...e.cz>
Cc: linux-pm@...ts.linux-foundation.org,
Alan Stern <stern@...land.harvard.edu>,
James.Bottomley@...senpartnership.com,
"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
Am Donnerstag 14 August 2008 15:50:21 schrieb Pavel Machek:
> On Wed 2008-08-13 18:21:29, Oliver Neukum wrote:
> > Am Mittwoch 13 August 2008 17:44:46 schrieb Alan Stern:
> > > > 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?
> >
> > I dispute that USB in general has this property. Some storage devices
> > need their caches flushed. USB itself is perfectly happy with autosuspending
> > the storage device (host) without telling the disks (devices)
> >
> > You could even argue that these storage devices violate the USB spec.
>
> Hmm... but suspended devices have very little power budget, right?
>
> So unless you have external power supply (2.5" frames generally
> don't), you can't really suspend and stay spinned up...
>
True, but the spec says that no state shall be lost.
I don't really argue against flushing the caches. But I cannot that this would
demand that we should implement autopsuspend for SCSI. It seems like
overengineering to me.
Regards
Oliver
--
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/
Powered by blists - more mailing lists