linux-kernel - Re: [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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdac=ztY0vXQ8Mu6H8fiAO4aFSSF-A6O1Q==zKOKEsJegw@mail.gmail.com>
Date:	Tue, 30 Oct 2012 22:51:11 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Magnus Damm <magnus.damm@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Felipe Balbi <balbi@...com>,
	Dmitry Torokhov <dmitry.torokhov@...il.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,
	Arnd Bergmann <arnd@...db.de>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:

> More seriously the amount of time we seem to have been spending recently
> on changes which end up requiring us to go through essentially every
> driver and add code to them (often several times) doesn't seem like
> we're doing a good job here.

If this is your main concern you should be made aware that there
are people out there planning to supplant the existing DT probe paths
that are now being added to each and every ARM-related driver
with an ACPI probe path as ARM servers come into the picture.

> pinctrl is really noticable because it's
> new but it's not the only thing.  As a subsystem maintainer this code
> just makes me want to add new subsystem features to pull the code out of
> drivers but obviously that's not something that should be being done at
> the subsystem level.

We did manage to drag the power/voltage domain per se out
of the AMBA bus, and recommend that people (like us) do that
business using the power domains.

I think most people (including OMAP) have bought
into the concept of using the runtime PM framework and power
domains to control the power domain switches.

It's this wider concept of using the loose concept "PM resource
domains" to control also clocks and pins that is at stake, and so
far the runtime PM core people (Rafael and Magnus) has not said
much so I think we need some kind of indication from them as to
what is to happen, long-term, with drivers handling their own clocks
and pins. Should it be centralized or not? If it's to be centralized it
needs to become a large piece of infrastructure refactoring and
needs the attention of Linaro and the like to happen.

I've CC:ed a few people into this thread so we get some traction,
we need more subsystem maintainers in here.

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/