How other applications use the ports that occupied by MM

[Bowden, Brendan]

> From: ModemManager-devel <modemmanager-devel-
> bounces at lists.freedesktop.org> On Behalf Of Dan Williams
> Sent: Thursday, March 21, 2019 10:20 AM
> To: Aleksander Morgado <aleksander at aleksander.es>; 王道之
> <lingzangwuhen at gmail.com>
> Cc: ModemManager (development) <modemmanager-
> devel at lists.freedesktop.org>
> Subject: Re: How other applications use the ports that occupied by MM
>
> On Mon, 2019-03-18 at 11:24 +0100, Aleksander Morgado wrote:
> > Hey,
> >
> > > I am trying to find a way to use the AT ports or mbim ports that
> > > occupied by MM as all the device ports were used by MM. eg. I want
> > > send AT command to the modem, but MM occupies the AT port. Is there
> > > any way to make MM stop using the AT port for a while but not kill
> > > the MM? To do that, maybe the application can send a D-bus signal or
> > > request a method to MM, then MM stop the AT port for a while, after
> > > application finish its work, send a D-bus info to MM, MM continue
> > > use the AT port.
> >
> > If the AT port is not the primary control port, you could add the
> > ID_MM_PORT_IGNORE udev tag on the specific TTY so that MM ignores it.
> >
> > > And I know in MM debug mode, mmcli could use --command  to send the
> > > AT command. Is there normal mode way to send AT command from MM?
> >
> > Right now --command only works while in debug mode, so that the user
> > doesn't send commands that may interfere with the control logic of
> > MM...
> >
> > But truth be told, we're already allowing QMI and MBIM commands to be
> > sent through the proxies while MM is running anyway...
> >
> > @Dan Williams what would you think if we open up the
> Modem.Command()
> > method also while not in debug mode? We could explicitly warn that MM
> > will treat all these commands as transparent, so if the state of modem
> > changes as a result of these commands, MM may get out of sync.
> > Another
> > option I'm thinking about is to make it a configure option instead.
> > Don't know, mixed feelings.
>
> Yeah, mixed feelings from me too. I guess before we do that, can we ask
> what commands people want to use? I'd rather it not be used a short circuit
> for stuff that could be fixed in MM or implemented fairly easily for a device.
> That's my only reservation, that having it may reduce the incentive to
> fix/enhance MM itself.
>
> Dan
>

We're looking at using the AT port to get a few status values that don't appear to be readily available from QMI. One we need in particular is  device temperature (there's a hardware failure condition that manifests as a very high temperature value). Of course any hints on how to pull this via QMI instead would be helpful also.

Brendan

> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments. Please be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.