This allows us to ignore all the delays when the device is emulated, with the
idea being to do dozens of device emulations in the CI tests.
Also, do not call fu_progress_sleep() when the device is emulated.
It turns out we do not want to know the current phase of the device, and we can
achieve the same thing tagging the GUsbDevice manually and clearing the events
at exactly the correct time.
This refactors the code as it was getting very confusing; before FuSmbios was
reading both SMBIOS and the kernel-provided DT -- and various things were
injecting overrides in three different place. To properly support FDT remove
one layer of indirection.
This also lets us use the compatible strings to enable plugins specifying the
flag _REQUIRE_HWID -- which means we only load the plugin if it's got a chance
of working. e.g.
[aspeed,ast2500]
This is needed because multiple plugins will soon be consuming the system FDT,
and we don't want to either parse this multiple times, or duplicate the loading
logic.
This will eventually allow us to reconstruct a SBoM using a UEFI file volume.
This can be used like this `fwupdtool firmware-parse efi/fwupdx64.efi pefile`
to produce:
<firmware gtype="FuPefileFirmware">
<data size="0xef59">MZ.</data>
<firmware>
<id>.text</id>
<offset>0x2d0</offset>
<size>0x7bab</size>
<data size="0x7bab">H...QRH.=....H.5</data>
</firmware>
...
<firmware gtype="FuCoswidFirmware">
<id>fwupd-efi:fwupdx64</id>
<idx>0x7</idx>
<version>1.4</version>
<offset>0xc4e0</offset>
<size>0xce</size>
<data size="0xce">..een-US</data>
<version_scheme>semver</version_scheme>
<product>fwupdx64</product>
<summary>EFI helpers to install system firmware</summary>
<colloquial_version>1.3-7-g881a508</colloquial_version>
<link>
<href>https://spdx.org/licenses/LGPL-2.0.html</href>
<rel>license</rel>
</link>
<entity>
<name>Richard Hughes</name>
<regid>hughsie.com</regid>
<role>maintainer</role>
<role>tag-creator</role>
</entity>
</firmware>
</firmware>
In various places the code was checking if a release was set, but this would
always be false as the release was being auto-created. This was masking valid
bugs, and was confusing to have the superclass have different semantics to the
baseclass.
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.
Only build libfwupdplugin source files once; we were only using one
non-exported symbol and so move that to the exported map so we can just link
the library in the self tests.
We now have two plugins getting the ESP values, and we only allow hardcoding
the ESP in uefi_capsule.conf.
Make all this a lot simpler by moving the ESP+BDP code to `FuContext`, which
also means we can handle the override (via the config file) in the engine,
and the override (in the command line tools) using the same mechanism.
Also, automate the migration of the `OverrideESPMountPoint` -> `EspLocation`
when loading the engine.
Fixes https://github.com/fwupd/fwupd/issues/5042
This allows the backend to identify the specific device for a specific phase.
For instance, there might be a pre-update runtime, a bootloader and a
post-update runtime and allowing tags to be saved to the backend object allows
us to identify each version of the same physical device.
This takes us one step closer to emulating a complete byte-perfect end-to-end
update without actual hardware installed.
This feature adds support for platform capability BOS descriptors which allows
the device itself to ship quirk data.
Use `sudo fwupdtool get-devices --save-backends=FILENAME` to save fake backend
devices to a file. This allows easy creation of self tests that do not require
physical hardware.
This is being used for other products, e.g. USB4 docks.
If non-Intel firmware is being used (e.g. ASMedia) then the explicit
calls to `fu_intel_thunderbolt_nvm_new()` can be changed to something
like `fu_firmware_new_from_gtypes()` with all the formats listed.
A user can place a JSON file in /etc/fwupd/bios-settings.d/ with
the default desired policy for the machine.
fwupd will load this policy on startup to ensure BIOS settings
are set as desired by the system administrator.
These are currently used interchangeably since there was indecisiveness
which to use as the feature was being developed.
As outward facing it will be named with "settings", change all uses
in the code to match this.
Semantically it is the desire of the security attribute, not the bios
attribute, i.e. you could imagine that a specific attribute would have
to be *foo or bar or baz* for HSI-1 and *only foo* for HSI-2
Also make it easier to add possible BIOS attribute target values in
plugin code.
This identifier can be used by plugins or the daemon to disambiguate
behavior between two different drivers.
Set it up so that plugins don't NEED to use it, but optionally can
find attributes by either name or ID
