|
Howdy,
Sorry this e-mail is a bit long, but hopefully I'll get all my issues in one e-mail and not have to spam the list with a bunch of questions. Last April (the fourth of April to be exact), I posted some code here that allowed a BACKPACK USB adapter to be used under Linux. I began to try and get it working as a kernel patch, but was pulled onto another project. Brad Hards had gotten it into a preliminary patch, but it had never gotten in to final form. I now have some time to get it working. I just looked at the usb code and it's changed a little while I was gone. So, I have a few questions. Some of this was in flux when I was around before. Here's a little background first. Our devices are mass storage devices, however they use the EZ-USB chips that are minus firmware when they are first turned on. The device itself actually has a usb connection on one end and a parallel port on the other. When the device is first plugged in to the USB connector, a scanning firmware is uploaded to the device. When the device is plugged into a BACKPACK drive, it renumerates and then uses a new PID to ask for a firmware that is appropriate for the newly connected device (there are 4 firmwares in all). Once this firmware is loaded, the device re-numerates again, and comes up as a standard mass-storage device, to be handled by usb-storage. Ok, now the questions: 1. Should this be made part of the usb-storage module, or should it be a separate module? It would require the usb-storage module in the end, but it does need to operate on the device when it isn't a mass-storage device(yet). 2. Is there a centralized loader for ez-usb, that I could use? I saw something like this in the serial directory. A secondary problem is a bit complicated. First, you have to understand our device is bus powered, but the drive is self powered. The problem occurs when the device is plugged into a BACKPACK drive before plugging it into a usb hub. The power coming from the parallel port causes the line on the usb connector that indicates the device is ready, to float a bit high. The end result is that the usb hub thinks the device is ready before it is. This is an error that we are accounting for in newer drives, but it already exists in the current usb adapters. It works in windows (eek.. using windows as the standard, they must have a longer delay on initalizing a usb device) and is argubly within or not within the standard. I have been able to solve the problem by incrementing HUB_PROBE_TRIES to 3 in hub.c. This gives the drive extra time to come ready without punishing other devices. Can I get this change made? I greatly appreciate any help and advice. I'd finally like to get this device into the kernel. Thanks, -Ken Hahn Engineer, MicroSolutions P.S. Are there any good bits of documentation on the Makefiles and Config files in the kernel? Where? |
- Re: [linux-usb-devel] BACKPACK USB Adapter Ken Hahn
- Re: [linux-usb-devel] BACKPACK USB Adapter Brad Hards
- Re: [linux-usb-devel] BACKPACK USB Adapter Ken Hahn
- Re: [linux-usb-devel] BACKPACK USB Adapter Brad Hards
- Re: [linux-usb-devel] BACKPACK USB Adapter Ken Hahn
- Re: [linux-usb-devel] BACKPACK USB Ada... Wolfgang M�es
- Re: [linux-usb-devel] BACKPACK USB... Brad Hards
- Re: [linux-usb-devel] BACKPACK... Wolfgang M�es
