T10/04-262 ATA pass thru - patch.

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.

[...]
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?

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

drivers/scsi/libata-core.c +1 -1

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

drivers/scsi/libata-scsi.c +111 -5

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

include/scsi/scsi.h +3 -0

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

Quoted 3 lines · John W. Linville

[...]
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 ?

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:

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.

Quoted 3 lines · 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?

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

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

Quoted 8 lines · Jeff Garzik

Quoted 3 lines · 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?

Quoted 3 lines

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

[...]

Quoted 1 line

Are you checking this against Rev 3 of the spec ?

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

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 <[email protected]>

Quoted 3 lines · 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?

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?

Quoted 3 lines · Luciano A. Stertz

[...]
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)

Quoted 2 lines · Jeff Garzik

[...]
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 ?

Quoted 7 lines · Andy Warner

Quoted 2 lines · Jeff Garzik

[...]
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.

Quoted 8 lines · Andy Warner

Quoted 3 lines · Luciano A. Stertz

[...]
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?

Quoted 5 lines

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)

Quoted 15 lines · Jeff Garzik

Quoted 8 lines · Andy Warner

Quoted 2 lines · Jeff Garzik

[...]
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.

Quoted 1 line

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.