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.
This is probably fall out from a previous code re-shuffling.
The EC version is already set elsewhere, and in many cases `self->ec_version`
is `NULL` at this time.
Board 4 was manufactured with package version 89.16.01.00 and this
will prevent properly upgrading between releases. Reset this version
to 00.00.00.00 if detected on this board.
Future metadata from the LVFS will set the protocol the firmware is expected to
use. As vendors love to re-use common terms like DFU for incompatible protocols,
namespace them with the controlling company ID with an approximate reverse DNS
namespace.
This also allows more than one plugin to define support for the same protocol,
for instance rts54hid+rts54hub and synapticsmst+dell-dock.
This mirrors the update process over DP aux to run the ESM update
first.
The thought process is as follows:
The "version" displayed doesn't show ESM version, only standard
bank version.
So if the update fails for the ESM then because the update of the
standard happening first it would never be flashed.
Otherwise this would cause fwupd to sit in an endless loop when providing a bad
image.
This additional enum is only available in EC16, but since it doesn't break existing
API on older EC images, don't bump minimum requirement to EC16 yet.
Since dell_dock is the priority plugin for MST flashing the VMM5331
no need to do delayed callbacks anymore.
When the dell_dock plugin bumps to EC 15 being the minimum requirement
more code can also be dropped.
Although this is (currently) slower to flash with, bad behavior
and corner case scenarios such as these don't occur:
* Flickering during enumeration
* Monitor plugged in during enumeration but not during flash
* Heavy DP traffic slowing down update significantly
* Sandboxes without access to `/dev/drm_dp_auxY` unable to flash
* Exercising existing graphics driver bugs leading to system freezes.
Additionally this removes a lot of code in dell_dock that was put
in place specifically to be able to support waking up the MST hub
to try to use DP aux for flashing.
Now DP aux will only be used to flash when fwupd is compiled
without `dell_dock`.
It was identified that at least one other device on this shared
I2C bus can't operate at the speed. This means that it may
inadvertently respond to commands intended for another device.
The libxmlb library is much faster to query, and does not require the daemon
to parse the XML metadata at startup. It's a zero-copy mmap design that is more
modern and less clunky.
RSS has reduced from 3Mb (peak 3.61Mb) to 1Mb (peak 1.07Mb) and the startup
time has gone from 280ms to 250ms.
These are certainly bugs with one of the components, but if the situation
happens in the field the plugin needs to finish initialization to allow
upgrading to a fixed component.
We'll just fall back to the name in the quirk (Dell dock) in this case.
This plugin requires infrastructure introduced in fwupd 1.1.3
and can not be backported to earlier versions of fwupd.
It works together with the Synaptics and Thunderbolt plugins to
coordinate the proper flashing procedure for devices in this dock.
