* Pavel Machek <pavel@???> [200424 20:46]:
> HI!
>
> > > > > Outgoing is easy. Incoming may be more tricky.
> > > > >
> > > > > We should really switch the code not to use AT code at all.
> > > >
> > > > Based on my experiments we cannot re-route the notifications
> > > > away from the /dev/motmdm* devices to the qmimodem. So it seems
> > > > at least incoming voice and sms need to be handled via /dev/motmdm*.
> > > > Probably also USSD.
> > >
> > > That was not what I meant.
> > >
> > > We are currently using /dev/motmdm <-> ofono/gatchat "AT parsing" <-> ofono/drivers/motorolamodem .
> > >
> > > But the motmdm does not really talk AT commands, they just happen to
> > > have "AT" in them. gatchat really does more harm than good. We should
> > > avoid using it.
> >
> > Ah OK yes I agree the modem is not AT compatible.
>
> It is not... and gatchat is unsuitable for this modem. But we are
> using it :-(, and it causes subtle/nasty problems.

Well if you can figure out a clean way to do raw packet reads and
writes in ofono without gatchat that would be great!

And then when it works, we can also easily just switch to using raw
/dev/gsmmux* interfaces instead of /dev/motmdm* (with same numbering)
and just leave out the whole kernel chardev thingy use for ofono.

Based on comments from Johan, we want to keep the /dev/gsmmux* support
as is for serdev users too. Presumably most serdev-ngsm users would
not need any custom handling, and only we are really stuck with the
custom packet IDs AFAIK.

If we still want to keep the kernel chardev support, that's still
doable to bring up /dev/motmdm* chardevs like now instead of
/dev/gsmmux* like we have now. But I'm guessing we don't even need it
if we get ofono working with raw packet reads and writes and stop
pretending to be using AT commands :)

Once we have raw packet read and write working, flipping to use the
raw /dev/gsmmux* should be trivial. At that point we just need to add
each packet ID to the beginning of each write as "U1234AT+CFUN?\r".
And then use it or ignore it in the results like we already do for the
kernel serdev gnss and audio drivers. I guess that only needs to be
done in the motorolamodem specific raw read and write functions.

For sending continuation messages, they start with just "U" with no
packet ID. And for the packet ID, we can just use something similar
to what kernel is using with jiffies % 10000.

> > > > > _USB_ networking. I need that to do any hacking on the phone.
> > > >
> > > > Oh I see via the OTG port, not qmicli using the modem over
> > > > OCHI :)
> > > >
> > > > I guess you could just configure acm and ecm on the OTG interface
> > > > via configfs and have your phone charged while you do that.
> > >
> > > I don't know what acm/ecm is, but I have USB networking working, and
> > > that includes 500mA charge from the USB port. Not _great_, but...
> >
> > Sounds like you're still using the old style USB gadgets. You can
> > configure a multi function gadget with using configfs where g_acm
> > is a USB serial port and g_ecm is a USB ethernet port.
>
> Yes, I'm. I'm quite happy with ssh. Dmesg would not go over g_acm, anyway?
>
> > > Unfortunately USB networking still disconnects rather often; lets say
> > > 5 times an hour. Still usable, but a bit annoying.
> >
> > Hmm maybe you have a broken micro-USB connector?
>
> I don't think it is mechanical. It sounds more like some kind of power
> problems really. Do you have rock solid connection with recent
> kernels?

Hmm OK. I'm typing this from a lapdock so at least the USB host mode
is behaving. Sounds like I need to test the USB peripheral support
again.

Care to check if your USB disconnects are related to the green battery
charge led turning on or off when the battery is full?

Recently I've started seeing an issue where the USB charging stops
after several hours, but I think that's only with spinal's experimental
capacity changes in droid4-pending-v5.6 so adding him to Cc.

Regards,

Tony