Re: qcserial: AT unsolicited response codes missing with Sierra Wireless MC7304

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 05, 2015 at 10:12:33PM +0100, Reinhard Speyerer wrote:
> Johan Hovold <johan@xxxxxxxxxx> wrote:
> 
> > On Sat, Dec 27, 2014 at 10:54:09PM +0100, Reinhard Speyerer wrote:
> > > Reinhard Speyerer <rspmn@xxxxxxxx> wrote:
> > > > Johan Hovold <johan@xxxxxxxxxx> wrote:
> > > > > On Sun, Dec 21, 2014 at 11:25:45PM +0100, Reinhard Speyerer wrote:
> >
> > > With the qcserial.c patch below (for Linux kernel 3.16.3) I was able to
> > > verify that adding the send_setup code fixes the missing URCs for the
> > > MC7304. To avoid potential side effects for other ports of the MC7304
> > > the send_setup code is only used for the AT port (USB interface 3).
> >
> > Thanks for verifying this.
> >
> > After looking at this some more, and depending on whether you can find
> > out if the vendor driver sends these requests for all devices, I think
> > your original proposal of simply moving this device over to option might
> > be the best solution after all.
> 
> Sorry,
> I don't know whether the vendor GobiSerial driver does this.

Ok, let's move the PID to option and if it turns out that more of these
devices require the modem-control signals (e.g. with more recent
firmware) we can consider moving it back after adding such support to
qcserial.
 
Bjørn, do you see any problems with this? Are there more interface
layouts for these devices out there perhaps (making options blacklisting
a bad fit)?

> > Perhaps you can use USB_DEVICE_AND_INTERFACE_INFO so you don't have to
> > blacklist so many interfaces explicitly (e.g. the AUDIO interfaces)?
> >
> Since the DM/DIAG interface uses bInterfaceSubClass/bInterfaceProtocol
> values which differ from the values for the NMEA and AT interfaces this
> seems to require two USB_DEVICE_AND_INTERFACE_INFO entries and might no
> longer work if the vendor decides to uses different value e.g. with newer
> firmware versions.
> 
> My preference would be to use USB_DEVICE_INTERFACE_CLASS with 0xff instead:
> 
> --- drivers/usb/serial/option.c-std	2014-08-04 00:25:02.000000000 +0200
> +++ drivers/usb/serial/option.c	2015-01-05 17:27:32.581915787 +0100
> @@ -236,2 +236,4 @@
>  
> +#define SIERRA_VENDOR_ID			0x1199
> +
>  #define CMOTECH_VENDOR_ID			0x16d8
> @@ -503,3 +505,3 @@
>  
> -#define MAX_BL_NUM  8
> +#define MAX_BL_NUM  11
>  struct option_blacklist_info {
> @@ -579,2 +581,7 @@
>  
> +static const struct option_blacklist_info sierra_mc73xx_blacklist = {
> +	.sendsetup = BIT(0) | BIT(2),
> +	.reserved = BIT(8) | BIT(10) | BIT(11),
> +};
> +
>  static const struct usb_device_id option_ids[] = {
> @@ -1075,2 +1082,4 @@
>  	{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
> +	{ USB_DEVICE_INTERFACE_CLASS(SIERRA_VENDOR_ID, 0x68c0, 0xff),
> +	  .driver_info = (kernel_ulong_t)&sierra_mc73xx_blacklist }, /* MC73xx */
>  	{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },

Looks good. Care to submit this as a proper patch (including removing
the PID from qcserial) so I can apply it?

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux