David Miller <davem@xxxxxxxxxxxxx> writes: > From: Aleksander Morgado <aleksander@xxxxxxxxxxxxx> > Date: Wed, 27 Sep 2017 23:31:03 +0200 > >> I'm not sure if binding this logic to a specific vid:pid (1410:9030) >> would be more appropriate here, or if it's ok to just bind >> class/subclass/protocol (as in the activesync case). Let me know >> what you think. > > I don't have enough USB Networking knowledge to make a decision here. > > Some things seem confusing. For example, if we should be matching > USB_CLASS_MISC, subclass=4, protocol=1 for RNDIS over Ethernet, then > we why aren't we also matching USB_CLASS_MISC, subclass=4, protocol=2 > for RNDIS over wireless and instead are matching "Remote RNDIS" in > the form of USB_CLASS_WIRELSS, subclass=1, protocol=3? > > I really don't understand any of this magic :-) > > So someone more knowledgable needs to review this. Let me just say that I am not qualified. But since this needs a review, I am going to offer my view anyway. FWIW, I don't think *anyone* understand this magic... I certainly don't. We can pretty much ignore the USB-IF and any specs, since that is what the vendors appear to do. They provide device specific drivers for Windows, so all they care about is that their device "works" with their driver. But in Linux we prefer to create drivers for device classes whenever we can, to avoid having to add every single device by ID. So we try to guess future patterns based on the devices we have observed, even when there is no clear spec. This is what Aleksander does here. He has a device with a 'Cls=ef(misc ) Sub=04 Prot=01' function. This device works with the rndis_host driver. That is all we know. We cannot prove that a class match is correct. But it does make sense to try it. At least we know that this works for one device. Adding anything else, e.g. based on the table at http://www.usb.org/developers/defined_class/#BaseClassEFh , is a bit more risky. We don't know if a driver will work with *any* such device until we've actually seen one. This is just my opinion, and probably full of bogus assumptions as usual. I was sort of hoping that some expert would speak up so I didn't have to :-) But FWIW: Reviewed-by: Bjørn Mork <bjorn@xxxxxxx> 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
