linux-kernel - Re: [PATCH v2 1/9] i2c: prepare runtime PM support for I2C client devices

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:	Sun, 15 Sep 2013 13:47:44 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:	Kevin Hilman <khilman@...aro.org>, linux-i2c@...r.kernel.org,
	Wolfram Sang <wsa@...-dreams.de>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	Lv Zheng <lv.zheng@...el.com>, Aaron Lu <aaron.lu@...el.com>,
	linux-arm-kernel@...ts.infradead.org,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Kyungmin Park <kyungmin.park@...sung.com>
Subject: Re: [PATCH v2 1/9] i2c: prepare runtime PM support for I2C client
 devices

On Sun, Sep 15, 2013 at 09:41:39AM +0300, Mika Westerberg wrote:

> There's also a less intrusive way of fixing the problem we see with ACPI
> enabled I2C devices:

> 	1. In I2C core i2c_device_probe() we power on the I2C controller
> 	and attach the client device to the ACPI power domain. Just like in
> 	this patch but we don't touch the I2C client device runtime PM.

> 	-> This should allow the existing drivers to keep using whatever
> 	runtime PM strategy they have chosen.

There should be no explicit need to power on the I2C controller if it's
implemented the same way the existing ones are - just have it power
itself on when it is doing a transfer.

> 	2. For ACPI enumerated I2C client devices drivers we need to
> 	implement the runtime PM in order to save power (otherwise the
> 	devices will be left powered on).

> and do the same for SPI devices as well.

> Then only thing that changes for non-ACPI devices is that the controller
> will be powered on during the client device probe (well, and during
> remove).

> Thoughts?

This is definitely less intrusive than the current proposal, there's one
ACPI I2C device binding queued for -next after the merge window (rt5640)
which will need an update.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)