At least with Titan Ridge devices 50 * 20 ms is way too short time
reading nvm_version so most of the time the daemon fails to figure out
the version of the just connected device. To make it work better with
Titan Ridge devices increase the timeout to 50 * 200 ms.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
There are other places in the plugin where we read nvm_version and it
can return -EAGAIN as well. To make sure it works consistenly accross
the plugin factor reading nvm_version to a helper function and use instead.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Additionally, if the user specified something invalid, do not autodetect the
ESP but return with a journal error. It seems wrong to ignore what the user
explicitly set and perhaps do something dangerous.
Alternative to https://github.com/hughsie/fwupd/pull/599
In this instance, we define the 'same device' to be a FuDevice that has at
least one matching GUID. We allow the plugins to define which one is 'better'
than other plugins, and use this to only have one FuDevice for the physical
device.
Alternative to https://github.com/hughsie/fwupd/pull/604
With composite CAB files it's difficult to see between devices when packed:
Homepage: http://support.dell.com/
Vendor: Dell Inc.
TrustFlags: none
Unknown Device
Guid: 558d18fa-5530-5fc8-9e4b-de3ee8a5eca7
Homepage: http://support.dell.com/
Vendor: Dell Inc.
TrustFlags: none
Unknown Device
Fix a logic error when testing requirements; what was supposed to happen was
that a the firmware requirements were only processed when we had a FuDevice set
in the FuInstallTask, but instead we were falling through to the handler for
'unknown requirement type'.
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.
Since the Redfish service may use a self-signed certificate without
specifying the hostname, we could have the problem to verify such
certificate. A new option, CACheck, is introduced so that the user can
decide whether to ignore the CA verification or not.
Signed-off-by: Gary Lin <glin@suse.com>
This commit adds redfish.conf to configure the IP and username/password
in case those are not available in SMBIOS and the EFI variables.
Since we can configure the IP in the conf file, the environment
variable, FWUPD_REDFISH_URI, is removed.
Signed-off-by: Gary Lin <glin@suse.com>
Although SoupAuthManager can create a proper SoupAuth from the
WWW-Authenticate header, some redfish implementations didn't provide
such header, and we would get a 401 response in the end.
In DSP0266, it mentions that "HTTP BASIC authentication as defined by
RFC7235 shall be supported", so it shall be safe to use Basic Auth
by default.
Signed-off-by: Gary Lin <glin@suse.com>
DeviceClass in Oem/Hpe indicates the type of device in the HPE machine.
In case SoftwareId is absent, we can use DeviceClass instead.
Signed-off-by: Gary Lin <glin@suse.com>
Although "Updateable" is defined in SoftwareInventory schema since
redfish v1.0.0, some machines(*) didn't support the field.
"SoftwareId" is defined in SoftwareInventory schema since v1.1.0, so
it probably isn't supported by every redfish machines.
(*) Try "/redfish/v1/UpdateService/FirmwareInventory/1/" with HPE DL380
Gen 10 in https://ilorestfulapiexplorer.ext.hpe.com/
Signed-off-by: Gary Lin <glin@suse.com>