Hello, Mark.

Mark Lord wrote:

Mark Lord wrote:

quoted

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_svw, 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.

I really would like to keep the LLD code small, and have good solid
core routines for non-hardware specific functionality.  All of this stuff
I'm beginning to do with sata_mv would be trivial if I wanted to bloat
the LLD, but really.. only a tiny bit of it need be custom to sata_mv.

The existing SFF reset/probe/pmp stuff is just about exactly what
sata_mv needs.. and I feel a strong desire to not clone/duplicate
that hard-won functionality.

I strongly agree but am having difficult time agreeing with the proposed
approach.

Much of it I can see being shared with other half-and-half chipset drivers
as we add PMP functionality to those.

Do we have other chips which have PMP support but still uses mixed SFF
interface?

Maybe that's just the embedded side me showing through?

It is tricky to define the right interfaces, though, as each chipset
does throw its own unique curve balls at us.

Yeah, exactly.  I think what needs to be done is to separate out SFF
assumptions from core layer, factor out SFF-proper helpers and use them
to implement LLDs for quasi-SFF controllers.

Thanks.

-- 
tejun