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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.