T10/04-262 ATA pass thru - patch.

T10/04-262 ATA pass thru - patch.

[Andy Warner]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

Here is a *very* rough and ready patch that implements
the ATA pass-thru CDB. The patch should apply cleanly
to any bk://gkernel.bkbits.net/libata-2.6 clone.

The 16-byte command opcode is a totally arbitrary 0x85,
allocation of a legit opcode is still pending.

The 12-byte command is not supported yet.

Only the following protocols are currently
supported: Non-Data, PIO-In, PIO-Out, DMA.

Multiple Count is currently ignored, and
read/write multiple are handled as vanilla PIO.

UDMA (protocols 11 & 12 in T10/04-262) probably
work, since at the libata level all DMA appear to
be handled the same.

Not supported are any of the reset protocols, packet,
queued, device diagnostics or FPDMA. I have no plans
to add packet support or queued support any time soon.
This should be enough to start SMART work, though.

This is my first patch generated from a bk-based
tree, so let me know if there are any problems
due to the way I've generated the patch.

Feedback/complaints -> me.
-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634

[-- Attachment #2: t10-patch-040927 --]
[-- Type: text/plain, Size: 4896 bytes --]

diff -ur -X /tmp/dontdiff libata-2.6-vanilla/drivers/scsi/libata-core.c t10-parser/drivers/scsi/libata-core.c
--- libata-2.6-vanilla/drivers/scsi/libata-core.c	2004-09-27 17:30:29.000000000 -0500
+++ t10-parser/drivers/scsi/libata-core.c	2004-09-27 21:30:23.000000000 -0500
@@ -1946,7 +1946,7 @@
 	sg->offset = (unsigned long) buf & ~PAGE_MASK;
 	sg_dma_len(sg) = buflen;
 
-	WARN_ON(buflen > PAGE_SIZE);
+//    WARN_ON(buflen > PAGE_SIZE);
 }
 
 void ata_sg_init(struct ata_queued_cmd *qc, struct scatterlist *sg,
diff -ur -X /tmp/dontdiff libata-2.6-vanilla/drivers/scsi/libata-scsi.c t10-parser/drivers/scsi/libata-scsi.c
--- libata-2.6-vanilla/drivers/scsi/libata-scsi.c	2004-09-27 17:30:29.000000000 -0500
+++ t10-parser/drivers/scsi/libata-scsi.c	2004-09-27 23:42:44.733522940 -0500
@@ -623,10 +623,22 @@
 {
 	struct scsi_cmnd *cmd = qc->scsicmd;
 
-	if (unlikely(drv_stat & (ATA_ERR | ATA_BUSY | ATA_DRQ)))
-		ata_to_sense_error(qc, drv_stat);
-	else
-		cmd->result = SAM_STAT_GOOD;
+	/*
+	 * If this was a pass-thru command, and the user requested
+	 * a check condition return including register values.
+	 * Note that check condition is generated, and the ATA
+	 * register values are returned, whether the command completed
+	 * successfully or not. If there was no error, SK, ASC and
+	 * ASCQ will all be zero.
+	 */
+	if ((cmd->cmnd[0] == ATA_16) && (cmd->cmnd[2] & 0x20)) {
+/*DWD*/		printk("XX  0x%0x/0x%0x\n", qc->tf.flags, qc->tf.protocol) ;
+	} else {
+		if (unlikely(drv_stat & (ATA_ERR | ATA_BUSY | ATA_DRQ)))
+			ata_to_sense_error(qc, drv_stat);
+		else
+			cmd->result = SAM_STAT_GOOD;
+	}
 
 	qc->scsidone(cmd);
 
@@ -688,7 +700,6 @@
 
 	if (xlat_func(qc, scsicmd))
 		goto err_out;
-
 	/* select device, send command to hardware */
 	if (ata_qc_issue(qc))
 		goto err_out;
@@ -1368,6 +1379,98 @@
 	return dev;
 }
 
+/*
+ * ata_scsi_map_proto() -	Map the protocol specified
+ *				in the pass-thru CDB onto the
+ *				protocol values used by taskfiles.
+ */
+static u8
+ata_scsi_map_proto(u8 byte1)
+{
+	switch((byte1 & 0x1e) >> 1) {
+		case 3:		/* Non-data */
+			return ATA_PROT_NODATA;
+
+		case 6:		/* DMA */
+			return ATA_PROT_DMA;
+
+		case 4:		/* PIO Data-in */
+		case 5:		/* PIO Data-out */
+			if (byte1 & 0xe0) {
+				return ATA_PROT_PIO_MULT;
+			}
+			return ATA_PROT_PIO;
+
+		case 10:	/* Device Reset */
+		case 0:		/* Hard Reset */
+		case 1:		/* SRST */
+		case 2:		/* Bus Idle */
+		case 7:		/* Packet */
+		case 8:		/* DMA Queued */
+		case 9:		/* Device Diagnostic */
+		case 11:	/* UDMA Data-in */
+		case 12:	/* UDMA Data-Out */
+		case 13:	/* FPDMA */
+		default:	/* Reserved */
+			break;
+	}
+
+	return ATA_PROT_UNKNOWN;
+}
+
+static unsigned int
+ata_scsi_pass_thru_16(struct ata_queued_cmd *qc, u8 *scsicmd)
+{
+	struct ata_taskfile *tf = &(qc->tf);
+	struct scsi_cmnd *cmd = qc->scsicmd;
+
+	if ((tf->protocol = ata_scsi_map_proto(scsicmd[1])) == ATA_PROT_UNKNOWN) {
+		return 1;
+	}
+
+	/*
+	 * If the CDB claims to contain extended
+	 * ATA commands copy the upper byte register values.
+	 * 
+	 * NOTE: at present copy all register fields,
+	 * regardless of which ones are valid according
+	 * to the .En bits. TODO: research optimal
+	 * algorithm for this.
+	 */
+	if (scsicmd[1] & 0x01) {
+		tf->hob_feature = scsicmd[3];
+		tf->hob_nsect = scsicmd[5];
+		tf->hob_lbal = scsicmd[7];
+		tf->hob_lbam = scsicmd[9];
+		tf->hob_lbah = scsicmd[11];
+		tf->flags |= ATA_TFLAG_LBA48 ;
+	} else {
+		tf->flags &= ~ATA_TFLAG_LBA48 ;
+	}
+
+	tf->feature = scsicmd[4];
+	tf->nsect = scsicmd[6];
+	tf->lbal = scsicmd[8];
+	tf->lbam = scsicmd[10];
+	tf->lbah = scsicmd[12];
+
+	tf->flags |= (ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE) ;
+	tf->device = scsicmd[13];
+	tf->command = scsicmd[14];
+
+	/*
+	 * TODO: find out if we need to do more here to
+	 *       cover scatter/gather case.
+	 */
+	qc->nsect = cmd->bufflen / ATA_SECT_SIZE ;
+
+	if (cmd->sc_data_direction == SCSI_DATA_WRITE) {
+		tf->flags |= ATA_TFLAG_WRITE;
+	}
+
+	return 0;
+}
+
 /**
  *	ata_get_xlat_func - check if SCSI to ATA translation is possible
  *	@dev: ATA device
@@ -1400,6 +1503,9 @@
 	case VERIFY:
 	case VERIFY_16:
 		return ata_scsi_verify_xlat;
+
+	case ATA_16:
+		return ata_scsi_pass_thru_16 ;
 	}
 
 	return NULL;
diff -ur -X /tmp/dontdiff libata-2.6-vanilla/include/scsi/scsi.h t10-parser/include/scsi/scsi.h
--- libata-2.6-vanilla/include/scsi/scsi.h	2004-09-27 17:30:40.000000000 -0500
+++ t10-parser/include/scsi/scsi.h	2004-09-27 22:11:07.000000000 -0500
@@ -113,6 +113,9 @@
 /* values for service action in */
 #define	SAI_READ_CAPACITY_16  0x10
 
+/* Temporary values for T10/04-262 until official values are allocated */
+#define	ATA_16		      0x85	/* 16-byte pass-thru [0x85 == unused]*/
+#define	ATA_12		      0xb3	/* 12-byte pass-thru [0xb3 == obsolete set limits command] */
 
 /*
  *  SCSI Architecture Model (SAM) Status codes. Taken from SAM-3 draft

Re: T10/04-262 ATA pass thru - patch.

[Andy Warner]

Two more notes:

1. Check Condition isn't supported yet. I'm working on that
   right now - expect it within 2 days.

2. Curtis has said that a new rev of the proposal is
   in process. Specifically, the *.En bits are being
   removed to make room for something else.
-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634

Re: T10/04-262 ATA pass thru - patch.

[John W. Linville]

On Tue, Sep 28, 2004 at 12:39:11AM -0500, Andy Warner wrote:

> 2. Curtis has said that a new rev of the proposal is
>    in process. Specifically, the *.En bits are being
>    removed to make room for something else.

Andy,

It looks like you are expecting everything below the *.En bit to be
shifted up by 1 byte.  Am I reading that right?

I guess I would have expected that space to become reserved for
something else?

Just comfirming...

John
-- 
John W. Linville
linville@tuxdriver.com

Re: T10/04-262 ATA pass thru - patch.

[John W. Linville]

On Wed, Sep 29, 2004 at 01:19:36PM -0500, Andy Warner wrote:
> John W. Linville wrote:
> > [...]
> > It looks like you are expecting everything below the *.En bit to be
> > shifted up by 1 byte.  Am I reading that right?
> 
> Are you checking this against Rev 3 of the spec ?

Ahh...I don't have the new spec.  Anyway, I guess that confirms it... :-)

John
-- 
John W. Linville
linville@tuxdriver.com

Re: T10/04-262 ATA pass thru - patch.

[John W. Linville]

On Wed, Sep 29, 2004 at 03:29:59PM -0300, Luciano A. Stertz wrote:
> 	If I understand it correctly, the kernel receives an ATA command, 
> creates a CDB, gets the ATA command from the CDB and issues it.
> 	It's a nice workaround, but user space software will still have to be 
> aware that the target device appears as SCSI but isn't in fact a SCSI 
> device... I guess that the ideal situation would be:
> 	1. The user space program sends SCSI commands to the device, without 
> even have to worry if it's really a SCSI device;
> 	2. The kernel issues equivalent ATA commands and fills in the requested 
> data.

Actually, I think you have it a little bit backwards.

Andy's patch would allow someone who knows the SCSI device is actually
an ATA device to send the device an ATA command through the SCSI
infrastructure (e.g using sg).

My patch will allow the SATA devices to accept the traditional
SMART-related ioctls (HDIO_DRIVE_CMD and HDIO_DRIVE_TASK).  The
information from those ioctls will be translated to an ATA pass-thru
SCSI command.  Andy's patch will then allow these commands to execute.

As before, the smart commands will need an option to tell them to treat
the drives like ATA drives rather than SCSI drives, but the unmodified
binaries will still work.

Does that clear things up?

John
-- 
John W. Linville
linville@tuxdriver.com

Re: T10/04-262 ATA pass thru - patch.

[Andy Warner]

John W. Linville wrote:
> [...]
> It looks like you are expecting everything below the *.En bit to be
> shifted up by 1 byte.  Am I reading that right?
> 
> I guess I would have expected that space to become reserved for
> something else?

Are you checking this against Rev 3 of the spec ?

I'll double check my end of things, but everything shifted
by 1 byte between revs 2 & 3, to make room for the control byte.
-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634

Re: T10/04-262 ATA pass thru - patch.

[Luciano A. Stertz]

	Just trying to understand the SATA SMART problem as a whole. With your 
patch, it's possible to send ATA commands that are encapsulated in CDBs, 
right? If so, to enable sending direct ATA commands to a SATA device, 
one has to create a ioctl that receives the command and creates a CDB 
from it, as John Linville did a few weeks ago. This way a user-space 
application (e.g. smartmontools) can use this ioctl to send ATA 
commands. Am I right?
	If I understand it correctly, the kernel receives an ATA command, 
creates a CDB, gets the ATA command from the CDB and issues it.
	It's a nice workaround, but user space software will still have to be 
aware that the target device appears as SCSI but isn't in fact a SCSI 
device... I guess that the ideal situation would be:
	1. The user space program sends SCSI commands to the device, without 
even have to worry if it's really a SCSI device;
	2. The kernel issues equivalent ATA commands and fills in the requested 
data.

	I don't know if it's possible / practical, but would be very convenient 
to user space developers. If it doesn't make sense to have this 
translation done in the kernel, maybe in a user space library?

	Luciano Stertz

Andy Warner wrote:
> Here is a *very* rough and ready patch that implements
> the ATA pass-thru CDB. The patch should apply cleanly
> to any bk://gkernel.bkbits.net/libata-2.6 clone.
> 
> The 16-byte command opcode is a totally arbitrary 0x85,
> allocation of a legit opcode is still pending.
> 
> The 12-byte command is not supported yet.
> 
> Only the following protocols are currently
> supported: Non-Data, PIO-In, PIO-Out, DMA.
> 
> Multiple Count is currently ignored, and
> read/write multiple are handled as vanilla PIO.
> 
> UDMA (protocols 11 & 12 in T10/04-262) probably
> work, since at the libata level all DMA appear to
> be handled the same.
> 
> Not supported are any of the reset protocols, packet,
> queued, device diagnostics or FPDMA. I have no plans
> to add packet support or queued support any time soon.
> This should be enough to start SMART work, though.
> 
> This is my first patch generated from a bk-based
> tree, so let me know if there are any problems
> due to the way I've generated the patch.
> 
> Feedback/complaints -> me.
> 
> 
> ------------------------------------------------------------------------
> 
> diff -ur -X /tmp/dontdiff libata-2.6-vanilla/drivers/scsi/libata-core.c t10-parser/drivers/scsi/libata-core.c
> --- libata-2.6-vanilla/drivers/scsi/libata-core.c	2004-09-27 17:30:29.000000000 -0500
> +++ t10-parser/drivers/scsi/libata-core.c	2004-09-27 21:30:23.000000000 -0500
> @@ -1946,7 +1946,7 @@
>  	sg->offset = (unsigned long) buf & ~PAGE_MASK;
>  	sg_dma_len(sg) = buflen;
>  
> -	WARN_ON(buflen > PAGE_SIZE);
> +//    WARN_ON(buflen > PAGE_SIZE);
>  }
>  
>  void ata_sg_init(struct ata_queued_cmd *qc, struct scatterlist *sg,
> diff -ur -X /tmp/dontdiff libata-2.6-vanilla/drivers/scsi/libata-scsi.c t10-parser/drivers/scsi/libata-scsi.c
> --- libata-2.6-vanilla/drivers/scsi/libata-scsi.c	2004-09-27 17:30:29.000000000 -0500
> +++ t10-parser/drivers/scsi/libata-scsi.c	2004-09-27 23:42:44.733522940 -0500
> @@ -623,10 +623,22 @@
>  {
>  	struct scsi_cmnd *cmd = qc->scsicmd;
>  
> -	if (unlikely(drv_stat & (ATA_ERR | ATA_BUSY | ATA_DRQ)))
> -		ata_to_sense_error(qc, drv_stat);
> -	else
> -		cmd->result = SAM_STAT_GOOD;
> +	/*
> +	 * If this was a pass-thru command, and the user requested
> +	 * a check condition return including register values.
> +	 * Note that check condition is generated, and the ATA
> +	 * register values are returned, whether the command completed
> +	 * successfully or not. If there was no error, SK, ASC and
> +	 * ASCQ will all be zero.
> +	 */
> +	if ((cmd->cmnd[0] == ATA_16) && (cmd->cmnd[2] & 0x20)) {
> +/*DWD*/		printk("XX  0x%0x/0x%0x\n", qc->tf.flags, qc->tf.protocol) ;
> +	} else {
> +		if (unlikely(drv_stat & (ATA_ERR | ATA_BUSY | ATA_DRQ)))
> +			ata_to_sense_error(qc, drv_stat);
> +		else
> +			cmd->result = SAM_STAT_GOOD;
> +	}
>  
>  	qc->scsidone(cmd);
>  
> @@ -688,7 +700,6 @@
>  
>  	if (xlat_func(qc, scsicmd))
>  		goto err_out;
> -
>  	/* select device, send command to hardware */
>  	if (ata_qc_issue(qc))
>  		goto err_out;
> @@ -1368,6 +1379,98 @@
>  	return dev;
>  }
>  
> +/*
> + * ata_scsi_map_proto() -	Map the protocol specified
> + *				in the pass-thru CDB onto the
> + *				protocol values used by taskfiles.
> + */
> +static u8
> +ata_scsi_map_proto(u8 byte1)
> +{
> +	switch((byte1 & 0x1e) >> 1) {
> +		case 3:		/* Non-data */
> +			return ATA_PROT_NODATA;
> +
> +		case 6:		/* DMA */
> +			return ATA_PROT_DMA;
> +
> +		case 4:		/* PIO Data-in */
> +		case 5:		/* PIO Data-out */
> +			if (byte1 & 0xe0) {
> +				return ATA_PROT_PIO_MULT;
> +			}
> +			return ATA_PROT_PIO;
> +
> +		case 10:	/* Device Reset */
> +		case 0:		/* Hard Reset */
> +		case 1:		/* SRST */
> +		case 2:		/* Bus Idle */
> +		case 7:		/* Packet */
> +		case 8:		/* DMA Queued */
> +		case 9:		/* Device Diagnostic */
> +		case 11:	/* UDMA Data-in */
> +		case 12:	/* UDMA Data-Out */
> +		case 13:	/* FPDMA */
> +		default:	/* Reserved */
> +			break;
> +	}
> +
> +	return ATA_PROT_UNKNOWN;
> +}
> +
> +static unsigned int
> +ata_scsi_pass_thru_16(struct ata_queued_cmd *qc, u8 *scsicmd)
> +{
> +	struct ata_taskfile *tf = &(qc->tf);
> +	struct scsi_cmnd *cmd = qc->scsicmd;
> +
> +	if ((tf->protocol = ata_scsi_map_proto(scsicmd[1])) == ATA_PROT_UNKNOWN) {
> +		return 1;
> +	}
> +
> +	/*
> +	 * If the CDB claims to contain extended
> +	 * ATA commands copy the upper byte register values.
> +	 * 
> +	 * NOTE: at present copy all register fields,
> +	 * regardless of which ones are valid according
> +	 * to the .En bits. TODO: research optimal
> +	 * algorithm for this.
> +	 */
> +	if (scsicmd[1] & 0x01) {
> +		tf->hob_feature = scsicmd[3];
> +		tf->hob_nsect = scsicmd[5];
> +		tf->hob_lbal = scsicmd[7];
> +		tf->hob_lbam = scsicmd[9];
> +		tf->hob_lbah = scsicmd[11];
> +		tf->flags |= ATA_TFLAG_LBA48 ;
> +	} else {
> +		tf->flags &= ~ATA_TFLAG_LBA48 ;
> +	}
> +
> +	tf->feature = scsicmd[4];
> +	tf->nsect = scsicmd[6];
> +	tf->lbal = scsicmd[8];
> +	tf->lbam = scsicmd[10];
> +	tf->lbah = scsicmd[12];
> +
> +	tf->flags |= (ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE) ;
> +	tf->device = scsicmd[13];
> +	tf->command = scsicmd[14];
> +
> +	/*
> +	 * TODO: find out if we need to do more here to
> +	 *       cover scatter/gather case.
> +	 */
> +	qc->nsect = cmd->bufflen / ATA_SECT_SIZE ;
> +
> +	if (cmd->sc_data_direction == SCSI_DATA_WRITE) {
> +		tf->flags |= ATA_TFLAG_WRITE;
> +	}
> +
> +	return 0;
> +}
> +
>  /**
>   *	ata_get_xlat_func - check if SCSI to ATA translation is possible
>   *	@dev: ATA device
> @@ -1400,6 +1503,9 @@
>  	case VERIFY:
>  	case VERIFY_16:
>  		return ata_scsi_verify_xlat;
> +
> +	case ATA_16:
> +		return ata_scsi_pass_thru_16 ;
>  	}
>  
>  	return NULL;
> diff -ur -X /tmp/dontdiff libata-2.6-vanilla/include/scsi/scsi.h t10-parser/include/scsi/scsi.h
> --- libata-2.6-vanilla/include/scsi/scsi.h	2004-09-27 17:30:40.000000000 -0500
> +++ t10-parser/include/scsi/scsi.h	2004-09-27 22:11:07.000000000 -0500
> @@ -113,6 +113,9 @@
>  /* values for service action in */
>  #define	SAI_READ_CAPACITY_16  0x10
>  
> +/* Temporary values for T10/04-262 until official values are allocated */
> +#define	ATA_16		      0x85	/* 16-byte pass-thru [0x85 == unused]*/
> +#define	ATA_12		      0xb3	/* 12-byte pass-thru [0xb3 == obsolete set limits command] */
>  
>  /*
>   *  SCSI Architecture Model (SAM) Status codes. Taken from SAM-3 draft


-- 
Luciano A. Stertz
luciano@tteng.com.br
T&T Engenheiros Associados Ltda
http://www.tteng.com.br
Fone/Fax (51) 3224 8425

Re: T10/04-262 ATA pass thru - patch.

[Jeff Garzik]

Luciano A. Stertz wrote:
> 
>     Just trying to understand the SATA SMART problem as a whole. With 
> your patch, it's possible to send ATA commands that are encapsulated in 
> CDBs, right? If so, to enable sending direct ATA commands to a SATA 
> device, one has to create a ioctl that receives the command and creates 
> a CDB from it, as John Linville did a few weeks ago. This way a 
> user-space application (e.g. smartmontools) can use this ioctl to send 
> ATA commands. Am I right?

No.  SCSI "send CDB" ioctls have existed for years.

The ioctls John added are merely for compatibility with existing IDE 
utilities.


>     If I understand it correctly, the kernel receives an ATA command, 
> creates a CDB, gets the ATA command from the CDB and issues it.
>     It's a nice workaround, but user space software will still have to 
> be aware that the target device appears as SCSI but isn't in fact a SCSI 
> device... I guess that the ideal situation would be:

The SAT INQUIRY draft follows the standard that I (libata) set:  the 
vendor id is "ATA".

	Jeff

Re: T10/04-262 ATA pass thru - patch.

[John W. Linville]

On Wed, Sep 29, 2004 at 04:38:50PM -0300, Luciano A. Stertz wrote:
> Luciano A. Stertz wrote:
> 	Ok, I guess now I got it. It was already possible to create and send 
> CDB, Andy's patch will 'decode' it so that it can be an ATA command.

Ding, ding, ding! :-)
-- 
John W. Linville
linville@tuxdriver.com

Re: T10/04-262 ATA pass thru - patch.

[Luciano A. Stertz]

Jeff Garzik wrote:
> Luciano A. Stertz wrote:
> 
>>
>>     Just trying to understand the SATA SMART problem as a whole. With 
>> your patch, it's possible to send ATA commands that are encapsulated 
>> in CDBs, right? If so, to enable sending direct ATA commands to a SATA 
>> device, one has to create a ioctl that receives the command and 
>> creates a CDB from it, as John Linville did a few weeks ago. This way 
>> a user-space application (e.g. smartmontools) can use this ioctl to 
>> send ATA commands. Am I right?
> 
> 
> No.  SCSI "send CDB" ioctls have existed for years.
> 
> The ioctls John added are merely for compatibility with existing IDE 
> utilities.
	Hmm, didn't know that. Do you mean that I can already send ATA commands 
to SATA devices? Where can I find information about these ioctls?

	Thanks again,
	Luciano

-- 
Luciano A. Stertz
luciano@tteng.com.br
T&T Engenheiros Associados Ltda
http://www.tteng.com.br
Fone/Fax (51) 3224 8425

Re: T10/04-262 ATA pass thru - patch.

[Luciano A. Stertz]

Luciano A. Stertz wrote:
> Jeff Garzik wrote:
> 
>> Luciano A. Stertz wrote:
>>
>>>
>>>     Just trying to understand the SATA SMART problem as a whole. With 
>>> your patch, it's possible to send ATA commands that are encapsulated 
>>> in CDBs, right? If so, to enable sending direct ATA commands to a 
>>> SATA device, one has to create a ioctl that receives the command and 
>>> creates a CDB from it, as John Linville did a few weeks ago. This way 
>>> a user-space application (e.g. smartmontools) can use this ioctl to 
>>> send ATA commands. Am I right?
>>
>>
>>
>> No.  SCSI "send CDB" ioctls have existed for years.
>>
>> The ioctls John added are merely for compatibility with existing IDE 
>> utilities.
> 
>     Hmm, didn't know that. Do you mean that I can already send ATA 
> commands to SATA devices? Where can I find information about these ioctls?
	Ok, I guess now I got it. It was already possible to create and send 
CDB, Andy's patch will 'decode' it so that it can be an ATA command.

> 
>     Thanks again,
>     Luciano
> 


-- 
Luciano A. Stertz
luciano@tteng.com.br
T&T Engenheiros Associados Ltda
http://www.tteng.com.br
Fone/Fax (51) 3224 8425

Re: T10/04-262 ATA pass thru - patch.

[Andy Warner]

John W. Linville wrote:
> [...]
> > Are you checking this against Rev 3 of the spec ?
> 
> Ahh...I don't have the new spec.  Anyway, I guess that confirms it... :-)

And remember revision 4 of the spec is incoming, so it's all got to
change at least one more time anyway.
-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634

[patch libata-2.6] libata: SMART support via ATA pass-thru

[John W. Linville]

Patch to add support for SMART to libata via the HDIO_DRIVE_CMD and
HDIO_DRIVE_TASK ioctls.  These ioctls are translated to ATA pass-thru
CDBs and submitted via scsi_wait_req().

Signed-off-by: John W. Linville <linville@tuxdriver.com>
--- 
Obviously, this patch depends on the "T10/04-262 ATA pass thru" patch
posted on 9/28 by Andy Warner.  It will likely need some rework both
when check condition is supported for ATA pass-thru and when new
revisions of T10/04-262 are released.

 drivers/scsi/libata-scsi.c |  153 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/scsi/libata.h      |    2 
 2 files changed, 155 insertions(+)

--- libata-2.6/drivers/scsi/libata.h.orig
+++ libata-2.6/drivers/scsi/libata.h
@@ -43,6 +43,8 @@ extern void ata_dev_select(struct ata_po
                            unsigned int wait, unsigned int can_sleep);
 extern void ata_tf_to_host_nolock(struct ata_port *ap, struct ata_taskfile *tf);
 extern void swap_buf_le16(u16 *buf, unsigned int buf_words);
+extern int ata_task_ioctl(struct scsi_device *scsidev, void __user *arg);
+extern int ata_cmd_ioctl(struct scsi_device *scsidev, void __user *arg);
 
 
 /* libata-scsi.c */
--- libata-2.6/drivers/scsi/libata-scsi.c.orig
+++ libata-2.6/drivers/scsi/libata-scsi.c
@@ -29,10 +29,13 @@
 #include "scsi.h"
 #include <scsi/scsi_host.h>
 #include <linux/libata.h>
+#include <linux/hdreg.h>
 #include <asm/uaccess.h>
 
 #include "libata.h"
 
+#define SECTOR_SIZE	512
+
 typedef unsigned int (*ata_xlat_func_t)(struct ata_queued_cmd *qc, u8 *scsicmd);
 static void ata_scsi_simulate(struct ata_port *ap, struct ata_device *dev,
 			      struct scsi_cmnd *cmd,
@@ -70,6 +73,146 @@ int ata_std_bios_param(struct scsi_devic
 	return 0;
 }
 
+/**
+ *	ata_cmd_ioctl - Handler for HDIO_DRIVE_CMD ioctl
+ *	@dev: Device to whom we are issuing command
+ *	@arg: User provided data for issuing command
+ *
+ *	LOCKING:
+ *	Defined by the SCSI layer.  We don't really care.
+ *
+ *	RETURNS:
+ *	Zero on success, negative errno on error.
+ */
+
+int ata_cmd_ioctl(struct scsi_device *scsidev, void __user *arg)
+{
+	int rc = 0;
+	u8 scsi_cmd[MAX_COMMAND_SIZE];
+	u8 args[4], *argbuf = NULL;
+	int argsize = 0;
+	struct scsi_request *sreq;
+
+	if (NULL == (void *)arg)
+		return -EINVAL;
+
+	if (copy_from_user(args, arg, sizeof(args)))
+		return -EFAULT;
+
+	sreq = scsi_allocate_request(scsidev, GFP_KERNEL);
+	if (!sreq)
+		return -EINTR;
+
+	memset(scsi_cmd, 0, sizeof(scsi_cmd));
+
+	if (args[3]) {
+		argsize = SECTOR_SIZE * args[3];
+		argbuf = kmalloc(argsize, GFP_KERNEL);
+		if (argbuf == NULL)
+			return -ENOMEM;
+
+		scsi_cmd[1]  = (4 << 1); /* PIO Data-in */
+		sreq->sr_data_direction = DMA_FROM_DEVICE;
+	} else {
+		scsi_cmd[1]  = (3 << 1); /* Non-data */
+		sreq->sr_data_direction = DMA_NONE;
+	}
+
+	scsi_cmd[0] = ATA_16;
+	scsi_cmd[2] = 0x1f;     /* no off.line or cc, yes all registers */
+
+	scsi_cmd[4] = args[2];
+	if (args[0] == WIN_SMART) { /* hack -- ide driver does this too... */
+		scsi_cmd[6]  = args[3];
+		scsi_cmd[8]  = args[1];
+		scsi_cmd[10] = 0x4f;
+		scsi_cmd[12] = 0xc2;
+	} else {
+		scsi_cmd[6]  = args[1];
+	}
+	scsi_cmd[14] = args[0];
+
+	/* Good values for timeout and retries?  Values below
+	   from scsi_ioctl_send_command() for default case... */
+	scsi_wait_req(sreq, scsi_cmd, argbuf, argsize, (10*HZ), 5);
+
+	if (sreq->sr_result) {
+		rc = -EIO;
+		goto error;
+	}
+
+	/* Need code to retrieve data from check condition? */
+
+	if ((argbuf)
+	 && copy_to_user((void *)(arg + sizeof(args)), argbuf, argsize))
+		rc = -EFAULT;
+error:
+	scsi_release_request(sreq);
+
+	if (argbuf)
+		kfree(argbuf);
+
+	return rc;
+}
+
+/**
+ *	ata_task_ioctl - Handler for HDIO_DRIVE_TASK ioctl
+ *	@dev: Device to whom we are issuing command
+ *	@arg: User provided data for issuing command
+ *
+ *	LOCKING:
+ *	Defined by the SCSI layer.  We don't really care.
+ *
+ *	RETURNS:
+ *	Zero on success, negative errno on error.
+ */
+int ata_task_ioctl(struct scsi_device *scsidev, void __user *arg)
+{
+	int rc = 0;
+	u8 scsi_cmd[MAX_COMMAND_SIZE];
+	u8 args[7];
+	struct scsi_request *sreq;
+
+	if (NULL == (void *)arg)
+		return -EINVAL;
+
+	if (copy_from_user(args, arg, sizeof(args)))
+		return -EFAULT;
+
+	memset(scsi_cmd, 0, sizeof(scsi_cmd));
+	scsi_cmd[0]  = ATA_16;
+	scsi_cmd[1]  = (3 << 1); /* Non-data */
+	scsi_cmd[2]  = 0x1f;     /* no off.line or cc, yes all registers */
+	scsi_cmd[4]  = args[1];
+	scsi_cmd[6]  = args[2];
+	scsi_cmd[8]  = args[3];
+	scsi_cmd[10] = args[4];
+	scsi_cmd[12] = args[5];
+	scsi_cmd[14] = args[0];
+
+	sreq = scsi_allocate_request(scsidev, GFP_KERNEL);
+	if (!sreq) {
+		rc = -EINTR;
+		goto error;
+	}
+
+	sreq->sr_data_direction = DMA_NONE;
+	/* Good values for timeout and retries?  Values below
+	   from scsi_ioctl_send_command() for default case... */
+	scsi_wait_req(sreq, scsi_cmd, NULL, 0, (10*HZ), 5);
+
+	if (sreq->sr_result) {
+		rc = -EIO;
+		goto error;
+	}
+
+	/* Need code to retrieve data from check condition? */
+
+error:
+	scsi_release_request(sreq);
+	return rc;
+}
+
 int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)
 {
 	struct ata_port *ap;
@@ -99,6 +242,16 @@ int ata_scsi_ioctl(struct scsi_device *s
 			return -EINVAL;
 		return 0;
 
+	case HDIO_DRIVE_CMD:
+		if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO))
+			return -EACCES;
+		return ata_cmd_ioctl(scsidev, arg);
+
+	case HDIO_DRIVE_TASK:
+		if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO))
+			return -EACCES;
+		return ata_task_ioctl(scsidev, arg);
+
 	default:
 		rc = -EOPNOTSUPP;
 		break;

Re: [patch libata-2.6] libata: SMART support via ATA pass-thru

[Jeff Garzik]

John W. Linville wrote:
> Patch to add support for SMART to libata via the HDIO_DRIVE_CMD and
> HDIO_DRIVE_TASK ioctls.  These ioctls are translated to ATA pass-thru
> CDBs and submitted via scsi_wait_req().
> 
> Signed-off-by: John W. Linville <linville@tuxdriver.com>

Looks pretty good to me...

I'll roll a new libata-dev bundle today or tomorrow.

	Jeff

Re: T10/04-262 ATA pass thru - patch.

[Luciano A. Stertz]

Jeff Garzik wrote:
> Luciano A. Stertz wrote:
> 
>>
>>     Just trying to understand the SATA SMART problem as a whole. With 
>> your patch, it's possible to send ATA commands that are encapsulated 
>> in CDBs, right? If so, to enable sending direct ATA commands to a SATA 
>> device, one has to create a ioctl that receives the command and 
>> creates a CDB from it, as John Linville did a few weeks ago. This way 
>> a user-space application (e.g. smartmontools) can use this ioctl to 
>> send ATA commands. Am I right?
> 
> 
> No.  SCSI "send CDB" ioctls have existed for years.
	Am I supposed to be able to run any ATA command from user-space now, 
then? Let's say I want to run a IDENTIFY DEVICE, how can I do that? I 
tried SG_IO, but sg_allow_access blocks my request since the 'ATA_16' 
command isn't recognized yet. Is there another way?

	Thanks again,
		Luciano

-- 
Luciano A. Stertz
luciano@tteng.com.br
T&T Engenheiros Associados Ltda
http://www.tteng.com.br
Fone/Fax (51) 3224 8425

Re: T10/04-262 ATA pass thru - patch.

[Andy Warner]

Luciano A. Stertz wrote:
> [...]
> 	Am I supposed to be able to run any ATA command from user-space now, 
> then? Let's say I want to run a IDENTIFY DEVICE, how can I do that? I 
> tried SG_IO, but sg_allow_access blocks my request since the 'ATA_16' 
> command isn't recognized yet. Is there another way?

I am using SG_IO to issue arbitrary ATA commands. Unfortunately
I can't share that customer code with you, sorry. But have
faith that you can do it. I've not had sg_allow_access()
get in my way doing this - I'll find out why not and report
back; I did not modify sg.c.

Until then, here's the result of an Identify Device (0xec) command:

$ sudo sg_ata sg=/dev/sg5 cmd=0xec buff=1b dev=0x00 style=2 swab=1
     0: 0x0C5A,0x3FFF,0xC837,0x0010,0x0000,0x0000,0x003F,0x0000: .Z?..7.......?..
     8: 0x0000,0x0000,0x334A,0x5331,0x435A,0x5351,0x2020,0x2020: ....3JS1CZSQ    
    16: 0x2020,0x2020,0x2020,0x2020,0x0000,0x4000,0x0004,0x332E:         ..@...3.
    24: 0x3137,0x2020,0x2020,0x5354,0x3331,0x3630,0x3032,0x3341: 17    ST3160023A
    32: 0x5320,0x2020,0x2020,0x2020,0x2020,0x2020,0x2020,0x2020: S               
    40: 0x2020,0x2020,0x2020,0x2020,0x2020,0x2020,0x2020,0x8010:               ..
    48: 0x0000,0x2F00,0x0000,0x0200,0x0200,0x0007,0x3FFF,0x0010: ../.........?...
    56: 0x003F,0xFC10,0x00FB,0x0010,0xFFFF,0x0FFF,0x0000,0x0007: .?..............
    64: 0x0003,0x0078,0x0078,0x00F0,0x0078,0x0000,0x0000,0x0000: ...x.x...x......
    72: 0x0000,0x0000,0x0000,0x0000,0x0002,0x0000,0x0000,0x0000: ................
    80: 0x007E,0x001B,0x3069,0x7C01,0x4003,0x3069,0x3C01,0x4003: .~..0i|.@.0i<.@.
    88: 0x203F,0x0000,0x0000,0xFEFE,0x0000,0x0000,0xFE00,0x0000:  ?..............
    96: 0x0000,0x0000,0x0000,0x0000,0x9EB0,0x12A1,0x0000,0x0000: ................
   104: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   112: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   120: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   128: 0x0000,0x9EB0,0x12A1,0x9EB0,0x12A1,0x2020,0x0002,0x42B6: ..........  ..B.
   136: 0x8000,0x008A,0x3C06,0x3C0A,0xFFFF,0x07C6,0x0100,0x0800: ....<.<.........
   144: 0x0FF0,0x1000,0x0002,0x0030,0x0000,0x0000,0x0000,0xFE06: .......0........
   152: 0x0000,0x0002,0x0050,0x008A,0x954F,0x0000,0x0023,0x000B: .....P...O...#..
   160: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   168: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   176: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   184: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   192: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   200: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   208: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   216: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   224: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   232: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   240: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000: ................
   248: 0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0xC8A5: ................

-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634

Re: T10/04-262 ATA pass thru - patch.

[Jeff Garzik]

Andy Warner wrote:
> Luciano A. Stertz wrote:
> 
>>[...]
>>	Am I supposed to be able to run any ATA command from user-space now, 
>>then? Let's say I want to run a IDENTIFY DEVICE, how can I do that? I 
>>tried SG_IO, but sg_allow_access blocks my request since the 'ATA_16' 
>>command isn't recognized yet. Is there another way?
> 
> 
> I am using SG_IO to issue arbitrary ATA commands. Unfortunately
> I can't share that customer code with you, sorry. But have
> faith that you can do it. I've not had sg_allow_access()
> get in my way doing this - I'll find out why not and report
> back; I did not modify sg.c.

Probably you were running as root, and Luciano was not (guessing)

	Jeff

Re: T10/04-262 ATA pass thru - patch.

[Andy Warner]

Jeff Garzik wrote:
> [...]
> Probably you were running as root, and Luciano was not (guessing)

Yup - but I was only doing it to get around the device
permissions (or so I thought.) Do people think I should
add ATA_16/ATA_12 to the approved list of scsi commands ?
-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634

Re: T10/04-262 ATA pass thru - patch.

[Jeff Garzik]

On Tue, Oct 05, 2004 at 05:37:03PM -0500, Andy Warner wrote:
> Jeff Garzik wrote:
> > [...]
> > Probably you were running as root, and Luciano was not (guessing)
> 
> Yup - but I was only doing it to get around the device
> permissions (or so I thought.) Do people think I should
> add ATA_16/ATA_12 to the approved list of scsi commands ?

If you do, it's not that simple -- you would need to check the ATA
command to see if it was permissible for an unpriveleged user to issue
that specific ATA command.

Otherwise, unpriveleged users could fry the hardware, or whatnot.

	Jeff

Re: T10/04-262 ATA pass thru - patch.

[Jens Axboe]

On Tue, Oct 05 2004, Jeff Garzik wrote:
> On Tue, Oct 05, 2004 at 05:37:03PM -0500, Andy Warner wrote:
> > Jeff Garzik wrote:
> > > [...]
> > > Probably you were running as root, and Luciano was not (guessing)
> > 
> > Yup - but I was only doing it to get around the device
> > permissions (or so I thought.) Do people think I should
> > add ATA_16/ATA_12 to the approved list of scsi commands ?
> 
> If you do, it's not that simple -- you would need to check the ATA
> command to see if it was permissible for an unpriveleged user to issue
> that specific ATA command.
> 
> Otherwise, unpriveleged users could fry the hardware, or whatnot.

This is getting more and more horrible...

ATA_16/ATA_12 should be allowed for read, and there should be a filter
for tha ta opcode below that. We need the per-genhd loadable command
filter lists for that.

-- 
Jens Axboe

Re: T10/04-262 ATA pass thru - patch.

[Luciano A. Stertz]

Jeff Garzik wrote:
> Andy Warner wrote:
> 
>> Luciano A. Stertz wrote:
>>
>>> [...]
>>>     Am I supposed to be able to run any ATA command from user-space 
>>> now, then? Let's say I want to run a IDENTIFY DEVICE, how can I do 
>>> that? I tried SG_IO, but sg_allow_access blocks my request since the 
>>> 'ATA_16' command isn't recognized yet. Is there another way?
>>
>>
>>
>> I am using SG_IO to issue arbitrary ATA commands. Unfortunately
>> I can't share that customer code with you, sorry. But have
>> faith that you can do it. I've not had sg_allow_access()
>> get in my way doing this - I'll find out why not and report
>> back; I did not modify sg.c.
> 
> 
> Probably you were running as root, and Luciano was not (guessing)
	I'm running as root. But there are many other variables in my 
environment... for example, I tried to back port the patch to an older 
2.4 kernel. Don't take my problem too seriously for now... I'll let you 
know if I discover something else.

-- 
Luciano A. Stertz
luciano@tteng.com.br
T&T Engenheiros Associados Ltda
http://www.tteng.com.br
Fone/Fax (51) 3224 8425

Re: T10/04-262 ATA pass thru - patch.

[Jeff Garzik]

Jens Axboe wrote:
> On Tue, Oct 05 2004, Jeff Garzik wrote:
> 
>>On Tue, Oct 05, 2004 at 05:37:03PM -0500, Andy Warner wrote:
>>
>>>Jeff Garzik wrote:
>>>
>>>>[...]
>>>>Probably you were running as root, and Luciano was not (guessing)
>>>
>>>Yup - but I was only doing it to get around the device
>>>permissions (or so I thought.) Do people think I should
>>>add ATA_16/ATA_12 to the approved list of scsi commands ?
>>
>>If you do, it's not that simple -- you would need to check the ATA
>>command to see if it was permissible for an unpriveleged user to issue
>>that specific ATA command.
>>
>>Otherwise, unpriveleged users could fry the hardware, or whatnot.
> 
> 
> This is getting more and more horrible...
> 
> ATA_16/ATA_12 should be allowed for read, and there should be a filter
> for tha ta opcode below that. We need the per-genhd loadable command
> filter lists for that.

I'm happy with requiring privelege for now...

	Jeff