Messages in this thread | | | Date | Tue, 21 Oct 2008 18:02:08 +0900 | From | Tejun Heo <> | Subject | Re: [smartmontools-support] inactive SATA drives won't stay in standby or sleep, PATA models did. (fwd) |
| |
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
| |