Re: [PATCH 3/4] ide: Implement disk shock protection support

From: Elias Oltmanns
Date: Fri Sep 12 2008 - 07:56:53 EST


Elias Oltmanns <eo@xxxxxxxxxxxxxx> wrote:
> Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx> wrote:
[...]
>> Since Tejun already raised concerns about multiplexing per-device
>> and per-port settings I'm not repeating them here. Please just
>> remember to backport fixes from libata version to ide one.
>
> For the sake of consistency, I've always tried to make ide and libata
> behave alike (or as close to it as possible). However, the final version
> of the libata patch is very hard to mimc in ide. Therefore, I wonder
> whether we can do in ide what we'd really like to do in libata
> eventually. The patch below is a real per-device implementation of the
> unload feature. However, I'd like you to confirm the crucial assumption
> underlying this patch: a port reset is the only way a device can
> interfere with another device on the same port. In particular, I haven't
> made an effort to understand pnp and similar stuff completely, but from
> a first glance I got the impression that these things are done per-port
> rather than per-device and that nothing sinister will happen behind our
> back. In short, can you confirm the following:
>
> Condition: device A on a port is parked (implies there is at least one
> request on the queue of that device, i.e we hold a
> reference to the device and thus to the port).
> Assumption: nothing will disturb the device because resets due to
> command failure / timeouts on device B are deferred (see my
> patch) and spurious commands like IDENTIFY (or whatever
> actions may be related to pnp and the like) are not
> performed while the device is sleeping and a request is
> waiting on the queue.

Sorry for spamming you again, but I forgot to mention one more thing: In
my hardware environment, I cannot easily test the code in do_reset1()
which is supposed to defer resets if necessary. Since we have something
very similar in libata (which I have tested), I'm quite confident that
everything will work out nicely. Still, you may want to pay special
attention to this piece of code.

Regards,

Elias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/