[PATCH] New Modem Manager Plugin for GCT Semiconductor's GDM724X usb devices

[Dan Williams]

On Wed, 2013-08-14 at 20:01 +0900, Won Kang wrote:
> Dear Dan,
> 
> Thank you so much for the review.
> 
> > I'll assume each ethernet device (eg lteXpdnX) can support one EPS
> > bearer at a time, correct?  If that's the case, then is there any way to
> > tell the modem at attach time which port to use?  Or does the modem use
> > one port for IPv4 and one for IPv6 and not tell which port it's going to
> > use except through %GCTNETCFG?
> 
> Yes, each network interface is to be used for a single bearer. It can
> be IPv4, IPv6 or both at the same time (e.g. Verizon). Unfortunately,
> the network interface gets chosen by the modem firmware and MM needs
> to know which one is to be used. This is because of the IMS pdn, which
> optionally gets connected automatically. The order of PDN connections
> determines which NIC is assigned accordingly. Therefore there is no
> other way for MM to know which NIC to use.

Not quite... :)

> >
> > What the code is currently relying on is the modem firmware *and kernel*
> > to always  map the same data port to the same USB interface number,
> > which is fine.  But then what the ModemManager plugin should do is to
> > read the USB interface number from the kernel, and use *that* to
> > determine which data port is which (and cache that number on each data
> > port at probe time, instead of doing it each dial).
> 
> The modem has only 2 USB interfaces, one for NICs and the other for
> TTYs (AT port, and monitoring port). It is not the case anymore, but
> the original interfaces were designed to have as much similarities
> with CDC ethernet and acm. Each interface is therefore multiplexed.
> One USB interface is used by all 4 NICs requiring the kernel driver to
> have an index for network packets. The same goes for the AT port and
> DM port.

Ok, then if the device multiplexes things, then you cannot rely on the
USB interface number.  My suggestion would be to update the kernel
driver to include a sysfs attribute for each net port and TTY for a
"port number" or something like that (see the 'hso' driver for a similar
idea), which is always in agreement with the firmware's idea of the port
number as defined by GCTNETCFG.  Relying on device name is never the
right thing to do, as that can change at any time independent of the
driver.

The GCT MM plugin would then read the "port number" attribute at
probe/detection time and cache that for later, then use it to determine
the correct data port for each bearer when connecting.  See
hso_custom_init() in plugins/mm-plugin-hso.c for an example of that.

Dan