linux-kernel - Re: platform/i2c busses: pm runtime and system sleep

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] [day] [month] [year] [list]

Message-ID: <AANLkTinz55AAYA7Ltgcs_z+ysedxtavW2xsdw4=4qP0_@mail.gmail.com>
Date:	Sat, 19 Feb 2011 11:16:17 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Rabin Vincent <rabin@....in>,
	khilman@...com, magnus.damm@...il.com,
	LKML <linux-kernel@...r.kernel.org>, stern@...land.harvard.edu,
	linux-i2c@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: platform/i2c busses: pm runtime and system sleep

2011/2/19 Russell King - ARM Linux <linux@....linux.org.uk>:
> [Me]
>> Both of these problems are solved by elegance if we use runtime
>> PM, since it will provide a hysteresis timeout that can be triggered
>> from interrupt context and call the idling hooks in process context.
>
> So what's the interdependence with the platform bus that was being talked
> about earlier in this thread?

That's about consistency of runtime PM semantics across
different buses as I understand it.

We have both platform bus and AMBA bus devices in the system,
so it is desireable if the semantics of their runtime PM are identical.

If I understand it, the difference is that the platform bus will call
runtime_suspend() on the device even if it was already in suspended
state, so the question is about whether the AMBA runtime PM
should do this too since it is similar to the platform bus, or if it should
go for the more intutive approach of not suspending suspended
hardware.

I think the current patch from Rabin as it stands does the latter, and
is good as it stands. It's the other buses and their drivers that
need patching.

Yours,
Linus Walleij
--
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/