I don't know what you mean by "wait for the device to fully come up",
but wouldn't you have to wait for that in any case? After all, how can
your patch eject it or do anything else if isn't fully up?
You don't have to wait for it to be mounted; the "eject" program is
perfectly happy to eject an unmounted CD. It will even eject an audio
CD.
And don't you have to wait for hotplug to see the new device even with
your patch installed?
Thanks Alan. Actually the driver ejects the card before hotplug even sees it, so it is
much faster than waiting 10-15 seconds for hotplug to finish searching for the
product/vendor ID in it's list, and then run a script to eject the device (remember it's a
slow system). The driver patch ejects it immediately which then allows the modem to be
presented to the OS, and to hotplug as well. We do need to wait for hotplug to see the
modem device, so we needed to get the non-wanted device out of the way as fast as
possible, which is what the driver hack helps achieve.
In our embedded platform when and/or if a CDMA type modem stops responding, or possibly
for some reason no longer sees a tower, it is faster to logically eject/insert the card
rather than reboot a unit when the modem is having problems. A card could be reset
several times a day ( or if there is a network outage, many more). So when a customer
wants as little downtime as possible, those 15 second waits can add up a lot.
I see your point that there are lots of other options other than a change to a USB driver.
So possibly this is not a good feature for the USB driver to have when it can be done in
user space.
-Brian Tuchten
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
