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.
Before:
$ fwupdmgr install XPS_test.cab
Retrying as an offline update...
Scheduling… UEFI firmware update failed: -1
After:
$ fwupdmgr install XPS_test.cab
Retrying as an offline update...
Scheduling… UEFI firmware update failed: libfwup.c:733 get_paths(): could not find shim or fwup on ESP: No such file or directory
As found in https://github.com/dell/libsmbios/pull/13
there are some errors with libsmbios error paths.
These need to be fixed in libsmbios, but at least avoid
running this code on those systems (and crashing fwupd).
Tracking a single smi object in the plugindata is more similar
to how other plugins operate and also allows moving FuPluginData
out of fu-dell-common, making fu-dell-tool less hacky and letting
other plugins use fu-dell-common as needed.
It now supports enabling things for other plugins too, so rather
mark any devices created by Dell as only readable, not flashable
when UEFI capsule is off.
The linker does not know which public symbol to call if a plugin calls it's own
symbol. Without this change one plugin could call into another plugin with the
wrong GsPluginData set.
Remove the dummy devices created for NVM and MST, these will
be created by other plugins. Other plugins will however
be using the Dell methods to enable these devices.
This is a large commit that removes all the providers and turns them into
plugins. I think having both providers _and_ plugins was super confusing.
Plugins are loaded at runtime so you could in theory develop a new plugin
without putting it in the fwupd source tree, although there are no installed
headers or PC files as I'm not sure it's a good idea at this stage.
This commit moves all the per-provider docs, tests, notes, debug dumps and test
data to plugin-specific directories -- these also allows the plugin author to
"own" more of the source tree so we don't enforce fu- prefixes and the style
guide everywhere.
This allows us to run the same action on all the plugins in the future, so we
could have a prepare(FuPlugin, FuDevice) and cleanup(FuPlugin, FuDevice) run
on *all* plugins, so doing an update using one plugin would allow us to work
around hardware quirks in other plugins.
If I've broken your out-of-tree provider it's trivial to port to the new API
with sed and a fixed up build file. If you need help please let me know.
