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