Re: [ModemManager] Alternating AT and QCDM during port probing?

[Dan Williams <dcbw redhat com>]

On Tue, 2011-06-14 at 21:38 -0500, Dan Williams wrote:
> On Wed, 2011-06-15 at 00:35 +0200, Aleksander Morgado wrote:
> > Hi Dan & list,
> > 
> > Would it be a good idea to alternate QCDM port probing along with the AT
> > port probing?, something like:
> >  * Try AT command(s)
> >  * If timeouts, try QCDM
> >  * If timeouts, try again AT command(s)
> >  * If timeouts, trya gain QCDM
> >  * If timeouts, try again AT command(s)
> >  * If timeouts, failed probing.
> > 
> > In this way, QCDM ports would be detected after just 1 timeout ideally,
> > and not after the 3 timeouts of the AT ports. Or even worse, as in the
> > ZTE plugin for example, which needs 6 AT command timeouts before
> > starting QCDM probing (3 ATE0+CPMS? and 3 AT+GCAP?).
> > 
> > Or is there a good reason to leave QCDM probing always for after AT
> > probing?
> 
> I think it was after just because it was added later and I didn't want
> to destabilize things too badly.  But this approach could work better,
> yes.  I don't believe there's a case where AT commands simply time out
> without a response.

One complication I just thought of was that some QCDM ports only respond
after the second probe attempt, because the AT commands look like
garbage to them, and the first QCDM command terminates the garbage with
the HDLC frame marker (0x7E) so the second QCDM command is the only one
actually readable by the port.  We can work around that though by
possibly sending 0x7E 0x7E when opening the port to clear out any
previous garbage, perhaps?

Dan