Tejun Heo writes: > 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. I see. Ok, then I'll forget about ->prereset and bind ->hardreset to code which does pdc_reset_port() before invoking sata_sff_hardreset(). Thanks for your input. /Mikael -- 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
