Now two plugins are using hardcoded SPI constants for various CFI chips,
and it makes sense to have some common quirk data that can be used by
both.
Add a FuSpiChip helper object that can be used by FuDevice subclasses
to get the specific SPI commands to use for each flash ID.
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
Add a FuDevice->ready() vfunc that is run after ->setup()
This allows plugins to perform setup actions that require quirk matches
after the instance IDs have been converted. This allows us to also
remove FuVliDevice->setup() as the ordering chain has been broken.
There are two USB-3 hubs internally (with the same VID&PID), and the
MSP430 is only attached to the top-level one.
Fixes https://github.com/fwupd/fwupd/issues/3366
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.
To implement the SPI commands, objects can derive from FuVliDevice and
implement the new vfuncs. This allows us to override the implementation for
minor API changes.
