Johan Hovold <johan@xxxxxxxxxx> 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. Agreed. >> 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. 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
