Future metadata from the LVFS will set the protocol the firmware is expected to
use. As vendors love to re-use common terms like DFU for incompatible protocols,
namespace them with the controlling company ID with an approximate reverse DNS
namespace.
This also allows more than one plugin to define support for the same protocol,
for instance rts54hid+rts54hub and synapticsmst+dell-dock.
Plugins are allowed to 'opt-out' of this behaviour using _RULE_INHIBITS_IDLE.
This should be used where waking up the hardware to coldplug is expensive,
either from a power consumption point of view, or if other artifacts are going
to be seem -- for instance if the screen flickers when probing display devices.
This functionality is also inhibited when the actual upgrade is happening,
for obvious reasons.
Admins can turn off this auto-sleep behaviour by editing the daemon.conf file.
Fixes https://github.com/hughsie/fwupd/issues/417
1. Since board ID in synapticsmst.quirk is different based upon how
the board ID is read, don't whitelist it in `write_firmware`
2. Allow using `--force` with `fwupdmgr` or `fwupdtool` to override
board ID check.
3. Allow using custom flag `ignore-board-id` to ignore board IDs.
This will be the default for EVB boards and can be used in the event
of a factory mistake as well.
4. Move the EVB board IDs into their own synapticsmst_evb.quirk.
This file will not be installed by default (So EVB boards are only
functional when manually installed).
Although this is (currently) slower to flash with, bad behavior
and corner case scenarios such as these don't occur:
* Flickering during enumeration
* Monitor plugged in during enumeration but not during flash
* Heavy DP traffic slowing down update significantly
* Sandboxes without access to `/dev/drm_dp_auxY` unable to flash
* Exercising existing graphics driver bugs leading to system freezes.
Additionally this removes a lot of code in dell_dock that was put
in place specifically to be able to support waking up the MST hub
to try to use DP aux for flashing.
Now DP aux will only be used to flash when fwupd is compiled
without `dell_dock`.
This plugin requires infrastructure introduced in fwupd 1.1.3
and can not be backported to earlier versions of fwupd.
It works together with the Synaptics and Thunderbolt plugins to
coordinate the proper flashing procedure for devices in this dock.
It wasn't hugely clear what the platform ID was actually meant to represent. In
some cases it was being used like a physical ID, in others it was a logical ID,
and in others it was both. In some cases it was even used as a sysfs path.
Clear up all the confusion by splitting the platform ID into two parts, an
optional *physical* ID to represent the electrical connection, and an optional
*logical* ID to disambiguate composite devices with the same physical ID.
Also create an explicit sysfs_path getter for FuUdevDevice to make this clear.
This allows WAIT_FOR_REPLUG to always work, rather than depending on the order
that the GUIDs were added, and that the kernel would always return the same
sysfs path (which it doesn't have to do, especially for hidraw devices).
If another plugin causes a Synaptics MST device to be removed, it
also needs to be removed from the cache to prevent problems when
the device is re-probed.
This flag is intended for devices that the restart procedure will
be performed as part of a transactional update by an external
controller.
None of the currently supported devices need this flag.
Panamera is a newer MST chip with a different flash layout and
multiple MCU running and accessing SPI/EEPROM simultaneously.
The firmware update process has to be run separately for each
SPI/EEPROM region.
Signed-off-by: Ryan Chang <ryan.chang@synaptics.com>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
- Split up `synapticsmst_device_write_firmware` to smaller more manageable
chunks
- Use `FuDeviceLocker` to ensure that device is in a known state after
update is complete (both in success or failure scenarios)
- Retry the write process up to 10 times in case of DPCD update failures
- Wait for flash clear to settle before writing to EEPROM/SPI
Any previously failed runs or outside tools may adjust the remote
control register leaving the MST controller in a poor state.
If remote control enablement fails, try to disable and then re-enable
before aborting.
As seen by recent testing this is not working every time.
Since e6cda81f we're now building GUIDs that represent all the possibilities
for shared parts so it's not important to set dock type.
If the dock information is available then show that in the device name
and restrict the GUIDs created.
If it's not available, then just create GUIDs for all known docks
GLib creates two static inline functions for paramaters that may
not be used that set off warnings in clang but not gcc.
Ignore these on clang builds everywhere that
G_DEFINE_AUTOPTR_CLEANUP_FUNC is used.
