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.
This allows us to show the devices in a GUI with a nice icon. Some of the icon
mappings are not perfect and I'll be asking the GNOME designers for some
additions to the icon specification.
Custom vendor icons can also be specified, and /usr/share/fwupd/icons would be
a good place to put them. If vendor icons are used they should show a physical
device with the branding, rather than just the vendor logo.
This is to help break the dependence on the Dell plugin during
initalization.
NOTE: there are corner cases that this plugin will no longer
detect Dell systems now, but these are expected to be rare.
Over the months the original meaning of ALLOW_OFFLINE and ALLOW_ONLINE have be
lost, and there is now a confusing mixture of uses in the source tree. With this
commit we make it clear the UPDATABLE flag is used to specify when the device is
updatable (e.g. from the desktop live session, or from the systemd offline
updates mode, or both) and the NEEDS_REBOOT flag lets us know when the update
is actually going to be done.
For instance, a UEFI UpdateCapsule can be *scheduled* from either the desktop
or from the update mode (but the latter would be a bit weird), but does require
a reboot. Some devices might only be updatable outside the live session, for
instance a hard drive update or a GPU update -- there's just too much going on
with a live session and we want to tightly control what's running during the
firmware flash.
This also means we don't have to "retry" the update when scheduling an update
that really can be scheduled whenever, but just requires a reboot to apply.
Automake and autoconf are impossible to fully understand and Meson now provides
everything we need for a much smaller, faster, and more understandable build.
See http://mesonbuild.com/ for more information.
