linux-kernel - Re: [PATCH update] PM: Introduce core framework for run-time PM of I/O devices (rev. 11)

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]

Message-ID: <aec7e5c30908022026t2fa8f328s27424073c9ff560b@mail.gmail.com>
Date:	Mon, 3 Aug 2009 12:26:14 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Alan Stern <stern@...land.harvard.edu>, Greg KH <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Pavel Machek <pavel@....cz>
Subject: Re: [PATCH update] PM: Introduce core framework for run-time PM of 
	I/O devices (rev. 11)

Hi again Rafael,

On Sat, Aug 1, 2009 at 3:53 AM, Rafael J. Wysocki<rjw@...k.pl> wrote:
> On Friday 31 July 2009, Magnus Damm wrote:
>> [Runtime PM v11]

>> > @@ -202,7 +203,9 @@ int driver_probe_device(struct device_dr
>> >        pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
>> >                 drv->bus->name, __func__, dev_name(dev), drv->name);
>> >
>> > +       pm_runtime_get_noresume(dev);
>> >        ret = really_probe(dev, drv);
>> > +       pm_runtime_put_noidle(dev);
>> >
>> >        return ret;
>> >  }
>>
>> This creates problems when drivers want to performing runtime resume
>> from within probe(). For more details please have a look at "[PATCH
>> 04/04] video: Runtime PM hack for SuperH LCDC driver".
>
> Ah, I see.  You'd like to call pm_runtime_get_sync() from .probe(), but that
> sees the usage counter different from zero and exits immediately.

Exactly.

> OTOH, I think we should prevent suspends from racing with .probe() at the core
> level.  Hmm.

Doesn't it make more sense to allow runtime suspend and resume to
happen after the pm_runtime_enable() call? What case are you trying to
protect against?

> One possible approach could be to call pm_runtime_resume() from
> sh_mobile_lcdc_probe() instead of pm_runtime_put_noidle().  Then, the platform
> code will have a chance to turn the device on and the later pm_runtime_get*()
> and pm_runtime_put*() calls will be balanced.  Of course, in that case the
> pm_runtime_get_noresume() in sh_mobile_lcdc_probe() won't be necessary any
> more.  Am I overlooking anything?

So for drivers that want to access hardware from .probe(), calling
pm_runtime_resume() after pm_runtime_enable() in should be enough?

Thanks for your help!

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/