linux-kernel - Re: [PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank

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:	Fri, 03 Feb 2012 09:50:19 -0800
From:	Kevin Hilman <khilman@...com>
To:	balbi@...com
Cc:	"Cousson\, Benoit" <b-cousson@...com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Tarun Kanti DebBarma <tarun.kanti@...com>,
	linux-omap@...r.kernel.org, tony@...mide.com,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Charulatha V <charu@...com>
Subject: Re: [PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank_count

Felipe Balbi <balbi@...com> writes:

[...]

>> >This question remains. Why do we need those funtions ?
>> 
>> These functions are called from the CPUIdle path so outside the scope
>> of the GPIO driver. These are part of a bunch of nasty PM hacks we
>> are doing in the CPU idle loop. We are in the process of getting rid
>> of most of them, but it looks like some are still needed.
>
> Too bad. I can see that the gpio pm implementation seems a bit
> "peculiar". I mean, pm does reference counting and yet the driver has
> checks to prevent multiple gets and puts on a single bank (meaning that
> pm counter will be either 0 or 1 at any point in time).
>
> To me it looks like those functions are there in order to forcefully put
> PER power domain in OFF because drivers are always holding a reference
> to their gpios (drivers generally gpio_request() on probe() and
> gpio_free() on remove()).
>
> Looks like the entire pm implementation on OMAP gpio driver has always
> considered only the fact that gpios can be requested and freed, but
> never that we want the system to go to OFF even while gpios are
> requested, because we have I/O PAD wakeups. At some point that has to be
> sorted out because that HACK is quite ugly :-)
>
> I'll see if I find some time to go over the interactions between
> gpio-omap.c and pm24x.c and pm34xx.c any of these days, but I can't
> promise anything ;-)

If you look at the state of these prepare/resume hacks at the end of
this series, you'll see that they are significantly cleaner and do
nothing but call the runtime PM hooks.

We have explored several ways to get rid of them completely in the idle
path but have not yet come up with a clean way, but this series gets us
a long ways towards that goal.

Kevin



--
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/