The CustomFlags feature is a bit of a hack where we just join the flags
and store in the device metadata section as a string. This makes it
inefficient to check if just one flag exists as we have to split the
string to a temporary array each time.
Rather than adding to the hack by splitting, appending (if not exists)
then joining again, store the flags in the plugin privdata directly.
This allows us to support negating custom properties (e.g. ~hint) and
also allows quirks to append custom values without duplicating them on
each GUID match, e.g.
[USB\VID_17EF&PID_307F]
Plugin = customflag1
[USB\VID_17EF&PID_307F&HUB_0002]
Flags = customflag2
...would result in customflag1,customflag2 which is the same as you'd
get from an enumerated device flag doing the same thing.
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
Before this change calling FuUsbDevice->open() opened the device, and
also unconditionally added various GUIDs and InstanceIDs which we
normally do in setup.
Then fu_device_setup() would call the FuSubclass->setup() vfunc which
would have no way of either opting out of the FuUsbDevice->setup()-like
behaviour, or controlling if the parent class ->setup is run before or
after the subclass setup.
Split up FuUsbDevice->open() into clear ->open() and ->setup() phases
and add the parent class calls where appropriate.
This means that ->setup() now behaves the same as all the other vfuncs.
There were some compilation warnings (one actual error) and possibility
to use incorrect efivar library.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
Shadow FwupdDevice::parent with FuDevice::parent so that we *also* set
the context and composite ID.
This means we can always install all components of the Lenovo docks.
There is no Manager object, so block devices must be discovered
manually.
Additionally, Type field contains FS name rather than its MBR ID in
hex form or a GPT GUID.
Signed-off-by: Richard Hughes <richard@hughsie.com>
