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.
The plugin currently supports Fastboot and QMI/PDC methods, but given
that QMI/PDC is exclusively used for carrier config installations,
there is no need for QMI/PDC-only updates, so make sure that
combination is right away forbidden.
This validation will also be useful when adding additional update
methods, as we'll be able to clearly specify which are the
combinations expcted.
The upgrade process requires that the USB interface layout is not
changed between upgrades, something that we require for AT and we also
require now for QMI. We store the USB interface number of the QMI port
as soon as the device is probed, and we use it to match the interface
number once the Udev based device is created.
squash! modem-manager: make sure the correct interface number is used for QMI
The built-in udev monitoring in the ModemManager plugin is only
required for those upgrade methods where the device switches into a
fully different port/interface layout. So far, we only expect this to
happen when the Fastboot update method is requested by the module.
The GUdevClient is created when the ModemManager sysfs path is
inhibited; we need to make sure we destroy the object once
uninhibited, or we'll otherwise create a new one if we're running
an additional upgrade operation afterwards.
This reverts commit b5eddee5f6.
Using pci function 0 works on my Lenovo P50 but not my Lenovo X1. Don't break
machines where we are shipping the chip rather than ones where we probably are
not, especially when it's probably a kernel bug somewhere.
Fixes https://github.com/fwupd/fwupd/issues/2608
The former drags on glib-networking and then gsettings-desktop-schemas, which
add over 5Mb to the minimal IoT and CoreOS composes. Everything already uses
libcurl (even NetworkManager!) and so this is an easy way to reduce image size.
