dcbw at redhat.com
Fri Jun 13 09:02:33 PDT 2014
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.
More information about the ModemManager-devel