My compiler doesn't understand -Wno-discard-qualifiers so drop it and
fix the warnings instead. I think it is better to explicitly fix them
anyways instead of just to ignore the discarded const qualifier in
general.
I think the option should be avoided in hand-written code. The warning
is there for a reason: To protect you from possibly overwriting data you
expect to not be modified when passing pointers around.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41215
This significantly speeds up the test suite.
They can't really be easily represented anyways in the test suite
since the devnode would have to change so much between steps.
Although the same payload is used for all 3 MST hubs in TB16 or WD15
it's possible this may change one day. Create separate GUID's for
all 3 different combinations by encoding the chip ID into the GUID
string.
Although WD15 and TB16 share a same payload today, this may not
be the case some day in the future. Use the fu-dell-common method
to determine the dock in use to build the GUID.
Tracking a single smi object in the plugindata is more similar
to how other plugins operate and also allows moving FuPluginData
out of fu-dell-common, making fu-dell-tool less hacky and letting
other plugins use fu-dell-common as needed.
* thunderbolt: Add special handling for safe mode on Dell systems
Dell systems are known to have the Model ID the same as the SystemID
that can be recovered from libsmbios. If the thunderbolt controller
is in safe mode, identify with this ID to allow the controller to be
flashed with a good FW.
* Minor changes in Thunderbolt README file
* Remove PCI-oriented GUID
* Handle Thunderbolt controller in safe-mode
* Get progress status updates for Thunderbolt
* Fix for Thunderbolt FW version display
* Style changes from pull request review
There was a lot of confusion about when remote control was turned
on or off leading to dsyfunctional cascade support.
This has been confirmed to work for querying and flashing both
VMM3320s in a Rugged Latitude 5414 + dock.
The synapticsmst-common.c file had some global state so that cascade devices
could use the device fd. This made the control flow error prone, and it meant
that the fd could be leaked trivially on any error path.
Moving the fd ownership to the device is the logical place for the control, and
means we can create "connections" to access the main device and the cascade
devices.
This fixes the warnings detected by Coverity.
Poll each plugin, and only register the service when all the delayed coldplug
devices have been added to the device list. This prevents returning an error
when calling "fwupdmgr get-devices" for the very first time.
Resolves: https://github.com/hughsie/fwupd/issues/82
It now supports enabling things for other plugins too, so rather
mark any devices created by Dell as only readable, not flashable
when UEFI capsule is off.
