Tejun Heo wrote:
Hello, Mark.

Mark Lord wrote:
Mark Lord wrote:
An alternative to all this, might be to expose the "select_pmp()"
function shown in the sample code, and have libata-pmp.c call that,
instead of having the new new .pmp_{read,write} functions.

I wonder if this might be more viable than first thought.

Say the LLD, be it ata_piix or sata_mv or sata_vw, were to provide
an option ata_operations method for "select_pmp_port(pmp)",
which the core could invoke prior to any direct manipulation
of the shadow registers.

I don't really think that's a good solution.  That's the quickest
solution for sata_mv but it just works around more fundamental problem
of assuming SFF behavior in core layer which we need to drop anyway.

No, the quickest solution for sata_mv, the one I apparently will now be using,
is to just clone about 250 lines of reset/debouce/probe code from libata-core
and change perhaps five lines of it to work around this issue plus some
chipset errata.

What I was thinking of, before, is the SATA specification which details
use of bits in the SCR to select a PMP port.  Pretty much exactly as
this chipset does it, except in the SCR rather than a proprieary port.

But no big deal.  I can clone code and not bother you any more.
In fact, some of the cloned code was already in sata_mv, and I removed
it this past week in my local working copy.  I'll just restore that,
along with another big blob so that we can select pm port where needed.

What a shame.

To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to