> - each driver, in ata_port_operations, specifies a soft_reset and > hard_reset functions, which take ata_port* as a parameter They already have them via the EH code. > - in ata_scsi_pass_through, check for HARDRESET and SRST, and call > respective driver's soft/hard reset function Old IDE has an ioctl for it - it would be good to provide this for compatibility as we have with some other needed ioctls. > Now here's where I'm not quite certain on how to proceed. Another > developer has recommended that the reset be performed from an error > context, so that pre/post reset get called automatically. However, > there's a few issues, one of which is, as I was told, that the user > process will resume before the reset is complete. Thus the user sends > SG_IO and gets an immediate response, before the reset is finished, > whereas running the reset command directly blocks the user process > until the drive returns. > > So the question is: should the driver simply call prereset, optionally > hardreset, softreset, and postreset, or set up the error handler > context to do it? I think you have to do the latter. I see no other way to get the locking right, and the old IDE was horrible (and broken) because it tried to do it in the user context. drivers/ide is a worked example of why *NOT* to simply call the methods. The EH just needs triggering and can do the rest sanely in a sensible context without adding new methods to the drivers. - 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
