1. 08 Jan, 2018 1 commit
  2. 02 Dec, 2017 1 commit
    • Andrew Jeffery's avatar
      gpio: gpiolib: Generalise state persistence beyond sleep · e10f72bf
      Andrew Jeffery authored
      General support for state persistence is added to gpiolib with the
      introduction of a new pinconf parameter to propagate the request to
      hardware. The existing persistence support for sleep is adapted to
      include hardware support if the GPIO driver provides it. Persistence
      continues to be enabled by default; in-kernel consumers can opt out, but
      userspace (currently) does not have a choice.
      
      The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are
      renamed, dropping the SLEEP prefix to reflect that the concept is no
      longer sleep-specific.  I feel that renaming to just *_MAY_LOSE_VALUE
      could initially be misinterpreted, so I've further changed the symbols
      to *_TRANSITORY and *_PERSISTENT to address this.
      
      The sysfs interface is modified only to keep consistency with the
      chardev interface in enforcing persistence for userspace exports.
      Signed-off-by: default avatarAndrew Jeffery <andrew@aj.id.au>
      Reviewed-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Acked-by: Rob Herring's avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      e10f72bf
  3. 20 Oct, 2017 1 commit
    • Andrew Jeffery's avatar
      gpio: Fix loose spelling · 2cbfca66
      Andrew Jeffery authored
      Literally.
      
      I expect "lose" was meant here, rather than "loose", though you could feasibly
      use a somewhat uncommon definition of "loose" to mean what would be meant by
      "lose": "Loose the hounds" for instance, as in "Release the hounds".
      Substituting in "value" for "hounds" gives "release the value", and makes some
      sense, but futher substituting back to loose gives "loose the value" which
      overall just seems a bit anachronistic.
      
      Instead, use modern, pragmatic English and save a character.
      
      Cc: Russell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarAndrew Jeffery <andrew@aj.id.au>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      2cbfca66
  4. 29 May, 2017 1 commit
  5. 07 Apr, 2017 1 commit
    • Laxman Dewangan's avatar
      gpio: core: Decouple open drain/source flag with active low/high · 4c0facdd
      Laxman Dewangan authored
      Currently, the GPIO interface is said to Open Drain if it is Single
      Ended and active LOW. Similarly, it is said as Open Source if it is
      Single Ended and active HIGH.
      
      The active HIGH/LOW is used in the interface for setting the pin
      state to HIGH or LOW when enabling/disabling the interface.
      
      In Open Drain interface, pin is set to HIGH by putting pin in
      high impedance and LOW by driving to the LOW.
      
      In Open Source interface, pin is set to HIGH by driving pin to
      HIGH and set to LOW by putting pin in high impedance.
      
      With above, the Open Drain/Source is unrelated to the active LOW/HIGH
      in interface. There is interface where the enable/disable of interface
      is ether active LOW or HIGH but it is Open Drain type.
      
      Hence decouple the Open Drain with Single Ended + Active LOW and
      Open Source with Single Ended + Active HIGH.
      
      Adding different flag for the Open Drain/Open Source which is valid
      only when Single ended flag is enabled.
      Signed-off-by: default avatarLaxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      4c0facdd
  6. 03 Oct, 2016 1 commit
  7. 05 Jan, 2016 1 commit
  8. 04 Jan, 2016 1 commit
    • Arnd Bergmann's avatar
      gpiolib: always initialize *flags from of_get_named_gpio_flags · 427e0dc5
      Arnd Bergmann authored
      The of_get_named_gpio_flags() function does nothing other than returning
      an error when CONFIG_OF_GPIO is disabled, but that causes spurious
      warnings about possible use of uninitialized variables in any code that
      does not check the of_get_named_gpio_flags() return value before trying
      to use the flags:
      
      drivers/input/misc/rotary_encoder.c: In function 'rotary_encoder_probe':
      drivers/input/misc/rotary_encoder.c:223:28: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
      drivers/power/bq24735-charger.c: In function 'bq24735_charger_probe':
      drivers/power/bq24735-charger.c:227:12: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
      drivers/power/sbs-battery.c: In function 'sbs_probe':
      drivers/power/sbs-battery.c:782:17: warning: 'gpio_flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      This changes the behavior of the inline helper to set the flags to zero
      when OF_GPIO is disabled, to avoid the warnings. In all cases I've
      encountered, we don't actually get to the place that uses the flags
      if CONFIG_OF is disabled because we won't enter the DT parser code.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      427e0dc5
  9. 16 Oct, 2015 1 commit
  10. 28 Jul, 2015 1 commit
  11. 15 Jan, 2015 1 commit
  12. 21 May, 2014 1 commit
    • Alexandre Courbot's avatar
      gpio: make of_get_named_gpiod_flags() private · f01d9075
      Alexandre Courbot authored
      of_get_named_gpiod_flags() is visible and directly usable by GPIO
      consumers, but it really should not as the gpiod interface relies
      on the simpler gpiod_get() to provide properly-configured GPIOs.
      
      of_get_named_gpiod_flags() is just used internally by gpiolib to
      implement gpiod_get(), and by the old of_get_named_gpio_flags()
      function, therefore it makes sense to make it gpiolib-private.
      
      As a side-effect, the unused (and unneeded) of_get_gpiod_flags()
      inline function is also removed, and of_get_named_gpio_flags() is moved
      from a static inline function to a regular one in gpiolib-of.c
      
      This results in all references to gpiod_* functions in of_gpio.h being
      gone, which is the way it should be since this file is part of the old
      integer GPIO interface.
      
      Changes since v1:
      - Fixed compilation error when CONFIG_OF_GPIO is not defined
      - Fixed warning due to of_gpio_flags enum not being declared
        in private gpiolib.h header
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      f01d9075
  13. 30 Oct, 2013 1 commit
  14. 19 Oct, 2013 1 commit
  15. 13 Feb, 2013 1 commit
  16. 18 May, 2012 1 commit
  17. 06 Feb, 2012 1 commit
  18. 12 Dec, 2011 1 commit
    • Grant Likely's avatar
      of: create of_phandle_args to simplify return of phandle parsing data · 15c9a0ac
      Grant Likely authored
      of_parse_phandle_with_args() needs to return quite a bit of data.  Rather
      than making each datum a separate **out_ argument, this patch creates
      struct of_phandle_args to contain all the returned data and reworks the
      user of the function.  This patch also enables of_parse_phandle_with_args()
      to return the device node pointer for the phandle node.
      
      This patch also ends up being fairly major surgery to
      of_parse_handle_with_args().  The existing structure didn't work well
      when extending to use of_phandle_args, and I discovered bugs during testing.
      I also took the opportunity to rename the function to be like the
      existing of_parse_phandle().
      
      v2: - moved declaration of of_phandle_args to fix compile on non-DT builds
          - fixed incorrect index in example usage
          - fixed incorrect return code handling for empty entries
      Reviewed-by: default avatarShawn Guo <shawn.guo@freescale.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      15c9a0ac
  19. 28 Jul, 2011 1 commit
  20. 28 Jun, 2011 1 commit
  21. 05 Jul, 2010 3 commits
    • Anton Vorontsov's avatar
      of/gpio: add default of_xlate function if device has a node pointer · 391c970c
      Anton Vorontsov authored
      Implement generic OF gpio hooks and thus make device-enabled GPIO chips
      (i.e.  the ones that have gpio_chip->dev specified) automatically attach
      to the OpenFirmware subsystem.  Which means that now we can handle I2C and
      SPI GPIO chips almost* transparently.
      
      * "Almost" because some chips still require platform data, and for these
        chips OF-glue is still needed, though with this change the glue will
        be much smaller.
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Bill Gatliff <bgat@billgatliff.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      CC: linux-kernel@vger.kernel.org
      CC: devicetree-discuss@lists.ozlabs.org
      391c970c
    • Grant Likely's avatar
      of/gpio: stop using device_node data pointer to find gpio_chip · 594fa265
      Grant Likely authored
      Currently the kernel uses the struct device_node.data pointer to resolve
      a struct gpio_chip pointer from a device tree node.  However, the .data
      member doesn't provide any type checking and there aren't any rules
      enforced on what it should be used for.  There's no guarantee that the
      data stored in it actually points to an gpio_chip pointer.
      
      Instead of relying on the .data pointer, this patch modifies the code
      to add a lookup function which scans through the registered gpio_chips
      and returns the gpio_chip that has a pointer to the specified
      device_node.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Anton Vorontsov <avorontsov@ru.mvista.com>
      CC: Grant Likely <grant.likely@secretlab.ca>
      CC: David Brownell <dbrownell@users.sourceforge.net>
      CC: Bill Gatliff <bgat@billgatliff.com>
      CC: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: Jean Delvare <khali@linux-fr.org>
      CC: linux-kernel@vger.kernel.org
      CC: devicetree-discuss@lists.ozlabs.org
      594fa265
    • Anton Vorontsov's avatar
      of/gpio: Kill of_gpio_chip and add members directly to gpio_chip · a19e3da5
      Anton Vorontsov authored
      The OF gpio infrastructure is great for describing GPIO connections within
      the device tree.  However, using a GPIO binding still requires changes to
      the gpio controller just to add an of_gpio structure.  In most cases, the
      gpio controller doesn't actually need any special support and the simple
      OF gpio mapping function is more than sufficient.  Additional, the current
      scheme of using of_gpio_chip requires a convoluted scheme to maintain
      1:1 mappings between of_gpio_chip and gpio_chip instances.
      
      If the struct of_gpio_chip data members were moved into struct gpio_chip,
      then it would simplify the processing of OF gpio bindings, and it would
      make it trivial to use device tree OF connections on existing gpiolib
      controller drivers.
      
      This patch eliminates the of_gpio_chip structure and moves the relevant
      fields into struct gpio_chip (conditional on CONFIG_OF_GPIO).  This move
      simplifies the existing code and prepares for adding automatic device tree
      support to existing drivers.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Bill Gatliff <bgat@billgatliff.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Jean Delvare <khali@linux-fr.org>
      a19e3da5
  22. 21 Dec, 2008 1 commit
  23. 03 Dec, 2008 1 commit
  24. 22 Jul, 2008 1 commit
  25. 16 Apr, 2008 1 commit