Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
On Alterlake and newer hardware the Platform Health Assessment Record
data can be used by the IHV to debug why a specific capsule update
failed. Any custom firmware loaded by the OEM can be identified and
used to further debug the root cause.
The call to g_proxy_resolver_get_default() is (transfer none) and so unref'ing
it causes GLib to get very upset. Also, move it to be per-FwupdClient rather
than per-request as it can be expensive to call in the PAC-runner case.
Add the IFD regions as child devices and set the region access on the child
devices. Also add read-only SPI descriptor as an HSI attribute and require
FLOCKDN on Intel hardware.
Use the hidden PCI 00:1f.5 device to set the SPIBAR automatically and generate
the quirk file automatically to support more hardware.
At the moment plugins are doing this a few different ways; either looping
through the HwIds manually (e.g. flashrom) or setting a custom flag that is
checked in fu_plugin_setup (e.g. uefi-recovery).
Define a standard 'Plugin' HwId quirk to simplify plugins.
Devices may want to support more than one protocol, and for some devices
(e.g. Unifying peripherals stuck in bootloader mode) you might not even be able
to query for the correct protocol anyway.
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!
Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.
This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.
This removes the workaround added in 99eb3f06b6.
Fixes https://github.com/fwupd/fwupd/issues/2915
Only a small amount of the firmware on the LVFS will be available. The user
can use --ipfs on the command line for testing, or change the system-wide
default in /etc/fwupd/daemon.conf.
The IPFS daemon and command line client will need to be installed manually.
The docs for `fwupd_device_get_children()` make it very clear that only the
parent should be assigned. Also add a warning to `fwupd_device_add_child()`
explaining it is for internal daemon use only.
We forgot to include FwupdClientDownloadFlags when adding the original method
fwupd_client_install_release() -- and we want to use additional download flags
for operations in the future.
