David Miller <davem@xxxxxxxxxxxxx> writes: > From: Rob Gardner <robmatic@xxxxxxxxx> > Date: Wed, 28 Aug 2013 18:40:22 -0600 > >> The exception list means "usb_device_id entries for specific devices >> that are known to need the workaround." There are just two such entries. >> There isn't even a separate list. So maybe we just have a nomenclature >> problem, and we could simply be calling this a "white list" instead of >> "exception list". The other possible meaning of whitelist (all devices >> that *don't* need the workaround) is unthinkable, as that would be a huge >> list and much more prone to be unmanageable than what we've got now. > > Ok I misunderstood. I thought we were discoving that all chips which > have been thoroughly investigated end up needing the workaround. > > I guess it's only a specific family of these chips which seem to all > have the problem? This driver is a class driver, which means that it deals with a number of completely independent chip designs from different vendors. We have so far seen and tested chips from ST-Ericsson, Qualcomm and Mediatek with this driver. Given that Microsoft requires MBIM, we are likely to see implementations on all available 3G/LTE chips (if there are any others?) Only devices with Qualcomm chips have the bug in question, and so far we have only observed it in modules made by Sierra Wireless. The firmware in these modules has a base part made by Qualcomm and an application part made by Sierra Wireless. We do not know which part of the firmware is responsible for the bug, but we do know that the Qualcomm base firmware used by these modules support MBIM framing. Based on this, I am guessing that the chip vendor Qualcomm is responsible for the bug. If correct, then the bug is likely to appear in products from many different module vendors. It would not be the first time we saw that... I do have a Huawei MBIM device with a Qualcomm chip, but this module does not have the Qualcomm firmware with MBIM support. The MBIM implementation is therefore assumed to be made by Huawei and running as a firmware application on the device. This device does not have the bug. Now, if we could just identify devices running a Qualcomm base firmware with MBIM support then we could enable the workaround for all those. But the driver does not have any way to identify them. It must base its decision on the USB descriptors, in practice only device ID and product ID. A module vendor can use chips from different sources (Huawei does this), and as Rob says: Laptop vendors will often have modules made with their own vendor ID. Most laptop vendors will also use modules from different vendors. HP, as a current example, is known to use modules both from Sierra Wireless (need the workaround) and Ericsson (does not want the workaround). This makes any sort of vendor matching difficult, and we end up with device specific blacklisting or whitelisting as the only option. If it had been only the two devices we have now, or even only a few tens of devices, this would not have been a big deal. But I do expect that the length of this exception list will be comparable to the list of devices supported by the qmi_wwan driver, i.e. hundreds. And, like that driver, the list will probably never be complete. Given the difficulties detecting the need for the workaround, the list is probably going to be extremely incomplete. Only a small percentage of end users with affected devices will be able to provide the necessary information. For the question of the workaround impact on devices without bug: They will work fine, and the effect will not be user noticable AFAICS. But it will have a negative impact on the device, most likely causing higher power consumption. Alexey has explained this much better than I can, as I do not fully understand the device firmware design and requirements: http://www.spinics.net/lists/linux-usb/msg78078.html Quoting part of his explanation (talking about the *device* CPU and INT - we do not care about the host): If host decides to send ZLP after full NTB, CPU must handle additional INT per every full NTB instead of doing useful work. For FTP transfer with constantly full NTBs you get twice amount of Interrupts. I do agree that this is unfortunate. And hurting standard compliant devices to work around a standard violating bug in other devices does not feel right. But I do not see any other option. 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
