пн, 9 мар. 2020 г. в 15:17, Oliver Neukum <oneukum@xxxxxxxx>: > > Am Freitag, den 06.03.2020, 01:33 +0500 schrieb Alexander Bersenev: > > The NCM specification defines two formats of transfer blocks: with 16-bit > > fields (NTB-16) and with 32-bit fields (NTB-32). Currently only NTB-16 is > > implemented. > > > > This patch adds the support of NTB-32. The motivation behind this is that > > some devices such as E5785 or E5885 from the current generation of Huawei > > LTE routers do not support NTB-16. The previous generations of Huawei > > devices are also use NTB-32 by default. > > > > Also this patch enables NTB-32 by default for Huawei devices > > Hi, > > do you really see no other option but to make the choice with yet > anothet flag? The rest of the code looks good to me. > Hi, The reason of yet another flag is that some Huawei devices, E5785 and E5885, are incorrectly reporting that they support NTB-16. In fact they support only NTB-32. Historically the Huawei devices used NTB-32 by default and there was a flag CDC_NCM_FLAG_RESET_NTB16 to work around the bug that some Huawei E3372H devices come out of reset in NTB-32 mode even if NTB-16 mode was set. This commit removes the CDC_NCM_FLAG_RESET_NTB16 flag, that was specific to Huawei devices and introduces the CDC_NCM_FLAG_PREFER_NTB32 flag. The NTB-16 has lower, protocol overhead, but NTB-32 allows to transfer more data per transfer block, up to 4GB, supporting both High Speed and SuperSpeed data rates. So NTB-32 can be faster on devices with big buffers and slower on devices with small buffers. Anyway, for 4g modem devices there should not be much difference between NDP-16 and NDP-32 because the 4g speeds are lower than the USB speed. But also there may be the devices, that, vice versa, buggy with NTB-32 and work well with NTB-16. So having a flag to choose the preferred implementation is probably the best option - it allows to keep older device to work as before, but if it is found out that the device works with NTB-32 better, the flag can be enabled for that device or vendor. Best, Alexander Bersenev
