We don't have to do this since we started counting the composite devices out
and back in, and relying on the parent being set at a specific instance seems
fragile in real-world testing.
To do this without rebooting the device implement VliUsbhubPdDevice->reload()
like the other FuVliUsbhubDevice child devices.
Fixes half of https://github.com/fwupd/fwupd/issues/2376
The FWUPD_INSTALL_FLAG_FORCE flag has really unclear semantics, and ignoring a
file CRC, checksum or model ID should only be done when using fwupdtool actually
debugging a plugin or firmware parser.
Use the existing --force flag when we want a "gentle nudge" like reuploading
previously processed reports.
This allows us to handle this in the plugin, which might mean detaching the
*proxy* device. It's also very important as a few plugins reboot the device
in ->attach() to get the new firmware version, which isn't required for a dump.
This partially reverts a58510b246 and does the
detach and attach in the few plugins where actually required.
The 721C is a VL103, which isn't a FuVliUsbhubDevice at all. Fixes the:
already set GType to FuVliPdDevice, ignoring FuVliUsbhubDevice
...message when the Mini dock / powered hub is inserted.
Conceptually we were trying to stuff subtly different actions into one vfunc:
* Read firmware from the device to update the verification checksums
* Read a firmware blob from the device for debugging
For the first action we might want to mask out the sections of the flash with
serial numbers (so the verification hashes match the ones published on the LVFS)
and for the second we want just a raw ROM file from the hardware with no
pre-processing that we can compare against an external SPI dumper.
Split out ->dump_firmware to get the raw blob, and allow plugins to also
implement ->read_firmware() if they have to mask out specific offsets or remove
specific images from the FuFirmware container.
In the common case when masking is not required, fall back to using a 'binary'
FuFirmware automatically to make most plugins simpler.
This object derives from FuDevice rather than FuVliDevice and so does not
inherit the NO_GUID_MATCHING flag like other devices.
Fixes https://github.com/fwupd/fwupd/issues/2364
The I²C proxy specification is not always shared with all other devices as
I originally hoped, instead there are other legacy devices that use different
sets of I²C commands.
Un-share various bits of code to allow for additional I²C devices to be added.
No logic changes.
Add two new vfuncs that can be used to collect report metadata from devices
both before and after the update has run. This means we can remove the hacks
where we set add 'global' metadata entries and just hope that there is only one
device from the same plugin that is updated.
This also allows us to collect debugging metadata from devices after an offline
update has been run.
As both hub devices share a FuVliUsbhubDeviceClass instance we cannot 'hijack'
the vfuncs depending on object type. This allows the downstream hub to proxy to
the upstream hub where a GPIOB reset can be performed.
We can have multiple FuVliPdDevice objects registered with the daemon, but they
will all share the FuVliPdDeviceClass instance. If one device requries a
silicon workaround, do not 'hijack' the vfunc for all devices of this type.
This means we do the right thing when updating both the one that requires the
workaround, and the 'normal' one.
The USB 2.0 controller is used as a 'backup' in case the USB 3.0 firmware fails
to start. Set USB 3 hubs as a greater priority so that the USB 2 ones do not
not get added if the USB 3 firmware is working.
