Skip to contentSkip to conversation

CDC_MMC_WR

PATCH New Pat LaVarre 1 participant 4 messages Nov 1, 2003 – Nov 6, 2003

Subsystems (2)
lore
Share & tools
lore
#0 lore raw
Quoted 3 lines

My 2003-10-13 -test7 patch,
with the q=raw suffix included
to help ask for hard tabs etc. intact, appears archived as:

Bzzzzt. Wrong link, sorry.

To see that 2.6.0-test7 patch that works -test8 or -test9 as well, the correct link into the depths of history is:

http://marc.theaimsgroup.com/?l=linux-scsi&m=106605749929120&q=raw

I know this because now for a friend I'm trying to apply this patch to 2.4.22.

Pat LaVarre

P.S. Of course unless you add an eol to the linux-scsi majordomo signature, you will be warned: "patch unexpectedly ends in middle of line".

#1 lore raw

PATCH 1/1 Backport CDC_MMC_WR

Jens A:

I have not yet seen you comment.

Quoted 2 lines

To see that 2.6.0-test7 patch that works -test8 or -test9 as well ...
http://marc.theaimsgroup.com/?l=linux-scsi&m=106605749929120&q=raw

With the inline plain text patch below, 2.4.22 seemingly works too, if we transliterate to 2.4 syntax from 2.6 syntax. Also here you can see I added some cdinfo %s cdi->name. I imagine we want those in 2.6.1 as well.

Personally I'm still too ignorant to know how to test for trouble, if by chance a patch of mine declares a /dev/scd$n writable that actually is not writable.

Pat LaVarre

drivers/cdrom/cdrom.c +53 -1
diff -Nur linux-2.4.22/drivers/cdrom/cdrom.c linux/drivers/cdrom/cdrom.c
@@ -310,6 +310,7 @@
 #define CHECKAUDIO if ((ret=check_for_audio_disc(cdi, cdo))) return ret
 
 /* Not-exported routines. */
+static void cdrom_get_cdc(struct cdrom_device_info *cdi);
 static int open_for_data(struct cdrom_device_info * cdi);
 static int check_for_audio_disc(struct cdrom_device_info * cdi,
 			 struct cdrom_device_ops * cdo);
@@ -402,6 +403,8 @@
 	cdinfo(CD_REG_UNREG, "drive \"/dev/%s\" registered\n", cdi->name);
 	cdi->next = topCdromPtr; 	
 	topCdromPtr = cdi;
+
+	cdrom_get_cdc(cdi);
 	return 0;
 }
 #undef ENSURE
@@ -436,6 +439,51 @@
 	return 0;
 }
 
+static int cdrom_get_configuration(struct cdrom_device_info *cdi)
+{
+	struct cdrom_generic_command cgc;
+	struct cdrom_device_ops *cdo = cdi->ops;
+	u_char buf[8];
+	int ret;
+	init_cdrom_command(&cgc, buf, sizeof(buf), CGC_DATA_READ);
+	cgc.cmd[0] = GPCMD_GET_CONFIGURATION;
+	cgc.cmd[7] = cgc.buflen >> 8;
+	cgc.cmd[8] = cgc.buflen & 0xff;
+	cgc.data_direction = CGC_DATA_READ;
+	ret = cdo->generic_packet(cdi, &cgc);
+	if (!ret) {
+		int profile = buf[6] << 8 | buf[7];
+		cdinfo(CD_REG_UNREG, "/dev/%s profile x%04X\n",
+			cdi->name, profile);
+		switch (profile) {
+			case 0x0001: /* Non-Removable Disk */
+			case 0x0002: /* Removable Disk */
+			case 0x0003: /* Magneto-Optical Erasable */
+			case 0x0005: /* AS-MO */
+			case 0x0012: /* DVD-RAM */
+			case 0x0022: /* DDCD-RW */
+				return 0;
+			case 0x001A: /* DVD+RW = not much rewrite in place */
+			default:
+				break;
+		}
+	}
+	cdi->mask |= CDC_MMC_WR;
+	return ret;
+}
+
+static void cdrom_get_cdc(struct cdrom_device_info *cdi)
+{
+	if (CDROM_CAN(CDC_MMC_WR) && !CDROM_CAN(CDC_DVD_RAM)) {
+		cdinfo(CD_REG_UNREG, "/dev/%s"
+			" cdrom_get_configuration\n", cdi->name);
+		if (cdrom_get_configuration(cdi)) {
+			cdinfo(CD_REG_UNREG, "/dev/%s"
+				" cdrom_get_configuration not\n", cdi->name);
+		}
+	}
+}
+
 struct cdrom_device_info *cdrom_find_device(kdev_t dev)
 {
 	struct cdrom_device_info *cdi;
@@ -465,7 +513,7 @@
 	if ((cdi = cdrom_find_device(dev)) == NULL)
 		return -ENODEV;
 
-	if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_DVD_RAM))
+	if ((fp->f_mode & FMODE_WRITE) && !CDROM_CAN(CDC_MMC_WR))
 		return -EROFS;
 
 	/* if this was a O_NONBLOCK open and we should honor the flags,
@@ -2479,6 +2527,10 @@
 	for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
 	    pos += sprintf(info+pos, "\t%d", CDROM_CAN(CDC_DVD_RAM) != 0);
 
+	pos += sprintf(info+pos, "\nTolerates random write:");
+	for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
+	    pos += sprintf(info+pos, "\t%d", CDROM_CAN(CDC_MMC_WR) != 0);
+
 	strcpy(info+pos,"\n\n");
 		
         return proc_dostring(ctl, write, filp, buffer, lenp);
include/linux/cdrom.h +2 -0
diff -Nur linux-2.4.22/include/linux/cdrom.h linux/include/linux/cdrom.h
@@ -387,6 +387,8 @@
 #define CDC_DVD			0x8000	/* drive is a DVD */
 #define CDC_DVD_R		0x10000	/* drive can write DVD-R */
 #define CDC_DVD_RAM		0x20000	/* drive can write DVD-RAM */
+// CDC_MO_DRIVE
+#define CDC_MMC_WR		0x80000 /* profile includes random write */
 
 /* drive status possibilities returned by CDROM_DRIVE_STATUS ioctl */
 #define CDS_NO_INFO		0	/* if not implemented */
drivers/ide/ide-cd.c +1 -1
diff -Nur linux-2.4.22/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
@@ -2683,7 +2683,7 @@
 				CDC_MEDIA_CHANGED | CDC_PLAY_AUDIO | CDC_RESET |
 				CDC_IOCTLS | CDC_DRIVE_STATUS | CDC_CD_R |
 				CDC_CD_RW | CDC_DVD | CDC_DVD_R| CDC_DVD_RAM |
-				CDC_GENERIC_PACKET,
+				CDC_GENERIC_PACKET | CDC_MMC_WR,
 	generic_packet:		ide_cdrom_packet,
 };
 
drivers/scsi/sr.c +4 -4
diff -Nur linux-2.4.22/drivers/scsi/sr.c linux/drivers/scsi/sr.c
@@ -128,7 +128,8 @@
 				CDC_MEDIA_CHANGED | CDC_PLAY_AUDIO |
 				CDC_RESET | CDC_IOCTLS | CDC_DRIVE_STATUS |
 				CDC_CD_R | CDC_CD_RW | CDC_DVD | CDC_DVD_R |
-				CDC_DVD_RAM | CDC_GENERIC_PACKET,
+				CDC_DVD_RAM | CDC_GENERIC_PACKET |
+				CDC_MMC_WR,
 	generic_packet:		sr_packet,
 };
 
@@ -407,7 +408,8 @@
 		return 0;
 	}
 
-	if ((SCpnt->request.cmd == WRITE) && !scsi_CDs[dev].device->writeable)
+	if ((SCpnt->request.cmd == WRITE) &&
+			((scsi_CDs[dev].cdi.mask & CDC_MMC_WR) != 0))
 		return 0;
 
 	/*
@@ -754,8 +756,6 @@
 	if ((buffer[n + 3] & 0x20) == 0) {
 		/* can't write DVD-RAM media */
 		scsi_CDs[i].cdi.mask |= CDC_DVD_RAM;
-	} else {
-		scsi_CDs[i].device->writeable = 1;
 	}
 	if ((buffer[n + 3] & 0x10) == 0)
 		/* can't write DVD-R media */
#2 lore raw
In reply to Pat LaVarre

Kindly offline I hear we want a better patch, specifically:

Have "the ->writeable bit actually be set if the device is writeable".

Anybody able to help me decrypt that remark more rapidly?

Does the ->writeable bit exist for ide-cd devices, or only for sr devices?

When cdrom.ko decides a device is not writable, how does cdrom.ko name that bit, else how does cdrom.ko call into ide-cd/sr to clear that bit?

Pat LaVarre

P.S. The 2.4.22 version of this 2.6.0-test7 -test8 -test9 patch is:

http://marc.theaimsgroup.com/?l=linux-scsi&m=106764981303759

List:     linux-scsi
Subject:  [PATCH] Backport CDC_MMC_WR
Date:     2003-11-01 1:22:49
#3 lore raw
Quoted 2 lines

Does the ->writeable bit exist for ide-cd devices, or only for sr devices?

I'm guessing only sr devices, since grep writeable fails in drivers/ide/ and in drivers/cdrom/.

Quoted 2 lines

When cdrom.ko decides a device is not writable, how does cdrom.ko name that bit, else how does cdrom.ko call into ide-cd/sr to clear that bit?

Call back into sr from cdrom may occur via the cdrom_device_ops.

We define cdrom_ioctl CDROM_GET_CAPABILITY but no SET of capability, though we do define CDROM_SET_OPTIONS.

Maybe we're telling me to add a call back to the cdrom_device_ops for cdrom to notify ide-cd/sr that the capabilities have changed. ide-cd could ignore that notification, sr could set scsi_cd->scsi_device->writeable accordingly.

Quoted 1 line

Have "the ->writeable bit actually be set if the device is writeable".

grep is failing to find code for me that fetches this bit.

Is this bit ever fetched?

http://lxr.linux.no/ident?v=2.6.0-test7&i=writeable
no hits.

http://lxr.linux.no/search?v=2.6.0-test7&string=writeable
over seventy hits. Apparently none relevant, except to say scsi_scan sets this bit for sd, clears this bit for sr, and sr sometimes sets and fetches this bit until I patch sr to branch on CDC_MMC_WR instead.

Pat LaVarre