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
For fuzzing we want to exclude libcurl support as it depends on other very heavy
libraries like OpenSSL or libtasn which make the fuzzing binary much larger if
linked statically.
This is probably a case where the device does not adhere to the specification.
Some hardware may be deliberately setting DNLOAD timeout to 0ms, and this patch
will make each request 5ms slower. This is probably a good tradeoff for having
most hardware 'just work' without a quirk entry.
Based on a patch by Zack Lee Yi Wei <zack_lee@chicony.com>, many thanks.
This has better multi-core performance and can run in persistent mode -- which
allows us to construct a test harness of all the parsers (which takes time) and
then just reuse the process for lots of different data.
These are expected to be flashed via UEFI capsules *not* Thunderbolt plugin
* Flashing via fwupd will require matching kernel work.
* They're left here only for parsing the binaries
```
FuThunderboltFirmwareUpdate:
Family: Maple Ridge
IsHost: true
IsNative: true
DeviceId: 0x1136
VendorId: 0xd4
ModelId: 0xa58
FlashSize: 0x0
Generation: 0x4
Ports: 0x2
HasPd: true
Section0: 0x4000
Section1: 0x4210
Section2: 0x4610
Section3: 0x22958
FuFirmwareImage:
Data: 0x67000
```
This is a safer version of g_bytes_new_from_bytes() which returns a GError
if the offsets are invalid rather than emitting a critical warning.
This prevents a critical warning and potential crash when parsing invalid
bcm57xx firmware.
Some vendors really really want 1.5.x in newer RHEL versions, but the version
of curl is too old. Add #ifdefs so that we can emulate (somewhat imperfectly)
the 'new' CURLU functonality.
I'm finally getting around to figuring out why I get occasional hard hangs after changing from a spidle to SSD. I've disabled fwupd in the meantime to see if it makes a difference. Adding the info since I don't see it already on the list.
