fmap is a Google flash layout format that is used in several of Google's
firmware projects, including Chrome OS Embedded Controller and the Chrome OS
coreboot firmwares. Introduce it as a firmware format in libfwupdplugin.
Unfortunately module type has more than I previously realized.
The meanings that previously were applied fortunately worked for
the most important case (130-180W TBT) but didn't for single C, dual
C or small power (45W) cases.
Since composite_prepare was trying to read and interpret these, it
causes failures when these other ones are encountered.
I reproduced this on a 130W adapter plugged into a single C (type 0x4).
This meant the update wouldn't install since NULL was returned for the
type.
In case a new module ID is added later, also return an "unknown" for
the metadata.
Force the FuDevice parent to have the largest of the child removal delays.
This avoids each plugin enumerating the children (which may not even be added
yet) to increase the length of the allowed parent delay.
Add two new vfuncs that can be used to collect report metadata from devices
both before and after the update has run. This means we can remove the hacks
where we set add 'global' metadata entries and just hope that there is only one
device from the same plugin that is updated.
This also allows us to collect debugging metadata from devices after an offline
update has been run.
When verifying a signature the valid results are ordered by timestamp. The
CHECKSUM results have a zero timestamp and should have been ordered last.
The sorting callback was wrong, which explains the odd result where we could
downgrade Jcat signatures before we fixed 64ebf9, and nicely explains why we
ignored a timestamp of zero in the first place.
When getting the timestamp, ensure we actually get the newest _signature_ not
just the newest result in case checksums start having timestamps in the future
for some reason. Use new API from libjcat where available, else fall back to
sneaking it out using GObject properties and magic values.
As both hub devices share a FuVliUsbhubDeviceClass instance we cannot 'hijack'
the vfuncs depending on object type. This allows the downstream hub to proxy to
the upstream hub where a GPIOB reset can be performed.
We can have multiple FuVliPdDevice objects registered with the daemon, but they
will all share the FuVliPdDeviceClass instance. If one device requries a
silicon workaround, do not 'hijack' the vfunc for all devices of this type.
This means we do the right thing when updating both the one that requires the
workaround, and the 'normal' one.
Introducing newer gusb caused these builds to run gusb as a subproject
and hence the introspection binaries were looked for.
Fixes: cd65ae ("Require libgusb 0.3.3")
Although this is something that we have always done on the LVFS, corporate
deployments that resign the firmware or metadata might not be signing the files
in the same way.
Always require a timestamp to prevent allowing an inadvertent rollback attack.
Provide the following metadata:
"Dirty firmware" bit
Protocol version
Header type
Maximum PDU Size
Flash protection status
Raw version string
Key Version
Minimum rollback
