lkml.org 
[lkml]   [2010]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: gpiolib and sleeping gpios

On Sat, 19 Jun 2010, ext David Brownell wrote:

>> The point I was trying to make is that there are lots of drivers which
>> will not work with gpios on sleeping io expanders because they call the
>> spinlock safe gpio calls.
>
> And they will trigger runtime warnings, and thus eventually get fixed.
> The way to do that is to check if the GPIO needs the cansleep() call
>
> That's the first category above: the driver should have used the
> cansleep() variant, and sotriggers a runtime warning.

Hi David -

Part of the reason why such drivers haven't been fixed might be that the
runtime warnings are only issued if DEBUG is defined in gpiolib.c:

/* When debugging, extend minimal trust to callers and platform code.
* Also emit diagnostic messages that may help initial bringup, when
* board setup or driver bugs are most common.
*
* Otherwise, minimize overhead in what may be bitbanging codepaths.
*/
#ifdef DEBUG
#define extra_checks 1
#else
#define extra_checks 0
#endif

...

int __gpio_get_value(unsigned gpio)
{
struct gpio_chip *chip;

chip = gpio_to_chip(gpio);
WARN_ON(extra_checks && chip->can_sleep);
return chip->get ? chip->get(chip, gpio - chip->base) : 0;
}

Do you think it would do more harm than good to unconditionally enable the
extra checks? I do see the comment about overhead there, but having them
enabled would probably aid driver developers in fixing existing code and
choosing the correct calls in the future.


BR,
Jani.


\
 
 \ /
  Last update: 2010-06-23 13:57    [W:0.106 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site