As an example, I'll use the sata_sil24 driver, as that's what I'll be
using on my machine (until sata_mv comes around)
On 7/17/07, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
> - 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.
You mean:
static const struct ata_port_operations sil24_ops = {
...
.error_handler = sil24_error_handler,
...
which then calls
ata_do_eh(ap, ata_std_prereset, sil24_softreset, sil24_hardreset,
ata_std_postreset);
How to then specify if you just need a softreset? My understanding is
all those functions get called.
> - 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.
Well, the SAT way of specifying soft/hardresets I found at [1] on page
104, and the basis for this is already in libata, just not
implemented: see ata_scsi_map_proto. Implementing it there seems more
compatible with the standard.
> 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.
Ugh.. I figured, I was just hoping I wouldn't have to deal with that.
Any idea on what happens to the user process (blocking, etc.) during
error handling? Surely if a disk needs to be hardreset during a normal
error, the user process doesn't hang for up to 30 seconds?
- Yasha
-
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
