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.
Provide the following metadata:
"Dirty firmware" bit
Protocol version
Header type
Maximum PDU Size
Flash protection status
Raw version string
Key Version
Minimum rollback
This should do the bulk transfers using protocol 6.
The output here is now equivalent to the output of
usb_updater2 -d 18d1:501a -f
fwupdtool --plugin-whitelist cros_ec get-devices --verbose
Servo Micro
DeviceId: 84d0e3f2a0f8b2328f7995767b23ebb40494723f
Guid: 8e2f7625-a164-55d7-8f09-f193c8ec33f1 <- USB\VID_18D1&PID_501A&REV_0100
Guid: 13564257-c649-586d-b4e4-4f048d480f36 <- USB\VID_18D1&PID_501A
Serial: CMO653-00166-040491U00771
Summary: Servo Micro (aka "uServo") Debug Board
Plugin: cros_ec_usb
Flags: registered
Vendor: Google Inc.
VendorId: USB:0x18D1
Version: servo_micro_v2.4.17-df61092c3
VersionFormat: plain
Created: 2020-05-20
PhysicalId: usb:03:00:02
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
```
See also: https://github.com/fwupd/fwupd/issues/2119
Reported-by: Anton Farygin <rider@altlinux.org>
Based on a patch by Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Fixes cross compilation for arm with clang which provides cpuid.h
but helpfully has this error:
```
#if !(__x86_64__ || __i386__)
#error this header is for x86 only
#endif
```
Fixes: #2131
To do this, rely on the AppStream ID to map to a translated string (providing a
fallback for clients that do not care) and switch the free-form result string
into a set of enumerated values that can be translated.
This fixes some of the problems where some things have to be enabled to "pass"
and other attributes have to be some other state. For cases where we want the
user to "do" something, provide a URL to a wiki page that we update out-of-band
of fwupd releases.
This only checks that it was available from the CPU.
To be complete an additional check should be made to show that it
was actually enabled from the firmware.
This will require a kernel modification though because MSR access
will be forbidden from userland while in kernel lockdown.
The kernel patches are a log way from being upstreamed, so disable this until
there is even a chance the user might be running it.
This removes the obsoletes line from *every* system running 'fwupdmgr security'.
We can read this from userspace even when SB is turned on and with the kernel
locked down. The kernel securityfs patches are still in-progress, but will take
significant time to get upstream.
The kernel patches are needed when the PCI device is hidden from userspace.
On a system that is not at all locked down running an old kernel several
of the items are a bit confusing.
```
Runtime Suffix -!
✔ fwupd plugins: OK
✔ Linux Kernel: OK
✘ Linux Kernel: Could not open file
✘ Linux Swap: Not encrypted
```
