Elias Oltmanns <eo@nebensachen.de> wrote:
quoted text
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
[...]
quoted text
>> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/