Systems with multiple host controllers will most likely have a different
NVM image for each controller but there is no guarantee that the device_id
within the NVM image varies from one controller to another.
To account for this, build a GUID that contains the last element of the
Thunderbolt controller's udev path.
Sample GUID strings from an XPS 9380 (which only contains one host controller):
```
Guid: 0f401ed2-b847-532a-adc8-3193fc737be6 <- TBT-00d408af-native
Guid: 420b0596-f5cb-5fd7-8416-c99d48ad8de9 <- TBT-00d408af-native-0000:05:00.0
```
This commit follows the presumption that the kernel will enumerate the controllers
in the same order every time.
Currently ICL shows up like this:
```
├─Unknown Device:
│ Device ID: d066959bf1b0da600f4fcaab5aa31cab3ff05eee
│ Summary: Unmatched performance for high-speed I/O
│ Current version: 71.00
│ Update Error: Missing non-active nvmem
│ Flags: internal|require-ac|registered
│ GUID: e72e778e-94f7-5ed2-b560-1c1262ee217c
```
Which isn't very useful to end users. Instead show the generic name
`Thunderbolt Controller` which matches the behavior change we've made
in UEFI FW and Touchpad FW items too.
```
├─Thunderbolt Controller:
│ Device ID: d066959bf1b0da600f4fcaab5aa31cab3ff05eee
│ Summary: Unmatched performance for high-speed I/O
│ Current version: 71.00
│ Update Error: Missing non-active nvmem
│ Flags: internal|require-ac|registered
│ GUID: e72e778e-94f7-5ed2-b560-1c1262ee217c
```
Also, quite the messages about missing vid/did as these won't exist
on ICL either.
Use this attribute to determine whether or not to try to read 'native'
from the Thunderbolt NVM image at probe time.
This attribute is new to kernel 5.5.
There are commits to the Thunderbolt kernel driver that make sure
that the upgrade process goes smoothly. If these commits aren't
present then it will look like a fwupd problem, when it's actually
a kernel problem.
When this issue was reported it appeared that commit
e4be8c9b6a
was missing from the locally tested kernel, but it's impossible
to determine that from userspace.
Prevent running the thunderbolt plugin on older kernels than that
set in `$sysconfdir/fwupd/thunderbolt.conf`.
By default that is set to 4.13.0, but if a distribution vendor has
backported all the necessary support it can be decreased to a lower
version for distro packages.
This controller isn't flashable in fwupd, but fwupd can display information
about it.
* Use a generic device ID (similar to safemode)
* Build device name attribute from DMI data
This leads to madness, as some formats are supersets of the detected types,
e.g. 'intel-me' is detected as 'quad' and 'bcd' is detected as 'pair'.
Where the version format is defined in a specification or hardcoded in the
source use a hardcoded enum value, otherwise use a quirk override.
Additionally, warn if the version does not match the defined version format
Future metadata from the LVFS will set the protocol the firmware is expected to
use. As vendors love to re-use common terms like DFU for incompatible protocols,
namespace them with the controlling company ID with an approximate reverse DNS
namespace.
This also allows more than one plugin to define support for the same protocol,
for instance rts54hid+rts54hub and synapticsmst+dell-dock.
`g_ascii_strtoull` returns 0 and sets `errno` to `-EINVAL` only when
the base is invalid. It's hardcoded to `16` so this is impossible.
Reading `-EINVAL` from `errno` is incorrect in these circumstances.
Fixes: https://github.com/hughsie/fwupd/issues/879
Plugins are allowed to 'opt-out' of this behaviour using _RULE_INHIBITS_IDLE.
This should be used where waking up the hardware to coldplug is expensive,
either from a power consumption point of view, or if other artifacts are going
to be seem -- for instance if the screen flickers when probing display devices.
This functionality is also inhibited when the actual upgrade is happening,
for obvious reasons.
Admins can turn off this auto-sleep behaviour by editing the daemon.conf file.
Fixes https://github.com/hughsie/fwupd/issues/417
We load the Thunderbolt controller firmware to see if the controller is in
native mode, as this changes the GUID. If the controller is asleep the firmware
is not cached by the kernel and it can take more than 4 seconds to read out
504kB of firmware.
We only need the first two 64-byte chunks, so only read what is required.
This speeds up fwupd starting substantially, and also means we don't have to
allocate a giant chunk of heap memory just to inspect one byte.
Fixes: https://github.com/hughsie/fwupd/issues/848
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.
Currently we only parse the nvm_version attribute according fwupd
expectations when the device is initially added. Elsewhere we just use
the raw version as is which might be problematic as the version format
can change in the middle (for example "33.02" vs. "33.2"). Fix this so
that fu_plugin_thunderbolt_udev_get_version () always returns parsed
version string.
Update self tests accordingly to have "parsed" version to which we
compare against.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
At least with Titan Ridge devices 50 * 20 ms is way too short time
reading nvm_version so most of the time the daemon fails to figure out
the version of the just connected device. To make it work better with
Titan Ridge devices increase the timeout to 50 * 200 ms.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
There are other places in the plugin where we read nvm_version and it
can return -EAGAIN as well. To make sure it works consistenly accross
the plugin factor reading nvm_version to a helper function and use instead.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
GLib creates two static inline functions for paramaters that may
not be used that set off warnings in clang but not gcc.
Ignore these on clang builds everywhere that
G_DEFINE_AUTOPTR_CLEANUP_FUNC is used.
Kernel v4.15 added support for native enumeration of Thunderbolt
topology. The enumeration mode affects both the BIOS and TBT FW
operation so they must agree on it. Platforms may support both modes,
native and "legacy" (or "BIOS-assist").
This change makes sure the new image is compatible with the current
controller mode (otherwise the BIOS and TBT FW will not be alligned on
it at least until next boot) and also adds a new GUID generation logic
for a controller in "native" mode so LVFS could contain 2 images, one for
the "legacy" mode and one for "native".
Signed-off-by: Yehezkel Bernat <yehezkel.bernat@intel.com>
This makes more sense; we're updating the device, not the plugin itself.
This also means we don't need to funnel everything through callbacks like
GFileProgressCallback and we can also update the state without adding an
explicit callback to each derived device type.
Kernel 4.15 adds support for Thunderbolt P2P devices via
CONFIG_THUNDERBOLT_NET. When turned on and activated fwupd will
show an empty device representing the IP connection between machines.
These device types aren't useful in fwupd and should be filtered.
Suggested-by: Mika Westerberg <mika.westerberg@intel.com>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
It's actually less scary to see a SHA1 hash than it is to see a path like
/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2. It's also way easier to
copy and paste into the various fwupdmgr command that require a device ID and
also means we can match a partial prefix much like git allows.
If we also move to a model where plugins can be changed during different stages
of the update (e.g. during detach) then the device might change connection type
and then the sysfs path not only becomes difficult to paste, but incorrect.
Session software doesn't care about the format of the device ID (it is supposed
to be an implementation detail) and so there's no API or ABI break here. A few
plugins also needed to be ported, but nothing too worrying.
This allows us to show the devices in a GUI with a nice icon. Some of the icon
mappings are not perfect and I'll be asking the GNOME designers for some
additions to the icon specification.
Custom vendor icons can also be specified, and /usr/share/fwupd/icons would be
a good place to put them. If vendor icons are used they should show a physical
device with the branding, rather than just the vendor logo.
