Some Poly usb devices report zero in the bwPollTimeout field of
GET_STATUS request. The host can issue the next DFU_DNLOAD
request immediately without any delay.
Introduced a private flag to skip the default DNLOAD timeout
(5ms) fix. It could remarkably reduce the firmware downloading
time taking into account the large firmware (more than 500MB).
Allow fwupd to use the BatteryStatePoll signal instead
of the GetBatteryState method call so that fwupd does
not need to run a timer itself and is automatically updated
on power connect/disconnect.
Change-Id: I81aad6a5933fa267473a83d1b97f4638235b155a
* dell-dock: open usb4 device in the activate call, and leave early
* trivial: read history earlier, at least before plugin register
* dell-dock: activate usb4 device exclusively if it needs activation
All the other vfuncs have 'plugin, device, flags' but prepare and
cleanup vfuncs being 'plugin, flags, device' order has been triggering
my OCD for the last few years.
We've just broken the symbol names, so it's the right time to fix this.
Module may not have been re-probed and exposed in MM when the FW version was successfully obtained, which leads to the report that failed to get device after update. In fact, FW has been uodated successfully, it needs to add 150s to wait for the module to be re-probed and exposed in MM.
Signed-off-by: Jarvis Jiang <jarvis.w.jiang@gmail.com>
Limits copying the get version response payload to the size of the out buffer.
Devices that return a larger payload pack the necessary version information at
the beginning of the payload.
Fixes: #1661
More than one person has asked about 'why call fu_plugin_update() for a
reinstall or downgrade' and I didn't have a very good answer.
The plugin API is not officially stable, and we should fix things to be
less confusing. Use the same verbs as the FuDevice vfuncs instead.
The RTD2141B has the same update protocol as RTD2142, but the Chromebook
targets that use it require us to find the drm_dp_aux_dev i2c channel
differently because the AMD display driver doesn't give each output a
unique name in sysfs, so it must be found by walking sysfs from the drm
device representing an output.
Change-Id: Icb6c1a40b8a62af72808d68a0a69555810abc272
Based on a patch by Twain Byrnes <binarynewts@google.com>, many thanks.
Use this to test:
sudo FWUPD_TEST_PLUGIN_XML="<config><delay_decompress_ms>100</delay_decompress_ms></config>" \
./src/fwupdtool --plugins test get-devices -v
Create and destroy /run/lock/power_override/fwupd.lock.
This file will hold the contents of getpid (), which will
stop the device from being suspended while the file exists.
The file will be created and written just before the
update is put into motion and be destroyed once the update
finishes, or upon restart in case of catastrophic failure.
Change-Id: If8dd17b0358862a842c9589e11ed0de12d852797
We don't want to show the big warning about the missing ESRT on server
hardware that is managed by a BMC:
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
Applying updates to my new P1G3:
* schedule the update in fwupd
* boot into the BootNext
* apply the capsule with RT->UpdateCapsule
* reboot with RT->ResetSystem
Except the firmware updater EFI binary then wasn't running. The ESRT
last_attempt_status comes back as Success on the reboot.
Disabling the UX capsule made the update apply correctly each and every
time. Until we can work out what models are affected, use a per-vendor
quirk to avoid delaying the release.
This CL moves the battery information retrieval into a new function,
called "fu_plugin_powerd_callback()", which returns the information in a
struct.
This information is then used in fu_plugin_update_prepare() for battery
checks. There is also a g_timeout_add() function being created in
fu_plugin_startup() in order to enable the plugin to repeatedly send a method
call to powerd.
fu_plugin_update_prepare is removed as its functionality is now handled
by src/fu-engine.c
Shim has had a hard time with loading updates from arguments in the
most recent release and this isn't the first time that happened.
Give distros and users an escape hatch that will allow using GRUB
instead.
We should be just checking if the thinklmi plugin inhibited the device,
and if we fix the bug where the last_attempt_status value was not being
read on startup then this test will then fail.
This adds a condition to the powerd plugin that passes updates on devices
that do not give provide valid battery information or whose battery
information is unknown, such as Chromeboxes, which have no battery to
read.
Only the backup BMC device (which we ignore anyway...) can be updated
by specifying the target ID, the others need an *empty* array so that
XCC can work out what devices need to be processed.
Currently the SUCCESS state overrides reboot-needed, thus making the
devices considered for successive git-upgrades within same boot. The
change preserves the REBOOT_NEEDED state. It also added a missed
'changed' signal, which otherwise would skip updating the persistent
state.
Change-Id: I6f60606f2253d89eab2f5bddceba19d19c4c9c97
Some distributions like RHEL change the default to not autoconnect
ethernet devices. This breaks connecting to the SMBIOS-defined BMC
adapter which means all the reads fail after a 60s timemout.
Autoconnect the internal USB ethernet adapter so we can use Redfish
without user action.
A series of changes are made to the powerd skeleton
plugin in order to reach two goals: ensuring that it handles cases correctly, given certain
information about the battery and/or certain return types and that it
successfully retrieves battery information from powerd to be used later.
Logic is then added to ensure updates are only performed
when that battery level is at or above the minimum threshold.
Then logic is added that checks if the device being updating requires
AC power. Along with this, specific
error statements are added for each scenario where an update is blocked.
To address the next goal, within fu_plugin_startup(), a GDBus connection
is established. However, instead of a direct connection to
powerd, the connection is changed to link to the general system bus with
g_bus_get_sync(). From there, a proxy is created to represent the
connection to powerd. A test call is made for the name of the service that the
proxy represents to check for successful communication.
Then, in fu_plugin_update_prepare(), the existing proxy is called and in the call,
the "GetBatteryState" is passed to make a method call method. The
response is filled into a GVariant, whose entries are initialized in new variables to use
for battery checks. And checks are added to make sure every step was
successful.
This CL creates a mostly empty fu-plugin-powerd.c that
has the file disable itself on startup with an error.
The README.md file was re-created to include information on
powerd and the specific interface it will use.
A meson.build file re-created to call fu-plugin-powerd.c.
It excludes a .conf install function was removed to be consistent with
an upstream change.
The general meson.build file includes the
powerd subdirectory for powerd to compile.
No .quirk file was included. There will be general daemon.quirk file for all plugins.
FIXUP: Adjusted copyright format and whitespace in fu-plugin-powerd.c
and plugin returns false on startup. Also added to "fu-plugin-powerd.so"
entry fwupd.spec.in.
The benefit of using the proxy device is that we can 'use' the proxy
device for device access, but 'report' the progress on the passed
FuDevice instance.
This means the front-end reports the device status correctly when
updating composite devices that us proxies.
The comment always said we should move it to the daemon if another
plugin started doing this, and that is now.
I assume at some point we forgot to remove it when converting an object
from FINAL to DERIVABLE and the anti-pattern just got copied around the
codebase...
The "return error and hope the client resubmits the firmware again"
pattern is clunky. There are two plugins doing this now, and about to
be one more.
This adds FwupdRequest which provides a structured way of asking the
user to perform an action, e.g. to replug the device or to press a
special key or button.
This replaces much of the UpdateMessage and UpdateImage API although
it is still used internally. Clients capable of processing the new
DeviceRequest signal should add REQUESTS to their feature flags.
Also, this allows us go back to the old meaning of _NEEDS_BOOTLOADER,
which was "needs rebooting into a bootloader mode" rather than the
slightly weird "user needs to do something and resubmit request".
The move to query sysattr for the name inadvertly changed the extent of
devices accepted by emmc probe. udev rules setup ID_NAME only for main
block device, but not for rpmb or boot, while 'name' sysattr is present
for all of them for they point to the same parent. The original check
for name was brittle either way and relied on a side effect of udev
subsystem. This CL introdues a proper filtering check that picks up only
the main devices. That is important because an attempt to perfrom an
update not on the main device returns a cryptic timeout error.
Change-Id: I3c2f5597c3e3ca2124c87cade3f345dece94027e
At this point it has to be present, but better have the check for
correctness sake.
Follow up of
64fa633e30
Change-Id: I51b5995e25dc4dc4ec63b90af271cd90650d184d
/run/udev/data/b* location of eMMC devices appears to be inaccessible
early on in the boot process which makes fwupd to skip eMMC devices if
the daemon started too early. ID_NAME udev attribute is effectively
copied from the sysfs attribute [1], thus making use of it is more
reliable.
[1] 1ed38f4174/etc/udev/rules.d/60-persistent-storage.rules (42)
Change-Id: I66b92dfeb13ec61b4d8166dd32a2460b6fbf92c2
There are now multiple plugins using drm_dp_aux_dev interface which
may potentially be combined with an amdgpu. Prevent exercising this
interface with any plugin using DP aux unless a new enough kernel is
installed.
