GLib creates two static inline functions for paramaters that may
not be used that set off warnings in clang but not gcc.
Ignore these on clang builds everywhere that
G_DEFINE_AUTOPTR_CLEANUP_FUNC is used.
On Dell dock devices set the FU_DEVICE_METADATA_DELL_DOCK_TYPE metadata
field which gets used by the synapticsmst plugin for recognizing dell
dock types.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
This will be useful in the future for debugging crashes with known
problematic versions of libsmbios.
Also use this information to turn off the blacklist from previously
bad known combinations of libsmbios + certain systems
This makes more sense; we're updating the device, not the plugin itself.
This also means we don't need to funnel everything through callbacks like
GFileProgressCallback and we can also update the state without adding an
explicit callback to each derived device type.
Crashes will happen when UEFI capsule is turned off due to fwupdate
trying to do a SMI request that invalidates the buffer used by fwupd.
This is due to both fwupdate and fwupd using libsmbios in the same process.
Fixes: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1726367
As type-C docks become more common MST controllers in the host are
going to become rarer. This should be a manageable whitelist
and prevent running the SMI on the majority of systems.
This allows us to show the devices in a GUI with a nice icon. Some of the icon
mappings are not perfect and I'll be asking the GNOME designers for some
additions to the icon specification.
Custom vendor icons can also be specified, and /usr/share/fwupd/icons would be
a good place to put them. If vendor icons are used they should show a physical
device with the branding, rather than just the vendor logo.
This reverts commit 257c14ebd1.
Although this is the preferable way to detect Dell systems this was
leading to executing SMI on some systems with problems.
libsmbios has some memory issues that need to be fixed first.
It's been decided that TPM mode switching won't be supported
on any other new platforms. Instead of blacklisting the outliers
whitelist the (smaller) list of platforms that do support the
feature.
Over the months the original meaning of ALLOW_OFFLINE and ALLOW_ONLINE have be
lost, and there is now a confusing mixture of uses in the source tree. With this
commit we make it clear the UPDATABLE flag is used to specify when the device is
updatable (e.g. from the desktop live session, or from the systemd offline
updates mode, or both) and the NEEDS_REBOOT flag lets us know when the update
is actually going to be done.
For instance, a UEFI UpdateCapsule can be *scheduled* from either the desktop
or from the update mode (but the latter would be a bit weird), but does require
a reboot. Some devices might only be updatable outside the live session, for
instance a hard drive update or a GPU update -- there's just too much going on
with a live session and we want to tightly control what's running during the
firmware flash.
This also means we don't have to "retry" the update when scheduling an update
that really can be scheduled whenever, but just requires a reboot to apply.
