Hi,
please consider the small patch below (for 2.4.19-rc1), adding support
for the Sagatek DCS-CF (aka Datafab KECF-USB - 07c4:a400) USB-CompactFlash
apdapter. Tested a little by copying files back and forth - transfer
speed is about 600 KB/s, and it hasn't crashed on me yet. I understand
it is a bit late before 2.4.19, but the device does not work at all
without the patch, and the patch does not change anything for other
vendor:device IDs, so there should be no risk of breaking things...
The new "limit INQUIRY to 36 bytes" flag might help other devices too
(instead of just not sending INQUIRY at all) if someone wants to try.
I just wanted to see what the device has to say - here are the kernel
messages with a 64 MB (really 61 MiB) CompactFlash card inserted:
hub.c: USB new device connect on bus1/1, assigned device number 2
scsi1 : SCSI emulation for USB Mass Storage devices
Vendor: Generic Model: STORAGE DEVICE Rev: 0.01
Type: Direct-Access ANSI SCSI revision: 02
Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0
SCSI device sda: 125441 512-byte hdwr sectors (64 MB)
usb-storage: Command will be truncated to fit in SENSE6 buffer.
sda: Write Protect is off
sda: sda1
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 2
The device I have was bought as "Sagatek DCS-CF".
I asked [email protected] for Linux support - they said it doesn't
work, but they may "consider supporting Linux in the near future".
I guess they mean "consider fixing the firmware in the near future" :)
Then I found this - http://martin.wilck.bei.t-online.de/
(the patch available there is a bit more complicated - my patch only
limits INQUIRY length to 36 bytes for one device, not all of them).
The device is called Datafab KECF-USB there, but the vendor and product
ID is the same; to add more confusion, my usb.ids file says that 07c4 is
"Simple Technologies, Inc." - who is the real manufacturer then? :)
Thanks,
Marek
--- linux/drivers/usb/storage/protocol.c.orig Tue Jun 25 15:38:23 2002
+++ linux/drivers/usb/storage/protocol.c Tue Jun 25 21:26:11 2002
@@ -283,6 +283,14 @@
{
int old_cmnd = 0;
+ /*
+ * Workaround for some devices - limit INQUIRY to 36 bytes.
+ */
+ if ((us->flags & US_FL_INQUIRY_36)
+ && srb->cmnd[0] == INQUIRY
+ && srb->cmnd[4] > 36)
+ srb->cmnd[4] = 36;
+
/* This code supports devices which do not support {READ|WRITE}_6
* Apparently, neither Windows or MacOS will use these commands,
* so some devices do not support them
--- linux/drivers/usb/storage/unusual_devs.h.orig Tue Jun 25 15:38:23 2002
+++ linux/drivers/usb/storage/unusual_devs.h Tue Jun 25 22:12:05 2002
@@ -461,6 +461,13 @@
US_FL_MODE_XLATE ),
#endif
+/* aka Sagatek DCS-CF (same vendor and product id) */
+UNUSUAL_DEV( 0x07c4, 0xa400, 0x0000, 0xffff,
+ "Datafab",
+ "KECF-USB",
+ US_SC_SCSI, US_PR_BULK, NULL,
+ US_FL_MODE_XLATE | US_FL_START_STOP | US_FL_INQUIRY_36 ),
+
/* Casio QV 2x00/3x00/4000/8000 digital still cameras are not conformant
* to the USB storage specification in two ways:
* - They tell us they are using transport protocol CBI. In reality they
--- linux/drivers/usb/storage/usb.h.orig Thu Nov 22 20:49:34 2001
+++ linux/drivers/usb/storage/usb.h Tue Jun 25 22:12:01 2002
@@ -101,6 +101,7 @@
#define US_FL_IGNORE_SER 0x00000010 /* Ignore the serial number given */
#define US_FL_SCM_MULT_TARG 0x00000020 /* supports multiple targets */
#define US_FL_FIX_INQUIRY 0x00000040 /* INQUIRY response needs fixing */
+#define US_FL_INQUIRY_36 0x00000080 /* Limit INQUIRY to 36 bytes */
#define USB_STOR_STRING_LEN 32
On Tue, Jun 25, 2002 at 11:44:51PM +0200, Marek Michalkiewicz wrote:
> Hi,
>
> please consider the small patch below (for 2.4.19-rc1), adding support
> for the Sagatek DCS-CF (aka Datafab KECF-USB - 07c4:a400) USB-CompactFlash
> apdapter. Tested a little by copying files back and forth - transfer
> speed is about 600 KB/s, and it hasn't crashed on me yet. I understand
> it is a bit late before 2.4.19, but the device does not work at all
> without the patch, and the patch does not change anything for other
> vendor:device IDs, so there should be no risk of breaking things...
Heh, send this to me again after 2.4.19-final is out, and I'll
reconsider it :)
thanks,
greg k-h
> Heh, send this to me again after 2.4.19-final is out, and I'll
> reconsider it :)
Do you see any potential problems with the patch, or is 2.4.19-final
now simply so close that you really don't want to change anything?
Thanks,
Marek
On Wed, Jun 26, 2002 at 05:14:17PM +0200, Marek Michalkiewicz wrote:
> > Heh, send this to me again after 2.4.19-final is out, and I'll
> > reconsider it :)
>
> Do you see any potential problems with the patch, or is 2.4.19-final
> now simply so close that you really don't want to change anything?
2.4.19-final is too close. I'll trust Matt to tell me if the patch is
ok or not technically, as it's his code. I'd also prefer for you to
work through him, as he is the maintainer, and not try to send things
like this to Marcelo directly (read Documentation/SubmittingPatches).
thanks,
greg k-h
> 2.4.19-final is too close. I'll trust Matt to tell me if the patch is
> ok or not technically, as it's his code. I'd also prefer for you to
> work through him, as he is the maintainer, and not try to send things
> like this to Marcelo directly (read Documentation/SubmittingPatches).
OK, and sorry if sending directly to Marcelo was the wrong thing to do
(I wouldn't have done that if the patch might affect other devices).
I've just played a little more with this device, and here is the really
minimal patch (new entry in unusual_devs.h for the flags, no other
changes in the code) - there should be no doubt if it's OK technically,
as it makes a device work that previously didn't...
The device I have is called "Sagatek DCS-CF", but the name "Sagatek"
is only on the packaging, and the "DCS-CF" is only on a small sticker
at tbe bottom side. So I left the name "Datafab" in the entry,
assuming it's really the same device inside (same vendor:product ID)
so I guess it's a Datafab product and Sagatek really just sells it...
Please at least consider this - later, the larger issue of limiting
INQUIRY to 36 bytes might have a different solution (in the SCSI code),
but in the meantime this micro-patch is sufficient. Thanks.
Regards,
Marek
--- linux/drivers/usb/storage/unusual_devs.h.orig Tue Jun 25 15:38:23 2002
+++ linux/drivers/usb/storage/unusual_devs.h Wed Jun 26 17:45:59 2002
@@ -461,6 +461,13 @@
US_FL_MODE_XLATE ),
#endif
+/* aka Sagatek DCS-CF */
+UNUSUAL_DEV( 0x07c4, 0xa400, 0x0000, 0xffff,
+ "Datafab",
+ "KECF-USB",
+ US_SC_SCSI, US_PR_BULK, NULL,
+ US_FL_FIX_INQUIRY | US_FL_MODE_XLATE | US_FL_START_STOP ),
+
/* Casio QV 2x00/3x00/4000/8000 digital still cameras are not conformant
* to the USB storage specification in two ways:
* - They tell us they are using transport protocol CBI. In reality they
Hi,
> Heh, send this to me again after 2.4.19-final is out, and I'll
> reconsider it :)
Over a month later, here it is - this drivers/usb/storage/unusual_devs.h
entry appears to be sufficient to make my Sagatek DCS-CF work:
/* aka Sagatek DCS-CF */
UNUSUAL_DEV( 0x07c4, 0xa400, 0x0000, 0xffff,
"Datafab",
"KECF-USB",
US_SC_SCSI, US_PR_BULK, NULL,
US_FL_FIX_INQUIRY ),
Not even US_FL_MODE_XLATE or US_FL_START_STOP is necessary as far as
I can tell, but I guess that may depend on the chip revision.
US_FL_FIX_INQUIRY is required, or the device does not work at all...
Boot messages (with a 64MB == ~61 MiB CF card) look like this:
scsi1 : SCSI emulation for USB Mass Storage devices
Vendor: Datafab Model: KECF-USB Rev: 0113
Type: Direct-Access ANSI SCSI revision: 02
Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0
SCSI device sda: 125185 512-byte hdwr sectors (64 MB)
sda: test WP failed, assume Write Enabled
sda: sda1
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 2
The "test WP failed" message appears to be harmless - I have tested
reading and writing, and it works for me.
Marek
On Sun, Aug 04, 2002 at 03:22:04PM +0200, Marek Michalkiewicz wrote:
> Hi,
>
> > Heh, send this to me again after 2.4.19-final is out, and I'll
> > reconsider it :)
>
> Over a month later, here it is - this drivers/usb/storage/unusual_devs.h
> entry appears to be sufficient to make my Sagatek DCS-CF work:
>
> /* aka Sagatek DCS-CF */
> UNUSUAL_DEV( 0x07c4, 0xa400, 0x0000, 0xffff,
> "Datafab",
> "KECF-USB",
> US_SC_SCSI, US_PR_BULK, NULL,
> US_FL_FIX_INQUIRY ),
That's a wide range for this device, do you really need 0x0000 - 0xffff
for this?
And send a patch to Matt, if he agrees with it, he'll send it on to me.
thanks,
greg k-h
Envelope-to: [email protected]
Date: Mon, 5 Aug 2002 08:56:58 -0700
From: Greg KH <[email protected]>
To: Marek Michalkiewicz <[email protected]>
cc: [email protected], [email protected],
[email protected], [email protected]
Subject: Re: [patch] USB storage: Datafab KECF-USB, Sagatek DCS-CF
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
Content-Disposition: inline
In-Reply-To: <[email protected]>
User-Agent: Mutt/1.4i
X-Operating-System: Linux 2.2.21 (i586)
Reply-By: Mon, 08 Jul 2002 14:36:57 -0700
(Sorry for the delay - found an old email lost between tons of spam...)
> On Sun, Aug 04, 2002 at 03:22:04PM +0200, Marek Michalkiewicz wrote:
> > Hi,
> >
> > > Heh, send this to me again after 2.4.19-final is out, and I'll
> > > reconsider it :)
> >
> > Over a month later, here it is - this drivers/usb/storage/unusual_devs.h
> > entry appears to be sufficient to make my Sagatek DCS-CF work:
> >
> > /* aka Sagatek DCS-CF */
> > UNUSUAL_DEV( 0x07c4, 0xa400, 0x0000, 0xffff,
> > "Datafab",
> > "KECF-USB",
> > US_SC_SCSI, US_PR_BULK, NULL,
> > US_FL_FIX_INQUIRY ),
>
> That's a wide range for this device, do you really need 0x0000 - 0xffff
> for this?
Well, I don't know what to do - the device I have is reported as
revision 0113. But the patch on http://martin.wilck.bei.t-online.de/
has a range of 0x0000 - 0x0015 so it would not handle my device.
> And send a patch to Matt, if he agrees with it, he'll send it on to me.
He is on the Cc: list. Please consider this entry, possibly with
US_FL_START_STOP and US_FL_MODE_XLATE flags added (no difference
for me, but present in the patch on the above mentioned page), for
inclusion in 2.4.20. I can make a patch if you tell me what range
and flags would be accepted.
Support for such devices out of the box becomes more important now
that motherboard BIOSes start supporting boot from USB storage
(so you could easily install a Linux distribution on a CF card,
or use one as a rescue disk simply plugged into an USB port if ever
needed - no need for a floppy or CD-ROM drive in a server).
I don't know how widespread this is, but such a feature has just
appeared in the latest MSI MS-6368 BIOS upgrade, for example...
Thanks,
Marek
Am Don, 2002-08-29 um 15.57 schrieb Marek Michalkiewicz:
> > > /* aka Sagatek DCS-CF */
> > > UNUSUAL_DEV( 0x07c4, 0xa400, 0x0000, 0xffff,
> > > "Datafab",
> > > "KECF-USB",
> > > US_SC_SCSI, US_PR_BULK, NULL,
> > > US_FL_FIX_INQUIRY ),
This works fine with 2.4.20 - congratulations!!
I wonder what happened to the SCSI inquiry - was it limited to 36 bytes?
Martin
> Am Don, 2002-08-29 um 15.57 schrieb Marek Michalkiewicz:
> > > > /* aka Sagatek DCS-CF */
> > > > UNUSUAL_DEV( 0x07c4, 0xa400, 0x0000, 0xffff,
> > > > "Datafab",
> > > > "KECF-USB",
> > > > US_SC_SCSI, US_PR_BULK, NULL,
> > > > US_FL_FIX_INQUIRY ),
>
> This works fine with 2.4.20 - congratulations!!
> I wonder what happened to the SCSI inquiry - was it limited to 36 bytes?
My understanding is that US_FL_FIX_INQUIRY flag fakes a response
without sending the SCSI inquiry to the device at all.
What revision number does your device have, so we can limit the range
(mine is 0113)? How about US_FL_MODE_XLATE and US_FL_START_STOP -
how to test if these flags are necessary?
Thanks,
Marek
On Mon, Sep 02, 2002 at 08:41:13AM +0200, Marek Michalkiewicz wrote:
> > Am Don, 2002-08-29 um 15.57 schrieb Marek Michalkiewicz:
> > > > > UNUSUAL_DEV( 0x07c4, 0xa400, 0x0000, 0xffff,
> > > > > "Datafab",
> > > > > "KECF-USB",
> > > > > US_SC_SCSI, US_PR_BULK, NULL,
> > > > > US_FL_FIX_INQUIRY ),
> >
> > This works fine with 2.4.20 - congratulations!!
> > I wonder what happened to the SCSI inquiry - was it limited to 36 bytes?
>
> My understanding is that US_FL_FIX_INQUIRY flag fakes a response
> without sending the SCSI inquiry to the device at all.
>
> What revision number does your device have, so we can limit the range
> (mine is 0113)? How about US_FL_MODE_XLATE and US_FL_START_STOP -
> how to test if these flags are necessary?
I wrote in my unusual_devices.h source:
/* Marek Michalkiewicz - needed at least for revisions 0015 and 0113 */
UNUSUAL_DEV( 0x07c4, 0xa400, 0x0000, 0xffff,
"Datafab",
"KECF-USB",
US_SC_SCSI, US_PR_BULK, NULL,
US_FL_FIX_INQUIRY ),
and
/* aeb - needed at least for revision 0100 */
UNUSUAL_DEV( 0x090c, 0x1132, 0x0000, 0xffff,
"Feiya",
"5-in-1 Card Reader",
US_SC_SCSI, US_PR_BULK, NULL,
US_FL_FIX_CAPACITY ),
If some revision has a certain property then most likely a later revision
has the same property. We maximize the chances that someone's device
will work out of the box by making the range as large as possible.
But document in the source what precisely is needed, so that if we
find a later revision without the quirk, the limits can be adapted.
Andries