25 Feb, 2016

1 commit

  • devm_get_gpiod_from_child() tries several property suffixes to find a
    GPIO descriptor. If all suffixes fail and no probe deferral has been
    detected, it returns the error of the last try.

    However, if any but the last try fails with a real error (e.g. -EBUSY),
    this error is not propagated, and -ENOENT will be returned.
    This confuses drivers that e.g. want to detect if a GPIO is already in
    use.

    To fix this, change the loop logic to continue on -ENOENT, which
    indicates the property was not found and the next suffix should be
    tried, and propagate all other detected errors.

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Linus Walleij

    Geert Uytterhoeven
     

06 Jul, 2015

1 commit

  • Now that all[1] users of the gpiod_get functions are converted to make
    use of the up to now optional flags parameter, make it mandatory which
    allows to remove some cpp magic.

    [1] all but etraxfs-uart which is broken anyhow and I'm allowed to
    ignore it by Jesper Nilsson :-)

    Acked-by: Alexandre Courbot
    Signed-off-by: Uwe Kleine-König

    Uwe Kleine-König
     

18 Mar, 2015

1 commit

  • Commit 1feb57a245a4910b03202a814ffc51a900bd4aca
    "gpio: add parameter to allow the use named gpios"
    includes a double-consted array. What we want is not
    const const * but const * const (const pointer to const
    data). Fix this.

    Reported-by: Dan Carpenter
    Cc: Olliver Schinagl
    Cc: Rojhalat Ibrahim
    Signed-off-by: Linus Walleij

    Linus Walleij
     

05 Mar, 2015

1 commit


04 Mar, 2015

1 commit

  • The gpio binding document says that new code should always use named
    gpios. Patch 40b73183 added support to parse a list of gpios from child
    nodes, but does not make it possible to use named gpios. This patch adds
    the con_id property and implements it is done in gpiolib.c, where the
    old-style of using unnamed gpios still works.

    Signed-off-by: Olliver Schinagl
    Acked-by: Bryan Wu
    Acked-by: Dmitry Torokhov
    Reviewed-by: Alexandre Courbot
    Signed-off-by: Linus Walleij

    Olliver Schinagl
     

05 Nov, 2014

1 commit

  • Some drivers need to deal with only firmware representation of its
    GPIOs. An example would be a GPIO button array driver where each button
    is described as a separate firmware node in device tree. Typically these
    child nodes do not have physical representation in the Linux device
    model.

    In order to help device drivers to handle such firmware child nodes we
    add dev[m]_get_named_gpiod_from_child() that takes a child firmware
    node pointer as its second argument (the first one is the parent device
    itself), finds the GPIO using whatever is the underlying firmware
    method, and requests the GPIO properly.

    Signed-off-by: Mika Westerberg
    Acked-by: Alexandre Courbot
    Acked-by: Grant Likely
    Signed-off-by: Rafael J. Wysocki

    Mika Westerberg
     

17 Aug, 2014

1 commit

  • Correct typo in the name of the type given to sizeof. Because it is the
    size of a pointer that is wanted, the typo has no impact on compilation or
    execution.

    This problem was found using Coccinelle (http://coccinelle.lip6.fr/). The
    semantic patch used can be found in message 0 of this patch series.

    Signed-off-by: Julia Lawall
    Acked-by: Alexandre Courbot
    Signed-off-by: Linus Walleij

    Julia Lawall
     

28 Jul, 2014

1 commit

  • The huge majority of GPIOs have their direction and initial value set
    right after being obtained by one of the gpiod_get() functions. The
    integer GPIO API had gpio_request_one() that took a convenience flags
    parameter allowing to specify an direction and value applied to the
    returned GPIO. This feature greatly simplifies client code and ensures
    errors are always handled properly.

    A similar feature has been requested for the gpiod API. Since setting
    the direction of a GPIO is so often the very next action done after
    obtaining its descriptor, we prefer to extend the existing functions
    instead of introducing new functions that would raise the
    number of gpiod getters to 16 (!).

    The drawback of this approach is that all gpiod clients need to be
    updated. To limit the pain, temporary macros are introduced that allow
    gpiod_get*() to be called with or without the extra flags argument. They
    will be removed once all consumer code has been updated.

    Signed-off-by: Alexandre Courbot
    Reviewed-by: Mark Brown
    Signed-off-by: Linus Walleij

    Alexandre Courbot
     

09 May, 2014

1 commit

  • Introduce gpiod_get_optional() and gpiod_get_index_optional() helpers
    that make it easier for drivers to handle optional GPIOs.

    Currently in order to handle optional GPIOs, a driver needs to special
    case error handling for -ENOENT, such as this:

    gpio = gpiod_get(dev, "foo");
    if (IS_ERR(gpio)) {
    if (PTR_ERR(gpio) != -ENOENT)
    return PTR_ERR(gpio);

    gpio = NULL;
    }

    if (gpio) {
    /* set up GPIO */
    }

    With these new helpers the above is reduced to:

    gpio = gpiod_get_optional(dev, "foo");
    if (IS_ERR(gpio))
    return PTR_ERR(gpio);

    if (gpio) {
    /* set up GPIO */
    }

    While at it, device-managed variants of these functions are also
    provided.

    Signed-off-by: Thierry Reding
    Reviewed-by: Alexandre Courbot
    Signed-off-by: Linus Walleij

    Thierry Reding
     

30 Oct, 2013

1 commit


23 Oct, 2013

1 commit


20 Oct, 2013

1 commit

  • Add gpiod_get(), gpiod_get_index() and gpiod_put() functions that
    provide safer management of GPIOs.

    These functions put the GPIO framework in line with the conventions of
    other frameworks in the kernel, and help ensure every GPIO is declared
    properly and valid while it is used.

    Signed-off-by: Alexandre Courbot
    Signed-off-by: Linus Walleij

    Alexandre Courbot
     

17 Jun, 2013

1 commit


05 Jul, 2012

1 commit


25 May, 2012

1 commit

  • Pull GPIO driver changes from Grant Likely:
    "Lots of gpio changes, both to core code and drivers.

    Changes do touch architecture code to remove the need for separate
    arm/gpio.h includes in most architectures.

    Some new drivers are added, and a number of gpio drivers are converted
    to use irq_domains for gpio inputs used as interrupts. Device tree
    support has been amended to allow multiple gpio_chips to use the same
    device tree node.

    Remaining changes are primarily bug fixes."

    * tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6: (33 commits)
    gpio/generic: initialize basic_mmio_gpio shadow variables properly
    gpiolib: Remove 'const' from data argument of gpiochip_find()
    gpio/rc5t583: add gpio driver for RICOH PMIC RC5T583
    gpiolib: quiet gpiochip_add boot message noise
    gpio: mpc8xxx: Prevent NULL pointer deref in demux handler
    gpio/lpc32xx: Add device tree support
    gpio: Adjust of_xlate API to support multiple GPIO chips
    gpiolib: Implement devm_gpio_request_one()
    gpio-mcp23s08: dbg_show: fix pullup configuration display
    Add support for TCA6424A
    gpio/omap: (re)fix wakeups on level-triggered GPIOs
    gpio/omap: fix broken context restore for non-OFF mode transitions
    gpio/omap: fix missing check in *_runtime_suspend()
    gpio/omap: remove cpu_is_omapxxxx() checks from *_runtime_resume()
    gpio/omap: remove suspend/resume callbacks
    gpio/omap: remove retrigger variable in gpio_irq_handler
    gpio/omap: remove saved_wakeup field from struct gpio_bank
    gpio/omap: remove suspend_wakeup field from struct gpio_bank
    gpio/omap: remove saved_fallingdetect, saved_risingdetect
    gpio/omap: remove virtual_irq_start variable
    ...

    Conflicts:
    drivers/gpio/gpio-samsung.c

    Linus Torvalds
     

19 May, 2012

1 commit

  • Allow drivers to use the modern request and configure idiom together
    with devres.

    As with plain gpio_request() and gpio_request_one() we can't implement
    the old school version in terms of _one() as this would force the
    explicit selection of a direction in gpio_request() which could break
    systems if we pick the wrong one. Implementing devm_gpio_request_one()
    in terms of devm_gpio_request() would needlessly complicate things or
    lead to duplication from the unmanaged version depending on how it's
    done.

    Signed-off-by: Mark Brown
    Acked-by: Linus Walleij
    Signed-off-by: Grant Likely

    Mark Brown
     

05 May, 2012

1 commit


05 Jan, 2012

1 commit