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.
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.
Per discussion of #2513, Ubuntu Core was going to use UEFI removable
path as default esp path, and it needs to change some parts around
getting the esp path and searching the shim app path. Also, a new option
"FallbacktoRemovablePath" is added into uefi.conf to be applied in this
case, and it will be false by default.
On failure, you get this:
no device found on drm_dp_aux5: Memory query failed: failed to write command
failed to get device after update: failed to wait for detach replug
This is not complete enough for LVFS-usage, but good enough to use with commands
such as fwupdtool. It's likely newer kbd and tp firmware will be required to
integrate with the fwupd in all required ways.
The PCI Vendor and Device ID locations located in firmware were mistakenly
swapped in the bcm5719-fw repository. As a result, the code here based on said
repository also has swapped IDs. This fixes the ids to reflect the
correct locations.
Signed-off-by: Evan Lojewski <github@meklort.com>
Before:
Information for the update status entry 0:
Information Version: 7
Firmware GUID: {ddc0ee61-e7f0-4e7d-acc5-c070a398838e}
Capsule Flags: 0x00000000x
Hardware Instance: 0
Update Status: attempted
Capsule File Path: /EFI/fedora/fw/fwupd-ddc0ee61-e7f0-4e7d-acc5-c070a398838e.cap
failed: Error opening file /sys/firmware/efi/efivars/fwupd-671d19d0-43c-
4852-98d9-1ce16f9967e4-0-0abba7dc-e516-4167-bbf5-4d9d1c739416: No such file
or directory
failed: Error opening file /sys/firmware/efi/efivars/fwupd-a9971959-9246-
4a5b-b2f2-ba6fdcb19349-0-0abba7dc-e516-4167-bbf5-4d9d1c739416: No such file
or directory
After:
Information for the update status entry 0:
Information Version: 7
Firmware GUID: {ddc0ee61-e7f0-4e7d-acc5-c070a398838e}
Capsule Flags: 0x00000000x
Hardware Instance: 0
Update Status: attempted
Capsule File Path: /EFI/fedora/fw/fwupd-ddc0ee61-e7f0-4e7d-acc5-c070a398838e.cap
Information for the update status entry 1:
Firmware GUID: {671d19d0-d43c-4852-98d9-1ce16f9967e4}
Update Status: No update info found
Information for the update status entry 2:
Firmware GUID: {a9971959-9246-4a5b-b2f2-ba6fdcb19349}
Update Status: No update info found
Fixes https://github.com/fwupd/fwupd/issues/2530
Although hotpluggging PCIe cards isn't common, it's how I'm testing this in the
device test enclosure. Add a tiny delay to wait for the kernel to populate the
net class on hotplug.
Unconditionally delete FWUPDATE_VERBOSE and FWUPDATE_DEBUG_LOG when deploying
the update using fwupdtool or fwupd and leave it to fwupdate.
If you want to debug the efi binary you then have to use fwupdate and squirt
the .cap file rather than using all the other layers.
Upon restarting the upstream VLI USB hub the cxaudio device re-enumerated okay
but would not service HID requests for 100ms, returning 'endpoint stalled'.
To make this more reliable retry the SetRequest up to 10 times after a short
delay to make enumeration reliable.
The GLib g_byte_array_set_size() function does not zero the contents if the
array size is larger, which leads to unpredictable output when using valgrind.
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
