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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
