[lkml]   [2010]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleeping gpios)
    David Brownell wrote:
    > --- On Tue, 6/22/10, Ryan Mallon <> wrote:
    >>> --- On Tue, 6/22/10, Ryan Mallon <>
    >> 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).


    > 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"???

    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.


     \ /
      Last update: 2010-06-23 21:15    [W:0.037 / U:13.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site