Option driver enhancement

[Felipe Balbi]

Hi Matthias,

On 10/3/07, Matthias Urlichs <smurf at smurf.noris.de> wrote:
> Hi,
>
> 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
>   these.
>
> * 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
> data...)
>
> 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
> _______________________________________________
> devel mailing list
> devel at linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
>


I could track down all the usb specific issues plus the sysfs you
wanna see. I'll be traveling on work during october but I'll still
have internet connection so during the trip I'll be studying option
driver and check what could be done on usb stack to make it work
better.



-- 
Best Regards,

Felipe Balbi
felipebalbi at users.sourceforge.net