Add new flag can receive HID report over Interrupt In endpoint instead
of control endpoint.
This commit also fixes a false error within software reset function.
Note that g_assert() should not be used in unit tests, since it is a
no-op when compiling with G_DISABLE_ASSERT. Use g_assert() in production
code, and g_assert_true() in unit tests.
See https://github.com/fwupd/fwupd/issues/3790
The restart message is supposed to be HIDPP_REPORT_ID_LONG according to
the specs, but it works just as well if we use
HIDPP_REPORT_ID_SHORT. We better stick to the specs, though.
Quite a few plugins are using a FuDeviceLocker to detach then attach in
the error path, and finding them isn't easy as we explicitly cast to a
FuDeviceLockerFunc.
For sanity, just provide both symbols so we can do the right thing in
both cases. It seems like a sensible thing to allow.
Fixes https://github.com/fwupd/fwupd/issues/3771
Using fu_common_strnsplit() has the drawback that a malicious user (or
a fuzzer!) could create a file with 5,000,000 newlines, and then pass
that into any parser that tokenizes into lines. This causes millions of
tiny allocations and quickly dirties hundreds of megabytes of RSS due
to heap overheads.
Rather than splitting a huge array and then processing each line, set
up a callback to process each line and only allocate the next string if
the token was parsed correctly. This means that we don't even dup the
buffer before we start parsing, rather than allocating everything and
then failing at the first hurdle.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38696
Since commit 078beaf, device de-duplication between plugins doesn't
work anymore. Both the TPM and Dell plugin create a device with an
identical physical ID and no logical ID. This makes the device list
think whichever plugin probes second is just updating the first.
To avoid this problem, set a logical ID in the Dell plugin, ensuring
that the device ID built from physical + logical is different from the
TPM plugin.
The side effect of this is that both devices will export into the device
list, but the TPM plugin's devices will not be upgradable.
I'm finding errors in a crostini container that the MSR plugin tries
to run and fails later. The plugin just shouldn't be passing startup
if /dev/cpu isn't present.
We actually check for fu_device_add_guid() not being an actual GUID,
but in the future we'll be warning if we do this magic fallback as it
hides not-quite-GUID typos.
No behaviour change.
CAPE family is Audio DSP for a board range of applications in IOT, PC
and mobile can be interfaced via I2C, UART or USB interface. This patch
is only for CX31993 and CX31988 chips, there is not immediate plans is
to add support to other CAPE devices.
CX31993 have two separate firmware .hid file for for each partition. It
need to convert two .hid files into a .fw file for fwupd tool to
consume.
Currently, this patch is only support for EPOS headsets with basic
firmware update feature. Either new code singing or manifest.xml are
unsupported yet.
The code has been tested with CX31993 EVK board.
A test firmware file is put at 'src/fuzzing/firmware/synaptics-cape.fw'
synaptics-cape: Port to new FuProgress API and style fixups
synaptics-cape: Fix compile errors and add missing test fw file
Signed-off-by: Simon Ho <simon.ho@synaptics.com>
synaptics-cape: Fix fuzzer test
Signed-off-by: Simon Ho <simon.ho@synaptics.com>
synaptics-cape: Fix progress bar number
Signed-off-by: Simon Ho <simon.ho@synaptics.com>
synaptics-cape: Mark the fuzzing target
trivial: Use a stable GLib branch for fuzzing
synaptics-cape: Fix progress bar number
Signed-off-by: Simon Ho <simon.ho@synaptics.com>
synaptics-cape: Fix readme
synaptics-cape: Style fixups
synaptics-cape: Fix progress bar percentage
synaptics-cape: Style fixups
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
Reset the CMOS based on a private flag. Tested on coreboot using an
offset of 123. Required when a CMOS layout or default option has
changed as the resulting flash will have 0's for the modified option.
