We go to great pains to set the parent to the MAX of the child delays, but we
don't actually set the children to have the new parent value.
This means if you update the child device without the parent in the transaction
we don't always wait for all the USB devices to come back -- which is what the
acquiesce delay is designed to do.
Fixes an intermittant device test for the Wacom USB tablet.
The SMBIOS specification says:
Maximum size of SMBIOS Structure Table, pointed to by the
Structure Table Address, in bytes. The actual size is guaranteed
to be less or equal to the maximum size.
So, the firmware is actually allowed to return a DMI blob smaller than the
specified size.
Fixes https://github.com/fwupd/fwupd/issues/5486
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.
If the device does not replug, and we change the GUsbDevice because the phase
changed we don't want reprobe the hardware.
If we reprobe then the emulated device will request extra data compared to the
real device, which will cause emulation to fail.
This can save 250us on each query (of which we do a *lot*), and reduces the
number of queries by about half if the user is using a libxmlb version that can
convert from `_BOUND_TEXT` to `_BOUND_INDEX_TEXT`.
The more devices detected, the bigger the difference, and without this patch
fixing libxmlb would break fwupd as we'e been searching with an index, but not
actually providing one.
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.
We already had this as an inhibit, but this was not translated client-side.
We also need to propagate the problem to the bootloader device if the device
replugs during firmware update.
Newer versions of dtc agressively pack the string table, using *any* matching
suffix rather than whole strings. This is specification compliant, but breaks
if you use the offset as a hash key as a [premature] optimization.
Just use the string table as a flat block of memory rather than pre-parsing it.
This fixes reading the system FDT on new OpenBMC builds.
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]
These paths may be used for bind mounts, which we can't accurately
discover. Leave a message in the logs accordingly, but allow these
paths.
fixes: #5185
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.
Remove the FuDeviceClass padding, as this library now loaded using an rpath
rather than a shared library with a static API. This matches what we did for
the FuFirmwareClass objects a while ago.
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>
The GCab decompression code is *scary* low level C that has not had any security
auditing other than by the fuzzer (which found plenty of memory-safety bugs).
Supporting LZX is useless at best, and could be a security exploit at worst.
