lkml.org 
[lkml]   [2012]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] gpiolib: Implement devm_gpio_request_one()
On Sat, Apr 07, 2012 at 10:00:18AM +0100, Mark Brown wrote:
> On Fri, Apr 06, 2012 at 07:25:12PM -0700, Grant Likely wrote:

> > Actually, I looked at it again, and the _one version behaves subtly
> > different from the non-_one version. That may be irrelevant though.

> It always does a direction set, yes. This will make a difference if the
> direction call either fails or blocks future reconfigurations, what was
> puzzling me was if this was an issue or not and like I say I decided to
> assume it was and stick with the same pattern.

Just after sending this (isn't that always the way?) I realised there is
one important case where it makes a difference: if the code does this:

gpio_request(foo, "bar");
gpio_direction_output(foo, 1);

then if the GPIO was already driving out high we will maintain steady
state. If, however, we were to do:

gpio_request(foo, "bar");
gpio_direction_input();
gpio_direction_output(foo, 1);

where the first two calls are the natural result of implementing
gpio_request() in terms of gpio_request_one() then the GPIO would glitch
high Z during the process which might have unfortunate consequences for
whatever the GPIO is controlling.

I think instead of redoing the implementation we need start a campaign
to convert gpio_request() users to gpio_request_one() - coccinelle can
probably take a large chunk of the work but it'll need some manual help
I expect.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2012-04-07 11:19    [W:0.031 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site