This fixes the confusing case where installing the CCGX firmware on a dock
would reboot the hub, leading to this output:
Installing on USB-I2C Bridge… ]
Installing on USB2.0 Hub…[************************************** ]
Installing on USB3.1 Hub…[************************************** ]
Installing on USB2.0 Hub…[************************************** ]
Installing on USB3.1 Hub…[************************************** ]
Installing on ThinkPad USB-C Dock Gen2 USB Audio…*************** ]
Installing on USB-I2C Bridge…*********************************** ]
Restarting device… [***************************************]
With the patch, this is now:
Installing on USB-I2C Bridge… ]
Restarting device… [***************************************]
Rather than return the first device with a matching counterpart GUID, and then
check to see if it was removed -- instead just return any item that matches and
has been removed.
This fixes updating the Logitech unifying receiver when more than one type of
device (e.g. RQR12 and RQR24) are connected.
The README says: "A test suite that can be used to interact with a fake device is installed when configured with `-Ddaemon=true` and `-Dtests=true`", so actually only install these tests when tests are enabled.
Switch to downloading the signature first, which we can then load to get the
suffixed build-specific URL of the actual metadata file. You need to have
libjcat 0.1.1 installed and fwupd built against the new version for this to
work.
Fixes https://github.com/fwupd/fwupd/issues/391
The cleanup action for the FuVliUsbhubPdDevice is correct, but was not
conditionalized in the composite cleanup, which meant we would reboot twice
for a normal USB hub update.
Move the parent reboot into the right place, although this does mean we might
reboot twice in the rare event of scheduing a FuVliUsbhubPdDevice *and*
FuVliUsbhubDevice update in the same transaction -- but resetting the device
state between updates is arguably correct anyway...
From [Lennart’s answer on systemd-devel][1]:
> fwupd.target should not list the various network management solutions,
> that is unnecessary, and ordering after network.target should be
> sufficient to achieve the same, in a generic fashion. i.e. network
> managers should order themselves before network.target, so that
> ordering yourself after that automatically orders you after all
> implementations at once...
So, remove the unneeded targets. As the service unit is not
installed/enabled, and instead called by a timer, the system will most
probably be online already.
[1]: https://lists.freedesktop.org/archives/systemd-devel/2020-March/044205.html
"Best practices for starting unit only if network is online"
We use the ParentGuid quirk key to logically 'tie-together' different discrete
devices into one logical device, for instance making the USB soundcard in a hub
the child of the USB controller on the same PCB.
Setting the discrete child is sometimes correct, for instance when rebooting
the hub, the audio device also goes away -- but it's also sometimes wrong.
If we set the child for a discrete device and the parent does *not* go away
then we get to a situation where the child reference may no longer be valid
if it comes back as a different object.
When we try to remove this no-longer-valid device with the removal timeout the
daemon segfaults. This is realy bad.
Continue to allow using fu_device_add_child() in plugins, where we know the
child lifecycle is is matched by the the parent. In the engine just set the
parent ID directly and let the client use this information to show the tree of
logical devices correctly. There's no benefit to setting up the children as
referenced objects anyway.
The VID:PID of the device in HPI mode is shared between multiple vendors, and
so we need to use both the silicon ID and the application ID to match specific
firmware updates.
This fixes the common problem encountered when developing plugins:
./src/fwupdmgr get-devices
Unsupported daemon version 1.4.0, client version is 1.4.0-179-gcf8095d5
Getting the version string from git means the commit version changes each time
we commit any patch, which means we need to use --force to install firmware
when building fwupd against a version that should be compatible.
It is also very inconvenient not bumping the release version for git snapshots
as firmware can no longer depend on the "planned" release triplet.
tl;dr: A good idea for Flashrom, not so awesome for me.
This allows the PCI topology to change, but assumes that thunderbolt host controllers
are enumerated in the same order every time.
It won't matter if the first controller jumped from bus 5 to 7 and consequently the
second from 65 to 71, but rather that the first was enumerated followed by the second.
