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

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

 



On Tue, Jan 06, 2015 at 09:58:40AM +0100, Bjørn Mork wrote:
> Johan Hovold <johan@xxxxxxxxxx> writes:
> 
> > 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)?
> 
> No, I don't see any problem.  It seems like the reasonable thing to do.
> I would have added these devices to the option driver in the first place
> had I known about the setup requirements.  Sorry for not catching that
> earlier.  And thanks to Reinhard for tracking this down.
> 
> There are plenty of different interface layouts for these devices, but
> Sierra Wireless use consistent interface numbering for different
> functions, so the blacklist_info should work fine regardless.
> 
> Note however that these devices also have multiple PID identities (and
> possibly also different VIDs?). The other identities may or may not have
> similar issues with the qcserial driver. I don't know. But some of these
> identities are shared with other devices, which complicates matters a
> bit.

Yeah, this feels a bit like whack-a-mole.

Did anyone have a look at these "vendor" drivers and how they do it? (And
why aren't the vendors upstreaming...). 

> >> @@ -503,3 +505,3 @@
> >>  
> >> -#define MAX_BL_NUM  8
> >> +#define MAX_BL_NUM  11
> >>  struct option_blacklist_info {
> 
> Completely unrelated question following... This hunk made me look at the
> implementation.  For the first time :-)
> 
> I wonder why the blacklist bit test is open coded this way.  Wouldn't it
> make more sense to drop the "loop over MAX_BL_NUM interfaces" and just
> use test_bit() instead?

Absolutely, the current implementation is completely retarded. That's
why I fixed it last Sunday when I looked at it. ;)

	http://marc.info/?l=linux-usb&m=142039356820488&w=2

I figured I'd apply Reinhard's patch with a stable tag first, though.

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