Commit Graph

92 Commits

Author SHA1 Message Date
Richard Hughes
1981c63d58 Remove FuFirmwareImage and just use FuFirmware instead
This allows us to 'nest' firmware formats, and removes a ton of duplication.

The aim here is to deprecate FuFirmwareImage -- it's almost always acting
as a 'child' FuFirmware instance, and even copies most of the vfuncs to allow
custom types. If I'm struggling to work out what should be a FuFirmware and
what should be a FuFirmwareImage then a plugin author has no hope.

For simple payloads we were adding bytes into an image and then the image into
a firmware. This gets really messy when most plugins are treating the FuFirmware
*as* the binary firmware file.

The GBytes saved in the FuFirmware would be considered the payload with the
aim of not using FuFirmwareImage in the single-image case.
2021-03-09 21:14:12 +00:00
Mario Limonciello
dfbb549f1e trivial: dell-dock: Save the base type in private structure
This may be used in the future for other expansion and determination.
2021-03-09 09:09:57 +00:00
Richard Hughes
c81b755872 Be more strict for custom quirk keys
Rather than trying to guess typos, force each plugin to register the quirk
keys it supports, so we can show a sensible warning if required at startup on
the console.
2021-03-03 08:30:34 +00:00
Richard Hughes
7d132b728c Simplify the quirk file format
The best way of not getting something wrong is to not require it in the first
place...

All plugins now use DeviceInstanceId-style quirk matches and we can just drop
the prefix in all files. We were treating HwId=, Guid= and DeviceInstanceId= in
exactly the same way -- they're just converted to GUIDs when building the silo!
2021-03-03 08:30:34 +00:00
Richard Hughes
b3f9841924 Support more than one protocol for a given device
Devices may want to support more than one protocol, and for some devices
(e.g. Unifying peripherals stuck in bootloader mode) you might not even be able
to query for the correct protocol anyway.
2021-03-01 16:14:36 +00:00
Mario Limonciello
ed918a4cec dell-dock: Remove non-passive update flow support
This is effectively a lot of dead code.

* The minimum requirements for this feature are EC 00.00.00.23 and Hub2 1.42.
* "A00" docks shipped with EC 01.00.00.00 and Hub2 1.47
2021-02-25 15:47:25 +00:00
Richard Hughes
078beafb2d Add a new internal flag to opt-in to GUID matching
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!

Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.

This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.

This removes the workaround added in 99eb3f06b6.

Fixes https://github.com/fwupd/fwupd/issues/2915
2021-02-25 15:47:25 +00:00
Richard Hughes
525f71f54b Merge the _udev_device() and _usb_device() vfuncs
There are now two 'backends' of device plug/unplug events, and there is about
to become three. Rather than just adding two more vfuncs for every backend type
define common ones that all providers can use.

Also fix up the existing in-tree plugins to use the new vfunc names and filter
on the correct GType.
2021-02-10 12:04:05 +00:00
Mario Limonciello
75835b4a0b Use FWUPD_COMPILATION define to indicate an in tree build
When this is done, include:
* Including the hash
* Including anything that is not ABI stable in plugins yet

Suggested-by: Simon McVittie <smcv@debian.org>
2021-01-22 14:01:25 -06:00
Richard Hughes
dd0159dc00 trivial: Remove excess #include 2021-01-13 20:06:08 +00:00
Mario Limonciello
8aa5d41eb7 Add external interface messages 2020-10-26 12:05:20 -05:00
Mario Limonciello
6a1a49eaef dell-dock: mirror updatable flag into thunderbolt
This makes sure that if an update is pending (as stored in the EC), Thunderbolt
won't show in a needing update state again.

Fixes: #2374
2020-09-11 14:08:32 -05:00
Mario Limonciello
e89ce1a935 trivial: dell-dock: check for valid dock type on open
Only add instance ID if it actually probes properly.

Otherwise this makes an invalid assumption that the device is a WD19
EC just because it had the correct hub in front.

Instead check the first time it's opened that the correct device
is identified (`EXPECTED_DOCK_TYPE`)
2020-08-28 09:53:54 -05:00
Richard Hughes
d09cf101c3 Change all instances of master/slave to initiator/target
This makes perfect sense, because the 'initiator' starts the transaction and
the 'target' is the addressee of the transaction. Even the I²C spec defines the
'master' as 'initiating' the transaction.

This is the same nomenclature now used by the Glasgow project too.
2020-07-01 15:44:30 +01:00
Mario Limonciello
834b28009d Add support for a delayed activation flow for Thunderbolt
This allows delaying the activation of Thunderbolt firmware until
shutdown/reboot or when the dock is unplugged.

This functionality requires features in the kernel:
https://lore.kernel.org/linux-usb/20200622143035.25327-1-mario.limonciello@dell.com/T/#t

Matrix of cases to support:

* Distro Old Linux kernel (doesn't support authenticate on disconnect)

  - WD19TB: Should have `skips-restart` flag set
    No flush or activate features called in `thunderbolt` plugin.
    `dell_dock` plugin will activate at end of composite update

  - All other devices: Shouldn't have flags set
    Should authenticate in Thunderbolt plugin.
    `1 > nvm_authenticate`

* Distro New Linux kernel (supports authenticate on disconnect)

  - WD19TB: Should have `usable-during-update` flag set but not `skips-restart`
    Should flush image to SPI in `thunderbolt` plugin
    `2 > nvm_authenticate_on_disconnect`
    Should configure TBT device for authenticate on disconnect
    `1 > nvm_authenticate_on_disconnect`
    `dell_dock` plugin will configure dock for authenticate on disconnect

  - All other devices: Shouldn't have flags set
    Should authenticate in `thunderbolt` plugin.
    `1 > nvm_authenticate`

* ChromeOS (supports authenticate on disconnect)

  - `thunerbolt.conf` will have `DelayedActivation=true`.

  - WD19TB: Should have `usable-during-update` flag set but not `skips-restart`
    Should flush image to SPI in `thunderbolt` plugin
    `2 > nvm_authenticate_on_disconnect`
    Should configure device for authenticate on disconnect
    `1 > nvm_authenticate_on_disconnect`
    `dell_dock` plugin will configure dock for authenticate on disconnect

  - All other devices: Should have both `usable-during-update` and `skips-restart` set
    Should flush image to SPI in `thunderbolt` plugin
    `2 > nvm_authenticate`
    Will activate upon logout/shutdown/reboot
    `1 > nvm_authenticate`
2020-06-22 16:09:10 -05:00
Mario Limonciello
7d5f6b0232 dell-dock: Add more module types to the enum
Unfortunately module type has more than I previously realized.
The meanings that previously were applied fortunately worked for
the most important case (130-180W TBT) but didn't for single C, dual
C or small power (45W) cases.

Since composite_prepare was trying to read and interpret these, it
causes failures when these other ones are encountered.

I reproduced this on a 130W adapter plugged into a single C (type 0x4).
This meant the update wouldn't install since NULL was returned for the
type.

In case a new module ID is added later, also return an "unknown" for
the metadata.
2020-06-17 17:10:05 -05:00
Mario Limonciello
8012fb3c8d trivial: dell-dock: clarify the pending update message (#2185)
To a user it's not obvious if being unplugged means host or AC adapter.
Unplugging from AC adapter will prevent the dock from completing an
update.
2020-06-17 11:49:33 -05:00
Mario Limonciello
838ae163e3 dell-dock: prevent updates to occur via synaptics-mst plugin
Although they normally work, some failures have been reported in the field
related to the MST hub not responding in the MST plugin.

When these failures have occurred the dell_dock plugin also fails to
enumerate.

So rather than allow some people who don't have dell_dock compiled to
update their MST hub using synaptics_mst, perform ALL updates for
mst hub via dell_dock.

```
18:06:24:0324 FuPluginSynapticsMST no device found on drm_dp_aux1: VMM5331 inside Dell dock is only supported by dell_dock
```
2020-05-28 08:59:07 -05:00
Mario Limonciello
a42daefb9e dell-dock: Capture the dock SKU in metadata
Should be helpful in reproducing failure reports.
2020-05-26 10:22:58 -05:00
Mario Limonciello
768a2680a6 Introduce a new flag skips-restart
This flag is used internally by plugins to indicate that they will
skip the phase of firmware installation that power cycles a device.

It is intended to be set by quirks or other environment settings.
2020-05-06 15:13:40 -05:00
Mario Limonciello
0cd2f10711 trivial: dell-dock: delay activation of the thunderbolt updates
There was some regression between 1.4.0 and now that prevented updates
containing a Thunderbolt controller from finishing.  They would just
sit pending Thunderbolt replug without ever finishing.

Remove the old hack for replug and instead push activation to the end
of the composite steps.

This is to avoid the device tree from changing significantly during
the update process.

This still isn't really ideal, we want to be able to add the flag
usable-during-update to the thunderbolt controller, but this requires
some extra work in the kernel.
2020-05-06 11:13:51 -05:00
Richard Hughes
a1ef52e5f9 dell-dock: Port to using fu_device_get_proxy()
This also cleans up the memory handling to prevent a ref-cycle loop that
prevented the dock devices from being finalized if the dock was removed.
2020-04-15 20:34:31 +01:00
Richard Hughes
eb326f7546 dell-dock: Port to fu_device_retry() 2020-03-28 12:46:03 +00:00
Richard Hughes
c04f5a3e15 Add FuHidDevice abstraction
Quite a few plugins use HID commands to communicate with the hardware. At the
mement we have ~6 implementations of SET_REPORT and are soon to add one more.

Move this into common code.
2020-03-19 17:02:07 +00:00
Richard Hughes
f50ff2c27e Decouple the version format from the version itself
If we say that the version format should be the same for the `version_lowest`
and the `version_bootloader` then it does not always make sense to set it at
the same time.

Moving the `version_format` to a standalone first-class property also means it
can be typically be set in the custom device `_init()` function, which means we
don't need to worry about *changing* ther version format as set by the USB and
UDev superclass helpers.
2020-02-25 14:00:09 +00:00
Richard Hughes
9a68084dbc Always check for PLAIN when doing vercmp() operations
In 1de7cc we checked the version format when checking for update, but there are
many other places that are doing verfmt-insensitive comparisons. For instance,
the predicates in <requires> all fail if the device version format is plain.
his breaks updating some NVMe drives where the `ne` requirements are not
semantic versions.

To avoid trying to catch all the bugs in different places, and in case we have
a future verfmt that should be treated another way, refactor this out in to a
common function and deprecate the old function.
2020-02-20 15:49:27 +00:00
Mario Limonciello
bd266bd0cf trivial: add some missing protocol definitions 2020-01-08 15:49:38 -06:00
Mario Limonciello
a21802acad trivial: dell-dock: drop unused quirk keyx 2019-12-12 13:59:41 -06:00
Mario Limonciello
fd6ffd6dac trivial: rename synapticsmst to synaptics-mst
This brings the naming nomenclature inline with the other plugins
2019-12-12 13:59:41 -06:00
Mario Limonciello
e2db568490 trivial: Set vendor ID for Dell WD19 to USB:0x413C (Fixes: #1653)
View after this update:
```
├─WD19TB:
│ │   Device ID:           a455a3a21752e5d31c228f1f5b51761dad88a432
│ │   Summary:             High performance dock
│ │   Current version:     01.00.00.02
│ │   Minimum Version:     01.00.00.00
│ │   Vendor:              Dell Inc. (USB:0x413C)
│ │   Install Duration:    1 minute
│ │   Serial Number:       J4T6SV2/3169046018716226
│ │   GUID:                cd357cf1-40b2-5d87-b8df-bb2dd82774aa ← USB\VID_413C&PID_B06E&hub&embedded
│ │   Device Flags:        • Updatable
│ │                        • Requires AC power
│ │                        • Supported on remote server
│ │                        • Device stages updates
│ │                        • Device can recover flash failures
│ │                        • Device is usable for the duration of the update
│ │
│ ├─Thunderbolt controller in Dell dock:
│ │     Device ID:         8357922f7f208e1f3b7537141ce17db04bc219d9
│ │     Summary:           Thunderbolt controller
│ │     Current version:   43.00
│ │     Vendor:            Dell Inc. (TBT:0x00D4)
│ │     Install Duration:  22 seconds
│ │     GUID:              c94770ca-1773-592c-b20a-e87243bc7cd0 ← TBT-00d4b070
│ │     Device Flags:      • Updatable
│ │                        • Requires AC power
│ │                        • Supported on remote server
│ │                        • Device stages updates
│ │
│ ├─Package level of Dell dock:
│ │     Device ID:         1eca9eabb0c992c136e1deb1f89e3f70c465aa1c
│ │     Summary:           A representation of dock update status
│ │     Current version:   01.00.08.01
│ │     Vendor:            Dell Inc. (USB:0x413C)
│ │     Install Duration:  5 seconds
│ │     GUID:              8ceeeffd-51b6-580c-9b75-69143227aff8 ← USB\VID_413C&PID_B06E&hub&status
│ │     Device Flags:      • Updatable
│ │                        • Supported on remote server
│ │                        • Device can recover flash failures
│ │                        • Device is usable for the duration of the update
│ │
│ ├─RTS5413 in Dell dock:
│ │     Device ID:         ca36279eeac13463fd5d974c88794859294fbfb1
│ │     Summary:           USB 3.1 Generation 1 Hub
│ │     Current version:   01.21
│ │     Vendor:            Dell Inc. (USB:0x413C)
│ │     Install Duration:  14 seconds
│ │     GUIDs:             86fb40c0-8bf5-5a8b-a4ad-3156cf6bfaf4 ← USB\VID_413C&PID_B06F&REV_0101
│ │                        b27d25f1-019d-5718-b41a-02ddaefe5577 ← USB\VID_413C&PID_B06F
│ │                        ac5b774c-b49d-566b-9255-85f0f7f8a4ed ← USB\VID_413C&PID_B06F&hub
│ │     Device Flags:      • Updatable
│ │                        • Requires AC power
│ │                        • Supported on remote server
│ │                        • Device stages updates
│ │                        • Device is usable for the duration of the update
│ │
│ ├─RTS5487 in Dell dock:
│ │     Device ID:         acb404019656654d44f80922d94735e831d9bb40
│ │     Summary:           USB 3.1 Generation 2 Hub
│ │     Current version:   01.47
│ │     Vendor:            Dell Inc. (USB:0x413C)
│ │     Install Duration:  3 seconds
│ │     GUIDs:             707c63d2-e597-5c40-84db-9b1bb4c48d96 ← USB\VID_413C&PID_B06E&REV_0101
│ │                        acfcd89b-105d-55b9-b85b-08bf8508f38c ← USB\VID_413C&PID_B06E
│ │                        568ffa1e-a0db-5287-9ea3-872b60f7730b ← USB\VID_413C&PID_B06E&hub
│ │     Device Flags:      • Updatable
│ │                        • Requires AC power
│ │                        • Supported on remote server
│ │                        • Device stages updates
│ │                        • Device is usable for the duration of the update
│ │
│ └─VMM5331 in Dell dock:
│       Device ID:         58931e8c9ef5eead9c007563814f96fcadb1b993
│       Summary:           Multi Stream Transport controller
│       Current version:   05.04.00
│       Vendor:            Dell Inc. (USB:0x413C)
│       Install Duration:  6 minutes
│       GUID:              89fec0b6-6b76-5008-b82c-5e5c6c164007 ← MST-panamera-vmm5331-259
│       Device Flags:      • Updatable
│                          • Requires AC power
│                          • Supported on remote server
│                          • Device stages updates
│                          • Device is usable for the duration of the update
```
2019-12-12 09:44:20 -06:00
Richard Hughes
0cc22a5ff6 trivial: Document the use of vendor-id in each plugin 2019-12-11 18:10:44 +00:00
Francois Berder
bb5385de76 plugins: Fix potential use of NULL pointer in fu_dell_dock_mst_write_register
Signed-off-by: Francois Berder <18538310+francois-berder@users.noreply.github.com>
2019-11-29 06:33:09 -06:00
Richard Hughes
aed7826c8f trivial: Properly namespace the defines in the exported header 2019-11-27 12:45:35 +00:00
Mario Limonciello
6b0e66354b Convert libfwupdprivate to a shared library libfwupdplugin 2019-11-27 11:32:43 +00:00
Richard Hughes
56ac823af9 Set the protocol per-device not per-plugin
Some plugins have devices with more than one protocol. Logically the protocol
belongs to the device, not the plugin, and in the future we could use this to
further check firmware that's about to be deployed.

This is also not exported into libfwupd (yet?) as it's remains a debug-feature
only -- protocols are not actually required for devices to be added.
2019-11-25 18:01:54 +00:00
Mario Limonciello
6abe21efbd trivial: stop including fu-hash.h as part of fu-plugin-vfuncs.h
Explicitly include it in all "in-tree" plugins.

If headers are exported out of tree we will likely explicitly not
export this header.
2019-11-25 09:29:46 +00:00
Richard Hughes
18b0a739e2 dell: Use the more portable g_usleep() 2019-11-22 14:23:48 +00:00
Mario Limonciello
97c1e727c4 Add new device flags indicating update resilience
fwupd clients will ideally use this information as part of a policy to schedule
updates in the background without user interactions on safe devices.
2019-10-17 11:38:46 -05:00
Richard Hughes
8653e70480 trivial: Remove G_BEGIN_DECLS from all private headers 2019-10-09 20:02:16 +01:00
Richard Hughes
731875af86 Remove FU_PLUGIN_RULE_REQUIRES_QUIRK as all the plugins now use it 2019-10-09 20:02:16 +01:00
Richard Hughes
4b30380e78 Provide a default implementation of common FuDevice actions
This reduces the amount of boilerplate in each plugin.

    32 files changed, 156 insertions(+), 584 deletions(-)
2019-10-04 14:57:32 +01:00
Mario Limonciello
15cd821094 trivial: dell-dock: correct another write_size error
This was more fallout from 7afd7cba0d
which led to write_size being set to 0 and an endless loop.
2019-09-23 09:57:38 -05:00
Mario Limonciello
e13f7a142e trivial: dell-dock: correct an error preventing write_size from being set
This fixes 7afd7cba0d which led to write_size
being set to 0 and an endless loop.
2019-08-27 09:28:30 -05:00
Richard Hughes
6e3e62bee8 Use fu_common_string_append_kv() in subclassed device
Also define the indent level in the the ->to_string vfunc so we can correctly
print client devices in all cases.
2019-08-14 16:48:37 +01:00
Richard Hughes
5308ea4fae Never use memcpy() in a possibly unsafe way
There are several subtle bugs in various places in fwupd caused by not treating
user-provided offsets into buffers as unsafe. As fwupd runs as root we have to
assume that all user firmware is evil, and also that devices cannot be trusted.

Make a helper to put all the logic into one place and convert all users.
2019-08-12 09:22:09 -05:00
Richard Hughes
7afd7cba0d Use FuFirmware as a container for firmware images
In many plugins we've wanted to use ->prepare_firmware() to parse the firmware
ahead of ->detach() and ->write_firmware() but this has the limitation that it
can only return a single blob of data.

For many devices, multiple binary blobs are required from one parsed image,
for instance providing signatures, config and data blobs that have to be pushed
to the device in different way.

This also means we parse the firmware *before* we ask the user to detach.

Break the internal FuDevice API to support these firmware types as they become
more popular.

This also allows us to move the Intel HEX and SREC parsing out of the dfu plugin
as they are used by a few plugins now, and resolving symbols between plugins
isn't exactly awesome.
2019-08-08 13:10:57 +01:00
Mario Limonciello
ffe7fe24bc trivial: Update icons for Thunderbolt and MST devices 2019-07-30 13:15:20 -07:00
Richard Hughes
dfa9e11bb2 Allow handling FORCE for devices that subclass FuDevice
Pass FwupdInstallFlags down to the vfunc to allow us to check the flags when
parsing the firmware and updating the device.
2019-05-05 15:29:00 -05:00
Richard Hughes
5079f26f0e Never guess the version format from the version string
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
2019-04-30 09:25:41 +01:00
Mario Limonciello
398afe545f trivial: dell-dock: set minimum board to 6
Drop all TODO and quirks for older pre-production boards.
2019-04-23 13:36:30 -05:00