The PCI Vendor and Device ID locations located in firmware were mistakenly
swapped in the bcm5719-fw repository. As a result, the code here based on said
repository also has swapped IDs. This fixes the ids to reflect the
correct locations.
Signed-off-by: Evan Lojewski <github@meklort.com>
Before:
Information for the update status entry 0:
Information Version: 7
Firmware GUID: {ddc0ee61-e7f0-4e7d-acc5-c070a398838e}
Capsule Flags: 0x00000000x
Hardware Instance: 0
Update Status: attempted
Capsule File Path: /EFI/fedora/fw/fwupd-ddc0ee61-e7f0-4e7d-acc5-c070a398838e.cap
failed: Error opening file /sys/firmware/efi/efivars/fwupd-671d19d0-43c-
4852-98d9-1ce16f9967e4-0-0abba7dc-e516-4167-bbf5-4d9d1c739416: No such file
or directory
failed: Error opening file /sys/firmware/efi/efivars/fwupd-a9971959-9246-
4a5b-b2f2-ba6fdcb19349-0-0abba7dc-e516-4167-bbf5-4d9d1c739416: No such file
or directory
After:
Information for the update status entry 0:
Information Version: 7
Firmware GUID: {ddc0ee61-e7f0-4e7d-acc5-c070a398838e}
Capsule Flags: 0x00000000x
Hardware Instance: 0
Update Status: attempted
Capsule File Path: /EFI/fedora/fw/fwupd-ddc0ee61-e7f0-4e7d-acc5-c070a398838e.cap
Information for the update status entry 1:
Firmware GUID: {671d19d0-d43c-4852-98d9-1ce16f9967e4}
Update Status: No update info found
Information for the update status entry 2:
Firmware GUID: {a9971959-9246-4a5b-b2f2-ba6fdcb19349}
Update Status: No update info found
Fixes https://github.com/fwupd/fwupd/issues/2530
Although hotpluggging PCIe cards isn't common, it's how I'm testing this in the
device test enclosure. Add a tiny delay to wait for the kernel to populate the
net class on hotplug.
Unconditionally delete FWUPDATE_VERBOSE and FWUPDATE_DEBUG_LOG when deploying
the update using fwupdtool or fwupd and leave it to fwupdate.
If you want to debug the efi binary you then have to use fwupdate and squirt
the .cap file rather than using all the other layers.
Upon restarting the upstream VLI USB hub the cxaudio device re-enumerated okay
but would not service HID requests for 100ms, returning 'endpoint stalled'.
To make this more reliable retry the SetRequest up to 10 times after a short
delay to make enumeration reliable.
The GLib g_byte_array_set_size() function does not zero the contents if the
array size is larger, which leads to unpredictable output when using valgrind.
To do this without rebooting the device implement VliUsbhubPdDevice->reload()
like the other FuVliUsbhubDevice child devices.
Fixes half of https://github.com/fwupd/fwupd/issues/2376
For instance, we can tell the user that UEFI UpdateCapsule is disabled in the
system firmware, or that efivarfs is not mounted. This is much better than
creating "dummy" devices which are really just hacks around the problem because
no better API existed. THe dummy devices cause as many problems as they solve.
Plugins have to set FWUPD_PLUGIN_FLAG_USER_WARNING if a warning should be shown
to the user, and only one warning will be shown of each failure type.
It is expected that GUI clients like gnome-software and gnome-firmware would use
this API to notify the user the localized message for why firmware updates are
not being shown.
Fixes https://github.com/fwupd/fwupd/issues/2456
Add quirks for PID 5048 and 5049, which are cros-ec devices
that update via USB endpoint. Notable about these two are
they support rw_sig, for RW region signature verification.
Our update flow prior to this was:
1. On detach, reboot to RO.
2. From Old RO, Update RW.
3. Reboot to New RW
4. From New RW, Update RO.
5. Reboot to finish
This flow has a flaw, which is that the Old RO may be buggy (especially
during development, before it's actually locked down and actually Read-Only).
This change will do the following instead:
1. On detach, do not reboot to RO if RO is writeable, and we are in RW
2. From old RW, Update RO
3. Reboot to new RO
4. From New RO, update RW
5. Reboot to finish.
This has a speed advantage as well, as we save one reboot cycle (2 vs 3).
As a result of the previous change, where we send an immediate reset to
devices in order to transition back to rw, we will end up reenumerating
as RO briefly, although the destination we wanted to get to was RW.
In that case, basically skip the write firmware step, set another write
required and allow the RO firmware to complete rw_sig and jump to the rw
partition.
Previously, we sent a 'stay-in-ro' subcommand when we are in
fu_cros_ec_usb_device_reset_to_ro, which is called from the detach phase,
in other words, we are currently sitting in RW.
This is incorrect, since stay-in-ro only interrupts an RO's
rw_sig process if it is in progress.
Instead, 'stay-in-ro' must be issued when the device reenumerates in RO,
immediately before the writing sequence starts. On devices that implement
rw_sig, they will briefly enumerate as RO before self-issuing a jump to RW
on the signature check being valid. In order to stay in RO to perform a RW
partition update, we must interrupt it as soon as we see the RO version
enumerate.
- Use pci function 0 instead of 1 when flashing firmware.
In certain situations, the BCM5719 NVM controller can lockup if
a function other than 0 is used to read from NVM word-by-word like
the kernel driver does.
- Fix APE_MODE offset in BAR[2] to enable proper resetting of the APE.
- Remove unnededed NVRam lock when resetting the APE.
Signed-off-by: Evan Lojewski <github@meklort.com>
1. Check FW in bootloader mode, need send reset command to firmware.
2. IAP Type register parameter is defind as how many bytes/page to be written.
3. Write IAP Type function in detach function.
4. Remove IAP Type function in setup function.
5. Modify page format for i2c-device
6. Modify firmware bin file size.
7. Modify firmware update flow when the firmware in bootloader mode.
8. Add another instance ID which corresponds to the IC type & module ID
* `ELANTP\ICTYPE_09&MOD_1234`
9. Add Lenovo ThinkPad X1 nano gen1 to elantp.quick
10. Add recovry device - lenovo thinkpad x1 nanao gen 1
11. Add elan touchpad device - vid:04f3 pid:314f
12. Set the firmware version when the firmware is incorrect.
Setting the default to number unconditionally causes problems when the device
is created using _register_proxy_device().
Based on a patch by Mario Limonciello <mario.limonciello@dell.com>, many thanks.
When support for dynamically mounting disks was added for 25ba41579f
udisks2 became a harder dependency and it was less obvious to users.
Create devices but show an error in why devices aren't updatable if
it's not found.
Users can still configure ESP manually in `uefi.conf`
Fixes: #2444
The FWUPD_INSTALL_FLAG_FORCE flag has really unclear semantics, and ignoring a
file CRC, checksum or model ID should only be done when using fwupdtool actually
debugging a plugin or firmware parser.
Use the existing --force flag when we want a "gentle nudge" like reuploading
previously processed reports.
This allows us to handle this in the plugin, which might mean detaching the
*proxy* device. It's also very important as a few plugins reboot the device
in ->attach() to get the new firmware version, which isn't required for a dump.
This partially reverts a58510b246 and does the
detach and attach in the few plugins where actually required.
With how well fwupd UEFI updates work these days >99% of people
don't need to see messages about the capsule update running.
Those who have problems, this isn't going to help them.
Firsly, that HSI isn't expected for embedded devices and then secondary how we
require SecureBoot to be available for HSI:1
At the moment we get a runtime failure if it is disabled. Making SB a part of
`HSI:1` makes this requiremnt explicit and prevents us getting `HSI:2!` if it
is not available.
The 721C is a VL103, which isn't a FuVliUsbhubDevice at all. Fixes the:
already set GType to FuVliPdDevice, ignoring FuVliUsbhubDevice
...message when the Mini dock / powered hub is inserted.
Use one of the errors mapping to FWUPD_UPDATE_STATE_FAILED_TRANSIENT to avoid
uploading a failure report for something the user has to fix, i.e. update the
distro shim package.
Conceptually we were trying to stuff subtly different actions into one vfunc:
* Read firmware from the device to update the verification checksums
* Read a firmware blob from the device for debugging
For the first action we might want to mask out the sections of the flash with
serial numbers (so the verification hashes match the ones published on the LVFS)
and for the second we want just a raw ROM file from the hardware with no
pre-processing that we can compare against an external SPI dumper.
Split out ->dump_firmware to get the raw blob, and allow plugins to also
implement ->read_firmware() if they have to mask out specific offsets or remove
specific images from the FuFirmware container.
In the common case when masking is not required, fall back to using a 'binary'
FuFirmware automatically to make most plugins simpler.
At the moment there are commands to convert one file format to another, but not
to 'merge' or alter them. Some firmware files are containers which can store
multiple images, each with optional id, idx and addresses.
This would allow us to, for instance, create a DfuSe file with two different
raw files that are flashed to different addresses on the SPI flash. It would
also allow us to create very small complicated container formats for fuzzing.
This can be used by writing a `firmware.builder.xml` file like:
<?xml version="1.0" encoding="UTF-8"?>
<firmware gtype="FuBcm57xxFirmware">
<version>1.2.3</version>
<image>
<version>4.5.6</version>
<id>header</id>
<idx>456</idx>
<addr>0x456</addr>
<filename>header.bin</filename>
</image>
<image>
<version>7.8.9</version>
<id>payload</id>
<idx>789</idx>
<addr>0x789</addr>
<data>aGVsbG8=</data>
</image>
</firmware>
...and then using something like:
# fwupdtool firmware-convert firmware.builder.xml firmware.dfu builder dfu
This is only applicable for kernel 5.9 or kernels that backported
the authenticate on disconnect patches.
For installation time this isn't very important since no device will
restart. This also isn't relevant for the authenticate on disconnect
scenario.
However the manual activation scenario, it's important to activate the
WD19TB device first, followed by Thunderbolt.
I2C doesn't have any specification for what is a probe and what is a more
destructive action. Sending tx_buf out on the i2c bus to a generic address
might not be safe in all cases.
To prevent this, use a HWID to check the machine DMI value during device
creation before ->probe() or ->setup() is called on the device.
If the device is not authorized, it may cause a composite update that it's part
of to not behave properly.
If device is authorized at runtime, add updatable flag at runtime as well
See #2374 for more details
This ensures we perform the updates in this order:
* cxaudio
* vli
* thunderbolt
As any other order causes enumeration failures.
Fixes some of https://github.com/fwupd/fwupd/issues/2377
Error will show up if (priv->physical_id == NULL) on
fu_device_ensure_id(). This method is called after probe but before
setup on fu_device_open.
Call fu_device_set_physical_id() on fu_thunderbolt_device_probe()
for the retimer case.
Fixes https://github.com/fwupd/fwupd/issues/2371
Change-Id: I0e462fff5e8abf6073318f6424b6736afc8259b8
This object derives from FuDevice rather than FuVliDevice and so does not
inherit the NO_GUID_MATCHING flag like other devices.
Fixes https://github.com/fwupd/fwupd/issues/2364
It seems the MEI parameters are not set for platforms such as Apollo Lake.
The only bit set was FPF_SOC_LOCK, with the others all cleared to zero.
Fixes https://github.com/fwupd/fwupd/issues/2335 for a peculiar definition of 'fix'.
As described in DFU protocol (7. Manifestation Phase), after the
firmware reprogramming is done, if bitWillDetach = 1, it doesn't
require the host to issue a USB bus reset, but the device can
generate a detach-attach sequence itself to go back to normal.
Add a quirk flag "no-bus-reset-attach" to skip the bus reset in
dfu_device_attach(), and increase the "RemoveDelay" as well.
Print the sysfs path for devices deriving from FuUdevDevice, which also allows
us to use FU_UDEV_DEVICE_DEBUG without monkey-patching the plugins that also
define a device_class->to_string() vfunc.
For some Poly USB Cameras, it takes a longer time than the
default (FU_DEVICE_REMOVE_DELAY_RE_ENUMERATE) for being detached
to DFU or attached to normal mode. Need to specify the timeout in
"RemoveDelay" quirk key.
Also replace the hard-coded timeout with fu_device_get_remove_delay()
in dfu-tool.c.
Some devices may accumulate the firmware image and perform the
entire reprogramming operation at one time. In this case, the
device enters dfuMANIFEST-SYNC or dfuMANIFEST state after
dfuDNLOAD-IDLE.
The fwupd shall be able to poll the status from the device via
DFU_GETSTATUS until the device completes the reprogramming or
reports an error.
For details, please refer to Section 7. Manifestation Phase and
A.1 Interface State Transition Diagram in the USB DFU protocol.
https://www.usb.org/sites/default/files/DFU_1.1.pdf
For not affecting the other DFU capable devices, introduce a quirk
"manifest-poll" to limit the logic.
The nr_chunks is defined as an unsigned short, the max value is
65536. Assume the transfer_size reported by device is 4096, the
maximum size of DFU firmware supported is 65536 * 4096 = 256MB.
To support larger DFU firmware, we can change the guint16 to
guint32.
This implements the following simple state machine:
1. Reboot to RO, Update RW first, set ANOTHER_WRITE_REQUIRED
2. Second time around, don't reboot into RO. Stay in RW.
3. Update RO.
4. Done.
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`)
This is much more efficient than parsing hundreds of lines of /proc/cpuinfo
and also causes hundreds of thousands less allocations at startup. For systems
with dozens of virtual CPUs the deduplication of device objects was increasing
start up time considerably.
Use the msr plugin to read the microcode version as this is not obtained using
CPUID, as it is instead being provided in an MSR.
To do this mount all ESP partitions and check all the binaries there to see if
they match any entries in the new dbx. If we applied the update when a hash
matched, we would unintentially 'brick' the users machine, as the grub and shim
binaries *have* to be updated first.
This functionality does reimplement the PE hashing functionality found in
sbsigntools and pesign. This was done for 4 main reasons:
* There were some memory safety issues found when fuzzing random binaries
* Executing the tools hundreds of times was a lot of overhead
* Operating from a blob of immutable mmap'd memory is much faster
* We only need a very small amount of functionality from both tools
The I²C proxy specification is not always shared with all other devices as
I originally hoped, instead there are other legacy devices that use different
sets of I²C commands.
Un-share various bits of code to allow for additional I²C devices to be added.
No logic changes.
Write the firmware to the usb device, first finding which section to
write to, then breaking into blocks (based on maximum pdu size),
and then into chunks, which are transferred to the device using bulk transfers.
The register specifications have been taken as a superset of the coreboot
documentation as different flags were documented in more detail on various
different platforms.
Having this new data allows us to add future tests and make the current tests
much easier to understand.
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.
This was an overloaded use of UpdateMessage that didn't make sense.
It doesn't affect the functionality of updating, just the security.
Hints about why the TPM PCR0 reconstruction failed should go
to the wiki page not the device.
We'll instead check this when the user tries to run an update. This
allows them to sign a bootloader after the daemon starts (or remove
a signed bootloader after starting)
Fixes: #2219
Trying to explain why ICL thunderbolt isn't updatable doesn't help
people. It just causes fwupdmgr and fwupdtool to show the device
front and center with a confusing message.
Instead don't populate the message and by the default device filter
it will be hidden.
See #2212 for background.
Reading the sysfs file seemed to have also eaten the `\n` as mentioned
on a bug.
```
├DW5821e Snapdragon X20 LTE:
│ Device ID: fa707b9af86ff44bc17316b6c3e5ea82aab3ce86
│ Summary: Mobile broadband device
│ Current version: T77W968.F1.0.0.4.2.GC.010
│ Vendor: Dell Inc. (USB:0x413c
│ )
│ GUIDs: 64da2d58-8d1b-5e5b-b793-f88ba5a25a8f
│ 761d6124-0002-5185-b767-9adf67bf1a5e
│ 795e079d-093b-5503-aa59-35b832480e95
│ Device Flags: • Updatable
```
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`
This plugin is only enabled when coreboot isn't detected.
It intentionally does not check for EFI to be disabled at startup
since it can also notify the user that UEFI capsule updates are
disabled on the system even if running in UEFI mode.
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.
Add two new vfuncs that can be used to collect report metadata from devices
both before and after the update has run. This means we can remove the hacks
where we set add 'global' metadata entries and just hope that there is only one
device from the same plugin that is updated.
This also allows us to collect debugging metadata from devices after an offline
update has been run.
As both hub devices share a FuVliUsbhubDeviceClass instance we cannot 'hijack'
the vfuncs depending on object type. This allows the downstream hub to proxy to
the upstream hub where a GPIOB reset can be performed.
We can have multiple FuVliPdDevice objects registered with the daemon, but they
will all share the FuVliPdDeviceClass instance. If one device requries a
silicon workaround, do not 'hijack' the vfunc for all devices of this type.
This means we do the right thing when updating both the one that requires the
workaround, and the 'normal' one.
Provide the following metadata:
"Dirty firmware" bit
Protocol version
Header type
Maximum PDU Size
Flash protection status
Raw version string
Key Version
Minimum rollback
This should do the bulk transfers using protocol 6.
The output here is now equivalent to the output of
usb_updater2 -d 18d1:501a -f
fwupdtool --plugin-whitelist cros_ec get-devices --verbose
Servo Micro
DeviceId: 84d0e3f2a0f8b2328f7995767b23ebb40494723f
Guid: 8e2f7625-a164-55d7-8f09-f193c8ec33f1 <- USB\VID_18D1&PID_501A&REV_0100
Guid: 13564257-c649-586d-b4e4-4f048d480f36 <- USB\VID_18D1&PID_501A
Serial: CMO653-00166-040491U00771
Summary: Servo Micro (aka "uServo") Debug Board
Plugin: cros_ec_usb
Flags: registered
Vendor: Google Inc.
VendorId: USB:0x18D1
Version: servo_micro_v2.4.17-df61092c3
VersionFormat: plain
Created: 2020-05-20
PhysicalId: usb:03:00:02
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
```
See also: https://github.com/fwupd/fwupd/issues/2119
Reported-by: Anton Farygin <rider@altlinux.org>
Based on a patch by Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Fixes cross compilation for arm with clang which provides cpuid.h
but helpfully has this error:
```
#if !(__x86_64__ || __i386__)
#error this header is for x86 only
#endif
```
Fixes: #2131
To do this, rely on the AppStream ID to map to a translated string (providing a
fallback for clients that do not care) and switch the free-form result string
into a set of enumerated values that can be translated.
This fixes some of the problems where some things have to be enabled to "pass"
and other attributes have to be some other state. For cases where we want the
user to "do" something, provide a URL to a wiki page that we update out-of-band
of fwupd releases.
This only checks that it was available from the CPU.
To be complete an additional check should be made to show that it
was actually enabled from the firmware.
This will require a kernel modification though because MSR access
will be forbidden from userland while in kernel lockdown.
The kernel patches are a log way from being upstreamed, so disable this until
there is even a chance the user might be running it.
This removes the obsoletes line from *every* system running 'fwupdmgr security'.
We can read this from userspace even when SB is turned on and with the kernel
locked down. The kernel securityfs patches are still in-progress, but will take
significant time to get upstream.
The kernel patches are needed when the PCI device is hidden from userspace.
On a system that is not at all locked down running an old kernel several
of the items are a bit confusing.
```
Runtime Suffix -!
✔ fwupd plugins: OK
✔ Linux Kernel: OK
✘ Linux Kernel: Could not open file
✘ Linux Swap: Not encrypted
```
The HSI specification is currently incomplete and in active development.
Sample output for my Lenovo P50 Laptop:
Host Security ID: HSI:2+UA!
HSI-1
✔ UEFI dbx: OK
✔ TPM: v2.0
✔ SPI: Write disabled
✔ SPI: Lock enabled
✔ SPI: SMM required
✔ UEFI Secure Boot: Enabled
HSI-2
✔ TPM Reconstruction: Matched PCR0 reading
HSI-3
✘ Linux Kernel S3 Sleep: Deep sleep available
HSI-4
✘ Intel CET: Unavailable
Runtime Suffix -U
✔ Firmware Updates: Newest release is 8 months old
Runtime Suffix -A
✔ Firmware Attestation: OK
Runtime Suffix -!
✔ fwupd plugins: OK
✔ Linux Kernel: OK
✔ Linux Kernel: Locked down
✘ Linux Swap: Not encrypted
This exports FuSecurityAttrs into libfwupdplugin so that we can pass the plugins
this object rather than a 'bare' GPtrArray. This greatly simplifies the object
ownership, and also allows us to check the object type before adding.
In the future we could also check for duplicate appstream IDs or missing
properties at insertion time.
This change also changes the fu_plugin_add_security_attrs() to not return an
error. This forces the plugin to handle the error, storing the failure in the
attribute itself.
Only the plugin know if a missing file it needs to read indicates a runtime
problem or a simple failure to obtain a specific HSI level.
MATEKF722SE has unconvetional behavior for dfu protocol, where the sector size
isn't specified and sector type is shiffted left by 1. This happens only for
one sector.
Sector parsing from MATEKF722SE:
* `016Kg`
* `64Kg`
* `128Kg`
* `048 e`
* `528e`
* `004 e`
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.
New enough hardware to have this feature isn't going to be in the marketplace
for a while. To use that newer hardware requires a very recent kernel (5.6 at
least, although it will probably be at least 5.9 by the time the hardware is
released).
The CET status will be used in future functionality.
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.
Thunderbolt images brought in from the SPI don't have a FARB header.
Thunderbolt update images do.
So these two types of images need to be handled separately from the
firmware parser.
The kernel interface for force power doesn't support tracking the state
of the device, and so this had to be tracked by fwupd.
Unfortunately due to system and thunderbolt controller firmware behavior
on some systems the thunderbolt controller /still/ didn't return even
when force power state was accurately tracked.
The device model for the uevent related to the device removal being ignored
doesn't really fit into the current fwupd architecture anymore either.
Lastly this is a very legacy feature at this point. Thunderbolt3 controllers
distributed in the last 3 years all operate in 'native' mode meaning that
they will always be powered and use runtime power management.
USB4 controllers won't have a concept of being force powered.
USB4 reimers will have this concept, but the state will be tracked by the
kernel and obfuscated from userspace.
So with all that said, tear out all of the force power related code.
Remove it's references to it's own GUdevclient and instead use
FuUdevDevice.
Some intentional casualties of the move:
* Plugin metadata around native and safe mode dropped.
- These haven't been useful in debugging anything and aren't relevant
on new hardware
* Extra GUID for 2 host controllers in same system dropped
- Although this was normally static information BIOS operations like
turning off PCI-E SD card reader or LAN controller changed things.
* The NVM version is parsed directly instead of through gudev to prevent
cached data breaking change events.
Remaining TODO:
* Force power w/ thunderbolt-power doesn't work
USB4 Controllers were showing up like this:
USB4 Controller:
Device ID: 3df660bc4bdb67fd6fc101b34c6fd8cd235e3f97
Summary: Unmatched performance for high-speed I/O
Current version: 00.00
Update Error: Device is in safe mode
GUID: 4d86f168-e1cc-5995-afd3-ae9df6a14f5e -> TBT-safemode
Device Flags: Internal device
Requires AC power
As a consequence, the version number is also set in the event that the silicon
or firmware app-id is not set, which also seems like the right thing to do.
The idea here is that the device would not come back after it was restarted,
and skipping the attach in the engine was only working around the fact that the
ebitdo did not split out an ->attach() function.
We can't really blame it; we only decoupled the _IS_BOOTLOADER requirement
for ->attach() recently...
The USB 2.0 controller is used as a 'backup' in case the USB 3.0 firmware fails
to start. Set USB 3 hubs as a greater priority so that the USB 2 ones do not
not get added if the USB 3 firmware is working.
These are a regression of 9e755e2a5 when devices are asleep.
However due to the current kernel and daemon architecture, logitech devices
are not checked again at any time so if the device isn't awake when
fwupd is started or the unifying dongle is plugged in it won't be present.
This will be changed in the future when the kernel has change events
associated with devices waking up.
Fixes: #1973
This also means we do the right thing when plugins call fu_device_add_flag()
directly, instead of just from a quirk file.
For instance, now `Flags = ~updatable` is a valid and useful thing to have and
allows us to remove the `Flags = None` hack.
This is nice in theory, until you need to look at the bootloader status of the
parent, or of a different device entirely. Handle this in plugins for the few
cases we care about and stop setting or clearing IS_BOOTLOADER manually just to
get the vfuncs to be run.
Note: I do not think we want to use cleanup() for attaching devices not in
bootloader states -- as cleanup is only run at the end of the composite update.
Doing this unconditionally means we accidentally 'bleed' one device mode into
another in a non-obvious way. For instance, a device might have two operating
modes with different GUIDs. If firmware is supplied for both modes in the same
cabinet archive then we might accidentally match the 'wrong' firmware when
the daemon has observed a mode switch and added the counterpart GUIDs.
We only really need the counterpart GUIDs when switching between Jabra, 8bitdo
and DFU devices where the DFU bootloader VID:PID is not manually tagged with
`CounterpartGuid` in a quirk file. In the general case lets keep it simple to
avoid difficult to find bugs.
The cleanup action for the FuVliUsbhubPdDevice is correct, but was not
conditionalized in the composite cleanup, which meant we would reboot twice
for a normal USB hub update.
Move the parent reboot into the right place, although this does mean we might
reboot twice in the rare event of scheduing a FuVliUsbhubPdDevice *and*
FuVliUsbhubDevice update in the same transaction -- but resetting the device
state between updates is arguably correct anyway...
