Option driver enhancement

Matthias Urlichs smurf at smurf.noris.de
Thu Oct 4 00:30:12 UTC 2007


Greg KH:
> > Please contact me privately for details.
> Oh come on, don't tease us, let's know what could be done here on this
> driver :)

Well, you talked me into it ... here's my current list of interesting
things to do to ^W with the Option driver.

All of the following is of course open to discussion. If somebody has a
good reason for saying that one or more of these enhancement ideas is
bullshit, please don't hesitate to speak up.

* The thing has no flow control whatsoever. Somebody should hammer
  their device with data while online and check if it tells us to slow
  down somehow. (This is, ideally, a job for somebody with a data
  flatrate contract.)

* ... except that it probably doesn't. In that case it might do the
  flow control in-band, which could happen either using the venerable
  ^S/^Q characters, or with flow control messages via multiplex mode.

  At the moment the Option driver doesn't know what the hell a ^S
  is or why it should care, and unless evidence shows up that it needs
  to I'd like to keep things that way.

* Multiplex mode, however, is independently useful. As the name implies,
  it is a way to talk to more than one part of a GSM modem concurrently,
  so you can do stuff like check the uplink quality (or send text
  messages ;-) while online. It is entered with AT+CMUX; you may or
  may not be able to leave that mode without physically powering down
  the USB bus.

  The OpenMoko people have written a kernel driver for multiplexing,
  but that is still out-of-tree. I'd like that to get fixed.

* The number and size of the USB buffers which the Option driver uses
  are chosen very conservatively, so as not to overwhelm some of the
  older cards which it supports. Needless to say, that means that the
  driver can't keep up with UMTS data rates.
  Its list of device IDs needs to be enhanced (in a blacklist-style sort
  of way) so that the driver can pick the limits from there, instead of
  having to use some sort of global pessimum.

* ... or from a couple of module parameters, so that people can
  test whether their device supports larger limits without recompiling.

* Speaking of module parameters: Resurrecting the vendor=/product= thing
  for the Option driver is something that I'm of two minds about. Yes it
  means that you can quickly connect new devices, but on the other hand
  people for whom that works tend not to send in patches for new device
  IDs. Thus, in the long run even more users need to hack their
  /etc/modules file for devices which should work out of the box. :-(

* That list should carry some other info -- like, which of the three
  endpoints that some of these devices export (see the current driver
  for the mess *that* is) is the actual data port and which is the side
  channel (or, when multiplexing, which channel corresponds to these --
  ETSI conveniently forgot to standardize that).

* Speaking of sysfs, it'd be nice to export some more details so that
  userspace doesn't need to duplicate our long list of device IDs,
  or magically know what kind of device the Option driver controls,
  to understand that this strange new device that's just been plugged in
  is a GSM modem.

* There's at least one other driver which has been cloned from option.c
  in the kernel, as well as at least one which is still based on the
  "standard" usbserial but shouldn't be. It'd make sense to (re-)unify

* Some of these GSM modems are connected by way of a PC-Card with an
  OHCI USB adapter. Needless to say, if you pull the card at the exact
  wrong time, Bad Things might happen. The kernel's USB stack has
  gotten a lot better about not being stupid (like panicing, or leaving
  locks locked) but it's not perfect yet.

  So somebody should do a pull-the-card test and then track down any
  stupid things that happen.

  This is a job for anybody who does *not* have any other USB devices
  connected to the computer s/he uses for such tests; USB debugging
  kindof sucks when you get a couple of kernel messages per keystroke
  and/or disk access ...

All in all, enough things to do to more than overwhelm the two people
who already emailed me and expressed their interest. ;-)

The end result I'd like to see is that, when the user plugs in their GSM
modem, that fact gets propagated via udev/hal/dbus so that a GUI window
pops up and asks for the PIN, after which (a) Network Manager sees the
device and is able to connect, and/or (b) I can use Telepathy to send
and receive text messages. (Using the card as a phone should of course
also be possible, but some of those modems don't even support audio

Much of that is user space, of course, but the kernel needs to provide
the infrastructure to make it happen.

Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf at smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
To love another is not enough....It is not enough to be "supportive" and
"there for them," and all the rest....She is waiting for the signal of
deep feeling, that one tear that says, "I admit the wound." -- Clarissa
Pinkola Estes, Women Who Run With the Wolves

More information about the devel mailing list