ModemManager: issues with port probing and cached capabilities

[Aleksander Morgado <aleksander lanedo com>]

Hi all,

My understanding is that the whole support for caching capabilities
after port probing is done so that if a plugin requests a probe, the
remaining plugins to check for support don't need to relaunch a new port
probe. If this is not the case, please stop reading now :-)

Port probing and grabbing usually falls under one of these options:
  (1) Usually only one single plugin does the port probing, checks
capabilities, and grabs the port. Sometimes there is even no probing
needed, as Samsung "net" subsystem devices.
  (2) Some other times a plugin does the port probing (vendor ID
matches) but then can't grab the port (capability checks fails), so
ModemManager ends up trying to default to the Generic plugin, which will
use the already cached capabilities to check for support.

With the RS232 modem support (not yet merged in master) there is still a
new option:
  (3) A plugin which supports RS232 modems does port probing (didn't do
vendor ID check with the udev-reported one), and finds that the vendor
ID from AT+CGMI is not the one it expects, so doesn't go on. Then, next
plugins checking for support will use the cached
capabilities/vendorID/productID.

There seems to be 2 problems in this logic:

-----

Most (all?) implementations of grab_port() in the plugins rely on the
fact that the port probing task they get as input argument is exactly
the one which did the port probing: there are calls to
mm_plugin_base_supports_task_get_probed_capabilities() usually in
grab_port() in order to know if a GSM or CDMA modem object is to be
created. This is even the case for the generic plugin, which means that
if some other plugin did the real port probing, once the Generic plugin
wants to grab the port (cases 2 and 3 above), the call to
mm_plugin_base_supports_task_get_probed_capabilities() will return 0 and
the port won't be grabbed, spitting something like:
   do_grab_port(): plugin 'Generic' claimed to support tty/ttyUSB0 but
couldn't: (-1) (unknown)

I guess this behaviour is undesired, we shouldn't make grab_port()
assume that the supports task that gets as input is really the supports
task that did the real probing. Or, otherwise, we could try to simulate
that a port probing was done by that supports task by copying the cached
capabilities within the supports task results. Any other suggestion on
how to avoid this issue?

-----

Another related issue comes from the fact that even for port probing,
different plugins may have special needs:
  * The Huawei plugin needs AT^CURC=0 and AT^GETPORTMODE before
launching the probe, for example.
  * In general, ModemManager allows plugins to setup a
custom_init_command in the supports task, with a custom callback to
report capabilities found in the response.

Now, if there is any previous plugin that launched a probe on that same
port and cached some invalid result of capabilities, the plugin with
special probing needs will rely on the cached result and not launch a
new probe, which is not good. I guess that for these plugins with
special needs, we shouldn't rely on the cached capabilities stored by a
previous supports task of another plugin, and always launch a new probe.

This issue anyway is probably a little less worrying due to the fact
that port probing is currently always launched once the vendor ID has
been done; so only case (2) above would be affected by this, and in this
specific case the Generic plugin (the one consuming the previously
cached capabilities) doesn't need any special port probing needs. Once
RS232 support gets in master, this issue may then affect also the case
(3) above for plugins supporting RS232 modems.

-----

What do you guys think about these two issues?

Now I wonder if it is really worth all this caching of capabilities,
when almost always port probing and grabbing will fall under case (1)
above: only one single plugin does the port probing, checks
capabilities, and grabs the port.

Cheers!

-- 
Aleksander