Johan Hovold <> writes:

> IIRC we have already started reusing entries, but the names have not
> always been made generic in the process. I think Bjørn may have proposed
> a generic naming scheme at some point, but that essentially just meant
> we encoded the two masks in the name.

Maybe. I dont' remember.

> Then we may just move over to
> encoding the masks directly in driver_data instead, at least if 16 bits
> is enough.


>> IIRC I considered just dumping the BIT(x) into the .driver_info but
>> then we'd only have 16 bits for each of send_setup and reserved on 32-
>> bit arches and I wasn't sure that was enough.  I've seen some devices
>> with lots of interfaces.  But doing it this way might have been clearer
>> than a sidecar struct like option_blacklist_info.
> Yeah, we should probably consider moving over to something like that.
> 16 bits would at least be enough for the devices we currently have
> blacklists for.

Yes, I think the current driver documents pretty well that we don't need
backlists for high interface numbers.

Checking the devices I have ever used, the only ones I found with
interface numbers higher than 16 were the Sierra Wireless modems of the
MDM9200/MDM9600 generation.  THe used 19 and 20 for two of their
QMI/RMNET functions.  But they are handled by the qcserial driver, so
that's not an issue wrt option.

I say go for the simple bitmasks!

You might also consider a general blacklist for stuff like ADB which
always need blacklisting.  By now, Google owns ff/42/xx whether you like
it or not.

To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to
More majordomo info at

Reply via email to