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.
Some plugins have devices with more than one protocol. Logically the protocol
belongs to the device, not the plugin, and in the future we could use this to
further check firmware that's about to be deployed.
This is also not exported into libfwupd (yet?) as it's remains a debug-feature
only -- protocols are not actually required for devices to be added.
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 order of events when casting causes an access to unintended memory.
```
0x00007ffff7bc19df in fwupd_guid_to_string (guid=0x8000000090d0, flags=FWUPD_GUID_FLAG_MIXED_ENDIAN) at ../libfwupd/fwupd-common.c:550
550 memcpy (&gnat, guid, sizeof(gnat));
(gdb) bt
#0 0x00007ffff7bc19df in fwupd_guid_to_string (guid=0x8000000090d0, flags=FWUPD_GUID_FLAG_MIXED_ENDIAN) at ../libfwupd/fwupd-common.c:550
#1 0x00007fffdbddd195 in fu_nvme_device_get_guid_safe (buf=0x7fffffffce70 "\\\034\\\034FI83Q060610103M66 BC501 NVMe SK hynix 128GB", ' ' <repeats 15 times>, "80001C0T\004", <incomplete sequence \344\254>, addr_start=3110) at ../plugins/nvme/fu-nvme-device.c:83
#2 0x00007fffdbddd60c in fu_nvme_device_parse_cns_maybe_dell (self=0x5555558cc8a0, buf=0x7fffffffce70 "\\\034\\\034FI83Q060610103M66 BC501 NVMe SK hynix 128GB", ' ' <repeats 15 times>, "80001C0T\004", <incomplete sequence \344\254>) at ../plugins/nvme/fu-nvme-device.c:201
#3 0x00007fffdbddda64 in fu_nvme_device_parse_cns (self=0x5555558cc8a0, buf=0x7fffffffce70 "\\\034\\\034FI83Q060610103M66 BC501 NVMe SK hynix 128GB", ' ' <repeats 15 times>, "80001C0T\004", <incomplete sequence \344\254>, sz=4096, error=0x7fffffffe008) at ../plugins/nvme/fu-nvme-device.c:295
#4 0x00007fffdbddde68 in fu_nvme_device_setup (device=0x5555558cc8a0, error=0x7fffffffe008) at ../plugins/nvme/fu-nvme-device.c:376
#5 0x0000555555587850 in fu_device_setup (self=0x5555558cc8a0, error=0x7fffffffe008) at ../src/fu-device.c:2076
#6 0x0000555555587412 in fu_device_open (self=0x5555558cc8a0, error=0x7fffffffe008) at ../src/fu-device.c:1920
#7 0x000055555558aa88 in fu_device_locker_new_full (device=0x5555558cc8a0, open_func=0x5555555872cb <fu_device_open>, close_func=0x555555587424 <fu_device_close>, error=0x7fffffffe008)
at ../src/fu-device-locker.c:154
#8 0x000055555558a925 in fu_device_locker_new (device=0x5555558cc8a0, error=0x7fffffffe008) at ../src/fu-device-locker.c:104
#9 0x00007fffdbddc4cd in fu_plugin_udev_device_added (plugin=0x5555558a6420, device=0x5555558c6300, error=0x7fffffffe008) at ../plugins/nvme/fu-plugin-nvme.c:24
#10 0x0000555555592cbf in fu_plugin_runner_udev_device_added (self=0x5555558a6420, device=0x5555558c6300, error=0x7fffffffe070) at ../src/fu-plugin.c:1281
#11 0x000055555557f0a8 in fu_engine_udev_device_add (self=0x5555557f9840, udev_device=0x5555558e5900) at ../src/fu-engine.c:3491
#12 0x000055555557f480 in fu_engine_enumerate_udev (self=0x5555557f9840) at ../src/fu-engine.c:3555
#13 0x0000555555580fc6 in fu_engine_load (self=0x5555557f9840, error=0x7fffffffe2c8) at ../src/fu-engine.c:4117
#14 0x0000555555566567 in fu_util_start_engine (priv=0x5555557eeb20, error=0x7fffffffe2c8) at ../src/fu-tool.c:138
#15 0x00005555555674e2 in fu_util_get_devices (priv=0x5555557eeb20, values=0x7fffffffe5d8, error=0x7fffffffe2c8) at ../src/fu-tool.c:490
#16 0x0000555555566aff in fu_util_run (priv=0x5555557eeb20, command=0x7fffffffe81a "get-devices", values=0x7fffffffe5d8, error=0x7fffffffe2c8) at ../src/fu-tool.c:242
#17 0x000055555556a514 in main (argc=2, argv=0x7fffffffe5c8) at ../src/fu-tool.c:1445
```
This also allows us to write mixed-endian structures and adds tests. As part of
this commit we've also changed the API of something that's not yet been in any
tarball release, so no pitchforks please.
This allows hardware from OEMs to *not* match generic firmware supplied by the
device manufacturer. The idea being, that the OEM will supply firmware that
will actually work on the device.
Based on a patch from Mario Limonciello, many thanks.
Affected drives should have a prominent statement in the update description,
possibly even the first line so it shows up by default in the updates panel.
It wasn't hugely clear what the platform ID was actually meant to represent. In
some cases it was being used like a physical ID, in others it was a logical ID,
and in others it was both. In some cases it was even used as a sysfs path.
Clear up all the confusion by splitting the platform ID into two parts, an
optional *physical* ID to represent the electrical connection, and an optional
*logical* ID to disambiguate composite devices with the same physical ID.
Also create an explicit sysfs_path getter for FuUdevDevice to make this clear.
This allows WAIT_FOR_REPLUG to always work, rather than depending on the order
that the GUIDs were added, and that the kernel would always return the same
sysfs path (which it doesn't have to do, especially for hidraw devices).
The daemon creates a baseclass of either FuUsbDevice or FuUdevDevice when the
devices are added or coldplugged to match the quirk database and to find out
what plugin to run.
This is proxied to plugins, but they are given the GUsbDevice or GUdevDevice and
the FuDevice is just thrown away. Most plugins either use a FuUsbDevice or
superclassed version like FuNvmeDevice and so we re-create the FuDevice, re-probe
the hardware, re-query the quirk database and then return this to the daemon.
In some cases, plugins actually probe the hardware three times (!) by creating
a FuUsbDevice to get the quirks, so that the plugin knows what kind of
superclass to create, which then itself probes the hardware again.
Passing the temporary FuDevice to the plugins means that the simplest ones can
just fu_plugin_device_add() the passed in object, or create a superclass and
incorporate the actual GUsbDevice and all the GUIDs.
This breaks internal plugin API but speeds up startup substantially and deletes
a lot of code.
The setup() is the counterpart to probe(), the difference being the former needs
the device open and the latter does not.
This allows objects that derive from FuDevice, and use FuDeviceLocker to use
open() and close() without worrying about the performance implications of
probing the hardware, i.e. open() now simply opens a file or device.
