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".
The move to query sysattr for the name inadvertly changed the extent of
devices accepted by emmc probe. udev rules setup ID_NAME only for main
block device, but not for rpmb or boot, while 'name' sysattr is present
for all of them for they point to the same parent. The original check
for name was brittle either way and relied on a side effect of udev
subsystem. This CL introdues a proper filtering check that picks up only
the main devices. That is important because an attempt to perfrom an
update not on the main device returns a cryptic timeout error.
Change-Id: I3c2f5597c3e3ca2124c87cade3f345dece94027e
The kernel allows configuring this, and certain plugins will use this
path to be able to load firmware in the kernel driver through runtime,
but to flash to the device.
At this point it has to be present, but better have the check for
correctness sake.
Follow up of
64fa633e30
Change-Id: I51b5995e25dc4dc4ec63b90af271cd90650d184d
/run/udev/data/b* location of eMMC devices appears to be inaccessible
early on in the boot process which makes fwupd to skip eMMC devices if
the daemon started too early. ID_NAME udev attribute is effectively
copied from the sysfs attribute [1], thus making use of it is more
reliable.
[1] 1ed38f4174/etc/udev/rules.d/60-persistent-storage.rules (42)
Change-Id: I66b92dfeb13ec61b4d8166dd32a2460b6fbf92c2
This also means we no longer pass in just one device to the
fu_device_list_wait_for_replug() function, but we rather wait for *all*
of the active devices.
This also cleans up the confusion on whether the engine should wait for
the 'root' device or the child device as either (or both) can be set as
required.
This makes the replug far more predictable for devices that have
children even in bootloader mode.
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.
