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.
If we're creating the child device using `Children=FuFooDevice|FOO&I2C_01` in
the quirk file then there's not actually anywhere to call FuDevice->setup()
on the child.
The logical place to do it is when we setup the parent, which is a NOP if
already called for the child. We also don't need to convert the child instance
IDs as it's already being handled during the child setup.
Tested-By: Ricky Wu <ricky_wu@realtek.com>
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>
This is really useful when working out HwId quirk values for remote systems.
fwupdtool export-hwids target.hwids
vim target.hwids
fwupdtool hwids target.hwids
We only convert the instance IDs to GUID after setup() has been called, which
means if we add even more instance IDs to the device in functions like
fu_plugin_device_registered() they never actually get converted to the GUID
form too.
It is impossible to choose a static default that is appropriate for both a tiny
ARM IoT device and a giant Xeon server.
Fixes https://github.com/fwupd/fwupd/issues/2760
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.
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.
The Thunderbolt plugin wasn't actually working properly for
`DelayedActivation` because Thunderbolt devices weren't actually registered.
This only affected ChromeOS.
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 fprint daemon only keeps the device open for 5 seconds and then releases it,
which seems like a small window to hit.
But! We're asking the user to authenticate with the same device we're about to
upgrade so a different part of the stack woke up the hardware just before we're
about to deploy an update onto it.
Just retry a few times to make sure the device is idle. Use a flag to prevent
accidentally causing regressions in other plugins.
Fixes https://github.com/fwupd/fwupd/issues/2650
