This support was using the wrong commands to add a HWID and thus
never actually functioned. Furthermore it's purpose is to pull
the PID out of the bootloader to be able to properly identify
the device when in bootloader mode (as in recovery mode).
When in this state, generate the correct instance IDs for both
possible Wacom VID. We can't tell which Wacom VID we are in
bootloader mode.
This makes everything simpler, at the expense of not being able to create a
`BootFFFF` entry -- but if we get that far something has already gone very
wrong with the firmware...
Some derivative distributions re-use bootloader paths from their
upstream. When this happens the current logic to look for the `ID`
key in `/etc/os-release` doesn't work properly.
Adjust the logic to:
1) Use `ID`
2) Test the path exists. If so, use it.
3) If it doesn't use `ID_LIKE`.
4) Test if that path exists, if so use it.
5) If that path doesn't exist, return the key from `ID`
6) The plugin will make this path.
This fixes a regression introduced by 2031ce3bf6
that leads to:
```
USB error on device 2dc8:5750 : No such device (it may have been disconnected) [-4]
```
The GNU gold linker uses the section name `.rela.dyn` instead of
`.rela` for containing the relocation information. If this section
is not copied the EFI executable can crash.
Fixes#1530
In an error block that checks for `NULL` sysfs, you will always see
`(null)` in the string.
```
FuPluginThunderbolt Unable to read generation: failed get id generation for (null)
```
This device was showing up from a LG 38UC99-W USB-C monitor
```
VMM0000:
Device ID: d762543f8c20f636e6fff031a000078d3e10c600
Summary: Multi-Stream Transport Device
Current version: 0.00.000
Vendor: Synaptics
GUIDs: 42addef4-40f9-5e89-b925-d564e35ed368 ← MST-(null)-vmm0000-0
cf8c03c5-18bf-53c4-971f-4a08f88932b5 ← MST-(null)-0
e9427b6a-7389-5461-a592-1da5f8ec99fd ← MST-(null)
Device Flags: • Updatable
```
```
failed to close device: Bad file descriptor
```
fu-udev-device will open a locker automatically now.
However synaptics-rmi closes the file descriptor on it's own with `g_clear_object`.
So destroy the fd in synaptics-rmi.
Set `IS_BOOTLOADER` unconditionally when in fastboot mode. This seems logically
what it is; a degraded mode that's able to update firmware without runtime
functionality.
Fixes https://github.com/fwupd/fwupd/issues/1532
This allows us to do three things:
* Fuzz the loader with `fwupdtool firmware-parse`
* Check the firmware *before* the hardware is put into bootloader mode
* Use FuChunk to build the 32 byte payload chunks
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.
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.
