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.
This works around a silicon errata which makes the existing 0xB0 chip reset
non-functional.
ALso, as VL10x and VL103 are so different now, use different `->attach()` and
`->detach()` implementations for code sanity.
Based on a patch by Sherlock Chu <SherlockChu@via-labs.com>, many thanks.
These are visually similar to Intel hex files, but different enough to demand
their own parser. Multiple images can be stored in one firmware file, with the
`addr` set to the SiliconID and the `idx` set to the position in the file.
The m-stack DFU quirk also requires that we get the runtime status so that the
USB_DFU_SUCCESS_FUNC callback gets called. We were doing this by accident
before, and since switching to the FuDevice subclass this was dropped.
The dfu_device_refresh_and_clear() function is safe to call on a device which
does not have a working runtime interface.
I misunderstood the original specification, and it seems even USB-hub-less
devices have the same header location as their "write-through" counterparts.
The logic was wrong; we should have been using command 0xB0 for attach back to
FW mode for both VL10x and VL103. Using a generic reset on VL103 always reset
the device back into bootloader mode as the ROM signatures were being written
by command 0xC0.
As now attach and detach have different code paths, there's no point having a
`FuVliDevice->reset()` vfunc, and so we can make everything a little simpler at
the same time.
If the measurements are missing but it's a UEFI system, it's a good indication
that the user has secure boot turned off.
Notify the user on the UEFI device through a non-fatal `UpdateMessage`
To accomplish this, move fu-uefi-vars into the plugin library for other plugins to use
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.
This does 'bleed' the metadata contents into areas previously covered by quirks,
but in this case may be pragmatic and more up to date than a build-time
generated quirk file, which increases the user-friendliness of fwupdmgr.
Some vendors want to ship updates for ATA hardware, but there are currently no
lock-down restrictions in place for these kind of devices.
There is the OUI from the WWN block which is supposed to identify the vendor,
but this is not always set and so we have to be a little creative. We can match
90% of hardware using the vendor name prefix, and the last 10% can be detected
with a heuristic that was the result of comparing over 900 drive models.
I'm not including very old drive models, media converters, raid controllers,
or external 'portable' drives as I don't think it is useful. Also, if the drive
contains a Dell vendor block just hardcode this as Dell rather than trying to
be clever.
Also ask the user to contribute OUI values if this data is found with no quirk
data as this is the only real sane way to manage this data long term.
The list of OUIs can be found here: http://standards-oui.ieee.org/oui.txt
