This allows delaying the activation of Thunderbolt firmware until
shutdown/reboot or when the dock is unplugged.
This functionality requires features in the kernel:
https://lore.kernel.org/linux-usb/20200622143035.25327-1-mario.limonciello@dell.com/T/#t
Matrix of cases to support:
* Distro Old Linux kernel (doesn't support authenticate on disconnect)
- WD19TB: Should have `skips-restart` flag set
No flush or activate features called in `thunderbolt` plugin.
`dell_dock` plugin will activate at end of composite update
- All other devices: Shouldn't have flags set
Should authenticate in Thunderbolt plugin.
`1 > nvm_authenticate`
* Distro New Linux kernel (supports authenticate on disconnect)
- WD19TB: Should have `usable-during-update` flag set but not `skips-restart`
Should flush image to SPI in `thunderbolt` plugin
`2 > nvm_authenticate_on_disconnect`
Should configure TBT device for authenticate on disconnect
`1 > nvm_authenticate_on_disconnect`
`dell_dock` plugin will configure dock for authenticate on disconnect
- All other devices: Shouldn't have flags set
Should authenticate in `thunderbolt` plugin.
`1 > nvm_authenticate`
* ChromeOS (supports authenticate on disconnect)
- `thunerbolt.conf` will have `DelayedActivation=true`.
- WD19TB: Should have `usable-during-update` flag set but not `skips-restart`
Should flush image to SPI in `thunderbolt` plugin
`2 > nvm_authenticate_on_disconnect`
Should configure device for authenticate on disconnect
`1 > nvm_authenticate_on_disconnect`
`dell_dock` plugin will configure dock for authenticate on disconnect
- All other devices: Should have both `usable-during-update` and `skips-restart` set
Should flush image to SPI in `thunderbolt` plugin
`2 > nvm_authenticate`
Will activate upon logout/shutdown/reboot
`1 > nvm_authenticate`
This plugin is only enabled when coreboot isn't detected.
It intentionally does not check for EFI to be disabled at startup
since it can also notify the user that UEFI capsule updates are
disabled on the system even if running in UEFI mode.
fmap is a Google flash layout format that is used in several of Google's
firmware projects, including Chrome OS Embedded Controller and the Chrome OS
coreboot firmwares. Introduce it as a firmware format in libfwupdplugin.
Unfortunately module type has more than I previously realized.
The meanings that previously were applied fortunately worked for
the most important case (130-180W TBT) but didn't for single C, dual
C or small power (45W) cases.
Since composite_prepare was trying to read and interpret these, it
causes failures when these other ones are encountered.
I reproduced this on a 130W adapter plugged into a single C (type 0x4).
This meant the update wouldn't install since NULL was returned for the
type.
In case a new module ID is added later, also return an "unknown" for
the metadata.
Force the FuDevice parent to have the largest of the child removal delays.
This avoids each plugin enumerating the children (which may not even be added
yet) to increase the length of the allowed parent delay.
Add two new vfuncs that can be used to collect report metadata from devices
both before and after the update has run. This means we can remove the hacks
where we set add 'global' metadata entries and just hope that there is only one
device from the same plugin that is updated.
This also allows us to collect debugging metadata from devices after an offline
update has been run.
