This allows us to be more specific when matching devices, and also means we get
more attributes 'for free' from the FuUdevDevice->probe().
This would allow us to have multiple device GTypes handling multiple MEI
interfaces in the same plugin., for instance, PTHI and MKHI.
The slight fly in the ointment is that the kernel does not set the 'dev' for
the mei_me devices, but it's always going to be just /dev/mei0, so hardcode it.
It is weird to do this when constructing the object, and it allows us
to match PossiblePlugin quirk matches on potentially better instance
IDs added by the superclass.
We were using 0x0 and 0xFFFF in different places, and only checking the
former in most cases. Just restrict the range to 0xFFFE and use 0x0 as
*invalid or not set* as before.
We don't want to include the SCSI LUN in the physical ID, as this is a
logical concept not relating to the hardware device.
Use the UDev devtype to find the 'correct' parent.
This reverts commit a7642a7b7e.
I forgot that we need the TYPE, DRIVER and most importantly subsystem
for PossiblePlugin quirk matches. We need something more subtle.
Provide a device instance builder that allows plugins to easily
create multiple instance IDs based on parent attributes.
Also fix a lot of the instance ID orders, so that we add more generic
IDs first, and more specific IDs after.
The only users of `SERIO\FWID` and `I2C\NAME` are already 'safe' and
the device GUIDs should all be unchanged.
There are no current users of the `MTD\NAME` instance IDs, and these
are the ones that may be more unpredictable and in need of sanity.
A UF2 device exposes a VFAT block device (sometimes called a Mass
Storage Device) which has a virtual file called `INFO_UF2.TXT` where
metadata can be read. It may also have a the current firmware exported
as a file called `CURRENT.UF2` which is in a 512 byte-block UF2 format.
Writing any file to the MSD will cause the firmware to be written.
Sometimes the device will restart and the volume will be unmounted
and then mounted again. In some cases the volume may not “come back”
until the user manually puts the device back in programming mode.
Match the block devices using the VID*PID, UUID or label, and then
create a UF2 device which can be used to flash firmware.
Note: We only read metadata from allow-listed IDs to avoid causing
regressions on non-UF2 volumes. To get the UUID and label you can
use commands like:
udisksctl info -b /dev/sda1
