Intel Arc products do not require the host CSME to update Arc firmware.
Firmware updates will work on both AMD and Intel platforms.
Arc products have their own Graphics Security Control for firmware updates and
leverage existing Intel technology like the MEI interface protocol to implement
the firmware update flow.
Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
The use-runtime-version flag was initially used with the Intuos
Pro Small (2nd-gen USB v2) to force the use of the legacy code
path. The legacy code path was required because of a bug in the
identification of the Bluetooth (I6) firmware.
It has been decided that the bug will be fixed before any fimware
changes are released, removing the need to use the legacy code path.
Recently we had an update that changed the system-defined Platform Key, and
we've certainly had updates in the past that changed the Boot#### variables.
Store some core ACPI and UEFI system integrity state from before and after the
update which can be used to mark (waivable) test failures on the LVFS.
* plugins/{flashrom,superio]: Add GUIDs for StarBook Mk VI - Intel
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
* plugins/{flashrom,superio]: Add GUIDs for StarBook Mk VI - AMD
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
* plugins/{flashrom,superio]: Add GUIDs for Byte Mk I - AMD
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
The fu_context_get_smbios_data() call will not work when creating the plugin
GType, so just create the SMI object when it is needed in ->startup().
Fixes https://github.com/fwupd/firmware-dell/issues/144
This does not serve much purpose now, but would be useful if we need to know
more about the installed PK from other plugins. If nothing else it makes the
`--verbose` output more helpful.
This allows us to be more specific when matching devices, and also means we get
more attributes 'for free' from the FuUdevDevice->probe().
This would allow us to have multiple device GTypes handling multiple MEI
interfaces in the same plugin., for instance, PTHI and MKHI.
The slight fly in the ointment is that the kernel does not set the 'dev' for
the mei_me devices, but it's always going to be just /dev/mei0, so hardcode it.
fwupd does not know if the firmware is signed or unsigned unless
the Quectel secureboot commands set this flag. Assume that the firmware
is unsigned by default, which is the case for most firmware unless they
have they support the secureboot AT commands. If that's the case, the
right flag will be set anyway.
The daemon wants to auto-add the parent relationship from the analogix device
to the VLI device automatically, which is arguably more correct anyway.
No behaviour change, but the tree output in fwupdmgr will be reversed now.
A harmless error shows up in debian packages at build time:
```
dpkg-shlibdeps: warning: cannot find library libfwupdplugin.so needed by debian/fwupd/usr/lib/x86_64-linux-gnu/fwupd-1.8.6/libfu_plugin_flashrom.so (ELF format: 'elf64-x86-64' abi: '0201003e00000000'; RPATH: '')
```
This doesn't cause a functional problem because libfwupdplugin has already
been loaded by the daemon by the time these libraries are loaded.
In case the `dpkg-shlibdeps` checker becomes more stringent in the future
fix the warning.
