Wacom has begun migrating its current Intuos product line to a new
Bluetooth chipset. This new revision uses new PIDs as well so we
need to update the quirks list.
Wacom is beginning to integrate a new Bluetooth chipset in their
devices. This chipset uses a somewhat different flash protocol
and requires the creation of a new fwupd module. Chipsets using
this new protocol are identified in the firmware descriptor with
ID 0x06, leading to our choice of module name: "bluetooth-id6".
The new chipset is first appearing in a minor update to the Wacom
Intuos (CTL-4100WL/CTL-6100WL) line. These devices do not support
the firmware descriptor interface, requiring us to statically assign
it as a module in the legacy codepath if any Bluetooth support is
found. This clutters the output of the `get-devices` command but the
update CAB files ensure the correct module is used depending on PID.
Timeout characteristics of the start/data/end commands can vary between
modules. Rather than leaving `fu_wac_module_set_feature` responsible for
setting a globally-reasonable timeout, allow the callers to specify a
locally-optimal value instead.
It may make sense to have the modem not doing anything during the upgrade,
so the inhibition would make total sense.
Signed-off-by: Jarvis Jiang <jarvis.w.jiang@gmail.com>
We only had to pile everything into the src/fuzzing/firmware directory
because honggfuzz could not cope with more than one input path.
This way each plugin is self contained and easy to copy.
Also, install the fuzzing builder objects as this fixes the installed
tests when srcdir does not exist.
Based on a patch by Jan Tojnar <jtojnar@gmail.com>, many thanks.
This allows us to override the location we load data files from, which
allows us to do more kinds of installed tests in the future.
Also, move the global data/tests content into the place that it is used
as it was getting impossible to manage.
Now two plugins are using hardcoded SPI constants for various CFI chips,
and it makes sense to have some common quirk data that can be used by
both.
Add a FuSpiChip helper object that can be used by FuDevice subclasses
to get the specific SPI commands to use for each flash ID.
This has not worked well in some time, and nobody noticed. The
alternative Google clusterfuzz support is better in every way and gets
run as part of CI.
In reality these are not super interesting as they only happen on
`->write()` and not `->parse()`.
In other news, the fuzzer now appreciates how critical the alignment
is, which is probably a good thing generally.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40088
There's no actual hardware to test this against yet, but this is how I
would lay out a plugin if there was.
We still need to work out a generic encapsulation for the offer and
payload (for each component and bank) so this can work with LVFS and
fwupd.
This avoids clashing with real-world devices that have the same VID/PID.
Many thanks to Ricky WU <ricky_wu@realtek.com> for all the help.
Fixes: https://github.com/fwupd/fwupd/issues/3835
Additionally, if the client does not set the feature flag `fde-warning`,
add an extra paragraph into the update description.
Fixes https://github.com/fwupd/fwupd/issues/3829
Resetting the CMOS before a write when switching branch will cause a lock on\
reboot which requires hard power off.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
