Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
..
Mmm.. gotta figure out a way to mark the port for RESET,
without having that action taint the commands already analyzed.
I suppose I'll have to just clone some code from libata-eh to
do the READ_LOG_EXT and then qc_complete() those commands
before continuing. Or something.
The usual way to handle this is to clear the controller state (not the
PHY) from ->error_handler() before calling the generic error_handler.
Many drivers do similar things - ahci restarts the engine, sil24 calls
sil24_init_port() and so on. Does mv need PHY reset to get it working
again?
..
Heh.. the thoughtful chip designers didn't include an engine-only reset
mechanism.
If we reset the engine, it resets the PHY. That's the whole problem here.
Things would be so much simpler if it did the simple thing.. :)
Eeeee... nice, so you have to reset the host PHY anyway? If so, just
freeze the host port. It will print some nasty messages (which we'll
need to subdue) but libata EH won't issue any command to fanout ports
before host port reset.
--
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
