public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
	linux-acpi <linux-acpi@vger.kernel.org>
Subject: ACPI power-resources not turned off after failure of device-driver's runtime resume function?
Date: Mon, 5 May 2025 15:49:09 +0200	[thread overview]
Message-ID: <8d52bffe-9d16-481e-a997-837988f2ebe5@redhat.com> (raw)

Hi Rafael,

While testing error handling in the atomisp driver, deliberately
making a camera-sensor driver not work by using gpioset to disable
a regulator, I noticed the following:

The ACPI device pm_domain runtime_resume function looks like this:

int acpi_subsys_runtime_resume(struct device *dev)
{
        int ret = acpi_dev_resume(dev);

        return ret ? ret : pm_generic_runtime_resume(dev);
}

Combined with the runtime_error flag blocking any futher
runtime-pm get() / put() calls (making them fail with -EINVAL)
this means that if the device's driver runtime resume
function called by pm_generic_runtime_resume() fails,
nothing will undo the acpi_dev_resume() leaving e.g.
ACPI power-resouces associated with dev in the on state.

I guess a possible fix would be to change
acpi_subsys_runtime_resume() to e.g.:

int acpi_subsys_runtime_resume(struct device *dev)
{
        int ret;

	ret = acpi_dev_resume(dev);
	if (ret)
		return ret;
		
	ret = pm_generic_runtime_resume(dev);
	if (ret)
		acpi_dev_suspend(dev);

        return ret;
}

but I'm not sure if this is the correct fix ?

Or is the assumption simply that if things go wrong it
is best to just leave everything as it us to avoid making
things worse? Similar to how this will result in the
runtime_error flag getting set disallowing further
runtime-pm get()/put() calls ?

###

About the runtime_error flag I also noticed that if I enable
the deliberately disabled regulator after first testing
the error handling then subsequent attempts to stream from
the sensor will fail because pm_runtime_get_sync() fails
with -EINVAL due to the runtime_error flag. I guess this is
deliberate and drivers can then e.g. queue a workqueue item
to do a full reset and then clear the runtime_error after that?

And it seems that the runtime-error also needs to be cleared
followed by a successful pm-runtime get() + put() pair 
to release the ACPI power-resources.

So I guess that drivers where errors may be intermittent and
the runtime-resume should be retried the next time, something
like this should be used: ? 

        ret = pm_runtime_resume_and_get(&sensor->client->dev);
        if (ret) {
                /* clear runtime error to retry resume the next time */
                pm_runtime_set_suspended(&sensor->client->dev);
                return ret;
        }

Regards,

Hans




                 reply	other threads:[~2025-05-05 13:49 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8d52bffe-9d16-481e-a997-837988f2ebe5@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox