Am 10.08.2010 21:30, schrieb Greg KH:
On Tue, Aug 10, 2010 at 12:37:23AM +0200, Josua Dietze wrote:
I maintain a Linux tool to put USB devices from one mode (or state)
to the other.
What program, usb-modeswitch?
That's the one, yes.
Usually there is more than one interface exposed after the mode
switch, but only one is suitable for a wireless connection; binding
the GSM driver ("option") or the generic serial driver will add
multiple ports though (ttyUSB).
Let the modem-manager program handle knowing which tty device to use,
that type of logic can usually only be detected after talking to the
device.
Unfortunately, I keep receiving reports that modem-manager picks the
wrong port after probing, and there is no way of setting the port
manually in NetworkManager. This happens mostly with devices where the
interrupt port has a number > 0. I have yet to meet a GSM modem device
where the "interrupt rule" does *not* apply.
I usually recommend using wvdial (autoprobing problems too) and edit
the port directly in the config file. And just entering "gsmmodem"
spares users the testing of all ports, some of which may seem to work
at first but then build up a very unreliable connection.
And what happens with your tool when in the near future, we want to talk
to those other device nodes because modem-manager knows what thoes ports
do and how to get the data out of them?
The usb_modeswitch helper in the post-switch rule only picks ttyUSB
ports and looks only for their transfer type. It doesn't do anything
to the ports if they are bulk.
Note that this is unrelated to the preceding switching process and
doesn't change anything at all except that one symlink.
And yes, it can be scrapped anytime without further consequences when
there are other solutions. It is a temporary workaround to make user's
life a little easier.
In short, you shouldn't have to do any of this.
I couldn't agree more! :-)
Regards,
Josua Dietze
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
