The unifying version numbers are of the form 'RQR24.00_B0000' which means we
have to force the plugin to 'plain' version format to avoid stripping out the
non-semver chars.
Fixes https://github.com/hughsie/fwupd/issues/1018
The udev plugin is somewhat special as it uses a non-subclassed FuDevice that
never gets 'opened'.
This means that we never automatically call fu_device_setup() and thus the
instance IDs are not converted into GUIDs before the device is added.
The checksum is now stored as the very last flash descriptor, so we need to pad
the SREC data to include the 'missing' data range. As we're doing that, we
should optimize like the Wacom updater does and skip writing descriptors that
are unused.
This also allows us to write mixed-endian structures and adds tests. As part of
this commit we've also changed the API of something that's not yet been in any
tarball release, so no pitchforks please.
This allows hardware from OEMs to *not* match generic firmware supplied by the
device manufacturer. The idea being, that the OEM will supply firmware that
will actually work on the device.
Based on a patch from Mario Limonciello, many thanks.
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.
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.
