This allows us to override the location we load data files from, which
allows us to do more kinds of installed tests in the future.
Also, move the global data/tests content into the place that it is used
as it was getting impossible to manage.
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.
More than one person has asked about 'why call fu_plugin_update() for a
reinstall or downgrade' and I didn't have a very good answer.
The plugin API is not officially stable, and we should fix things to be
less confusing. Use the same verbs as the FuDevice vfuncs instead.
There are now multiple plugins using drm_dp_aux_dev interface which
may potentially be combined with an amdgpu. Prevent exercising this
interface with any plugin using DP aux unless a new enough kernel is
installed.
The dell-dock plugin has a check whether or not to create the I2C based
child device based upon whether thunderbolt link is active during probe.
So there will never be a situation that daemon needs to de-duplicate and
set priority between the two plugins.
There is a lot of code in fwupd that just assigns a shared object type to
a FuPlugin, and then for each device on that plugin assigns that same shared
object to each FuDevice.
Rather than proxy several kinds of information stores over two different levels
of abstraction create a 'context' which contains the shared *system* state
between the daemon, the plugins and the daemon.
This will allow us to hold other per-machine state in the future, for instance
the system battery level or AC state.
This makes a lot more sense; we can parse a firmware and export the same XML
we would use in a .builder.xml file. This allows us to two two things:
* Check we can round trip from XML -> binary -> XML
* Using a .builder.xml file we can check ->write() is endian safe
This allows us to 'nest' firmware formats, and removes a ton of duplication.
The aim here is to deprecate FuFirmwareImage -- it's almost always acting
as a 'child' FuFirmware instance, and even copies most of the vfuncs to allow
custom types. If I'm struggling to work out what should be a FuFirmware and
what should be a FuFirmwareImage then a plugin author has no hope.
For simple payloads we were adding bytes into an image and then the image into
a firmware. This gets really messy when most plugins are treating the FuFirmware
*as* the binary firmware file.
The GBytes saved in the FuFirmware would be considered the payload with the
aim of not using FuFirmwareImage in the single-image case.
The best way of not getting something wrong is to not require it in the first
place...
All plugins now use DeviceInstanceId-style quirk matches and we can just drop
the prefix in all files. We were treating HwId=, Guid= and DeviceInstanceId= in
exactly the same way -- they're just converted to GUIDs when building the silo!
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
This allows a device subclass to call the parent method after doing an initial
action, or even deliberately not call the *generic* parent method at all.
It also simplifies the plugins; you no longer have to remember what the plugin
is deriving from and accidentally clobber the wrong superclass method.
There are now two 'backends' of device plug/unplug events, and there is about
to become three. Rather than just adding two more vfuncs for every backend type
define common ones that all providers can use.
Also fix up the existing in-tree plugins to use the new vfunc names and filter
on the correct GType.
When this is done, include:
* Including the hash
* Including anything that is not ABI stable in plugins yet
Suggested-by: Simon McVittie <smcv@debian.org>
This logic error wasn't being caught because the `DelayedActivation`
sysfs code wasn't running.
Basically the WD19TB device will have `skips-restart` applied by the quirk
by default. After `fu_thunderbolt_device_setup_controller` has run
it will have `skips-restart` removed but `usable-during-update` applied
if on a new enough kernel.
In this circumstance the `DelayedActivation` would re-apply `skips-restart`
which is the wrong intended behavior per 834b28009d
Asking the user for the UID mapping isn't working very well, as it requires lots
of manual handholding. It also doesn't work very well when the device vendor
does not actually have a PCI ID or if the vendor has split into two entities.
Just use the OUI address as an additional VendorID and match any of the device
IDs against any of the metadata-supplied values.
These are expected to be flashed via UEFI capsules *not* Thunderbolt plugin
* Flashing via fwupd will require matching kernel work.
* They're left here only for parsing the binaries
```
FuThunderboltFirmwareUpdate:
Family: Maple Ridge
IsHost: true
IsNative: true
DeviceId: 0x1136
VendorId: 0xd4
ModelId: 0xa58
FlashSize: 0x0
Generation: 0x4
Ports: 0x2
HasPd: true
Section0: 0x4000
Section1: 0x4210
Section2: 0x4610
Section3: 0x22958
FuFirmwareImage:
Data: 0x67000
```
This is a safer version of g_bytes_new_from_bytes() which returns a GError
if the offsets are invalid rather than emitting a critical warning.
This prevents a critical warning and potential crash when parsing invalid
bcm57xx firmware.
The FWUPD_INSTALL_FLAG_FORCE flag has really unclear semantics, and ignoring a
file CRC, checksum or model ID should only be done when using fwupdtool actually
debugging a plugin or firmware parser.
Use the existing --force flag when we want a "gentle nudge" like reuploading
previously processed reports.
This is only applicable for kernel 5.9 or kernels that backported
the authenticate on disconnect patches.
For installation time this isn't very important since no device will
restart. This also isn't relevant for the authenticate on disconnect
scenario.
However the manual activation scenario, it's important to activate the
WD19TB device first, followed by Thunderbolt.
If the device is not authorized, it may cause a composite update that it's part
of to not behave properly.
If device is authorized at runtime, add updatable flag at runtime as well
See #2374 for more details
Error will show up if (priv->physical_id == NULL) on
fu_device_ensure_id(). This method is called after probe but before
setup on fu_device_open.
Call fu_device_set_physical_id() on fu_thunderbolt_device_probe()
for the retimer case.
Fixes https://github.com/fwupd/fwupd/issues/2371
Change-Id: I0e462fff5e8abf6073318f6424b6736afc8259b8
