This allows us to 'nest' firmware formats, and removes a ton of duplication.
The aim here is to deprecate FuFirmwareImage -- it's almost always acting
as a 'child' FuFirmware instance, and even copies most of the vfuncs to allow
custom types. If I'm struggling to work out what should be a FuFirmware and
what should be a FuFirmwareImage then a plugin author has no hope.
For simple payloads we were adding bytes into an image and then the image into
a firmware. This gets really messy when most plugins are treating the FuFirmware
*as* the binary firmware file.
The GBytes saved in the FuFirmware would be considered the payload with the
aim of not using FuFirmwareImage in the single-image case.
The best way of not getting something wrong is to not require it in the first
place...
All plugins now use DeviceInstanceId-style quirk matches and we can just drop
the prefix in all files. We were treating HwId=, Guid= and DeviceInstanceId= in
exactly the same way -- they're just converted to GUIDs when building the silo!
Devices may want to support more than one protocol, and for some devices
(e.g. Unifying peripherals stuck in bootloader mode) you might not even be able
to query for the correct protocol anyway.
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!
Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.
This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.
This removes the workaround added in 99eb3f06b6.
Fixes https://github.com/fwupd/fwupd/issues/2915
When this is done, include:
* Including the hash
* Including anything that is not ABI stable in plugins yet
Suggested-by: Simon McVittie <smcv@debian.org>
The end year is legally and functionally redundant, and more importantly causes
cherry-pick conflicts when trying to maintain old branches. Use git for history.
Asking the user for the UID mapping isn't working very well, as it requires lots
of manual handholding. It also doesn't work very well when the device vendor
does not actually have a PCI ID or if the vendor has split into two entities.
Just use the OUI address as an additional VendorID and match any of the device
IDs against any of the metadata-supplied values.
The plugin currently supports Fastboot and QMI/PDC methods, but given
that QMI/PDC is exclusively used for carrier config installations,
there is no need for QMI/PDC-only updates, so make sure that
combination is right away forbidden.
This validation will also be useful when adding additional update
methods, as we'll be able to clearly specify which are the
combinations expcted.
The upgrade process requires that the USB interface layout is not
changed between upgrades, something that we require for AT and we also
require now for QMI. We store the USB interface number of the QMI port
as soon as the device is probed, and we use it to match the interface
number once the Udev based device is created.
squash! modem-manager: make sure the correct interface number is used for QMI
The built-in udev monitoring in the ModemManager plugin is only
required for those upgrade methods where the device switches into a
fully different port/interface layout. So far, we only expect this to
happen when the Fastboot update method is requested by the module.
The GUdevClient is created when the ModemManager sysfs path is
inhibited; we need to make sure we destroy the object once
uninhibited, or we'll otherwise create a new one if we're running
an additional upgrade operation afterwards.
Reading the sysfs file seemed to have also eaten the `\n` as mentioned
on a bug.
```
├DW5821e Snapdragon X20 LTE:
│ Device ID: fa707b9af86ff44bc17316b6c3e5ea82aab3ce86
│ Summary: Mobile broadband device
│ Current version: T77W968.F1.0.0.4.2.GC.010
│ Vendor: Dell Inc. (USB:0x413c
│ )
│ GUIDs: 64da2d58-8d1b-5e5b-b793-f88ba5a25a8f
│ 761d6124-0002-5185-b767-9adf67bf1a5e
│ 795e079d-093b-5503-aa59-35b832480e95
│ Device Flags: • Updatable
```
If we say that the version format should be the same for the `version_lowest`
and the `version_bootloader` then it does not always make sense to set it at
the same time.
Moving the `version_format` to a standalone first-class property also means it
can be typically be set in the custom device `_init()` function, which means we
don't need to worry about *changing* ther version format as set by the USB and
UDev superclass helpers.
In 1de7cc we checked the version format when checking for update, but there are
many other places that are doing verfmt-insensitive comparisons. For instance,
the predicates in <requires> all fail if the device version format is plain.
his breaks updating some NVMe drives where the `ne` requirements are not
semantic versions.
To avoid trying to catch all the bugs in different places, and in case we have
a future verfmt that should be treated another way, refactor this out in to a
common function and deprecate the old function.
There are several subtle bugs in various places in fwupd caused by not treating
user-provided offsets into buffers as unsafe. As fwupd runs as root we have to
assume that all user firmware is evil, and also that devices cannot be trusted.
Make a helper to put all the logic into one place and convert all users.
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.
The DW5821e in modem mode uses the 0x81D7 PID, but when it boots in
fastboot mode it uses the 0x81D6 PID. The upgrade procedure was able
to automatically match these two devices because they both shared the
very generic per-VID (0x413C) GUID, but this is no longer operational
since commit 8ef139faba, as the very generic GUIDs have been removed
for matching purposes.
So, define a quirk for the DW5821e, in order to add a counterpart
GUID to make device matching work properly again.
Fixes https://github.com/hughsie/fwupd/issues/1271
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).
