For some Poly USB Cameras, it takes a longer time than the
default (FU_DEVICE_REMOVE_DELAY_RE_ENUMERATE) for being detached
to DFU or attached to normal mode. Need to specify the timeout in
"RemoveDelay" quirk key.
Also replace the hard-coded timeout with fu_device_get_remove_delay()
in dfu-tool.c.
Some devices may accumulate the firmware image and perform the
entire reprogramming operation at one time. In this case, the
device enters dfuMANIFEST-SYNC or dfuMANIFEST state after
dfuDNLOAD-IDLE.
The fwupd shall be able to poll the status from the device via
DFU_GETSTATUS until the device completes the reprogramming or
reports an error.
For details, please refer to Section 7. Manifestation Phase and
A.1 Interface State Transition Diagram in the USB DFU protocol.
https://www.usb.org/sites/default/files/DFU_1.1.pdf
For not affecting the other DFU capable devices, introduce a quirk
"manifest-poll" to limit the logic.
systemd 246 replaced the variable names (4908de44b0).
The old ones are kept for backwards compatibility but some of them interpolate new variable names so redefining them breaks.
Curiously, only systemdshutdowndir is affected by that here.
The nr_chunks is defined as an unsigned short, the max value is
65536. Assume the transfer_size reported by device is 4096, the
maximum size of DFU firmware supported is 65536 * 4096 = 256MB.
To support larger DFU firmware, we can change the guint16 to
guint32.
This implements the following simple state machine:
1. Reboot to RO, Update RW first, set ANOTHER_WRITE_REQUIRED
2. Second time around, don't reboot into RO. Stay in RW.
3. Update RO.
4. Done.
Newer version of libgusb has g_usb_device_get_configuration_index which
will be used by cros-ec plugin.
Skip bumping this dependency on Debian and Ubuntu as of this commit date,
they don't know about 0.3.5 yet.
This prevents carrying hacks in the packaging specific to CI things
that will never actually land in Debian.
This will keep CI availability high while new packages are not yet
actually landed into Debian.
Only add instance ID if it actually probes properly.
Otherwise this makes an invalid assumption that the device is a WD19
EC just because it had the correct hub in front.
Instead check the first time it's opened that the correct device
is identified (`EXPECTED_DOCK_TYPE`)
This is much more efficient than parsing hundreds of lines of /proc/cpuinfo
and also causes hundreds of thousands less allocations at startup. For systems
with dozens of virtual CPUs the deduplication of device objects was increasing
start up time considerably.
Use the msr plugin to read the microcode version as this is not obtained using
CPUID, as it is instead being provided in an MSR.
To do this mount all ESP partitions and check all the binaries there to see if
they match any entries in the new dbx. If we applied the update when a hash
matched, we would unintentially 'brick' the users machine, as the grub and shim
binaries *have* to be updated first.
This functionality does reimplement the PE hashing functionality found in
sbsigntools and pesign. This was done for 4 main reasons:
* There were some memory safety issues found when fuzzing random binaries
* Executing the tools hundreds of times was a lot of overhead
* Operating from a blob of immutable mmap'd memory is much faster
* We only need a very small amount of functionality from both tools
