From: Josua Dietze <digidietze@draisberghof.de>
To: linux-hotplug@vger.kernel.org
Subject: Re: Environment woes
Date: Tue, 10 Aug 2010 20:02:10 +0000 [thread overview]
Message-ID: <4C61B042.1040903@draisberghof.de> (raw)
In-Reply-To: <4C608323.5010502@draisberghof.de>
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
next prev parent reply other threads:[~2010-08-10 20:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-09 22:37 Environment woes Josua Dietze
2010-08-10 4:37 ` Kay Sievers
2010-08-10 6:28 ` Josua Dietze
2010-08-10 19:30 ` Greg KH
2010-08-10 20:02 ` Josua Dietze [this message]
2010-08-10 20:14 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C61B042.1040903@draisberghof.de \
--to=digidietze@draisberghof.de \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).