02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

12 May, 2015

1 commit

  • Remove gpiod_sysfs_set_active_low (and gpio_sysfs_set_active_low) which
    allowed code to change the polarity of a gpio line even after it had
    been exported through sysfs.

    Drivers should not care, and generally does not know, about gpio-line
    polarity which is a hardware feature that needs to be described by
    firmware.

    It is currently possible to define gpio-line polarity in device-tree and
    acpi firmware or using platform data. Userspace can also change the
    polarity through sysfs.

    Note that drivers using the legacy gpio interface could still use
    GPIOF_ACTIVE_LOW to change the polarity before exporting the gpio.

    There are no in-kernel users of this interface.

    Cc: Jonathan Corbet
    Cc: Harry Wei
    Cc: Arnd Bergmann
    Cc: linux-doc@vger.kernel.org
    Cc: linux-kernel@zh-kernel.org
    Cc: linux-arch@vger.kernel.org
    Signed-off-by: Johan Hovold
    Reviewed-by: Alexandre Courbot
    Signed-off-by: Linus Walleij

    Johan Hovold
     

29 Oct, 2014

1 commit


20 Feb, 2014

2 commits


25 Nov, 2013

1 commit


12 Nov, 2013

1 commit

  • Pull GPIO changes from Linus Walleij:
    "Here is the bulk of GPIO changes for the v3.13 development cycle.

    I've got ACKs for the things that affect other subsystems (or it's my
    own subsystem, like pinctrl). Most of that pertain to an attempt from
    my side to consolidate and get rid of custom GPIO implementations in
    the ARM tree. I will continue doing this.

    The main change this time is the new GPIO descriptor API, background
    for this can be found in Corbet's summary from this january in LWN:

    http://lwn.net/Articles/533632/

    Summary:

    - Merged the GPIO descriptor API from Alexandre Courbot. This is a
    first step toward trying to get rid of the global GPIO numberspace
    for the future.

    - Add an API so that driver can flag that a certain GPIO line is
    being used by a irqchip backend for generating IRQs, so that we can
    enforce checks, like not allowing users to switch that line to an
    output at runtime, since this makes no sense. Implemented
    corresponding calls in a few select drivers.

    - ACPI GPIO cleanups, refactorings and switch to using the
    descriptor-based interface.

    - Support for the TPS80036 Palmas GPIO variant.

    - A new driver for the Broadcom Kona GPIO SoC IP block.

    - Device tree support for the PCF857x driver.

    - A set of ARM GPIO refactorings with the goal of getting rid of a
    bunch of custom GPIO implementations from the arch/arm/* tree:

    * Move the IOP GPIO driver to the GPIO subsystem and fix all users
    to use the gpiolib API for accessing GPIOs. Delete the old
    custom GPIO implementation.

    * Delete the unused custom PXA GPIO implemention.

    * Convert all users of the IXP4 custom GPIO implementation to use
    gpiolib and delete the custom implementation.

    * Delete the custom Gemini GPIO implementation, also completely
    unused.

    - Various cleanups and renamings"

    * tag 'gpio-v3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (85 commits)
    gpio: gpio-mxs: Remove unneeded dt checks
    gpio: pl061: don't depend on CONFIG_ARM
    gpio: bcm-kona: add missing .owner to struct gpio_chip
    gpiolib: provide a declaration of seq_file in gpio/driver.h
    gpiolib: include gpio/consumer.h in of_gpio.h for desc_to_gpio()
    gpio: provide stubs for devres gpio functions
    gpiolib: devres: add missing headers
    gpiolib: make GPIO_DEVRES depend on GPIOLIB
    gpiolib: devres: fix devm_gpiod_get_index()
    gpiolib / ACPI: document the GPIO descriptor based interface
    gpiolib / ACPI: allow passing GPIOF_ACTIVE_LOW for GpioInt resources
    gpiolib / ACPI: add ACPI support for gpiod_get_index()
    gpiolib / ACPI: convert to gpiod interfaces
    gpiolib: add gpiod_get() and gpiod_put() functions
    gpiolib: port of_ functions to use gpiod
    gpiolib: export descriptor-based GPIO interface
    Fixup "MAINTAINERS: GPIO-INTEL-MID: add maintainer"
    gpio: bcm281xx: Don't print addresses of GPIO area in probe()
    gpio: tegra: use new gpio_lock_as_irq() API
    gpio: rcar: Include linux/of.h header
    ...

    Linus Torvalds
     

30 Oct, 2013

1 commit

  • commit 6b3d8145dcfdbbb43f13544e16f44f4574f941dd
    "gpiolib: make GPIO_DEVRES depend on GPIOLIB"
    breaks builds when device drivers are using devm_gpio*
    devres functions without enabling GPIOLIB, relying on
    the devres code to be compiled anyway.

    Provide stubs so that we get these if we're using the
    devres functions without GPIOLIB.

    Reported-by: Fengguang Wu
    Cc: Alexandre Courbot
    Signed-off-by: Linus Walleij

    Linus Walleij
     

20 Oct, 2013

1 commit

  • This patch exports the gpiod_* family of API functions, a safer
    alternative to the legacy GPIO interface. Differences between the gpiod
    and legacy gpio APIs are:

    - gpio works with integers, whereas gpiod operates on opaque handlers
    which cannot be forged or used before proper acquisition
    - gpiod get/set functions are aware of the active low state of a GPIO
    - gpio consumers should now include to access
    the new interface, whereas chips drivers will use

    The legacy gpio API is now built as inline functions on top of gpiod.

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

    Alexandre Courbot
     

16 Oct, 2013

2 commits

  • This patch adds the infrastructure required to register non-linear gpio
    ranges through gpiolib and the standard GPIO device tree bindings.

    Signed-off-by: Christian Ruppert
    Signed-off-by: Linus Walleij

    Christian Ruppert
     
  • It is currently often possible in many GPIO drivers to request
    a GPIO line to be used as IRQ after calling gpio_to_irq() and,
    as the gpiolib is not aware of this, set the same line to
    output and start driving it, with undesired side effects.

    As it is a bogus usage scenario to request a line flagged as
    output to used as IRQ, we introduce APIs to let gpiolib track
    the use of a line as IRQ, and also set this flag from the
    userspace ABI.

    The API is symmetric so that lines can also be flagged from
    .irq_enable() and unflagged from IRQ by .irq_disable().
    The debugfs file is altered so that we see if a line is
    reserved for IRQ.

    Cc: Enric Balletbo i Serra
    Cc: Grant Likely
    Cc: Jean-Christophe PLAGNIOL-VILLARD
    Cc: Santosh Shilimkar
    Acked-by: Alexandre Courbot
    Reviewed-by: Stephen Warren
    Reviewed-by: Javier Martinez Canillas
    Signed-off-by: Linus Walleij

    Linus Walleij
     

16 Apr, 2013

1 commit


22 Jan, 2013

1 commit

  • Some architectures (e.g. blackfin) provide gpio API without requiring
    GPIOLIB support (ARCH_WANT_OPTIONAL_GPIOLIB). devm_gpio_* functions
    should also work for these architectures, since they do not really
    depend on GPIOLIB.

    Add a new option GPIO_DEVRES (enabled by default) to control the build
    of devres.c. It also removes the empty version of devm_gpio_*
    functions for !GENERIC_GPIO build from linux/gpio.h, and moves the
    function declarations from asm-generic/gpio.h into linux/gpio.h.

    Signed-off-by: Shawn Guo
    Signed-off-by: Linus Walleij

    Shawn Guo
     

21 Nov, 2012

2 commits

  • To be crystal clear on what the arguments mean in this
    funtion dealing with both GPIO and PIN ranges with confusing
    naming, we now have gpio_offset and pin_offset and we are
    on the clear that these are offsets into the specific GPIO
    and pin controller respectively. The GPIO chip itself will
    of course keep track of the base offset into the global
    GPIO number space.

    Reviewed-by: Viresh Kumar
    Signed-off-by: Linus Walleij

    Linus Walleij
     
  • Like with commit 3c739ad0df5eb41cd7adad879eda6aa09879eb76
    it is not always enough to specify all the pins of a gpio_chip
    from offset zero to be added to a pin map range, since the
    mapping from GPIO to pin controller may not be linear at all,
    but need to be broken into a few consecutive sub-ranges or
    1-pin entries for complicated cases. The ranges may also be
    sparse.

    This alters the signature of the function to accept offsets
    into both the GPIO-chip local pinspace and the pin controller
    local pinspace.

    Reviewed-by: Stephen Warren
    Reviewed-by: Viresh Kumar
    Signed-off-by: Linus Walleij

    Linus Walleij
     

12 Nov, 2012

4 commits

  • The includes are updated again: now we need to account
    for the problem introduced by commit:
    595679a8038584df7b9398bf34f61db3c038bfea
    "gpiolib: fix up function prototypes etc"

    Actually we need static inlines in include/asm-generic/gpio.h
    as well since we may have GPIOLIB but not PINCTRL.
    Make sure to move all the CONFIG_PINCTRL business
    to the end of the file so we are sure we have
    declared struct gpio_chip.

    And we need to keep the static inlines in
    but here for the !CONFIG_GENERIC_GPIO case, and then we
    may as well throw in a few warnings like the other
    prototypes there, if someone would have the bad taste
    of compiling without GENERIC_GPIO even.

    Signed-off-by: Linus Walleij

    Linus Walleij
     
  • The fact that of_gpiochip_add_pin_range() and
    gpiochip_add_pin_range() share too much code is fragile and
    will invariably mean that bugs need to be fixed in two places
    instead of one.

    So separate the concerns of gpiolib.c and gpiolib-of.c and
    have the latter call the former as back-end. This is necessary
    also when going forward with other device descriptions such
    as ACPI.

    This is done by:

    - Adding a return code to gpiochip_add_pin_range() so we can
    reliably check whether this succeeds.

    - Get rid of the custom of_pinctrl_add_gpio_range() from
    pinctrl. Instead create of_pinctrl_get() to just retrive the
    pin controller per se from an OF node. This composite
    function was just begging to be deleted, it was way to
    purpose-specific.

    - Use pinctrl_dev_get_name() to get the name of the retrieved
    pin controller and use that to call back into the generic
    gpiochip_add_pin_range().

    Now the pin range is only allocated and tied to a pin
    controller from the core implementation in gpiolib.c.

    Signed-off-by: Linus Walleij

    Linus Walleij
     
  • Commit 69e1601bca88809dc118abd1becb02c15a02ec71
    "gpiolib: provide provision to register pin ranges"

    Got most of it's function prototypes wrong, so fix this up by:

    - Moving the void declarations into static inlines in
    (previously the actual prototypes were declared
    here...)

    - Declare the gpiochip_add_pin_range() and
    gpiochip_remove_pin_ranges() functions in
    together with the pin range struct declaration itself.

    - Actually only implement these very functions in gpiolib.c
    if CONFIG_PINCTRL is set.

    - Additionally export the symbols since modules will need to
    be able to do this.

    Reviewed-by: Stephen Warren
    Signed-off-by: Linus Walleij

    Linus Walleij
     
  • pinctrl subsystem needs gpio chip base to prepare set of gpio
    pin ranges, which a given pinctrl driver can handle. This is
    important to handle pinctrl gpio request calls in order to
    program a given pin properly for gpio operation.

    As gpio base is allocated dynamically during gpiochip
    registration, presently there exists no clean way to pass this
    information to the pinctrl subsystem.

    After few discussions from [1], it was concluded that may be
    gpio controller reporting the pin range it supports, is a
    better way than pinctrl subsystem directly registering it.

    [1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816

    Cc: Grant Likely
    Signed-off-by: Viresh Kumar
    Signed-off-by: Shiraz Hashim
    [Edited documentation a bit]
    Signed-off-by: Linus Walleij

    Shiraz Hashim
     

05 Jul, 2012

1 commit

  • The bit 2 and 3 in GPIO flag are allocated for the
    flag OPEN_DRAIN/OPEN_SOURCE. These bits are reused
    for the flag EXPORT/EXPORT_CHANGEABLE and so creating
    conflict.
    Fix this conflict by assigning bit 4 and 5 for the
    flag EXPORT/EXPORT_CHANGEABLE.

    Signed-off-by: Laxman Dewangan
    Signed-off-by: Linus Walleij

    Laxman Dewangan
     

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
     

12 May, 2012

1 commit

  • Rather than requiring architectures that use gpiolib but don't have any
    need to define anything custom to copy an asm/gpio.h provide a Kconfig
    symbol which architectures must select in order to include gpio.h and
    for other architectures just provide the trivial implementation directly.

    This makes it much easier to do gpiolib updates and is also a step towards
    making gpiolib APIs available on every architecture.

    For architectures with existing boilerplate code leave a stub header in
    place which warns on direct inclusion of asm/gpio.h and includes
    linux/gpio.h to catch code that's doing this. Direct inclusion of
    asm/gpio.h has long been deprecated.

    Signed-off-by: Mark Brown
    Acked-by: Jonas Bonn
    Acked-by: Tony Luck
    Acked-by: Linus Walleij
    Signed-off-by: Grant Likely

    Mark Brown
     

06 Apr, 2012

2 commits


29 Mar, 2012

1 commit

  • Pull GPIO changes for v3.4 from Grant Likely:
    "Primarily gpio device driver changes with some minor side effects
    under arch/arm and arch/x86. Also includes a few core changes such as
    explicitly supporting (electrical) open source and open drain outputs
    and some help for parsing gpio devicetree properties."

    Fix up context conflict due to Laxman Dewangan adding sleep control for
    the tps65910 driver separately for gpio's and regulators.

    * tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6: (34 commits)
    gpio/ep93xx: Remove unused inline function and useless pr_err message
    gpio/sodaville: Mark broken due to core irqdomain migration
    gpio/omap: fix redundant decoding of gpio offset
    gpio/omap: fix incorrect update to context.irqenable1
    gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_*
    gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg
    gpio/omap: fix _set_gpio_irqenable implementation
    gpio/omap: fix trigger type to unsigned
    gpio/omap: fix wakeup_en register update in _set_gpio_wakeup()
    gpio: tegra: tegra_gpio_config shouldn't be __init
    gpio/davinci: fix enabling unbanked GPIO IRQs
    gpio/davinci: fix oops on unbanked gpio irq request
    gpio/omap: Fix section warning for omap_mpuio_alloc_gc()
    ARM: tegra: export tegra_gpio_{en,dis}able
    gpio/gpio-stmpe: Fix the value returned by _get_value routine
    Documentation/gpio.txt: Explain expected pinctrl interaction
    GPIO: LPC32xx: Add output reading to GPO P3
    GPIO: LPC32xx: Fix missing bit selection mask
    gpio/omap: fix wakeups on level-triggered GPIOs
    gpio/omap: Fix IRQ handling for SPARSE_IRQ
    ...

    Linus Torvalds
     

05 Mar, 2012

3 commits

  • Adding support for the open source gpio on which client
    can specify the open source property through GPIO flag
    GPIOF_OPEN_SOURCE at the time of gpio request.
    The open source pins are normally pulled low and it
    cannot be driven to output with value of 0 and so
    when client request for setting the pin to LOW, the
    gpio will be set to input direction to make pin in tristate
    and hence PULL-DOWN on pins will make the state to LOW.
    The open source pin can be driven to HIGH by setting output
    with value of 1.

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

    Laxman Dewangan
     
  • Adding support for the open drain gpio on which client
    can specify the open drain property through GPIO flag
    GPIOF_OPEN_DRAIN at the time of gpio request.
    The open drain pins are normally pulled high and it
    cannot be driven to output with value of 1 and so
    when client request for setting the pin to HIGH, the
    gpio will be set to input direction to make pin in tristate
    and hence PULL-UP on pins will make the state to HIGH.
    The open drain pin can be driven to LOW by setting output
    with value of 0.

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

    Laxman Dewangan
     
  • If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
    other BUG variant in a static inline (i.e. not in a #define) then
    that header really should be including and not just
    expecting it to be implicitly present.

    We can make this change risk-free, since if the files using these
    headers didn't have exposure to linux/bug.h already, they would have
    been causing compile failures/warnings.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

24 Oct, 2011

1 commit

  • Currently struct gpio is only defined when using gpiolib which makes the
    stub gpio_request_array() much less useful in drivers than is ideal as
    they can't work with struct gpio. Since there are no other definitions
    in kernel instead make the define always available no matter if gpiolib
    is selectable or selected, ensuring that drivers can always use the
    type.

    Signed-off-by: Mark Brown
    Signed-off-by: Grant Likely

    Mark Brown
     

16 Jun, 2011

1 commit

  • Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO
    is enabled by moving them to .

    Fixes these build errors in linux-next:
    sound/soc/codecs/ak4641.c:524: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)
    sound/soc/codecs/wm8915.c:2921: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function)

    Signed-off-by: Randy Dunlap
    Signed-off-by: Grant Likely

    Randy Dunlap
     

28 May, 2011

1 commit


27 May, 2011

1 commit

  • Make the code a bit more readable.

    Instead of casting an int to an unsigned then comparing to
    MAX_NR_GPIOS, add a >= 0 test and let the compiler optimizer
    do the conversion to unsigned.

    The generated code should be the same.

    Signed-off-by: Joe Perches
    Acked-by: Linus Walleij
    Signed-off-by: Grant Likely

    Joe Perches
     

15 Jan, 2011

1 commit


14 Jan, 2011

3 commits

  • This reverts commit 0fdae42d361bbb431ca0ab0efed5126a94821177, which
    wasn't really supposed to go in, and causes lots of annoying warnings.

    Quoth Andrew:
    "Complete brainfart - I meant to drop that patch ages ago."

    Quoth Greg:
    "Ick, yeah, that patch isn't ok to go in as-is, all of the callers
    need to be fixed up first, which is what I thought we had agreed on..."

    Reported-by: Stephen Rothwell
    Acked-by: Andrew Morton
    Acked-by: Greg KH
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • Signed-off-by: Wolfram Sang
    Cc: David Brownell
    Cc: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Wolfram Sang
     
  • Because GPIOs can have crucial functions especially in embedded systems,
    we are better safe than sorry regarding their configuration. For
    gpio_request, the documentation is simply enforced: "The return
    value of gpio_request() must be checked." For gpio_direction_* and
    gpio_request_*, we now act accordingly.

    Signed-off-by: Wolfram Sang
    Cc: David Brownell
    Cc: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Wolfram Sang
     

01 Sep, 2010

1 commit

  • With CONFIG_GPIOLIB=n, the 'struct gpio_chip' is not declared,
    so the following pops up on PowerPC:

    cc1: warnings being treated as errors
    In file included from arch/powerpc/platforms/52xx/mpc52xx_common.c:19:
    include/linux/of_gpio.h:74: warning: 'struct gpio_chip' declared
    inside parameter list
    include/linux/of_gpio.h:74: warning: its scope is only this definition
    or declaration, which is probably not what
    you want
    include/linux/of_gpio.h:75: warning: 'struct gpio_chip' declared
    inside parameter list
    make[2]: *** [arch/powerpc/platforms/52xx/mpc52xx_common.o] Error 1

    This patch fixes the issue by providing the proper forward declaration.

    Signed-off-by: Anton Vorontsov
    Signed-off-by: Grant Likely

    Anton Vorontsov
     

28 May, 2010

1 commit

  • A few architectures, like OMAP, allow you to set a debouncing time for the
    gpio before generating the IRQ. Teach gpiolib about that.

    Mark said:
    : This would be generally useful for embedded systems, especially where
    : the interrupt concerned is a wake source. It allows drivers to avoid
    : spurious interrupts from noisy sources so if the hardware supports it
    : the driver can avoid having to explicitly wait for the signal to become
    : stable and software has to cope with fewer events. We've lived without
    : it for quite some time, though.

    David said:
    : I looked at adding debounce support to the generic GPIO calls (and thus
    : gpiolib) some time back, but decided against it. I forget why at this
    : time (check list archives) but it wasn't because of lack of utility in
    : certain contexts.
    :
    : One thing to watch out for is just how variable the hardware capabilities
    : are. Atmel GPIOs have something like a fixed number of 32K clock cycles
    : for debounce, twl4030 had something odd, OMAPs were more like the Atmel
    : chips but with a different clock. In some cases debouncing had to be
    : ganged, not per-GPIO. And so forth.

    Signed-off-by: Felipe Balbi
    Cc: Tony Lindgren
    Cc: David Brownell
    Reviewed-by: Mark Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Felipe Balbi
     

16 Dec, 2009

1 commit

  • Drivers may use gpiolib sysfs as part of their public user space
    interface. The GPIO number and polarity might change from board to
    board. The gpio_export_link() call can be used to hide the GPIO number
    from user space. Add support for also hiding the GPIO line polarity
    changes from user space.

    Signed-off-by: Jani Nikula
    Cc: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jani Nikula
     

23 Sep, 2009

1 commit

  • Commit 926b663ce8215ba448960e1ff6e58b67a2c3b99b (gpiolib: allow GPIOs to
    be named) already provides naming on the chip level. This patch provides
    more flexibility by allowing multiple names where ever in sysfs on a per
    GPIO basis.

    Adapted from David Brownell's comments on a similar concept:
    http://lkml.org/lkml/2009/4/20/203.

    [randy.dunlap@oracle.com: fix build for CONFIG_GENERIC_GPIO=n]
    Signed-off-by: Jani Nikula
    Acked-by: David Brownell
    Cc: Daniel Silverstone
    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jani Nikula