From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [smartmontools-support] inactive SATA drives won't stay in standby or sleep, PATA models did. (fwd) Date: Tue, 21 Oct 2008 18:02:08 +0900 Message-ID: <48FD9A90.8000205@gmail.com> References: <48EBFE9B.9070503@gmail.com> <18674.4081.839329.116533@harpo.it.uu.se> <48F2D9A8.1030502@gmail.com> <18683.50533.786782.474536@harpo.it.uu.se> <48FD580E.4080101@gmail.com> <18685.35653.125899.390135@harpo.it.uu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from ti-out-0910.google.com ([209.85.142.184]:40517 "EHLO ti-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751897AbYJUJEM (ORCPT ); Tue, 21 Oct 2008 05:04:12 -0400 Received: by ti-out-0910.google.com with SMTP id b6so1071381tic.23 for ; Tue, 21 Oct 2008 02:04:10 -0700 (PDT) In-Reply-To: <18685.35653.125899.390135@harpo.it.uu.se> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Mikael Pettersson Cc: Christian Mueller , Bruce Allen , Smartmontools Mailing List , LKML , IDE/ATA development list Hello, Mikael Pettersson wrote: > Tejun Heo writes: > > Hello, Mikael. > > I would put this into ->hardreset itself as the controller can also > > get out of sync with reality during reset. > > The only thing I see going on between prereset and (hard/soft)reset > is an optional freeze, so I don't see why moving the pdc_reset_port() > into the beginning of hardreset() would make any difference. > > sata_promise currently uses the ->hardreset and ->softreset inherited > from ata_sff_port_ops, so it would need to override both to ensure that > we always do pdc_reset_port() before libata does its thing. That's why > I felt doing that in ->prereset would be the right solution. Hmm.. reset sequence goes on like the following. 1. prereset 2. hardreset, if fail, retry 3. follow-up softreset if requested, if fail, goto #2 4. postreset, if successful So, if some PHY event happens while the reset is waiting for device readiness and makes the controller state go out of sync with the drive. ->prereset() will NOT be called for the following retry. As a rule, ->hardreset should be able to reset the controller from all possible situations. ->prereset can be used to smooth out initial reset tries (ie. during initial probing, waiting for device readiness before SRST for SFF controllers w/o hardreset) but at best its function is advisory. When things go wrong, ->hardreset should be able to provide solution whatever state the controller is in. If both hard and soft resets work better with the controller reset added, I think it would be best to override both. Thanks. -- tejun