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

[Dan Williams]

On Fri, 2014-06-13 at 17:02 +0200, Aleksander Morgado wrote:
> On Fri, Jun 13, 2014 at 4:58 PM, Bjørn Mork <bjorn at mork.no> wrote:
> >> Puff... the largest AT command response may be pretty large. Not sure
> >> if will hit 1024, though.
> >>
> >> Another thing we could try is to detect the issue in userspace; and if
> >> we get 256 bytes from the AT-capable /dev/cdc-wdm port, just schedule
> >> another read() to be done in an idle. This is a non-blocking socket,
> >> so it shouldn't harm... unless the kernel doesn't fill the buffer
> >> again with the remaining data in the time we're doing the idle...
> >
> > I could be wrong, ref the driver complexity, but I believe the driver
> > won't fetch the remaining data from the modem until the modem sends
> > another notification.  And I am guessing the modem won't do that twice
> > for the same message, even if the driver only read part of it.
> 
> 
> Oh, ok.... 1024 it is, then? ;)

The longest messages I can think of are stuff like this (SYSCFGEX),
maybe +COPS=? responses in areas with a couple different providers, and
possibly IPv6 "get IP details" commands like E2IPCFG/IPDPADDR.  But all
those are going to be way less than 1024 bytes.  But obviously some are
larger than 256.  I think 1024 is probably good max for now.

Dan