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.
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 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.
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.
We want to allow all the device hotplug events to be processed before
marking the update as completed. Otherwise, we might have a situation
where we have a child device attached to a parent, where we want to
update the parent, then the child. e.g.
1. Add parent
2. Add child
3. Update parent
4. Attach parent
5. Wait for parent
...some time passes...
6. Parent re-appears
7. Update finishes, client indicates success
...child update is scheduled...
...which returns with failure as it does not exist...
8. Add child
The child should have been added *before* the update completed to avoid
the caller from needing an unspecified delay as a *workaround*.
Only opt-in plugins that have been tested -- unconditionally enabling
this may cause regressions on devices like docks.
Fixes https://github.com/fwupd/fwupd/issues/4378
This allows us to make smarter policy decisions in the future on when
to show unavailable updates. It also means we can show translated
text in the frond-end clients.
Only problems the user can "fix" are enumerated. For example, opening
the laptop lid, or charging the device battery.
Some plugins were creating local versions (which were not attached to
the daemon progress in any way) as a workaround as they needed to do
actions that took a long time to complete.
Provide a device instance builder that allows plugins to easily
create multiple instance IDs based on parent attributes.
Also fix a lot of the instance ID orders, so that we add more generic
IDs first, and more specific IDs after.
This allows us to show in the tools if a device is currently affected
by a specific CVE. For instance, we could inform the user that a device
requires a critical firmware update that is being actively exploited.
Note, this also means we can show the user a firmware update is now
required, even though the firmware may not be available on the LVFS.
Also show the issue in the `fwupdmgr security` output, e.g.
There are devices with issues:
Samsung — MZVLB2T0HALB-000L7:
• CVE-2022-12345
• CVE-2022-54321
Most vendors do not mirror the firmware update to an external display,
and some don't behave correctly when the lid is shut and the machine is
docked. Add this quirk just for Lenovo for now.
Fixes https://github.com/fwupd/firmware-lenovo/issues/181
This change offline ports in the host controller
for retimers to enumerate in the NDA case.
-offline and rescan usb4 ports
-this enable enumeration of the retimers
-updates nvm to the enumerated retimers
-online usb4 port this will de-enumerate retimers
BUG=b:187506425
TEST=emerge-volteer fwupd
Signed-off-by: Kranthi Kuntala <kranthi.kuntala@intel.corp-partner.google.com>
Quite a few plugins are using a FuDeviceLocker to detach then attach in
the error path, and finding them isn't easy as we explicitly cast to a
FuDeviceLockerFunc.
For sanity, just provide both symbols so we can do the right thing in
both cases. It seems like a sensible thing to allow.
Fixes https://github.com/fwupd/fwupd/issues/3771
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
The benefit of using the proxy device is that we can 'use' the proxy
device for device access, but 'report' the progress on the passed
FuDevice instance.
This means the front-end reports the device status correctly when
updating composite devices that us proxies.
The comment always said we should move it to the daemon if another
plugin started doing this, and that is now.
The "return error and hope the client resubmits the firmware again"
pattern is clunky. There are two plugins doing this now, and about to
be one more.
This adds FwupdRequest which provides a structured way of asking the
user to perform an action, e.g. to replug the device or to press a
special key or button.
This replaces much of the UpdateMessage and UpdateImage API although
it is still used internally. Clients capable of processing the new
DeviceRequest signal should add REQUESTS to their feature flags.
Also, this allows us go back to the old meaning of _NEEDS_BOOTLOADER,
which was "needs rebooting into a bootloader mode" rather than the
slightly weird "user needs to do something and resubmit request".
At the moment the device list auto-removes children when the parent is
removed. This was originally working around the bug that the child
devices had no backend ID, and thus were not matched like the parent
in fu_engine_backend_device_removed_cb() and removed automatically.
Using the workaround means that the children are potentially removed
before the parent depending on the order of the device list -- which
might be modified by replug events.
I think the old cleanup is probably an anti-pattern, and going forward
composite devices should probably define _NO_AUTO_REMOVE_CHILDREN but
we don't want to change this behaviour for plugins already expecting
the old flow, or for devices with no parent backend IDs.
