Similar to NVME, ATA drives distributed by Dell have special values
that should be used to designate fwupd GUIDs and only run correct
firmware.
When detecting Dell GUIDs remove the standard fwupd GUIDs. "Generic"
firmware targeted to those GUIDs will fail to install.
Replace the non-breaking space with a traditional space rather than changing
the expected output with #ifdef to allow running the tests with a daemon
compiled against an older glib2 version.
Two new arguments added to fwupdtool: `--prepare` and `--cleanup`
They are used only with the `install-blob` command
This makes sure that devices can get rebooted in dell-dock even if using
fwupdtool to install a single blob.
Signed-off-by: Richard Hughes <richard@hughsie.com>
During download and activation we have to reset the drive to apply the new
firmware. If the kernel gets an unexpected ATA reset then it might panic.
Default to activating the command on the next drive power-up to be safe.
Many thanks to the Dell storage team for the advice.
A device that has gone through a fastboot update may need more than
the previous default of 10s to come back up. Just use a much longer
value to make sure it's detected properly.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Splitting the file into lines does increase memory usage, but allows us to use
a much simpler parser design. This is just like we fixed IHEX a few weeks ago.
Some hardware from Lenovo deduplicates UEFI Boot entries, and uses the old
string 'Linux-Firmware-Updater' to avoid removing the firmware update entry.
Although this is forbidden in the UEFI specification we shouldn't break
firmware updates from old firmware versions.
Provide a quirk for this, and automatically whitelist anything with the LENOVO
SMBIOS Manufacturer.
This behavior will prevent the dock from performing most resets until
it has been unplugged from a host system.
This significantly speeds up the perceived update duaration and prevents
data loss during update.
It's not confirmed whether EC23 or later EC will enable it.
* So only enable by a custom flag until this is confirmed.
* Custom flag will be dropped when included into stable EC release.
This functionality also relies upon the CAB file providing a message warning
user that the dock might not be usable after unplugging for up to 1 minute.
The idea is that if the user should know something about the device update
"after" it's succesfully completed then the plugin can set `UpdateMessage`
for the device and a client can show it.
An example would be a device that doesn't reboot on its own and the user
needs to power cycle it manually.
