Daniele Palmas <dnlplm@xxxxxxxxx> writes: > Il giorno lun 3 ago 2020 alle ore 11:49 Greg KH > <gregkh@xxxxxxxxxxxxxxxxxxx> ha scritto: >> >> Where does QMI_WDA_SET_DATA_FORMAT come from? >> > > This is a request of Qualcomm proprietary protocol used, among other > things, to configure data aggregation for modems. There's an open > source userspace implementation in the libqmi project > (https://cgit.freedesktop.org/libqmi/tree/data/qmi-service-wda.json) > >> And the commit log says that this "depends on the chipset being used", >> so why don't you know that at probe time, does the chipset change? :) >> > > Me too does not understand this, I let the author explain... > >> > Currently there's a workaround for setting rx_urb_size i.e. changing >> > the network interface MTU: this is fine for most uses with qmap, but >> > there's the limitation that certain values (multiple of the endpoint >> > size) are not allowed. >> >> Why not just set it really high to start with? That should not affect >> any older devices, as the urb size does not matter. The only thing is >> if it is too small that things can not move as fast as they might be >> able to. >> > > Yes, this was proposed in the past by Bjørn > (https://lists.freedesktop.org/archives/libqmi-devel/2020-February/003221.html), > but I was not sure about issues with old modems. Ah, right. Forgot about that. > Now I understand that there are no such issues, then I agree this is > the simplest solution: I've seen modems requiring as much as 49152, > but usually the default for qmap is <= 16384. > > And, by the way, increasing the rx urb size is required also in > non-qmap mode, since the current value leads to babbling issues with > some chipsets (mine > https://www.spinics.net/lists/linux-usb/msg198025.html and Paul's > https://lists.freedesktop.org/archives/libqmi-devel/2020-February/003217.html), > so I think we should definitely increase this also for non-qmap mode. > > Bjørn, what do you think? I think we have good enough reasons to increase the rx urb size by default. Let's try. Bjørn
