Make port roles more flexible. We have modems that do PPP
on interfaces other than the primary interface, and that
wasn't possible with the old code. So clean up all that
logic and move the port organization code into the core
so we can reduce code in the plugins.
In the new world order, the plugins say whether the port
is a QCDM port, an AT port, or ignored. If it's an AT
port the plugins get to tag it as primary, secondary, or
PPP, or any combination of the 3. This allows for modems
where PPP should really be done on the secondary port
(Huawei E220, Sierra devices) so that the primary port
stays open for command and status.
Modem subclasses no longer get asked to handle port grabbing
themselves. Instead, that's now done by the generic classes
(MMGenericCdma and MMGenericGsm) and the plugins are notified
when a port is grabbed so they can add unsolicited response
handlers for it. After all ports are grabbed by the generic
classes, they get "organized", which assigns various ports
to the roles of PRIMARY, SECONDARY, DATA, and QCDM based
on specific rules and hints that the plugin provided (which
are expressed as MMAtPortFlags). The plugins then have
a chance to perform fixups on the primary port if they choose.
The plugin code is responsible for determining the port
hints (ie MMAtPortFlags) at probe time, instead of having
a combination of the plugin and the modem class do the
job. This simplifies things greatly for the plugins at
the expense of more complicated logic in the core.
Various bits of the code didn't check if response was valid
or not during error conditions, and when an error occurs
sometimes it'll be NULL (since not all errors are translated
errors from the modem, some are serial or general ones). We
have to make sure we don't try to use response->str when
response doesn't exist.
Found in the generic CDMA code likely as a result of
d5d9eec2b5 but was a bug long
before that commit happened anyway.
We need to ensure that the supports task always has the results of the probing,
no matter if the probing was just launched by the plugin grabbing the port, or
by a previous plugin. We do this during supports_port(), by propagating to the
supports task any possible previously cached probing results.
The X200 shares the same USB VID and PID as the X060s but the X200
does not use the same AT command set; it uses the X22X plugin
instead. Since both modems also report the same +GMM and +GMI
responses, we have to fall back to using +GMR even though that's
a pretty sketchy way to tell them apart if the firmware ever changes.
Other devices from the same vendor (x220) need to be handled by
the x22x plugin, so Longcheer can't just rely on the vendor ID
match to know whether it should handle the modem.
Pass the device's hardware IDs through modem creation and use them
when calculating the device's identifier. Add a bunch of testcases
for real hardware to ensure we don't break the device ID in the
future unless we really want to.
These are Longcheer-based devices, but the vendor ID is different.
We had tagged the X060s' ports in the rules but never updated the
plugin to handle the different vendor ID.
Anything with vendor ID 0x1c9e really; like Alcatel X020, X030,
X060s, etc. Longcheer appears to make the actual hardware that all
the devices with vendor ID 0x1c9e use. You'll see it in .INF files
with "CMLONG" as part of the USB interface definition.
If the ports are not correctly detected, we need to get the driver's
.INF files to determine what the ports should be, and add them to
the udev rules file.
