[PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Kristian Evensen]

From: Kristian Evensen <kristian.evensen@gmail.com>

Sierra Wireless MC73xx interface 10 is not usable with QMI, as the interface
does not respond to any QMI messages. We are now left with interface 8 for the
MC73xx, which is consistent with most other Sierra Wireless QMI-devices.

Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
---
 drivers/net/usb/qmi_wwan.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 602dc66..197c012 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -753,7 +753,6 @@ static const struct usb_device_id products[] = {
 	{QMI_FIXED_INTF(0x1199, 0x68a2, 8)},	/* Sierra Wireless MC7710 in QMI mode */
 	{QMI_FIXED_INTF(0x1199, 0x68a2, 19)},	/* Sierra Wireless MC7710 in QMI mode */
 	{QMI_FIXED_INTF(0x1199, 0x68c0, 8)},	/* Sierra Wireless MC73xx */
-	{QMI_FIXED_INTF(0x1199, 0x68c0, 10)},	/* Sierra Wireless MC73xx */
 	{QMI_FIXED_INTF(0x1199, 0x901c, 8)},    /* Sierra Wireless EM7700 */
 	{QMI_FIXED_INTF(0x1199, 0x901f, 8)},    /* Sierra Wireless EM7355 */
 	{QMI_FIXED_INTF(0x1199, 0x9041, 8)},	/* Sierra Wireless MC7305/MC7355 */
-- 
1.9.1

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Bjørn Mork]

Kristian Evensen <kristian.evensen@gmail.com> writes:

> From: Kristian Evensen <kristian.evensen@gmail.com>
>
> Sierra Wireless MC73xx interface 10 is not usable with QMI, as the interface
> does not respond to any QMI messages.

Really?  I don't have any such devices to test with unfortunately, but
the Sierra Wireless (SWI) "USB Driver Developer's Guide - AirPrime
MC73xx" [1] claims that interfaces 8, 10 and 11 represent RMNET1, RMNET2
and RMNET3 respectively.  It is confirmed [2] from SWI that RMNET3 is
non-functional, similar to the status of the MC77xx devices, but RMNET2
is believed to work. At least I believe so until you sent this patch...

Just to be sure: You do have a configuration where interfaces #10 and
#11 are visible, but none of them respond to any QMI at all?  Not even
CTL SYNC?  Could you get a minimal usbmon trace of that?

Note that interface #10 (RMNET2) still is enabled for 1199:68c0 in the
current (Version S2.20N2.27) out-of-tree drivers from SWI [3],
indicating that they believe it works:


#define BIT_9X15    (31)
..
static int GobiNetDriverBind(
   struct usbnet *         pDev,
   struct usb_interface *  pIntf )
{
..
   /* We only accept certain interfaces */
   if (pIntf->cur_altsetting->desc.bInterfaceClass != USB_CLASS_VENDOR_SPEC )
   {
      DBG( "Ignoring non vendor class interface #%d\n",
           pIntf->cur_altsetting->desc.bInterfaceNumber );
      return -ENODEV;
   }
   else if (pDev->driver_info->data &&
          !test_bit(pIntf->cur_altsetting->desc.bInterfaceNumber, &pDev->driver_info->data)) {
      DBG( "invalid interface %d\n",
           pIntf->cur_altsetting->desc.bInterfaceNumber );
      return -ENODEV;
   }
..
static const struct driver_info GobiNetInfo_9x15 = {
   .description   = "GobiNet Ethernet Device",
   .flags         = FLAG_ETHER,
   .bind          = GobiNetDriverBind,
   .unbind        = GobiNetDriverUnbind,
#ifdef DATA_MODE_RP
   .rx_fixup      = GobiNetDriverRxFixup,
   .tx_fixup      = GobiNetDriverTxFixup,
#elif defined(QOS_MODE)
   .tx_fixup      = GobiNetDriverTxQoS,
   //WORD AROUND integrated from qmi_wwan.c::qmi_wwan_rx_fixup
   .rx_fixup      = GobiNetDriverLteRxFixup,
#else
   .rx_fixup      = GobiNetDriverLteRxFixup,
#endif
   .data          = BIT(8) | BIT(10) | BIT(BIT_9X15),
};

#define QMI_G3K_DEVICE(vend, prod) \
   USB_DEVICE(vend, prod), \
   .driver_info = (unsigned long)&GobiNetInfo_gobi

#define QMI_9X15_DEVICE(vend, prod) \
   USB_DEVICE(vend, prod), \
   .driver_info = (unsigned long)&GobiNetInfo_9x15

/*=========================================================================*/
// Qualcomm Gobi 3000 VID/PIDs
/*=========================================================================*/
static const struct usb_device_id GobiVIDPIDTable [] =
{
   // Sierra Wireless MC7750 QMI Device VID/PID
   {
      USB_DEVICE( 0x1199, 0x68a2 ),
      .driver_info = (unsigned long)&GobiNetInfo_qmi,
   },

   // Gobi 3000
   {QMI_G3K_DEVICE(0x05c6, 0x920d)},
   {QMI_G3K_DEVICE(0x1199, 0x9011)},
   {QMI_G3K_DEVICE(0x1199, 0x9013)},
   {QMI_G3K_DEVICE(0x1199, 0x9015)},
   {QMI_G3K_DEVICE(0x1199, 0x9019)},
   {QMI_G3K_DEVICE(0x03f0, 0x371d)},
   // 9x15
   {QMI_9X15_DEVICE(0x1199, 0x68C0)},
   {QMI_9X15_DEVICE(0x1199, 0x9041)},
   {QMI_9X15_DEVICE(0x1199, 0x9051)},
   {QMI_9X15_DEVICE(0x1199, 0x9053)},
   {QMI_9X15_DEVICE(0x1199, 0x9054)},
   {QMI_9X15_DEVICE(0x1199, 0x9055)},
   {QMI_9X15_DEVICE(0x1199, 0x9056)},
   {QMI_9X15_DEVICE(0x1199, 0x9061)},

   //Terminating entry
   { }
};

MODULE_DEVICE_TABLE( usb, GobiVIDPIDTable );



AFAICS, this code makes the driver bind to interfaces 8 and 10 on all
QMI_9X15_DEVICEs.  The BIT_9X15 is higher than any interface number in
use on these devices, and is used to trigger a slightly different QMI
startup sequence for 9x15 devices (this driver does some QMI internally,
contrary to the in-kernel driver which leaves all that to userspace).

> We are now left with interface 8 for the
> MC73xx, which is consistent with most other Sierra Wireless QMI-devices.

Well, I do have an MC7710 and it most certainly support both RMNET1 and
RMNET2 (on interface #19).  So if the MC73xx is to be consistent with
other SWI QMI devices, then I would expect it to support RMNET2 as well,
only using interface #10 instead of #19.  And that's how I understood
the reply from SWI in [2].


Access to these documents might require registration, but I include the
references here for completeness since these are my primary sources of
information:

[1] http://source.sierrawireless.com/resources/airprime/minicard/airprime_mc73xx_usb_driver_developers_guide/
[2] https://forum.sierrawireless.com/viewtopic.php?f=117&t=6110&p=32629#p32629
[3] http://source.sierrawireless.com/resources/airprime/software/usb-drivers-linux-qmi-software/



Bjørn

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Kristian Evensen]

Hi,

On Mon, Feb 9, 2015 at 12:51 PM, Bjørn Mork <bjorn@mork.no> wrote:
> Just to be sure: You do have a configuration where interfaces #10 and
> #11 are visible, but none of them respond to any QMI at all?  Not even
> CTL SYNC?  Could you get a minimal usbmon trace of that?

Yes, that is correct. I will get hold of the device with the card in
it and run another test to provide the trace. The model is MC7304 btw.

Thanks for all the additional info.

-Kristian

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Kristian Evensen]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

Hi,

On Mon, Feb 9, 2015 at 12:55 PM, Kristian Evensen
<kristian.evensen@gmail.com> wrote:
> Hi,
>
> On Mon, Feb 9, 2015 at 12:51 PM, Bjørn Mork <bjorn@mork.no> wrote:
>> Just to be sure: You do have a configuration where interfaces #10 and
>> #11 are visible, but none of them respond to any QMI at all?  Not even
>> CTL SYNC?  Could you get a minimal usbmon trace of that?

Here is a minial usbmon where I send SYNC to interface 10. After I
made the trace, I tried interface 8 (to make sure that there was
nothing wrong with modem) and it worked fine. ModemManager or any
similar tool is not running.

The firmware is SWI9X15C_05.05.02.00 r19147 carmd-fwbuild1 2013/11/15 13:54:28

-Kristian

[-- Attachment #2: mc73xx-intf-10-no-reply.log --]
[-- Type: text/x-log, Size: 747 bytes --]

ffff8800cbbad240 1429569304 S Ii:3:050:7 -115:256 10 <
ffff8800cbbadb40 1429569566 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
ffff8800cbbadb40 1429570337 C Co:3:050:0 0 12 >
ffff8800cbbad240 1434576966 C Ii:3:050:7 -2:256 0
ffff8800cbbad240 1434577061 S Ii:3:050:7 -115:256 10 <
ffff8800cbbadb40 1434577154 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
ffff8800cbbadb40 1434577968 C Co:3:050:0 0 12 >
ffff8800cbbad240 1439584564 C Ii:3:050:7 -2:256 0
ffff8800cbbad240 1439584687 S Ii:3:050:7 -115:256 10 <
ffff8800cbbadb40 1439584829 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
ffff8800cbbadb40 1439585699 C Co:3:050:0 0 12 >
ffff8800cbbad240 1440477055 C Ii:3:050:7 -2:256 0

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Bjørn Mork]

Kristian Evensen <kristian.evensen@gmail.com> writes:
> On Mon, Feb 9, 2015 at 12:55 PM, Kristian Evensen
> <kristian.evensen@gmail.com> wrote:
>> Hi,
>>
>> On Mon, Feb 9, 2015 at 12:51 PM, Bjørn Mork <bjorn@mork.no> wrote:
>>> Just to be sure: You do have a configuration where interfaces #10 and
>>> #11 are visible, but none of them respond to any QMI at all?  Not even
>>> CTL SYNC?  Could you get a minimal usbmon trace of that?
>
> Here is a minial usbmon where I send SYNC to interface 10. After I
> made the trace, I tried interface 8 (to make sure that there was
> nothing wrong with modem) and it worked fine. ModemManager or any
> similar tool is not running.

Thanks.

> The firmware is SWI9X15C_05.05.02.00 r19147 carmd-fwbuild1 2013/11/15 13:54:28

That is pretty old relative to this hardware. First commercial release?
I don't really want to push you to do an upgrade, but it would sure be
nice to have this test repeated on a recent firmware version.  Not that
I can spot anything particularily promising in the release notes.

Did you have one of these 9x15 modems, Aleksander?  Did you ever verify
whether the additional QMI interface(s) worked?

I did find our previous discussions about these two RMNET1 and RMNET2
functions, e.g:
http://lists.freedesktop.org/archives/libqmi-devel/2014-July/000875.html
and it seems to indicate that both work as long as you configure them
for 802.3 framing. But that could just be an information feedback
loop... 


> -Kristian
> ffff8800cbbad240 1429569304 S Ii:3:050:7 -115:256 10 <
> ffff8800cbbadb40 1429569566 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
> ffff8800cbbadb40 1429570337 C Co:3:050:0 0 12 >
> ffff8800cbbad240 1434576966 C Ii:3:050:7 -2:256 0
> ffff8800cbbad240 1434577061 S Ii:3:050:7 -115:256 10 <
> ffff8800cbbadb40 1434577154 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
> ffff8800cbbadb40 1434577968 C Co:3:050:0 0 12 >
> ffff8800cbbad240 1439584564 C Ii:3:050:7 -2:256 0
> ffff8800cbbad240 1439584687 S Ii:3:050:7 -115:256 10 <
> ffff8800cbbadb40 1439584829 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
> ffff8800cbbadb40 1439585699 C Co:3:050:0 0 12 >
> ffff8800cbbad240 1440477055 C Ii:3:050:7 -2:256 0




Hmm, it's been a long time since I've looked at one of these so I might
be wrong, but I must admit that it looks pretty dead.  I assume the
ENOENT Ii callback status indicates a timeout?



Bjørn

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Kristian Evensen]

On Mon, Feb 9, 2015 at 2:33 PM, Bjørn Mork <bjorn@mork.no> wrote:
> That is pretty old relative to this hardware. First commercial release?
> I don't really want to push you to do an upgrade, but it would sure be
> nice to have this test repeated on a recent firmware version.  Not that
> I can spot anything particularily promising in the release notes.

I updated firmware now, but still see the same behavior.

> I did find our previous discussions about these two RMNET1 and RMNET2
> functions, e.g:
> http://lists.freedesktop.org/archives/libqmi-devel/2014-July/000875.html
> and it seems to indicate that both work as long as you configure them
> for 802.3 framing. But that could just be an information feedback
> loop...

That is correct. In order for this device to accept network traffic
(or driver to accept packets from device), I have to set the transfer
mode to 802.3.

-Kristian

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[David Miller]

From: Kristian Evensen <kristian.evensen@gmail.com>
Date: Mon, 9 Feb 2015 15:30:02 +0100

> On Mon, Feb 9, 2015 at 2:33 PM, Bjørn Mork <bjorn@mork.no> wrote:
>> That is pretty old relative to this hardware. First commercial release?
>> I don't really want to push you to do an upgrade, but it would sure be
>> nice to have this test repeated on a recent firmware version.  Not that
>> I can spot anything particularily promising in the release notes.
> 
> I updated firmware now, but still see the same behavior.
> 
>> I did find our previous discussions about these two RMNET1 and RMNET2
>> functions, e.g:
>> http://lists.freedesktop.org/archives/libqmi-devel/2014-July/000875.html
>> and it seems to indicate that both work as long as you configure them
>> for 802.3 framing. But that could just be an information feedback
>> loop...
> 
> That is correct. In order for this device to accept network traffic
> (or driver to accept packets from device), I have to set the transfer
> mode to 802.3.

So what are we going to do with this patch?

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Kristian Evensen]

On Mon, Feb 9, 2015 at 11:19 PM, David Miller <davem@redhat.com> wrote:
> So what are we going to do with this patch?

I spent some more time yesterday reading through the references
provided by Bjørn, as well as doing some more searching. The devices
exported by interface 8 and 10 offers the same functionality, and
interface 8 seems to work for all MC73xx-devices (there is no
reference of anyone not getting a connection through it). Interface
10, on the other hand, only seems to work on some MC73xx-devices. I
see no point in carrying around a reference in the driver to an
interface that might work in some cases, when there is one that always
works. However, there might be a modem or a particular firmware
revision I am not aware of. Bjørn/Aleksander knows more about
available QMI-devices than me, so I think they should decide.

-Kristian

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Bjørn Mork]

David Miller <davem@redhat.com> writes:
> From: Kristian Evensen <kristian.evensen@gmail.com>
> Date: Mon, 9 Feb 2015 15:30:02 +0100
>
>> On Mon, Feb 9, 2015 at 2:33 PM, Bjørn Mork <bjorn@mork.no> wrote:
>>> That is pretty old relative to this hardware. First commercial release?
>>> I don't really want to push you to do an upgrade, but it would sure be
>>> nice to have this test repeated on a recent firmware version.  Not that
>>> I can spot anything particularily promising in the release notes.
>> 
>> I updated firmware now, but still see the same behavior.
>> 
>>> I did find our previous discussions about these two RMNET1 and RMNET2
>>> functions, e.g:
>>> http://lists.freedesktop.org/archives/libqmi-devel/2014-July/000875.html
>>> and it seems to indicate that both work as long as you configure them
>>> for 802.3 framing. But that could just be an information feedback
>>> loop...
>> 
>> That is correct. In order for this device to accept network traffic
>> (or driver to accept packets from device), I have to set the transfer
>> mode to 802.3.
>
> So what are we going to do with this patch?

I am hoping to get a second opinion from Aleksander.



Bjørn

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Aleksander Morgado]

On Tue, Feb 10, 2015 at 8:49 AM, Bjørn Mork <bjorn@mork.no> wrote:
>>> On Mon, Feb 9, 2015 at 2:33 PM, Bjørn Mork <bjorn@mork.no> wrote:
>>>> That is pretty old relative to this hardware. First commercial release?
>>>> I don't really want to push you to do an upgrade, but it would sure be
>>>> nice to have this test repeated on a recent firmware version.  Not that
>>>> I can spot anything particularily promising in the release notes.
>>>
>>> I updated firmware now, but still see the same behavior.
>>>
>>>> I did find our previous discussions about these two RMNET1 and RMNET2
>>>> functions, e.g:
>>>> http://lists.freedesktop.org/archives/libqmi-devel/2014-July/000875.html
>>>> and it seems to indicate that both work as long as you configure them
>>>> for 802.3 framing. But that could just be an information feedback
>>>> loop...
>>>
>>> That is correct. In order for this device to accept network traffic
>>> (or driver to accept packets from device), I have to set the transfer
>>> mode to 802.3.
>>
>> So what are we going to do with this patch?
>
> I am hoping to get a second opinion from Aleksander.

I have a MC7304 and a MC7354 and both work with interfaces #8 and #10,
the only difference being that #10 ends up being raw-ip by default
instead of 802.3. I previously had old firmware in both, from early
last year IIRC, but last week I upgraded both to the latest firmware
available.

The only case in which I've seen such a modem (a MC7304) with 1 single
valid QMI interface (actually being #8) is when the modem is put in
"single-qmi" interface mode, which you can do forcing it to get the
MC7710 PID, e.g. AT!UDPID=68A2. But otherwise, if the modem was
exposed as 0x68c0, if#10 always worked for me...

-- 
Aleksander
https://aleksander.es

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Aleksander Morgado]

On Tue, Feb 10, 2015 at 9:43 AM, Aleksander Morgado
<aleksander@aleksander.es> wrote:
> On Tue, Feb 10, 2015 at 8:49 AM, Bjørn Mork <bjorn@mork.no> wrote:
>>>> On Mon, Feb 9, 2015 at 2:33 PM, Bjørn Mork <bjorn@mork.no> wrote:
>>>>> That is pretty old relative to this hardware. First commercial release?
>>>>> I don't really want to push you to do an upgrade, but it would sure be
>>>>> nice to have this test repeated on a recent firmware version.  Not that
>>>>> I can spot anything particularily promising in the release notes.
>>>>
>>>> I updated firmware now, but still see the same behavior.
>>>>
>>>>> I did find our previous discussions about these two RMNET1 and RMNET2
>>>>> functions, e.g:
>>>>> http://lists.freedesktop.org/archives/libqmi-devel/2014-July/000875.html
>>>>> and it seems to indicate that both work as long as you configure them
>>>>> for 802.3 framing. But that could just be an information feedback
>>>>> loop...
>>>>
>>>> That is correct. In order for this device to accept network traffic
>>>> (or driver to accept packets from device), I have to set the transfer
>>>> mode to 802.3.
>>>
>>> So what are we going to do with this patch?
>>
>> I am hoping to get a second opinion from Aleksander.
>
> I have a MC7304 and a MC7354 and both work with interfaces #8 and #10,
> the only difference being that #10 ends up being raw-ip by default
> instead of 802.3. I previously had old firmware in both, from early
> last year IIRC, but last week I upgraded both to the latest firmware
> available.
>
> The only case in which I've seen such a modem (a MC7304) with 1 single
> valid QMI interface (actually being #8) is when the modem is put in
> "single-qmi" interface mode, which you can do forcing it to get the
> MC7710 PID, e.g. AT!UDPID=68A2. But otherwise, if the modem was
> exposed as 0x68c0, if#10 always worked for me...


BTW, regarding the patch... if interface #10 ends up being usable only
in some 73xx models, I would still leave it available anyway in the
kernel driver. Userspace can always figure out whether the interface
is usable or not (e.g. MM does some QMI probing on the interface
before flagging it as usable).

A similar issue we had with if#11 IIRC, which the sierra driver marked
it as being QMI but we never made it work once, so we ended up
removing it from qmi_wwan (see commit fc0d6e9cd0a). Now I wonder if we
should have done that only by testing it once with my hw.

-- 
Aleksander
https://aleksander.es

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Bjørn Mork]

Aleksander Morgado <aleksander@aleksander.es> writes:
> On Tue, Feb 10, 2015 at 9:43 AM, Aleksander Morgado
> <aleksander@aleksander.es> wrote:
>> On Tue, Feb 10, 2015 at 8:49 AM, Bjørn Mork <bjorn@mork.no> wrote:
>>
>>> I am hoping to get a second opinion from Aleksander.
>>
>> I have a MC7304 and a MC7354 and both work with interfaces #8 and #10,
>> the only difference being that #10 ends up being raw-ip by default
>> instead of 802.3. I previously had old firmware in both, from early
>> last year IIRC, but last week I upgraded both to the latest firmware
>> available.
>>
>> The only case in which I've seen such a modem (a MC7304) with 1 single
>> valid QMI interface (actually being #8) is when the modem is put in
>> "single-qmi" interface mode, which you can do forcing it to get the
>> MC7710 PID, e.g. AT!UDPID=68A2. But otherwise, if the modem was
>> exposed as 0x68c0, if#10 always worked for me...
>
>
> BTW, regarding the patch... if interface #10 ends up being usable only
> in some 73xx models, I would still leave it available anyway in the
> kernel driver. Userspace can always figure out whether the interface
> is usable or not (e.g. MM does some QMI probing on the interface
> before flagging it as usable).

Yes, agreed.  Thanks for the testing.  Sorry Kristian, but if interface #10
is usable on some modems with this device ID, then the driver should
support those modems.

So this is a NAK on the patch.

> A similar issue we had with if#11 IIRC, which the sierra driver marked
> it as being QMI but we never made it work once, so we ended up
> removing it from qmi_wwan (see commit fc0d6e9cd0a). Now I wonder if we
> should have done that only by testing it once with my hw.

Yes, it would be nice if you could revisit that just to be 103% sure.

I believe the driver will bind to any unbound QMI interfaces if you add
the device ID using the "new_id" sysfs file, so it should be testable
without rebuilding the kernel. At least on newer kernels, where the
dynamic USB ids override the built-in ones.

But contrary to the interface #10 situation, we have no indications that
#11 has ever worked for anyone.


Bjørn

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Kristian Evensen]

On Tue, Feb 10, 2015 at 10:10 AM, Bjørn Mork <bjorn@mork.no> wrote:
> Yes, agreed.  Thanks for the testing.  Sorry Kristian, but if interface #10
> is usable on some modems with this device ID, then the driver should
> support those modems.
>
> So this is a NAK on the patch.

Ok, thanks for testing.

-Kristian

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Kristian Evensen]

On Tue, Feb 10, 2015 at 9:51 AM, Aleksander Morgado
<aleksander@aleksander.es> wrote:
>> The only case in which I've seen such a modem (a MC7304) with 1 single
>> valid QMI interface (actually being #8) is when the modem is put in
>> "single-qmi" interface mode, which you can do forcing it to get the
>> MC7710 PID, e.g. AT!UDPID=68A2. But otherwise, if the modem was
>> exposed as 0x68c0, if#10 always worked for me...

My modem has the expected PID (0x68c0).

> BTW, regarding the patch... if interface #10 ends up being usable only
> in some 73xx models, I would still leave it available anyway in the
> kernel driver. Userspace can always figure out whether the interface
> is usable or not (e.g. MM does some QMI probing on the interface
> before flagging it as usable).

I will not fight strongly for this patch. My motivation was mostly to
clean up, since it looks a bit messy keeping an additional interface +
cdc-wdm device around which will never be used (and can be avoided).

> A similar issue we had with if#11 IIRC, which the sierra driver marked
> it as being QMI but we never made it work once, so we ended up
> removing it from qmi_wwan (see commit fc0d6e9cd0a). Now I wonder if we
> should have done that only by testing it once with my hw.

Interface 11 does not reply on my device as well.

-Kristian

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Aleksander Morgado]

On Tue, Feb 10, 2015 at 10:18 AM, Kristian Evensen
<kristian.evensen@gmail.com> wrote:
>> BTW, regarding the patch... if interface #10 ends up being usable only
>> in some 73xx models, I would still leave it available anyway in the
>> kernel driver. Userspace can always figure out whether the interface
>> is usable or not (e.g. MM does some QMI probing on the interface
>> before flagging it as usable).
>
> I will not fight strongly for this patch. My motivation was mostly to
> clean up, since it looks a bit messy keeping an additional interface +
> cdc-wdm device around which will never be used (and can be avoided).

With ModemManager you can use both WWAN interfaces by creating
independent Bearer objects and getting them connected independently
(e.g. to different APNs). Not sure if anyone will ever do that, but
well.

-- 
Aleksander
https://aleksander.es

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Kristian Evensen]

On Tue, Feb 10, 2015 at 11:37 AM, Aleksander Morgado
<aleksander@aleksander.es> wrote:
> With ModemManager you can use both WWAN interfaces by creating
> independent Bearer objects and getting them connected independently
> (e.g. to different APNs). Not sure if anyone will ever do that, but
> well.

Thanks for reminding me of this use case. One scenario where it makes
sense is how IPv4/IPv6 is handled by some mobile broadband operators.
I know of at least one Norwegian ISP that at least used different APNs
for IPv4 and IPv6.

-Kristian

Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

[Bjørn Mork]

Kristian Evensen <kristian.evensen@gmail.com> writes:
> On Tue, Feb 10, 2015 at 11:37 AM, Aleksander Morgado
> <aleksander@aleksander.es> wrote:
>> With ModemManager you can use both WWAN interfaces by creating
>> independent Bearer objects and getting them connected independently
>> (e.g. to different APNs). Not sure if anyone will ever do that, but
>> well.
>
> Thanks for reminding me of this use case. One scenario where it makes
> sense is how IPv4/IPv6 is handled by some mobile broadband operators.
> I know of at least one Norwegian ISP that at least used different APNs
> for IPv4 and IPv6.

Sure, very useful for testing, although I don't think that they meant it
that way.  I believe the assumption is that you get full Internet access
using either APN, with DNS64/NAT64/464XLAT for the IPv6 only one.

Other use cases I can think of:
 - dedicated MMS APN
 - dedicated voice APN
 - VPN APN(s)

all in combination with an Internet access APN.  So yes, two independent
bearers are certainly useful.  I expect many modems will support more
than one bearer in the near future.  The Intel XMM7160 based modems,
like for example the Sierra Wireless EM7345, already support 8(!)


Bjørn