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.
>> @@ -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?
Bjørn
--
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
