As a consequence, the version number is also set in the event that the silicon
or firmware app-id is not set, which also seems like the right thing to do.
The idea here is that the device would not come back after it was restarted,
and skipping the attach in the engine was only working around the fact that the
ebitdo did not split out an ->attach() function.
We can't really blame it; we only decoupled the _IS_BOOTLOADER requirement
for ->attach() recently...
The USB 2.0 controller is used as a 'backup' in case the USB 3.0 firmware fails
to start. Set USB 3 hubs as a greater priority so that the USB 2 ones do not
not get added if the USB 3 firmware is working.
These are a regression of 9e755e2a5 when devices are asleep.
However due to the current kernel and daemon architecture, logitech devices
are not checked again at any time so if the device isn't awake when
fwupd is started or the unifying dongle is plugged in it won't be present.
This will be changed in the future when the kernel has change events
associated with devices waking up.
Fixes: #1973
This also means we do the right thing when plugins call fu_device_add_flag()
directly, instead of just from a quirk file.
For instance, now `Flags = ~updatable` is a valid and useful thing to have and
allows us to remove the `Flags = None` hack.
This is nice in theory, until you need to look at the bootloader status of the
parent, or of a different device entirely. Handle this in plugins for the few
cases we care about and stop setting or clearing IS_BOOTLOADER manually just to
get the vfuncs to be run.
Note: I do not think we want to use cleanup() for attaching devices not in
bootloader states -- as cleanup is only run at the end of the composite update.
Doing this unconditionally means we accidentally 'bleed' one device mode into
another in a non-obvious way. For instance, a device might have two operating
modes with different GUIDs. If firmware is supplied for both modes in the same
cabinet archive then we might accidentally match the 'wrong' firmware when
the daemon has observed a mode switch and added the counterpart GUIDs.
We only really need the counterpart GUIDs when switching between Jabra, 8bitdo
and DFU devices where the DFU bootloader VID:PID is not manually tagged with
`CounterpartGuid` in a quirk file. In the general case lets keep it simple to
avoid difficult to find bugs.
The cleanup action for the FuVliUsbhubPdDevice is correct, but was not
conditionalized in the composite cleanup, which meant we would reboot twice
for a normal USB hub update.
Move the parent reboot into the right place, although this does mean we might
reboot twice in the rare event of scheduing a FuVliUsbhubPdDevice *and*
FuVliUsbhubDevice update in the same transaction -- but resetting the device
state between updates is arguably correct anyway...
