Skip to contentSkip to conversation

sg.c: SG_DXFER_TO_FROM_DEV mean DMA_BIDIRECTIONAL

PATCH In review Luben Tuikov 4 participants 4 messages Nov 4, 2006 – Nov 5, 2006

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 sg.c: SG_DXFER_TO_FROM_DEV mean DMA_BIDIRECTIONAL

SG_DXFER_TO_FROM_DEV means DMA_BIDIRECTIONAL, not
DMA_FROM_DEVICE.

---
 drivers/scsi/sg.c |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

This patch is 8 months old.

Luben

drivers/scsi/sg.c +5 -6
index 5a0a193..3f81477 100644
@@ -608,12 +608,11 @@ sg_write(struct file *filp, const char _
 	if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV)
 		if (printk_ratelimit())
 			printk(KERN_WARNING
-			       "sg_write: data in/out %d/%d bytes for SCSI command 0x%x--"
-			       "guessing data in;\n" KERN_WARNING "   "
-			       "program %s not setting count and/or reply_len properly\n",
+			       "sg_write: program %s: data in/out %d/%d bytes for SCSI command 0x%x--"
+			       "bidirectional;\n",
+			       current->comm,
 			       old_hdr.reply_len - (int)SZ_SG_HEADER,
-			       input_size, (unsigned int) cmnd[0],
-			       current->comm);
+			       input_size, (unsigned int) cmnd[0]);
 	k = sg_common_write(sfp, srp, cmnd, sfp->timeout, blocking);
 	return (k < 0) ? k : count;
 }
@@ -724,13 +723,13 @@ sg_common_write(Sg_fd * sfp, Sg_request
 	}
 
 	switch (hp->dxfer_direction) {
-	case SG_DXFER_TO_FROM_DEV:
 	case SG_DXFER_FROM_DEV:
 		data_dir = DMA_FROM_DEVICE;
 		break;
 	case SG_DXFER_TO_DEV:
 		data_dir = DMA_TO_DEVICE;
 		break;
+	case SG_DXFER_TO_FROM_DEV:
 	case SG_DXFER_UNKNOWN:
 		data_dir = DMA_BIDIRECTIONAL;
 		break;
Signature · 1 line
1.4.3.3.g8478
#2 lore raw
In reply to Luben Tuikov
Quoted 9 lines · Luben Tuikov

SG_DXFER_TO_FROM_DEV means DMA_BIDIRECTIONAL, not
DMA_FROM_DEVICE.

---
 drivers/scsi/sg.c |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

This patch is 8 months old.

While this patch is sensible, it breaks a very arcane usage that I inherited with the sg driver in 1998. At that time there was no resid, so application clients (e.g. cdrecord) had no way of knowing if the amount of data they requested to be read, was actually read. So, as indirect IO was the only game in town, the hack used was to prefill the kernel buffer prior to a read, and then check if it had been overwritten after the read operation.
Hence SG_DXFER_TO_FROM_DEV was actually a read from the device.

Some LLDs still do not implement resid (properly).

I'm happy to accept the change as long as people are prepared to wear the breakage.

Doug Gilbert

#3 lore raw
Quoted 2 lines · Douglas Gilbert

I'm happy to accept the change as long as people are prepared to wear the breakage.

You're the maintainer ... is that an ACK or a NACK?

James