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

_______________________________________________
wimax mailing list
[email protected]
http://www.linuxwimax.org/mailman/listinfo/wimax

Reply via email to