[PATCH] libata: Add additional queued command opcodes from SATA spec

[PATCH] libata: Add additional queued command opcodes from SATA spec

[Marc C]

This patch adds the new queued opcodes to the ATA device command
list.

Rev 3.0 and 3.1 of the SATA spec introduced the following
opcodes:

- NCQ QUEUE MANAGEMENT
- SEND FPDMA QUEUED
- RECEIVE FPDMA QUEUED

Signed-off-by: Marc C <marc.ceeeee@gmail.com>
---
 include/linux/ata.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/ata.h b/include/linux/ata.h
index ee0bd95..ae0e447 100644
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -239,6 +239,9 @@ enum {
     ATA_CMD_WRITE_QUEUED_FUA_EXT = 0x3E,
     ATA_CMD_FPDMA_READ    = 0x60,
     ATA_CMD_FPDMA_WRITE    = 0x61,
+    ATA_CMD_NCQ_QUEUE_MGMT    = 0x63,
+    ATA_CMD_FPDMA_SEND    = 0x64,
+    ATA_CMA_FPDMA_RECEIVE    = 0x65,
     ATA_CMD_PIO_READ    = 0x20,
     ATA_CMD_PIO_READ_EXT    = 0x24,
     ATA_CMD_PIO_WRITE    = 0x30,
--
1.8.1.3

Re: [PATCH] libata: Add additional queued command opcodes from SATA spec

[Tejun Heo]

Hello,

On Fri, Jul 19, 2013 at 06:17:14PM -0700, Marc C wrote:
> This patch adds the new queued opcodes to the ATA device command
> list.
> 
> Rev 3.0 and 3.1 of the SATA spec introduced the following
> opcodes:
> 
> - NCQ QUEUE MANAGEMENT
> - SEND FPDMA QUEUED
> - RECEIVE FPDMA QUEUED

Hmmm, are you planning to add code making use of the above new
commands soon?  If not, why add the opcodes at all?  ata.h isn't
aiming to contain all possible ATA commands.

Thanks.

-- 
tejun

Re: [PATCH] libata: Add additional queued command opcodes from SATA spec

[Marc C]

Hi Tejun,

> Hmmm, are you planning to add code making use of the above new
> commands soon?  If not, why add the opcodes at all?  ata.h isn't
> aiming to contain all possible ATA commands.

                                                        
That is the goal.

I have some out-of-tree user apps that exploit those opcodes
(via uapi). I eventually will have additional patches, but cannot 
submit the pull request for them until the SATA 3.2 spec is public.

Regards,
Marc

On Jul 22, 2013, at 1:00 PM, Tejun Heo <tj@kernel.org> wrote:

> Hello,
> 
> On Fri, Jul 19, 2013 at 06:17:14PM -0700, Marc C wrote:
>> This patch adds the new queued opcodes to the ATA device command
>> list.
>> 
>> Rev 3.0 and 3.1 of the SATA spec introduced the following
>> opcodes:
>> 
>> - NCQ QUEUE MANAGEMENT
>> - SEND FPDMA QUEUED
>> - RECEIVE FPDMA QUEUED
> 
> Hmmm, are you planning to add code making use of the above new
> commands soon?  If not, why add the opcodes at all?  ata.h isn't
> aiming to contain all possible ATA commands.
> 
> Thanks.
> 
> -- 
> tejun

Re: [PATCH] libata: Add additional queued command opcodes from SATA spec

[Tejun Heo]

Hello,

On Mon, Jul 22, 2013 at 01:42:42PM -0700, Marc C wrote:
> I have some out-of-tree user apps that exploit those opcodes
> (via uapi). I eventually will have additional patches, but cannot 

Hmmm?  I don't think ata.h is visible to userland, is it?

> submit the pull request for them until the SATA 3.2 spec is public.

Let's add the opcodes when it becomes actually used in the kernel then
unless it's gonna be a PITA on your end.

Thanks!

-- 
tejun

Re: [PATCH] libata: Add additional queued command opcodes from SATA spec

[Marc C]

Hi Tejun,

> Hmmm?  I don't think ata.h is visible to userland, is it?
I had done so locally so I wouldn't have to re-define all of
the opcodes.

> Let's add the opcodes when it becomes actually used in the kernel then
> unless it's gonna be a PITA on your end.
Sounds good!

Thanks,
Marc

On Jul 22, 2013, at 1:45 PM, Tejun Heo <tj@kernel.org> wrote:

> Hello,
> 
> On Mon, Jul 22, 2013 at 01:42:42PM -0700, Marc C wrote:
>> I have some out-of-tree user apps that exploit those opcodes
>> (via uapi). I eventually will have additional patches, but cannot 
> 
> Hmmm?  I don't think ata.h is visible to userland, is it?
> 
>> submit the pull request for them until the SATA 3.2 spec is public.
> 
> Let's add the opcodes when it becomes actually used in the kernel then
> unless it's gonna be a PITA on your end.
> 
> Thanks!
> 
> -- 
> tejun