From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luben Tuikov Subject: Re: [PATCH] libata: device suspend/resume Date: Tue, 24 May 2005 09:05:12 -0400 Message-ID: <42932688.80203@adaptec.com> References: <20050523201535.GA24298@havoc.gtf.org> <1116880875.5021.34.camel@mulgrave> <20050523204516.GA28058@havoc.gtf.org> <1116886206.5021.42.camel@mulgrave> <20050524062128.GT9855@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from magic.adaptec.com ([216.52.22.17]:34964 "EHLO magic.adaptec.com") by vger.kernel.org with ESMTP id S262036AbVEXNFS (ORCPT ); Tue, 24 May 2005 09:05:18 -0400 In-Reply-To: <20050524062128.GT9855@suse.de> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Jens Axboe Cc: James Bottomley , Jeff Garzik , SCSI Mailing List , linux-ide@vger.kernel.org On 05/24/05 02:21, Jens Axboe wrote: > suspend/resume is a lot more complicated than just flushing a cache, the > below will probably get you safe asleep but you will never get devices > alive again after power-up on suspend-to-ram. > > I also greatly prefer issuing a standby command to the drive after the > flush, so that we don't risk using the emergency parks of the drive. If > a drive happens to lie about wrt the flush command, it gets an extra > chance to flush the cache as it now knows that power will be gone very > soon. So I think the ->suspend/->resume hooks should belong to the LLD, > not the ULD as the ULD has no idea how to suspend all devices types. Very, very true and very, very correct! Luben