Matthew Dharm wrote:
>> * mount -r -n /dev/sda1 /mnt/cf
>> START_STOP - start
>
>
> Here is where we need to change the behavior. Right here we need to fail
> the command with the right sense data -- at least, that seems to work
> correctly for other devices. Th
Looking at the code, there's clear potential.
Just to make sure I understand, the idea of this code is to serve as an
interface between the USB-storage driver and a device-specific reader?
So that any SmartMedia reader only has to implement the various commands
in the ssfdc_info?
If that is t
BTW, I think the standard kernel source tabspace is 8... I don't think
the ssfdc_mgr.* code conforms to that?
--Rob
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Sancho Dauskardt wrote:
>
> * when should the mapping table be rebuilt ?
>START_STOP time & ALLOW_MEDIUM_REMOVAL time aren't quite suitable...
>Or ist there just an easy mount option which forces READ_CAPACITY to
> always be called ?
Dunno... This is probably related to the "mount/umo
Alan Cox wrote:
> Erk. The scsi layer does not support 256 byte block media
Oh dear.
Uhh...1MB and 2MB cards are obsolete?
Does anyone actually have any of these cards? Maybe we should fatally
deprecate them.
--Rob
___
[EMAIL PROTECTED]
To uns
> Since I'm new to Linux-USB, where should I send the source to (~20K) ?
Can you tar and bzip/gzip it? Then I think it could go on this list.
> Size is ment to be bytes --> O.K. to write multiple pages in one shot.
> I'll add comments.
Ok, that's better then. But then I probably wouldn't call
Sancho Dauskardt wrote:
> Now I'm doing the SSFDC stuff. Of course I could just copy sddr09 and
> fudge in the differences USB protocol stuff, but I would prefer to
> transfer all the SSFDC-things into a separate ssfdc_mgr.c which could be
> used by all SSFDC devices, regardless of the bus/d
Nnnn-kay... I upgraded to 2.4.3 and didn't have a problem... I'll wait
for more info.
--Rob
> Eric Sandeen wrote:
>
>
>>
>> Hm, I hit the "too big size" BUG() in kmalloc in this version.
>>
>> Loaded module, mounted the device, and tried a cp *.jpg, and it oopsed
>> on that bug. :(
_
Eric Sandeen wrote:
>
> Hm, I hit the "too big size" BUG() in kmalloc in this version.
>
> Loaded module, mounted the device, and tried a cp *.jpg, and it oopsed
> on that bug. :(
Oh dear.
I'm on kernel 2.4.2. What kernel are you on? I'll probably upgrade to
the most recent prekernel to se
All,
The latest release of the SDDR09 driver (in the CVS tree) contains fixes
for reading 32MB and larger SmartMedia cards. I was able to successfully
read a fully-loaded 32MB card. Also I added support for 128MB cards.
--Rob
___
[EMAIL PROTECTED]
*
* Current development and maintenance by:
* (c) 2000, 2001 Robert Baruch ([EMAIL PROTECTED])
*
* The SanDisk SDDR-09 SmartMedia reader uses the Shuttle EUSB-01 chip.
* This chip is a programmable USB controller. In the SDDR-09, it has
* been programmed to obey a certain limited set of SCSI
een something like this before... AFAICT, it's a cosmetic error in
> the /proc/scsi/scsi display.
>
> Matt
>
> On Tue, Mar 27, 2001 at 07:55:41PM -0500, Robert Baruch wrote:
>
>> I attached both the SDDR09 and HP8200e, modprobed usb-storage, and I
>> found tha
> This line looks funny:
>
> srb->request_bufflen
>
> Shouldn't it be ???
>
> srb->request_bufflen = sizeof(mode_page_01))
>
Will,
No, that's the way it should be. If the size of the buffer that we're
going to put the answer into is less than what we need, then retur
,9 @@
/* Driver for SCM Microsystems USB-ATAPI cable
*
- * $Id: shuttle_usbat.c,v 1.11 2000/11/13 22:29:36 mdharm Exp $
+ * $Id: shuttle_usbat.c,v 1.14 2001/03/28 01:02:06 groovyjava Exp $
*
* Current development and maintenance by:
- * (c) 2000 Robert Baruch ([EMAIL PROTECTED])
+ * (
I attached both the SDDR09 and HP8200e, modprobed usb-storage, and I
found that according to /proc/scsi/scsi, both devices got the same scsi
LUN! Not sure where in the code the LUN's are allocated, though.
--Rob
___
[EMAIL PROTECTED]
To unsubscribe,
Matthew Dharm wrote:
> Rob --
>
> Are you sure this is the right patch file? It doesn't look like it
> implements the changes you describe...
>
> Matt
For sure... Unless what's in CVS isn't in kernel 2.4.2. This is a patch
against the previous version of what's in CVS.
It looks funny when i
And here is the change (relative to the previous patch) to the SDDR09
driver which accepts an ALLOW_MEDIUM_REMOVAL command (and does nothing
with it except put out a debug message).
It's in CVS, and here is the patch.
--Rob
--- sddr09.c.orig Tue Mar 27 17:28:34 2001
+++ sddr09.cTue
maintenance by:
- * (c) 2000 Robert Baruch ([EMAIL PROTECTED])
+ * (c) 2000, 2001 Robert Baruch ([EMAIL PROTECTED])
*
* The SanDisk SDDR-09 SmartMedia reader uses the Shuttle EUSB-01 chip.
* This chip is a programmable USB controller. In the SDDR-09, it has
@@ -38,7 +38,7 @@
#include
Right, OK, that explains it. I need to modify the driver to respond to a
mode sense on page 0x3F as well as 0x01. The SDDR-09 does not respond to
MODE SENSE requests at all, so I need to dummy up the proper response.
Clearly I have to do the same with ALLOW MEDIUM REMOVAL.
--Rob
Matthew Dharm
Hi Willy,
I'll probably have to investigate the ALLOW MEDIUM REMOVAL command, but
the MODE SENSE command is a little puzzling... Can you provide a kernel
log of the command that gets sent to the driver? The driver is supposed
to handle one MODE SENSE command, but if there are more it should
h
20 matches
Mail list logo
