Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
The dell-dock plugin has a check whether or not to create the I2C based
child device based upon whether thunderbolt link is active during probe.
So there will never be a situation that daemon needs to de-duplicate and
set priority between the two plugins.
Data is accessed at offset 0x13, so the code must abort if size is
0x13 when you can access only offsets 0x00 through 0x12.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Otherwise the following build error happens:
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:54:10: error: ‘G_USB_DEVICE_DIRECTION_HOST_TO_DEVICE’ undeclared (first use in this function)
54 | G_USB_DEVICE_DIRECTION_HOST_TO_DEVICE,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:54:10: note: each undeclared identifier is reported only once for each function it appears in
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:55:10: error: ‘G_USB_DEVICE_REQUEST_TYPE_VENDOR’ undeclared (first use in this function)
55 | G_USB_DEVICE_REQUEST_TYPE_VENDOR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:56:10: error: ‘G_USB_DEVICE_RECIPIENT_DEVICE’ undeclared (first use in this function)
56 | G_USB_DEVICE_RECIPIENT_DEVICE,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c: In function ‘fu_analogix_device_receive’:
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:96:10: error: ‘G_USB_DEVICE_DIRECTION_DEVICE_TO_HOST’ undeclared (first use in this function)
96 | G_USB_DEVICE_DIRECTION_DEVICE_TO_HOST,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:97:10: error: ‘G_USB_DEVICE_REQUEST_TYPE_VENDOR’ undeclared (first use in this function)
97 | G_USB_DEVICE_REQUEST_TYPE_VENDOR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:98:10: error: ‘G_USB_DEVICE_RECIPIENT_DEVICE’ undeclared (first use in this function)
98 | G_USB_DEVICE_RECIPIENT_DEVICE,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and more...
On Alterlake and newer hardware the Platform Health Assessment Record
data can be used by the IHV to debug why a specific capsule update
failed. Any custom firmware loaded by the OEM can be identified and
used to further debug the root cause.
The code currently assumes that the firmware sections are in sorted
order (e.g. using images_cnt as the current index). This seems to
be the case with real firmware images, but is not actually guaranteed
by anything. Rewriting the code to use the actual index from the WA
header is a little difficult so just assert this condition for now.
The value of `self->firmware_index` is not valid until we call
`fu_wac_device_ensure_firmware_index`. Because of this, we would always
request the firmware for index 0. If that slot is currently active then
our attempt to program it will fail since the pages are write-protected.
Annoyingly the only signs that something has gone wrong are that the
flash completes almost instantly and the firmware version never changes.
To fix this we re-order our usage of the variable to be after it
becomes valid. We also add a noisy failure message that is triggered
if no blocks are written.
Fixes: 7afd7cba0d ("Use FuFirmware as a container for firmware images")
Version numbers used by Wacom firmware are typically coded as packed BCD
numbers. The minor version numbers are typically rendered with leading
zeros in the wild, though it appears fwupd doesn't follow this same
visual convention.
Some example versions:
* { 0x00, 0x05 } --> 0.05 (Wacom rendering) / 0.5 (fwupd rendering)
* { 0x01, 0x01 } --> 1.01 (Wacom rendering) / 1.1 (fwupd rendering)
* { 0x01, 0x23 } --> 1.23 (Wacom rendering) / 1.23 (fwupd rendering)
Fixes: 872ec1b68f (Add an experimental plugin to update some new Wacom tablets)
