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: <CACRpkdapQJY0aoam741O0fb8EeM9BLk_Psq5TaPG84J7wEvCLw@mail.gmail.com>
Date:	Tue, 30 Oct 2012 15:02:23 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	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,
	Kevin Hilman <khilman@...com>
Subject: Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:

>> Moving this handling to bus code or anywhere else
>> invariably implies that resource acquisition/release order
>> does not matter, and my point is that it does.
>
> Doing this in the buses is definitely wrong, as you say it's not bus
> specific.  I do however think we can usefully do this stuff in a SoC
> specific place like a power domain, keeping the SoC integration code
> together and out of the drivers.  IME the SoCs where you need to do
> different things for different IPs shoudl mostly still get some reuse
> out of such an approach.

Talking to Kevin Hilman today he was also stressing that
power domains is a good thing for handling resources, especially
when replacing prior hacks in the custom clk code. However
he pointed specifically to clocks and voltages, which may
be true.

What worries me is when knowledge of the hardware which
is traditionally a concern for the device driver start to
bubble up to the power domain (or better renamed resource
domain if use like this, as Felipe points out).

I worry that we will end up with power/resource domain
code that start to look like this:

suspend()
switch (device.id) {
case DEV_FOO:
  clk_disable();
  pinctrl_set_state();
  power_domain_off();
case DEV_BAR:
  pinctrl_set_state();
  clk_disable();
  // Always-on domain
case DEV_BAZ:
  pinctrl_set_state();
  clk_disable();
  power_domain_off();
case ...

Mutate the above with silicon errata, specific tweaks etc that
Felipe was mentioning.

What is happening is that device-specific behaviour which
traditionally handled in the driver is now inside the
power/resource domain.

I agree that if the domain was doing the same thing for each
piece of hardware, this would be the right thing to do,
and I think the in-kernel examples are all "simple",
e.g. arch/arm/mach-omap2/powerdomain* is all about
power domains and nothing else, and the notifiers used
by SHmobile is all about clock gating and nothing else.

Another effect is that moving all resource handling to
power domains is that if we do that for a widely shared
device driver like the PL011 that mandates that power
domains need to be implemented for U300, Ux500,
Nomadik, SPEAr 13xx, 3xx, 6xx, Versatile, Versatile
Express, Integrator (AP & CP) and BCM2835. Probably
more.

None of which has power domains (upstream) as
of today. Some of which (U300, Ux500, Nomadik,
SPEAr, Integrator, BCM2835) implement pin control.

Basically power (resource) domains have the side-effect
of in this light not doing one thing (power domains) but
instead imposing all-or-nothing imperialistic characteristics.

While avoiding a set of distributed, optional pinctrl hooks,
it mandates a central piece of upfront powerdomain
boilerplate to be present in each and every platform that
wants to control its pins.

I think the lesser of two evils is the distributed approach,
and then I'm talking about pinctrl only, disregarding the
fact that clocks and power domains are basically subject to
the same kind of argument. I still buy into the concept of
using power domains for exactly power domains only.
Arguably this is an elegance opinion...

I worry that the per-SoC power domain implementation
which will live in arch/arm/mach-* as of today will become
the new board file problem, overburdening the arch/* tree.
Maybe I'm mistaken as to the size of these things,
but just doing ls arch/arm/mach-omap2/powerdomain*
makes me start worrying.

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/