The CustomFlags feature is a bit of a hack where we just join the flags
and store in the device metadata section as a string. This makes it
inefficient to check if just one flag exists as we have to split the
string to a temporary array each time.
Rather than adding to the hack by splitting, appending (if not exists)
then joining again, store the flags in the plugin privdata directly.
This allows us to support negating custom properties (e.g. ~hint) and
also allows quirks to append custom values without duplicating them on
each GUID match, e.g.
[USB\VID_17EF&PID_307F]
Plugin = customflag1
[USB\VID_17EF&PID_307F&HUB_0002]
Flags = customflag2
...would result in customflag1,customflag2 which is the same as you'd
get from an enumerated device flag doing the same thing.
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.
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
This allows a device subclass to call the parent method after doing an initial
action, or even deliberately not call the *generic* parent method at all.
It also simplifies the plugins; you no longer have to remember what the plugin
is deriving from and accidentally clobber the wrong superclass method.
At the moment FuChunks are sometimes mutable, and sometimes immutable, and it's
all a bit too low level for comfort.
Before we can do any kind of optimisation or verification we need plugins to
stop reading directly from the C structure. The aim here is to make FuChunk
optionally mutable without making assumptions about the memory model, and also
to be able to introspect it for the docs.
That giant uint64_t isn't looking so big now, and we'll want to add even more
to it in the future. Split out some private flags that are never useful to the
client, although the #defines will have to remain until we break API again.
Print the sysfs path for devices deriving from FuUdevDevice, which also allows
us to use FU_UDEV_DEVICE_DEBUG without monkey-patching the plugins that also
define a device_class->to_string() vfunc.
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).
