Re: new ata_port_operations for .pmp_{read,write} ?

[Tejun Heo <htejun@gmail.com>]

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_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