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.
Over the months the original meaning of ALLOW_OFFLINE and ALLOW_ONLINE have be
lost, and there is now a confusing mixture of uses in the source tree. With this
commit we make it clear the UPDATABLE flag is used to specify when the device is
updatable (e.g. from the desktop live session, or from the systemd offline
updates mode, or both) and the NEEDS_REBOOT flag lets us know when the update
is actually going to be done.
For instance, a UEFI UpdateCapsule can be *scheduled* from either the desktop
or from the update mode (but the latter would be a bit weird), but does require
a reboot. Some devices might only be updatable outside the live session, for
instance a hard drive update or a GPU update -- there's just too much going on
with a live session and we want to tightly control what's running during the
firmware flash.
This also means we don't have to "retry" the update when scheduling an update
that really can be scheduled whenever, but just requires a reboot to apply.