[PATCH] HAL support for HSO modems

[Filip Aben]

> -----Original Message-----
> From: Dan Williams [mailto:dcbw at redhat.com]
> Sent: woensdag 25 februari 2009 17:08
> To: Filip Aben
> Cc: Peter Henn; Colin Watson; hal at lists.freedesktop.org
> Subject: RE: [PATCH] HAL support for HSO modems
> 
> 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.

Correct, that would be the 'modem' port.

> 
> 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.

The control port doesn't exist on those earlier devices. The purpose of
the control port
is to control the IP interface. Since there's no IP interface on those
cards, there isn't
a control port either.
For those devices, the type of port is determined by the USB interface
number.

0 = Modem port
1 = Diagnostic port
2 = Application port
3 = smart-card port (optional)

This goes for any pre-hso usb-based Option device.

Regards,

Filip-