Re: [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleeping gpios)

[Ryan Mallon <ryan@bluewatersys.com>]

David Brownell wrote:
> 
> --- On Tue, 6/22/10, Ryan Mallon <ryan@bluewatersys.com> wrote:
> 
>>> --- On Tue, 6/22/10, Ryan Mallon <ryan@bluewatersys.com>
>> wrote:

>>>> 'Can sleep' for a gpio has two different meanings
>> depending
>>>> on context
>>> NO; for the GPIO itself it's only ever had one
>>> meaning, regardless of context.
>>>
>>> You're trying to conflate the GPIO and one
>>> of the contexts in which it's used.  That's
>>> the problem you seem to be struggling with.
>>>
>>> Please stop conflating/confusing
>>> those two disparate concepts...
>> I'm not. 
> 
> BUT Your "counter" example below is solid
> proof that you are:  it shows exactly the
> confusion I pointed out:  call context versus
> the GPIO itself.  There's no way I can read
> that as anything except "you are"...
> 
>  
> Your intent here seems perhaps more to
> be a troll than to address any real
> technical issues.  I don't see much
> point participating any further.
> 
> 
>  Some gpios, such as those on io expanders, may
>> sleep in their
>> implementations of the gpio_(set/get) functions.
>>
> 
> Such GPIOs have a "cansleep" attribute, in short.
> 
> 
>> Drivers, which use a gpio, may call gpio_(set/get)
>> functions for a given
>> gpio from a context where it is not safe to sleep.
> 
> And that's the call dontext
> (in this case, from a driver).

Yes.

>   QED.  You are confusing two disparate concepts.

We are saying exactly the same thing.

> 
>  In this
>> case, a gpio
>> which may sleep (ie one on an i2c io-expander) cannot be
>> used with this
>> driver. The gpio_request will succeed, but any call to
>> gpio_(set/get)_value will produce a warning.
>>
>>>> example, if a driver calls gpio_get_value(gpio)
>> from an
>>>> interupt handler
> 
> 
> (YOU introduce interrupt/IRQ handlers...)
> 
>>>> then the gpio must not be a sleeping gpio.
>>> In a threaded IRQ handler it's OK to use
>>> the get_value_cansleep() option..
>> Ugh, you are really twisting my words.
> 
> 
> You said IRQ handler, so did I.  In what csense could I
> possibly be "twisting" your words"???
> 
> 
> STOP TROLLING.

Okay, I messed up the wording an used 'interrupt handler' as an example
of a non-sleep safe context. If I had said 'atomic' or 'spinlock'
context you would probably be telling me off for missing some other
non-sleep safe contexts.

The point is that we are discussing the issue of calls which may sleep.
Even if I was not entirely clear by getting the wording wrong, you _do_
know what I am talking about. You could correct on the bits on I get
wrong instead of labeling me a troll.

If we strip my patch back to just introducing gpio_request_cansleep,
which would be used in any driver where all of the calls are
gpio_(set/get)_cansleep, and make gpio_request only allow non-sleeping
gpios then incorrect use of gpios would be caught at request time and
returned to the caller as an error.

~Ryan