| Age | Commit message (Collapse) | Author |
|---|
|
Apparently this test is the only code that checks the return code from
pm_runtime_barrier(), and it turns out that's for good reason -- it's
inherently racy, and a bad idea. We're going to make
pm_runtime_barrier() return void, so prepare for that by dropping any
return code checks.
This resolves some test failures seen like the following:
[ 34.559694] # pm_runtime_error_test: EXPECTATION FAILED at drivers/base/power/runtime-test.c:177
[ 34.559694] Expected 1 == pm_runtime_barrier(dev), but
[ 34.559694] pm_runtime_barrier(dev) == 0 (0x0)
[ 34.563604] # pm_runtime_error_test: pass:0 fail:1 skip:0 total:1
Reported-by: Guenter Roeck <linux@roeck-us.net>
Closes: https://lore.kernel.org/lkml/93259f2b-7017-4096-a31b-cabbf6152e9b@roeck-us.net/
Signed-off-by: Brian Norris <briannorris@chromium.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Link: https://patch.msgid.link/20251202193129.1411419-1-briannorris@chromium.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The kunit_device_register() function never returns NULL, it returns
error pointers. Update the assertions to use
KUNIT_ASSERT_NOT_ERR_OR_NULL() instead of checking for NULL.
Fixes: 7f7acd193ba8 ("PM: runtime: Add basic kunit tests for API contracts")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The pm_runtime.h docs say pm_runtime_put() and pm_runtime_put_sync()
return 1 when already suspended, but this is not true -- they return
-EAGAIN. On the other hand, pm_runtime_put_sync_suspend() and
pm_runtime_put_sync_autosuspend() *do* return 1.
This is an artifact of the fact that the former are built on rpm_idle(),
whereas the latter are built on rpm_suspend().
There are precious few pm_runtime_put()/pm_runtime_put_sync() callers
that check the return code at all, but most of them only log errors, and
usually only for negative error codes. None of them should be treating
this as an error, so:
* at best, this may fix some case where a driver treats this condition
as an error, when it shouldn't;
* at worst, this should make no effect; and
* somewhere in between, we could potentially clear up non-fatal log
messages.
Fix the pm_runtime_already_suspended_test() while tweaking the behavior.
The test makes a lot more sense when these all return 1 when the device
is already suspended:
pm_runtime_put_sync(dev);
pm_runtime_suspend(dev);
pm_runtime_autosuspend(dev);
pm_request_autosuspend(dev);
pm_runtime_put_sync_autosuspend(dev);
Notably, I've avoided testing the return codes for these, since they
really should be ignored by callers, and we may make them 'void'
altogether:
pm_runtime_put(dev);
pm_runtime_put_autosuspend(dev);
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
In exploring the various return codes and failure modes of runtime PM
APIs, I found it helpful to verify and codify many of them in unit
tests, especially given that even the kerneldoc can be rather complex to
reason through, and it also has had subtle errors of its own.
Notably, I avoid testing the return codes for pm_runtime_put() and
pm_runtime_put_autosuspend(), since code that checks them is probably
wrong, and we're considering making them return 'void' altogether. I
still test the sync() variants, since those have a bit more meaning to
them.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
