linux-kernel - Re: [PATCH v2] ALSA: hda/tegra: enable clock during probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 31 Jan 2019 12:46:54 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Jon Hunter <jonathanh@...dia.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Sameer Pujar <spujar@...dia.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." 
        <alsa-devel@...a-project.org>, mkumard@...dia.com,
        rlokhande@...dia.com, sharadg@...dia.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-tegra@...r.kernel.org, Linux PM <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v2] ALSA: hda/tegra: enable clock during probe

On Thu, Jan 31, 2019 at 12:21 PM Takashi Iwai <tiwai@...e.de> wrote:
>
> On Thu, 31 Jan 2019 12:05:30 +0100,
> Thierry Reding wrote:
> >
> > On Wed, Jan 30, 2019 at 05:40:42PM +0100, Takashi Iwai wrote:

[cut]

> > > If I understand correctly the code, the pm domain is already activated
> > > at calling driver's probe callback.
> >
> > As far as I can tell, the domain will also be powered off again after
> > probe finished, unless the device grabs a runtime PM reference. This is
> > what happens via the dev->pm_domain->sync() call after successful probe
> > of a driver.
>
> Ah, a good point.  This can be a problem with a probe work like this
> case.
>
> > It seems to me like it's not a very well defined case what to do when a
> > device needs to be powered up but runtime PM is not enabled.
> >
> > Adding Rafael and linux-pm, maybe they can provide some guidance on what
> > to do in these situations.
> >
> > To summarize, what we're debating here is how to handle powering up a
> > device if the pm_runtime infrastructure doesn't take care of it. Jon's
> > proposal here was, and we use this elsewhere, to do something like this:
> >
> >       pm_runtime_enable(dev);
> >       if (!pm_runtime_enabled(dev)) {
> >               err = foo_runtime_resume(dev);
> >               if (err < 0)
> >                       goto fail;
> >       }
> >
> > So basically when runtime PM is not available, we explicitly "resume"
> > the device to power it up.
> >
> > It seems to me like that's a fairly common problem, so I'm wondering if
> > there's something that the runtime PM core could do to help with this.
> > Or perhaps there's already a way to achieve this that we're all
> > overlooking?
> >
> > Rafael, any suggestions?
>
> If any, a common helper would be appreciated, indeed.

I'm not sure that I understand the problem correctly, so let me
restate it the way I understand it.

What we're talking about is a driver ->probe() callback.  Runtime PM
is disabled initially and the device is off.  It needs to be powered
up, but the way to do that depends on some configuration of the board
etc., so ideally

pm_runtime_enable(dev);
ret = pm_runtime_resume(dev);

should just work, but the question is what to do if runtime PM doesn't
work as expected.  That is, CONFIG_PM_RUNTIME is unset?  Or something
else?