libata: Add additional queued command opcodes from SATA spec

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(+)

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

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.

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

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

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!

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

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