It wasn't hugely clear what the platform ID was actually meant to represent. In
some cases it was being used like a physical ID, in others it was a logical ID,
and in others it was both. In some cases it was even used as a sysfs path.
Clear up all the confusion by splitting the platform ID into two parts, an
optional *physical* ID to represent the electrical connection, and an optional
*logical* ID to disambiguate composite devices with the same physical ID.
Also create an explicit sysfs_path getter for FuUdevDevice to make this clear.
This allows WAIT_FOR_REPLUG to always work, rather than depending on the order
that the GUIDs were added, and that the kernel would always return the same
sysfs path (which it doesn't have to do, especially for hidraw devices).
As an example use case earlier development versions of a Thunderbolt module
may contain DROM corresponding to one model ID and transition to another
model ID. Even if lying about the GUIDs supported by the device via a
quirk the Thunderbolt validation will fail because the device isn't
intended for that system.
This should only be used during development.
The daemon creates a baseclass of either FuUsbDevice or FuUdevDevice when the
devices are added or coldplugged to match the quirk database and to find out
what plugin to run.
This is proxied to plugins, but they are given the GUsbDevice or GUdevDevice and
the FuDevice is just thrown away. Most plugins either use a FuUsbDevice or
superclassed version like FuNvmeDevice and so we re-create the FuDevice, re-probe
the hardware, re-query the quirk database and then return this to the daemon.
In some cases, plugins actually probe the hardware three times (!) by creating
a FuUsbDevice to get the quirks, so that the plugin knows what kind of
superclass to create, which then itself probes the hardware again.
Passing the temporary FuDevice to the plugins means that the simplest ones can
just fu_plugin_device_add() the passed in object, or create a superclass and
incorporate the actual GUsbDevice and all the GUIDs.
This breaks internal plugin API but speeds up startup substantially and deletes
a lot of code.
If another plugin causes a Synaptics MST device to be removed, it
also needs to be removed from the cache to prevent problems when
the device is re-probed.
1) Switch to daemon provided vfuncs for USB
2) Set quirks so that the plugin only runs when Realtek NIC shows up
3) Rely on the daemon to process all removals by parent tree
Objects deriving from FuUdevDevice() like FuNvmeDevice typically want to do
FuDevice->FuUdevDevice->FuNvmeDevice rather than FuDevice->FuNvmeDevice.
This matches what FuUsbDevice does.
The setup() is the counterpart to probe(), the difference being the former needs
the device open and the latter does not.
This allows objects that derive from FuDevice, and use FuDeviceLocker to use
open() and close() without worrying about the performance implications of
probing the hardware, i.e. open() now simply opens a file or device.
Probe is supposed to be used to check things like the VID and PID, and to
optionally add extra GUIDs to the device. Crucially, it doesn't require open()
to operate, and so it's wrong to reprobe() on calling close().
This caused errors of mismatching devices that didn't have platform
ID's set.
Example:
18:40:24:0555 Fu ignoring device 370e10407b1f04ade798a9f1d3e1fa57c67750c3 [uefi] existing device 088df415cdee883ec89563e41e6d495924250174 [amt] already exists
Fixes: 3a8d5328 ("Allow the device list to take care of waiting for the device replug")
Commit 0f72ef2f88 causes probe to be re-run on FuDevices.
Any devices derived from FuUsbDevice that set the "Name" key will have the
quirks re-evaluated when GUIDs are added again leading to warnings like this:
```
(fwupdtool:8259): Fu-WARNING **: 23:04:43.144: device 970e85c8400ed95ec5c02b86e52a0ca4ce6fc051 overwriting same name value: Dell USB hub
```
ComputerHardwareIds.exe seems to strip any trailing whitespace before building
the UTF-16 string for hashing. If a SMBIOS blob contains strings with trailing
whitespace then until now the 'fwupdmgr hwids' output would show different
HwIds than when running Windows on the same hardware -- which confuses everyone.
Although this may change the HwIds from 1.1.1 to 1.1.2 on some hardware, I'd
argue it's more important to match the Windows Hardware IDs rather than have
a 'similar, but not the same' implementation.
This affects the Lenovo X380 Yoga, although may also affect other machines.
