Re: ModemManager: Letting plugins manage RS232 modems

[Dan Williams <dcbw redhat com>]

On Thu, 2011-05-05 at 16:54 +0200, Aleksander Morgado wrote:
> Hi all,
> 
> (sorry for the long email)
> 
> ModemManager plugins need several steps to know whether they can handle
> a given connected modem. The flow is usually something like this:
> 
>         (1) Check vendor ID (and sometimes also product ID), with one of
>         the following methods:
>                 (1.a) Use vendor/product IDs reported by udev (obtained
>                 from the USB interface)
>                 (1.b) Check for a specific envvar set in the udev device
>                 (e.g. ID_MM_ERICSSON_MBM). The vendor/product
>                 relationship w.r.t the envvar is moved to the udev rules
>                 file.
> 
>         (2) Check interface subsystem type (some plugins only support
>         "tty"s, for example)
> 
>         (3) Check modem capabilities, to see if they are GSM or CDMA.
>                 (3.1) If capabilities already cached, just check them.
>                 (3.2) If capabilities not already cached, launch port
>                 probing:
>                         (3.2.1) Probe capabilities. If any of the
>                         following commands succeeds and we parse a valid
>                         reply, the remaining ones are skipped.
>                                 (3.2.1.1) AT+GCAP (3 times). If all 3
>                                 get timed out, check if port is QCDM.
>                                 (3.2.1.2) ATI
>                                 (3.2.1.3) AT+CPIN?
>                                 (3.2.1.4) AT+CGMM
>                         (3.2.2) Notify the probe end and let the plugin
>                         check the capabilities in the signal handler.
> 
> All plugins, except for the generic one, will do the vendor ID check to
> see if they can support the connected modem. Unfortunately, both (1.a)
> and (1.b) methods to check vendor ID depend on the values reported by
> udev, and sometimes they do not correspond with the real modem
> vendor/product IDs:
>  * For modems connected via an adapter (bluetooth, RS232<->USB, ...),
> usually the adapter's vendor/product ID are reported by udev.
>  * For modems connected to a RS232 port, there's no vendor/product ID
> reported by udev.
>  * Probably some other situations I can't think of...
> 
> So how can we let plugins know if they can handle these devices?
> 
> We could extend the port probing so that in addition to the
> capabilities, we also try to query vendor and model via AT commands.
> This would be done as a new step just after probing capabilities (3.2.1)
> and before notifying the probe end (3.2.2):
>  
>         (3.2.1) Probe capabilities (...)
>         (3.2.2) Probe vendor ID. If any of the following commands
>         succeeds  and we parse a valid reply, the remaining ones are
>         skipped. If all the commands fail, product probing is also
>         skipped.
>                 (3.2.2.1) AT+CGMI
>                 (3.2.2.2) AT+GMI
>                 (3.2.2.3) ATI
>         (3.2.3) Probe product ID. If any of the following commands
>         succeeds and we parse a valid reply, the remaining ones are
>         skipped.
>                 (3.2.3.1) AT+CGMM
>                 (3.2.3.2) AT+GMM
>                 (3.2.3.3) ATI
>         (3.2.4) Notify the probe end and let the plugin check the
>         capabilities/vendor/product in the signal handler.
> 
> This would allow plugins that expect (for example) RS232 modems, to do
> an additional check on the vendor ID (and/or product ID) string reported
> by the modem itself. These additional AT commands during probing would
> be sent only if we got a successful capabilities query (so not tried if
> the port is a QCDM one for example); and the replies could be cached in
> the AT port handler, so at the end it shouldn't affect much the time
> needed to setup the modem (as these commands are usually afterwards
> issued when querying card info). This solution should be enough for both
> RS232 modems connected directly to a RS232 port and for modems connected
> to the PC via an adapter.
> 
> An implementation of this can be checked at the following commit:
> https://gitorious.org/lanedo/modemmanager/commit/b06faebb748a18c5428afc8aa7a71b95d79a5fbe
> 
> And an example of how it can be used here:
> https://gitorious.org/lanedo/modemmanager/commit/62ba095c26528eaa519598124b3494829bedf501
> 
> Some other ideas I thought about:
>  (a) During whitelisting the RS232 port in udev, include an envvar like
> ID_MM_MY_PLUGIN, so that the plugin can the look for it and if found,
> assume it can handle the modem. But this doesn't work for RS232 modems
> connected via a USB adapter; and also it would be very plugin-specific.
>  (b) Add a custom init command in the specific plugin during port
> probing, which checks vendor ID and compare it there. I don't dislike
> this solution that much, but it ends up being very plugin-specific, not
> a general solution.

I like it.  I now see what you were talking about :)  Let's push it to
git master for now and we can cherry-pick to MM_05 later if it turns out
it works well for all the devices we can find.  I'm a bit wary of making
such a big change in MM_05 right now given that I'd like to keep that
branch pretty quiet in preparation for the 05 release.

Dan