> > OK I think I found the reason fo ofono doing a variable
> > number of commands on start-up with sudo test/enable-modem.
> > There seems to be some kind of issue with handling of
> > commands and results in ofono. See the logs below for
> > test/enable-modem. The AT+SCRN=0 is sent and then AT+CFUN=1
> > without waiting for results from the previous command :)
> > Is there maybe a missing sync somewhere after writes?
> No idea. I just copied the code from other drivers and it seemed to
> work for me.
Yeah presumably that works for serial ports.
Still not sure what is going on there. Part of the problem seems to be
ofono expects serial protocol, and will happily split & batch things
together, but motmdm is really packet-based.
/* Prepend Motorola custom packet numbering */
snprintf(cmd, cmdlen, "U%04i%s\r", mot_dlci->id, buf);
We already have \r or \n from the user. Will this add extra one?
I guess this will not work with embedded zero bytes...
Plus it seems kernel auto-splits stream from user into packets...
static ssize_t motmdm_cdev_write(struct file *file, const char __user
...should it work byte-by-byte? This way if userland sends
AT+FOO=1\rAT+BAR=2\r, it will be sent as a single packet, which is
probably wrong thing to do.
...should it also treat ^Z as an end of packet? In case of SMS
sending, AT+GCGMS= should go in one packet and hex data in another
one, if I understand things correctly....
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html