Re: [smartmontools-support] inactive SATA drives won't stay in standbyor sleep, PATA models did. (fwd)
From: Tejun Heo
Date: Tue Oct 21 2008 - 05:04:25 EST
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.
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/