-this is indeed needed to reflect the updated version after system reboot
Signed-off-by: Kranthi Kuntala <kranthi.kuntala@intel.corp-partner.google.com>
Change-Id: Id4751d531528590cc93c08db0d0939a547f4d59f
This method does not indicate whether the kernel has enabled encryption.
That information is only visible from the kernel log at this time.
Continue to read the MSRs though, because if/when we get a method for the
kernel to export it we may use these as a basis of "support" but not a
indication of it being enabled.
encrypted:
```FuPluginMsr SME/SEV check MSR: eax 01000f, ebx 016f
FuPluginMsr PCI_MSR_AMD64_SYSCFG: 0f40000, sme_is_enabled=1
FuPluginMsr PCI_MSR_AMD64_SEV: 00, sev_is_enabled=0
```
not_encrypted:
```
FuPluginMsr SME/SEV check MSR: eax 01000f, ebx 016f
FuPluginMsr PCI_MSR_AMD64_SYSCFG: 0f40000, sme_is_enabled=1
FuPluginMsr PCI_MSR_AMD64_SEV: 00, sev_is_enabled=0
```
Add a quirk for NovaCustom NV4x devices.
These laptops are running coreboot and are updatable using flashrom.
The HwId GUID matches to both previous Insyde firmware and the current
Dasharo firmware. The Dasharo GUID matches to the devices running
Dasharo firmware. This way the device can be switched from Insyde
to Dasharo using `fwupdmgr switch-branch`.
Homepage: https://configurelaptop.eu/nv40-series/
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
The initial name of the varianle has been changed upon review in
[nrf_desktop DFU PR](https://github.com/nrfconnect/sdk-nrf/pull/6343)
This commit align the naming with NRF desktop upstream and fix testing
images URLs for device testing.
This is the ID assigned to STMicroelectronics... more specifically for
a mini LED display. It also seems to be used by other vendors who also
did not change the default from the devkit, e.g. the Vaydeer Multimedia
Console.
Fixes https://github.com/fwupd/fwupd/issues/4180
The logic was built on the presumption of Ubuntu core which doesn't
have /etc/os-release. Since other distributions do have /etc/os-release
adjust the logic to instead build the path explicitly.
When fastboot is used, the modem is rediscovered through udev
after upgrading. However, the modem-manager plugin did not mark
the modem as unhibited with ModemManager. This resulted into
ModemManager not exposing the modem without restarting ModemManager or
rebooting the device.
Mark the modem as uninhibited and do not take ownership over the
plugin data as this caused segfaults.
At the moment a lot of the failures are only visible when running the
daemon in verbose mode, and the inhibit functionalit provides us a way
to unset FWUPD_DEVICE_FLAG_UPDATABLE from multiple places, as well as
setting the update error for the user to see why.
Although they do a lot of the same things, trying to deal with both
kinds of device in the same GObject type was making it very hard to
understand and maintain.
Split out two GObjects that both derive from FuThunderboltDevice.
This leads to reports of:
systemd-modules-load[1710]: Failed to insert 'ipmi_si': No such device
systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
This allows us to replace the 'dfu-tool replace' with a much more
controlled 'fwupdtool firmware-patch' command that patches at a set of
specific offsets.
Drop in the new functionality into the existing firmware ->write()
vfuncs so that the image headers, footers and/or checksums are correct.
It's a common action for plugins to call FuUsbDevice->open() then claim
interfaces, and then release them just before FuUsbDevice->close().
It's also something a lot of plugins get wrong, so provide common code
to handle it correctly in one place.
