The kernel starting point would be that we have an AHCI driver. If you
need workarounds for hardware errata then they can go into it and that

is

fine. We support NCQ so we can use the queue depths. If there are
extensions then the AHCI driver can be enhanced.

We understand that AHCI driver can be patched for hardware errata and
other customizations, but main concern is performance.

Similarly if you've got performnace problems going through the libata
core and AHCI driver the right thing to do is to fix the performance
problems in the core (or rewrite bits of the core as needed).

I think the starting point would be to explain what problems you see

with

the existing driver, and where the profiling tools say the bottlenecks
are when you try and get full speed under libata + libata ahci driver.

The performance difference is not just because of libata + libata ahci
driver. Our driver gets the request before elevator comes into picture.
So, the stack starting from elevator,scsi upper, scsi mid, libata and
libata ahci driver attributes to the performance difference. 

Otherwise we will end up with one AHCIish driver per vendor and it

turns

into a nightmare for maintenance.

Regards,
Asai Thambi