lkml.org 
[lkml]   [2010]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleeping gpios)
    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




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