[review] aleksander/huawei-ndisdup-cdc-wdm-rebased-1.2

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:
> On Fri, Jun 13, 2014 at 10:24 AM, Bjørn Mork <bjorn at mork.no> wrote:
>> Eyyh, thinking some more about this I wonder if cdc-wdm play well with
>> this strategy?  We cannot expect the firmware to notify us again about
>> the remaining bytes.  Which means that we won't read them until the next
>> time the firmware has something to tell us.  Which is probably what
>> screws up MM here?  The delay between the initial 256 bytes and the rest
>> is possibly infinite.
>>
>> This is probably food for a generic cdc-wdm fixup: We should resubmit
>> the read URB if the last read returned a full buffer.
>
>
> Yeah, if we don't get a IN event in the socket we won't try to read
> anything, so in this case we read up to the first 256 bytes and then
> MM was just sitting there waiting for more events to come.
> Is this something quick to fix in the driver?

A real quick fix is just increasing the size of the buffer.

I don't know about fixing the real problem. The cdc-wdm driver has
become a bit more messy than it should have been, making any such change
risky. I wonder how we could end up making this so complicated? ;-)

And then there is the question whether this change is appropriate for
all protocols handled by the cdc-wdm driver.  WDM and MBIM have well
defined message sizes, so we know we'll get a notification for the next
message even if we read a full buffer. And WDM is obviously important
here...

The problem is QMI and the Huawei NCM thing, where we really don't know
what the firmware will send.  For QMI we do depend on having big enough
buffers anyway.  Nothing is prepared to see a split QMI message, which
is why we have set the buffer size to as much as 4096 in qmi_wwan.  I am
tempted to just close my eyes and see if the problem goes away :-)

Or maybe just go for the quick fix, like and increase the huawei_cdc_ncm
buffer size?  What do you say, Enrico? Is 512 bytes fine, or maybe 1024?
What is the largest single AT command response we can expect over this
channel?


Bjørn