In many plugins we've wanted to use ->prepare_firmware() to parse the firmware
ahead of ->detach() and ->write_firmware() but this has the limitation that it
can only return a single blob of data.
For many devices, multiple binary blobs are required from one parsed image,
for instance providing signatures, config and data blobs that have to be pushed
to the device in different way.
This also means we parse the firmware *before* we ask the user to detach.
Break the internal FuDevice API to support these firmware types as they become
more popular.
This also allows us to move the Intel HEX and SREC parsing out of the dfu plugin
as they are used by a few plugins now, and resolving symbols between plugins
isn't exactly awesome.
This leads to madness, as some formats are supersets of the detected types,
e.g. 'intel-me' is detected as 'quad' and 'bcd' is detected as 'pair'.
Where the version format is defined in a specification or hardcoded in the
source use a hardcoded enum value, otherwise use a quirk override.
Additionally, warn if the version does not match the defined version format
The timeout to wait for the modem after being uninhibited was until
now exclusively to cover the port probing time, because the device
would be already available and ready to be used as soon as the
inhibition was removed.
With the change to include carrier config selection as part of the
fwupd upgrade process, the time to wait for the modem after being
uninhibited should now cover a full reboot of the module, and so the
original timeout of 45s could be a bit tight under some circumstances
(e.g the MM device probing logic is quite slow when there is no SIM
card detected by the module).
We increase this timeout to a much safer value of 120s, which is
extremely long for most cases, but should also be enough to cover even
the worst case scenario.
When we install the MCFG carrier config files with QMI PDC, we were
not explicitly selecting one, and that would end up reporting the
"DF" (default) config is in use. Instead, we should explicitly select
the carrier configuration that we were using before the firmware
upgrade operation.
For example, if the device originally was running with the Vodafone
specific carrier configuration (e.g. T77W968.F1.0.0.3.7.VF.009) and we
trigger the upgrade to the next available firmware associated to
the Vodafone carrier (e.g. T77W968.F1.0.0.3.8.VF.009), we would want
the device to boot with the Vodafone carrier config selected, instead
of booting without any config selected (T77W968.F1.0.0.3.8.DF.009).
This also fixes several upgrade problems detected by fwupd, because it
may end up complaining that the target firmware that was selected to
be installed (e.g. VF variant) is not the one actually reported by the
device after the upgrade (e.g. DF variant).
The selection of which is the config to activate is based on mapping
the mcfg file name with the firmware version reported by the module
before the upgrade. E.g. if the VF variant is reported by the module
(T77W968.F1.0.0.3.7.VF.009), fwupd will look for a MCFG file named
with the "mcfg.VF." prefix.
If a device reports that qmi-pdc is supported (e.g. DW5821e that
supports both fastboot and qmi-pdc), we'll end up first running the
fastboot installation before doing the qmi-pdc installation procedure.
These changes also make sure that the MM device inhibition is kept for
as long as the whole process is ongoing. Only after the last method is
run, the inhibition will be removed.
In order to handle devices being exposed in the system while the MM
inhibition is in place, e.g. to be able to run qmi-pdc after fastboot,
a simple udev based watcher is included, which will take care of
creating the FuMmDevice that is not associated to any modem currently
exposed by MM, but that shares all the details of the original device.
This new logic assumes that the devices don't change their USB layout
during a firmware upgrade, which is not a very good assumption, but it
works for the case at hand. If this is not the case, we may need to
end up doing some custom AT port probing instead of relying on the
original one reported by MM being still valid (note that we don't rely
on the device name, as that may change if some other device is plugged
in the system while we're doing the update, we rely on the USB
interface number).
