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.
A test run should really fail if it cannot find the test data, rather
then reporting success (thus masking that it never ran). Fix the test to
find it data (probably broken with the port to meson) and make it fail
if it cannot find its data.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Rather then always assuming open() fails because of permission denied,
generate the GError code from the errno and add the related strerror to
the message. And ofcourse output the error message in debugging rather
then just ignoring it.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
The type of Dell dock gets used in the device GUID, so make that
mandatory for device enumeration to succeed. Only relying on the
synapticsmst plugin to be cold plugged after the dell plugin isn't
enough to ensure this.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
When hitting a failure during enumerating make sure remote control mode
is disabled again.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
4a036018 broke the callback progress by putting the wrong device type in.
23:34:11:0715 GLib-GObject invalid cast from 'SynapticsMSTDevice' to 'FuDevice'
23:34:11:0715 Fu fu_device_set_progress: assertion 'FU_IS_DEVICE (device)' failed
b6f79556 caused the device ID strings to change, which synaptics
MST plugin was relying upon.
Update to use metadata instead to communicate this information.
Switching to build in -werror in 4016c839a8
was not working properly. Adjust the CI builds to use --werror instead.
Also while doing this, enable -werror in clang builds.
This makes more sense; we're updating the device, not the plugin itself.
This also means we don't need to funnel everything through callbacks like
GFileProgressCallback and we can also update the state without adding an
explicit callback to each derived device type.
