[PATCH] HAL support for HSO modems

[Dan Williams]

On Tue, 2009-02-03 at 16:29 +0100, Filip Aben wrote:
> 
> > -----Original Message-----
> > From: Dan Williams [mailto:dcbw at redhat.com]
> > Sent: dinsdag 3 februari 2009 16:18
> > To: Peter Henn
> > Cc: Colin Watson; hal at lists.freedesktop.org; Filip Aben
> > Subject: Re: [PATCH] HAL support for HSO modems
> > 
> > On Mon, 2009-01-26 at 19:01 +0100, Peter Henn wrote:
> > > Hi Dan,
> > >
> > > Dan Williams schrieb:
> > > > On Mon, 2009-01-26 at 17:21 +0100, Peter Henn wrote:
> > > >> Dear Dan,
> > > >>
> > > >> please find the answers inline ...
> > > >>
> > > >> Dan Williams schrieb:
> > > >>> On Tue, 2009-01-13 at 01:22 +0100, Peter Henn wrote:
> > > >>>> Dear Dan and Colin,
> > > >>>>
> > > >>>> some "short" remarks to the HAL patches I did in the udev
> > package.
> > > >>>> I saw the the NM just catches the first two serial ports of our
> > WWAN modems. That is done obviously because of a hal patch, which marks
> > these interfaces with some kind of GSM functionality. And unfortunately
> > this patch did not make sure to mark only tty channels, which can
> > really be used for a PPP connection with Option WWAN modems.
> > > >>>> So I used the HAL patches, which are currently part of the hso-
> > udev package.
> > > >>> I'm putting together a generic proposal for modem port/channel
> > tags, got
> > > >>> a few questions below.  Hopefully we can ship these in standard
> > upstream
> > > >>> software and then you won't have to maintain hso-udev anymore :)
> > > >>>
> > > >> Hmm, hso-udev supports also the selective suspend setting of the
> > driver.
> > > >
> > > > Ok, what are the cases where that shouldn't be enabled by default?
> > > Yes it is enabled by default.
> > >
> > > > Are
> > > > there bugs somewhere that cause it to fail for some cases?
> > > Oh USB selective suspend is pretty new and only a small couple of
> > > drivers currently using that feature. So there is a general risk.
> > > Also there exists some risks with very old WWAN-modem firmware, which
> > > may show trouble with that feature itself or may freeze your host. So
> > it
> > > can be helpful to know how that USB selective suspend can be
> > disabled.
> > > This is currently handled with the osetsuspend script, which is also
> > > called from udev during the WWAN-modem hotplug or after coldstart.
> > >
> > >
> > > >
> > > >>>> But first I should explain the different interfaces, which will
> > be offered by Option WWAM modem using a hso driver:
> > > >>>>
> > > >>>> a) Network channel:
> > > >>>> The hso driver supports an IP network interface, which is
> > similar to an Ethernet interface. Unfortunately this network interface
> > should not be seen as a Wired interfaces, but also not as a WLAN
> > interface. We use that network like interface to increase the WWAN
> > performance and did that specially for the Full Speed USB devices in
> > the past to prevent data throughput bottle necks. But the network
> > configuration and IP address setup can not be done by DHCP! Therefore
> > you we use a AT command channel the:
> > > >>> Right; this will never get exposed to userspace as a TTY since
> > it's
> > > >>> handled internally by the driver, but this type is useful for
> > modems
> > > >>> that don't work this way.  We'll tag existing ports/channels that
> > *do*
> > > >>> use PPP with a "data" type.
> > > >>>
> > > >>>> b) WWAN control channel:
> > > >>>> This tty interface can _not_ be used for a PPP modem channel.
> > The Control channel is used to configure and setup the WWAN modem with
> > AT commands. Note that here then the data traffic will be routed by the
> > network interface. These has to do with the USB transmission and the
> > hardware chips, which will be used and the bandwidth of USB channels.
> > > >>>>
> > > >>>> c) Application port:
> > > >>>> The Application port is very similar to the WWAN control
> > channel. It can also _not_ be used as a PPP channel, although you can
> > use AT commands according to the GSM specification like on the control
> > channel. The Application port offers a 2nd dedicated interface, e.g.
> > for sending SMS, setting up a voice call for WWAN modems, which support
> > that.
> > > >>> Can the "Application" port also be used as the WWAN control
> > channel, or
> > > >>> does it reject the OWANCALL/OWANDATA commands?
> > > >>>
> > > >> Yes, the application port can establish the OWANCALL/OWANDATA
> > commands.
> > > >
> > > > Ok; does this mean that we can basically use the Application,
> > > > Application2, Modem, and Control ports interchangeably?
> > > Yes, that is my knowledge about that, but should naturally not be
> > done
> > > in parallel ;-)
> > > The basic idea/history was having an extra port for extra application
> > > like SMS daemon. Note that only a small number of WWAN-modems have a
> > 2nd
> > > application port.
> > 
> > It's come to my attention that only the 'control' port provides the
> > unsolicited _OWANCALL responses.  Is that correct?  Is there a way to
> > turn on the unsolicited responses on any of the other ports, given that
> > you've said the other ports can also accept OWANCALL/OWANDATA commands?
> > 
> > Thanks!
> > Dan
> 
> Hi Dan,
> 
> You're absolutely right.
> 
> Control channel = only OWANCALL unsolicited.
> App channel = all unsoliciteds except OWANCALL.
> 
> Unfortunately this is not something that can be changed.

One more question for you, regarding earlier modems driven by the
'option' driver, like 0af0:7001 (Model GE0301, "Globetrotter HSUPA
Modem")...

I'm getting reports that only ttyUSB0 will emit CONNECT after dialing.
Other ttys will accept dial commands, but only ttyUSB0 will emit
CONNECT.

Is there a firmware method to determine which port on these older modems
is the "Control" port?  Or if those cards' firmware doesn't support
that, any chance you could provide a small table which maps Option
devices by USB ID to which endpoint is the Control port?  We'll need to
add port types to the option driver much like the 'hso' driver currently
has them.

Thanks!
Dan