> > The device I have, doesn't ReEnumerate upon new firmware, it just starts
> > working.
>
>A EZUSB device that doesn't ReEnumerate? That's their claim to fame! :)
>(and their patent, but that's a different issue.)
Yes, EzUSB for sure. I have a 'compatible' OEM device, which was sold with
different firmware, and tata, the other firmware does ReEnumerate. This
process takes 2..5 sek; possibly this is why they are'nt doing it on the
original firmware. Does the ReEnumeration always take this long ?
>I don't think that this program will work for you as proposed. It
>relies on the fact that an "empty" device will hang around for forever
>before firmware gets downloaded.
Having an "empty" device hanging around shouldn't be a problem, unless some
driver starts talking to it ?
The idea was more to have some kind of a kernel-based firmware library
sitting in the background.
Steps:
* insmod ezusb-firmware
* cat frimware > /dev/whoever --> sends it to the kernel-module
* plug in usb-device.
* modprobe usb-driver
* driver requsts firmware from 'ezusb-firmware'
But now thinking of all the special-case consequences, I've trashed the
idea. But another 60k firmware as kernel bloat won't make me happy either.
>Otherwise you have to kick start the userspace program at _just_ the
>right time to get it to work properly which can be difficult.
Hm;
* usb-driver asks ezusb-fw-lib for fw
* no fw -> ezusb-fw-lib remembers the driver/device
* userland comes along with fw
* ezusb-fw-lib notify's either the driver, or does some kind of re-probe() ??
Ofcoure then:
a) we'll have devices hanging around without fw.
b) non-ReEnumeration devices would have to reject the first probe() call,
when there is no fw available.
But this whole issue is not really new to USB, so what are all the others
doing ?
- sda
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
