Now incorporate is fixed to copy across the properties we need in the
superclass, we don't need to do the subclass ->probe().
Note, we still need to do the subclassed ->probe() when using
FU_UDEV_DEVICE_FLAG_VENDOR_FROM_PARENT or when looking at properties
on the parent device.
This also removes the spurious 'already set GType to FuVliUsbhubDevice,
ignoring FuVliUsbhubDevice' messages when running the daemon.
The signed payload attribute is currently set for devices connected through
Intel host controllers. When Thunderbolt 3 devices are connected to non-Intel
host controllers they still support signed payloads.
Update the flag accordingly in these circumstances.
tristate features will automatically disable if dependencies marked
as required are missing.
Packagers can manually override using `auto_features`.
Link: https://mesonbuild.com/Build-options.html#features
- this is needed for the retimer to be accessible after update
- and to bring the port back to online
Signed-off-by: Kranthi Kuntala <kranthi.kuntala@intel.corp-partner.google.com>
Change-Id: I2234ebe23a55fc03f9ef30c1ea10febfe46a2003
-this is indeed needed to reflect the updated version after system reboot
Signed-off-by: Kranthi Kuntala <kranthi.kuntala@intel.corp-partner.google.com>
Change-Id: Id4751d531528590cc93c08db0d0939a547f4d59f
Although they do a lot of the same things, trying to deal with both
kinds of device in the same GObject type was making it very hard to
understand and maintain.
Split out two GObjects that both derive from FuThunderboltDevice.
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>
We were calling g_module_symbol() 2703 times, which is actually more
expensive than you'd think.
It also means the plugins are actually what we tell people they are:
A set of vfuncs that get run. The reality before that they were dlsym'd
functions that get called at pretty random times.
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.
