There was some regression between 1.4.0 and now that prevented updates
containing a Thunderbolt controller from finishing. They would just
sit pending Thunderbolt replug without ever finishing.
Remove the old hack for replug and instead push activation to the end
of the composite steps.
This is to avoid the device tree from changing significantly during
the update process.
This still isn't really ideal, we want to be able to add the flag
usable-during-update to the thunderbolt controller, but this requires
some extra work in the kernel.
Thunderbolt images brought in from the SPI don't have a FARB header.
Thunderbolt update images do.
So these two types of images need to be handled separately from the
firmware parser.
We're planning to ship fwupd 1.4.x in RHEL 8 and so it makes sense to have a
stable branch to do point releases. I don't intend to release versions 1.5.x
any time soon, so moderately-agressive backporting to 1_4_X is okay.
The kernel interface for force power doesn't support tracking the state
of the device, and so this had to be tracked by fwupd.
Unfortunately due to system and thunderbolt controller firmware behavior
on some systems the thunderbolt controller /still/ didn't return even
when force power state was accurately tracked.
The device model for the uevent related to the device removal being ignored
doesn't really fit into the current fwupd architecture anymore either.
Lastly this is a very legacy feature at this point. Thunderbolt3 controllers
distributed in the last 3 years all operate in 'native' mode meaning that
they will always be powered and use runtime power management.
USB4 controllers won't have a concept of being force powered.
USB4 reimers will have this concept, but the state will be tracked by the
kernel and obfuscated from userspace.
So with all that said, tear out all of the force power related code.
Remove it's references to it's own GUdevclient and instead use
FuUdevDevice.
Some intentional casualties of the move:
* Plugin metadata around native and safe mode dropped.
- These haven't been useful in debugging anything and aren't relevant
on new hardware
* Extra GUID for 2 host controllers in same system dropped
- Although this was normally static information BIOS operations like
turning off PCI-E SD card reader or LAN controller changed things.
* The NVM version is parsed directly instead of through gudev to prevent
cached data breaking change events.
Remaining TODO:
* Force power w/ thunderbolt-power doesn't work
USB4 Controllers were showing up like this:
USB4 Controller:
Device ID: 3df660bc4bdb67fd6fc101b34c6fd8cd235e3f97
Summary: Unmatched performance for high-speed I/O
Current version: 00.00
Update Error: Device is in safe mode
GUID: 4d86f168-e1cc-5995-afd3-ae9df6a14f5e -> TBT-safemode
Device Flags: Internal device
Requires AC power
The returned ID is the result of the SHA1 hash of the actual device ID. This
does not match anything found by the client, and so the install fails.
The symbol is exported as I think the device ID is an important identifier and
used in various fwupd tools.
When backported to the stable branch the verification should just be a static
function in src/fu-engine.c rather than a new symbol.
It is a good practice to install files relative to our own variables
https://www.bassi.io/articles/2018/03/15/pkg-config-and-paths/
and it is required on systems like NixOS.
Unfortunately, systemd allows overriding the root prefix,
see also 1c2c7c6cb3,
so we cannot just do that.
Let's at least make the systemd installation prefix overridable.
This will also allow us to drop `systemdsystemunitdir` option since
systemd hardcodes it to `${rootprefix}/lib/systemd/system`.
