linux-kernel - Re: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support

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: <CACRpkdarSNg1zACZKGBt1ypMzE+-KF-o594EcZ1EP484v+4HRw@mail.gmail.com>
Date:	Thu, 1 Nov 2012 14:22:11 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Kevin Hilman <khilman@...prootsystems.com>
Cc:	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Felipe Balbi <balbi@...com>, Benoit Cousson <b-cousson@...com>,
	Sourav Poddar <sourav.poddar@...com>, tony@...mide.com,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org,
	linux-arm-kernel@...ts.infradead.org, linux-input@...r.kernel.org
Subject: Re: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On Thu, Nov 1, 2012 at 12:42 PM, Kevin Hilman
<khilman@...prootsystems.com> wrote:
> [Me]
>> Well, the pinctrl grabbers in these drivers are using these states also
>> for platforms that do not even select CONFIG_PM.  For example
>> mach-nomadik is quite happy that the PL011 driver is thusly
>> muxing in its pins. And would require refactoring to use PM
>> domains.
>
> If CONFIG_PM is disabled, then is it safe to assume that the pins in
> question are probably only done once at init time.  I assume during
> ->probe(). ?

Sadly no.

Consider drivers/tty/serial/amba-pl011.c

Many ARM platforms have several instances of PL011, and not all of
them have CONFIG_PM & friends, so it's a good example.

Here the driver will probe and currently fetch a pinctrl handle and
looks up two states: "default", which refers to the situation you
describe, and optionally "sleep" which will put pins into a
low-power state.

The driver will currently put the pins into the "sleep" state when
.shutdown() is called by something (userspace or in-kernel users).

So in the new suggested scheme using runtime PM, this
would have to be replaced by pm_runtime_get[_sync]()
and pm_runtime_put() hints and the current pin handling
deleted, and for each platform using this driver instead
implement a PM domain to do the same thing.

Else you loose this runtime power optimization.

This is what I refer to the all-or-nothing charcter of
runtime PM domains... but maybe it's a good thing,
I haven't quite made my mind up about it.

> (...) if what we want/need are only ways to introduce SoC-specific
> integration details into non-PM transitions (e.g. probe/remove), maybe
> bus notifiers would suffice here.  e.g. you'd get a bus notifier when
> the device is added/attached and any init-time pinctrl setup could be
> done then.  This still keeps drivers clean of SoC-specific integration
> data/code, and also allows that to happen whether or not PM features are
> enabled.

It doesn't cut it for any of our drivers as shown above,
but it would work for the patch in $SUBJECT.

It sounds like the way silicon clocks are handled on
SH am I right?

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/