Although they normally work, some failures have been reported in the field
related to the MST hub not responding in the MST plugin.
When these failures have occurred the dell_dock plugin also fails to
enumerate.
So rather than allow some people who don't have dell_dock compiled to
update their MST hub using synaptics_mst, perform ALL updates for
mst hub via dell_dock.
```
18:06:24:0324 FuPluginSynapticsMST no device found on drm_dp_aux1: VMM5331 inside Dell dock is only supported by dell_dock
```
This flag is used internally by plugins to indicate that they will
skip the phase of firmware installation that power cycles a device.
It is intended to be set by quirks or other environment settings.
There was some regression between 1.4.0 and now that prevented updates
containing a Thunderbolt controller from finishing. They would just
sit pending Thunderbolt replug without ever finishing.
Remove the old hack for replug and instead push activation to the end
of the composite steps.
This is to avoid the device tree from changing significantly during
the update process.
This still isn't really ideal, we want to be able to add the flag
usable-during-update to the thunderbolt controller, but this requires
some extra work in the kernel.
Quite a few plugins use HID commands to communicate with the hardware. At the
mement we have ~6 implementations of SET_REPORT and are soon to add one more.
Move this into common code.
If we say that the version format should be the same for the `version_lowest`
and the `version_bootloader` then it does not always make sense to set it at
the same time.
Moving the `version_format` to a standalone first-class property also means it
can be typically be set in the custom device `_init()` function, which means we
don't need to worry about *changing* ther version format as set by the USB and
UDev superclass helpers.
In 1de7cc we checked the version format when checking for update, but there are
many other places that are doing verfmt-insensitive comparisons. For instance,
the predicates in <requires> all fail if the device version format is plain.
his breaks updating some NVMe drives where the `ne` requirements are not
semantic versions.
To avoid trying to catch all the bugs in different places, and in case we have
a future verfmt that should be treated another way, refactor this out in to a
common function and deprecate the old function.
Some plugins have devices with more than one protocol. Logically the protocol
belongs to the device, not the plugin, and in the future we could use this to
further check firmware that's about to be deployed.
This is also not exported into libfwupd (yet?) as it's remains a debug-feature
only -- protocols are not actually required for devices to be added.
There are several subtle bugs in various places in fwupd caused by not treating
user-provided offsets into buffers as unsafe. As fwupd runs as root we have to
assume that all user firmware is evil, and also that devices cannot be trusted.
Make a helper to put all the logic into one place and convert all users.
In many plugins we've wanted to use ->prepare_firmware() to parse the firmware
ahead of ->detach() and ->write_firmware() but this has the limitation that it
can only return a single blob of data.
For many devices, multiple binary blobs are required from one parsed image,
for instance providing signatures, config and data blobs that have to be pushed
to the device in different way.
This also means we parse the firmware *before* we ask the user to detach.
Break the internal FuDevice API to support these firmware types as they become
more popular.
This also allows us to move the Intel HEX and SREC parsing out of the dfu plugin
as they are used by a few plugins now, and resolving symbols between plugins
isn't exactly awesome.
This leads to madness, as some formats are supersets of the detected types,
e.g. 'intel-me' is detected as 'quad' and 'bcd' is detected as 'pair'.
Where the version format is defined in a specification or hardcoded in the
source use a hardcoded enum value, otherwise use a quirk override.
Additionally, warn if the version does not match the defined version format
EC23 is the last version that will be supported on board 4 SKUs with
base PD firmware versions 18+.
* If on EC23 already, don't mark the device as updatable anymore.
* Flashing EC24 or later when currently on EC 22 or less will potentially
cause bricked docks that can't enumerate, so prevent this scenario
during update path.
This behavior will prevent the dock from performing most resets until
it has been unplugged from a host system.
This significantly speeds up the perceived update duaration and prevents
data loss during update.
It's not confirmed whether EC23 or later EC will enable it.
* So only enable by a custom flag until this is confirmed.
* Custom flag will be dropped when included into stable EC release.
This functionality also relies upon the CAB file providing a message warning
user that the dock might not be usable after unplugging for up to 1 minute.
Some SKUs of board 4 and later have silicon that will not work with anything
but EC19 or later. So once flashed up to EC19 prohibit downgrades below that
to keep from bricking devices.
