Hi Dan, >>> If the mass-storage device is a "driver cd" thing, then the correct >>> method for "fixing" these devices is to write a small shim driver >>> for >>> libusual that (by default) simply ejects the mass-storage device >>> whenever it's inserted, but allows override of this behavior using a >>> module parameter. See the following Sierra TruInstall patches for >>> how >>> this should happen: >> >> Oh, so that's how they do it? They wait for a eject command to >> "change" >> personas and become their real device? > > Yep. Some Option devices need to be sent the SCSI REZERO command > instead of a simple eject. Firmware dependent method really. The > Option 'hso' devices have: > > - bDeviceClass 0 (Defined at Interface level) > - bDeviceSubClass 0 > - bDeviceProtocol 0 > + bDeviceClass 255 Vendor Specific Class > + bDeviceSubClass 255 Vendor Specific Subclass > + bDeviceProtocol 255 Vendor Specific Protocol > > that's - == pre REZERO, + == post REZERO. Same thing for the Huawei > modems. So you can at least usually tell whether it's supposed to be > the modem or the mass-storage device on the first plug. > >> Out of curiosity, how would it work when the device is reconnected >> and/or the >> system boots? The device requires another eject to switch into >> being what it >> should be? > > Yep. On Windows and Mac OS X, the custom drivers that the devices > have > on their mass-storage CD thing probably handle this for you > automatically. As should we under Linux :) I was looking into that and actually I was really close to post patches for the HSO and Novatel cards that I have. There is no point in ever mounting these as storage devices since it just wastes time and roundtrips through userspace. We could already be connected in that 5-10 seconds. Anyhow, just got distracted by vacation :) Regards Marcel
