Ken Hahn wrote:
>
> Hi,
>
> My name is Ken Hahn. I work as an Engineer at Micro Solutions (the people
> who make BACKPACK CD-RW's and CD-ROMS).
>
> I'm happy to be able to tell you that we are releasing source code to make
> our BACKPACK USB adapter work with Linux, under the GPL (attached to this
> e-mail).
On behalf on Linux users, and GPL bigots, everywhere, thanks for this all-too-rare
but very welcome decision.
> This driver works by uploading firmware to the adapter which makes it look
> like a mass-storage class device. At this point, the usb-storage code takes
> over. There are actually 5 firmwares (1 to scan, and 4 for different types
> of drives).
>
> This code does come with a caveat. It is not finished yet, I just figured
> I'd get it up and out to others to be looked at. It has one particular
> problem that will keep it from working under certain circumstances (next
> paragraph describes the problem and how to get around it)
>
> Our device is not quite a self powered device or a usb-powered device. As a
> result, when you connect it to the drive before you connect it to a USB hub,
> it requires more time to initialize than is currently allowed by the Linux
> kernel. This can be solved by incrementing HUB_PROBE_TRIES in hub.c from 2
> to 3 retries, as this allows enough time for the device to initialize. (We
> need about 500 ms. I belive the current 2 retries only provides 400 ms)
This is well out of spec. My reading of the USB Spec 1.1 says that you get
100ms of debounce (Taadb) and 10ms of reset recovery (Yrstrcy). This is from
Table 7-11 and Figure 7-19.
You might be able to do something like the sony memory stick reader, which has
a hub built in, but the reader device only "connects" to the hub when the
media is put in. You still might be in trouble for the "media in on start" case
though.
> Would folk be open to increasing this number from 2 to 3? This would be the
> simplest solve as it doesn't really punish any device that probes faster.
I don't see any problem, but you need to appeal to the maintainer.
> Thanks, and enjoy the code,
>
> Ken Hahn
> Engineer - Micro Solutions
>
> P.S. Any help merging this into kernel code (and creating a patch out of
> it) will be very much appreciated! :)
How appreciated :)
I will do it later today (with an ugly ifdef if Johannes hasn't decided on the
2 vs 3 issue).
If someone else beats me, I think that the firmware should be segmented, like
the stuff that Hugh Blemings did for the Keyspan devices. Otherwise there is
too much kernel bloat from the firmware.
In any case, I recommend that you guys make sure that Matthew Dharm (who
maintains the USB Mass Storage driver) has one (or more) of your devices.
Brad
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
