netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn@mork.no>
To: Kristian Evensen <kristian.evensen@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI
Date: Mon, 09 Feb 2015 12:51:54 +0100	[thread overview]
Message-ID: <87a90nqp45.fsf@nemi.mork.no> (raw)
In-Reply-To: <1423477027-10869-1-git-send-email-kristian.evensen@gmail.com> (Kristian Evensen's message of "Mon, 9 Feb 2015 11:17:07 +0100")

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

  reply	other threads:[~2015-02-09 11:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-09 10:17 [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI Kristian Evensen
2015-02-09 11:51 ` Bjørn Mork [this message]
2015-02-09 11:55   ` Kristian Evensen
2015-02-09 12:26     ` Kristian Evensen
2015-02-09 13:33       ` Bjørn Mork
2015-02-09 14:30         ` Kristian Evensen
2015-02-09 22:19           ` David Miller
2015-02-10  6:04             ` Kristian Evensen
2015-02-10  7:49             ` Bjørn Mork
2015-02-10  8:43               ` Aleksander Morgado
2015-02-10  8:51                 ` Aleksander Morgado
2015-02-10  9:10                   ` Bjørn Mork
2015-02-10  9:19                     ` Kristian Evensen
2015-02-10  9:18                   ` Kristian Evensen
2015-02-10 10:37                     ` Aleksander Morgado
2015-02-10 10:53                       ` Kristian Evensen
2015-02-10 11:39                         ` Bjørn Mork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a90nqp45.fsf@nemi.mork.no \
    --to=bjorn@mork.no \
    --cc=kristian.evensen@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).