Systems with multiple host controllers will most likely have a different
NVM image for each controller but there is no guarantee that the device_id
within the NVM image varies from one controller to another.
To account for this, build a GUID that contains the last element of the
Thunderbolt controller's udev path.
Sample GUID strings from an XPS 9380 (which only contains one host controller):
```
Guid: 0f401ed2-b847-532a-adc8-3193fc737be6 <- TBT-00d408af-native
Guid: 420b0596-f5cb-5fd7-8416-c99d48ad8de9 <- TBT-00d408af-native-0000:05:00.0
```
This commit follows the presumption that the kernel will enumerate the controllers
in the same order every time.
This also lets us remove the call to dfu_device_wait_for_replug() which was
causing a deadlock due to unsafe main context usage. Splitting the code allows
us to use the device list to watch for replug, without adding even more Jabra-
specific plugin code to the DFU plugin.
Looking at this with a 40,000ft view, the Jabra runtime really doesn't have
much in common with DFU and the reason it was originally all lumped together
was that the daemon couldn't "change" plugins between detach and update.
It's unfortunate that we have to include a sleep() in the DFU code after the
DFU probe, but this is specified by Jabra themselves. Attempting to open the
device without waiting reboots the hub back into runtime firmware mode, so we
can't even retry the failing setup action.
It's not usual to open the device from inside the device, otherwise there is a
possibility of a deadlock. For devices without the ->prepare() virtual function
the ->open() should either be a NOP or very fast indeed.
To debug flashing failures it's sometimes requried to get a SPI dump of the
hardware to analysis.
Add a debug-only command that lets us dump the device from the engine.
During startup we do 1898 persistent allocations to load the quirk files, which
equates to ~90kb of RSS. Use libxmlb to create a mmap'able store we can query
with XPath queries at runtime.
We can't use the IOTA mechanism in bootloader mode, and failing to create the
FuSynapromDevice object means we can't recover the hardware if the flash failed.
Some devices don't set the CAN_DOWNLOAD attribute in their runtime descriptor.
Rather than quirk these devices just assume that all DFU devices with a DFU
interface can download in DFU mode. The logic being, why would they expose a
runtime DFU interface if they can't download new firmware in DFU mode...
Devices like the DW1820A that are currently blacklisted because of broken DFU
support will remain blocked with this change.
This makes the daemon less destructive at startup, especially if the ESP
is not mounted.
It's stored in 3 different places right now, so move it into one point of truth.
Now the ESP is detected when needed including all point of time safety checks and
dynamically mounted and unmounted if necessary.
Currently the test runs for 100ms and looks to see that at least 8 times
the poll function callback hit.
This normally works well enough, but during self tests it depends upon
too much timing and leads to failures sometimes:
```
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.189: poll cnt=0
*# DEBUG: poll cnt=1
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.199: poll cnt=1
*** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.209: poll cnt=2
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.227: poll cnt=3
*# DEBUG: poll cnt=4
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.255: poll cnt=4
*# DEBUG: poll cnt=5
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.267: poll cnt=5
Bail out! ERROR:../src/fu-self-test.c:3489:fu_device_poll_func: assertion failed (cnt >= 8): (6 >= 8)
--- stderr ---
**
ERROR:../src/fu-self-test.c:3489:fu_device_poll_func: assertion failed (cnt >= 8): (6 >= 8)
-------
```
Mark this as a slow test so that it doesn't cause CI failures.
Makes `fwupd-refresh.service` strictly opt-in.
Some distros are defaulting to all systemd services on and causing
more refreshes than desirable by default, especially when using
both `gnome-software` and `fwupd-refresh.service`
It appears to only happen on non-dell systems trying to look up system
ID through `sysinfo_get_dell_system_id`
Other than CI non-dell systems won't be running this code.
Detect and parse current coreboot version.
There's no need to depend on libflashrom for now.
An update mechanism isn't implemented as the kernel interface isn't
stable yet and will be implemented in a separate commit.
Tested on coreboot enabled machine.
Example output:
coreboot System Firmware
DeviceId: 81104bde9db7cb037936659ea727c739f47a5029
Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a <- main-system-firmware
Guid: de6fd40f-4ec9-5c0b-95e1-8fb13d1b030c <- LENOVO&ThinkPad T410&2537VG5
Guid: 978b0d18-bfe9-5279-9a9f-68dc247a705f <- LENOVO&ThinkPad T410&LENOVO&2537VG5
Summary: Open Source system boot firmware
Plugin: coreboot
Flags: internal|registered
Vendor: LENOVO
Version: 4.10.991
VersionFormat: triplet
Icon: computer
Created: 2019-10-14
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Allow a plugins to cherry-pick specific HWIDs and add them as InstanceIds.
By adding them as InstanceIds rather than adding them as GUIDs, the
original string can be found in the output generated by:
$ fupdmgr get-devices
Example output:
Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a <- main-system-firmware
Guid: de6fd40f-4ec9-5c0b-95e1-8fb13d1b030c <- LENOVO&ThinkPad T410&2537VG5
Guid: 978b0d18-bfe9-5279-9a9f-68dc247a705f <- LENOVO&ThinkPad T410&LENOVO&2537VG5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
As the plugin is allowed to change print out the entire FuDevice before
performing each step when in verbose mode.
Note, these are only show during update if run with --verbose, not at startup.
