Created lspcon-i2c-spi flashrom device that uses udev to detect i2c
devices that can be updated with the lspcon-i2c-spi flashrom programmer.
This change implements the logic from crrev.com/c/2792124 adapted to the
upstream flashrom plugin.
This change allows other device types to derive from common flashrom
code in the flashrom-device type.
Change-Id: Ic963fd586e0a73153c54889fce50055753a1bf5c
Due the lack of pei-aarch64 support in binutils, the gnu-efi crt0 harcodes
the PE32+ sections among other things. These crt0 aren't aware of the SBAT
section and so custom ones have to be used.
In the same vein as commit cfd1f2f42a ("uefi-capsule: Ensure SBAT metadata
is added correctly") included custom linker scripts, this change add a set
of crt0 for arm and aarch64 that hardcode a SBAT section in the PE headers.
These are the crt0 from gnu-efi plus the following fixes from Peter Jones:
* Include .sbat in section headers
* Fix some PE headers
* Calculate the VirtualSize of .sbat separately
* Put .rel* and .dyn* in .rodata
The linker scripts used in the project were copied from the shim project,
but there were a few fixes made after this original copy.
Until binutils have proper pei-aarch64 support, the linker scripts should
be kept in sync to make sure that the PE32+ binaries are built correctly.
The fixes included in this change are the following:
* Include missing .text sections in PE/COFF binary (Chris Coulson)
* Put .sbat after _edata (Peter Jones)
* Fix some PE headers for arm and aarch64 (Peter Jones)
* Include the aligned part in SizeOfRawData of sbat for arm and aarch64 (Gary Lin)
* Swizzle some sections to make old sbsign happier for arm and aarch64 (Peter Jones)
* Put .rel* and .dyn* in .rodata for arm and aarch64 (Peter Jones)
This allows plugins to set the battery power state of the *machine* which means
we can automatically inhibit devices with FWUPD_DEVICE_FLAG_REQUIRE_AC set.
It also allows to set the BatteryThreshold to 25% for Lenovo hardware, and we
can override other vendors with further quirks as required.
Fixes https://github.com/fwupd/fwupd/issues/3084
The activation flag is stored into the history database, but not all
plugins will want to inherit it on coldplug the next time the daemon
is started.
For example the Dell Dock plugin will query this information from the
device and it will prevent getting into a bad state as a result.
Fixes: #3106
We were seeing:
,----
| (dfu-tool:1139827): GLib-WARNING **: 17:34:42.671: GError set over the top of a previous GError or uninitialized memory.
| This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
| The overwriting error message was: no device matches for 1234:abcd
`----
This is because we were attempting to overwrite libgusb's error with one
for fwupd, and glib rightfully complains. So let's prefix it instead.
If only one plugin is enabled and there exists a device match for a GType that
has not been registered then the user sees a GType error about not being able
to create a device that wouldn't be created anyway.
By removing the error in the quirk parser we will catch actual errors in
fu_plugin_runner_backend_device_added() which actually does chcek for
FWUPD_PLUGIN_FLAG_DISABLED.
Fixes https://github.com/fwupd/fwupd/issues/3099
Add the IFD regions as child devices and set the region access on the child
devices. Also add read-only SPI descriptor as an HSI attribute and require
FLOCKDN on Intel hardware.
Use the hidden PCI 00:1f.5 device to set the SPIBAR automatically and generate
the quirk file automatically to support more hardware.
There is a lot of code in fwupd that just assigns a shared object type to
a FuPlugin, and then for each device on that plugin assigns that same shared
object to each FuDevice.
Rather than proxy several kinds of information stores over two different levels
of abstraction create a 'context' which contains the shared *system* state
between the daemon, the plugins and the daemon.
This will allow us to hold other per-machine state in the future, for instance
the system battery level or AC state.
Although a 4-state question encodes all the possibilities entirely correctly,
it's not easy for end users to understand. Replace the 2x2 logic by two boolean
questions.
This also has the advantage that we only offer to make the upload automatic if
the initial upload actually succeeded.
We already have two things managing the UPDATABLE_HIDDEN->UPDATABLE transition,
and we're about to add a third.
Add a 'stackable' inhibit-style API so we do not accidentally mark a device as
updatable when it should remain hidden.
Some users are enabling updates-testing and then wondering why there are no more
firmware updates available. It appears after a 'fwupdmgr refresh' but that's
not obvious to end users who don't know about how this stuff is built.
