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
On Tue, Apr 10, 2001 at 09:13:05PM +0200, Sancho Dauskardt wrote:
>
> > > What happens when swapping different size CompactFlash cards ?
> >
> >It appears that, if a TEST_UNIT_READY fails with the right sense data to
> >indicate a media-change, the disk is re-validated. But don't quote me on
> >
> > What happens when swapping different size CompactFlash cards ?
>
>It appears that, if a TEST_UNIT_READY fails with the right sense data to
>indicate a media-change, the disk is re-validated. But don't quote me on
>that...
Sounds good, but in a mount,umount,mount sequence only one TEST_UNIT_
On Tue, Apr 10, 2001 at 04:57:51PM +0200, Sancho Dauskardt wrote:
> So any ideas of how we can force the BLKRRPART ioctl() or sd_init_onedisk()
> with each mount ?
>
> What happens when swapping different size CompactFlash cards ?
It appears that, if a TEST_UNIT_READY fails with the right sense
>
>Re-reading the mapping:
>
>That's a problem. I'm not familiar enough with the way SCSI works to know
>how to tell it that the media changed. And if it knows that the media
>changed, will it get the capacity again? If no-one knows the answer to
>this off-hand, I'll read the source and find o
>
>They are deprecated anyway since they don't use the same
>voltage as newer ones (ie all the new smartmedia readers
>since at least 1 year or more can not use them)
Um, sorry to object, but:
Dev-ID:
E8,EC -> 1MB-3.3V
6E -> 1MB 3.3V or 5V
EA -> 2MB-3.3V
64 -> 2MB-5V
E5 ->
Le lun, 09 avr 2001 21:20:00, Robert Baruch a écrit :
> 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.
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
I see it's not that easy to get a generic & fast abstract support for the
different command sets.
Check out the ssfdc_xx.x files attached. I'm still waiting for approval
concerning the NDA, so only some bits on the real driver included.
Stil some more problems:
* when should the mapping table
>These cards would show up as 256bytes/sector devices to the scsi layer ?
>From all specs/docs I've seen, one should really hide this detail from
> other layers ?
Erk. The scsi layer does not support 256 byte block media
___
[EMAIL PROTECTED
> 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
I'm currently waiting for an O.K. on publishing the Carry-specific bits.
But until I (hopefully) get that, I'll publish the ssfdc_info.c &.h
Since I'm new to Linux-USB, where should I send the source to (~20K) ?
>I've been trying to work on write-access, hoping to have it done by the
>end of th
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
Um... I raised this issue a while back... nobody is interested in this for
general busses, but it might be good for USB devices, since we now have two
that need it.
I don't know if we support 1&2 MByte cards... but teh full mapping is so we
can add write support. Check the CVS repository, and if
On Sat, Apr 07, 2001 at 09:55:29PM +0200, Sancho Dauskardt wrote:
> I'm currently writing a driver for some Carry USB
> CompactFlash/SmartMedia/MemoryStick Card readers (www.carry.com.tw,
> USB-Vendor 0x7CC). I have some doc's under NDA and the CompactFlash part is
> already working quite nic
Hi all,
I'm currently writing a driver for some Carry USB
CompactFlash/SmartMedia/MemoryStick Card readers (www.carry.com.tw,
USB-Vendor 0x7CC). I have some doc's under NDA and the CompactFlash part is
already working quite nicely under 2.4.2.
Now I'm doing the SSFDC stuff. Of course I coul
19 matches
Mail list logo
