1. 02 Mar, 2018 1 commit
  2. 11 Feb, 2018 1 commit
    • Linus Torvalds's avatar
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds authored
      
      
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
      
          for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
          done
      
      with de-mangling cleanups yet to come.
      
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      
      The next patch from Al will sort out the final differences, and we
      should be all done.
      
      Scripted-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
  3. 23 Jan, 2018 2 commits
  4. 17 Jan, 2018 2 commits
  5. 12 Jan, 2018 2 commits
    • Linus Walleij's avatar
      gpio: Export devm_gpiod_get_from_of_node() for consumers · 92542edc
      Linus Walleij authored
      
      
      We have been holding back on adding an API for fetching GPIO handles
      directly from device nodes, strongly preferring to get it from the
      spawn devices instead.
      
      The fwnode interface however already contains an API for doing this,
      as it is used for opaque device tree nodes or ACPI nodes for getting
      handles to LEDs and keys that use GPIO: those are specified as one
      child per LED/key in the device tree and are not individual devices.
      
      However regulators present a special problem as they already have
      helper functions to traverse the device tree from a regulator node
      and two levels down to fill in data, and as it already traverses
      GPIO nodes in its own way, and already holds a pointer to each
      regulators device tree node, it makes most sense to export an
      API to fetch the GPIO descriptor directly from the node.
      
      We only support the devm_* version for now, hopefully no non-devres
      version will be needed.
      
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      92542edc
    • Linus Walleij's avatar
      gpio: Break out code to get a descriptor from a DT node · 6392cca4
      Linus Walleij authored
      
      
      Sometimes a GPIO needs to be taken from a node without
      a device associated with it. The fwnode accessor does this,
      let's however break out the DT code for now.
      
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      6392cca4
  6. 10 Jan, 2018 2 commits
  7. 09 Jan, 2018 1 commit
  8. 05 Jan, 2018 1 commit
    • Linus Walleij's avatar
      gpio: label descriptors using the device name · 24e78079
      Linus Walleij authored
      
      
      Some GPIO lines appear named "?" in the lsgpio dump due to their
      requesting drivers not passing a reasonable label.
      
      Most typically this happens if a device tree node just defines
      gpios = <...> and not foo-gpios = <...>, the former gets named
      "foo" and the latter gets named "?".
      
      However the struct device passed in is always valid so let's
      just label the GPIO with dev_name() on the device if no proper
      label was passed.
      
      Cc: Reported-by: Jason Kridner <jkridner@beagleboard.org>
      Reported-by: default avatarJason Kridner <jkridner@beagleboard.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      24e78079
  9. 02 Jan, 2018 3 commits
  10. 28 Dec, 2017 1 commit
  11. 21 Dec, 2017 3 commits
  12. 20 Dec, 2017 1 commit
  13. 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: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      e10f72bf
  14. 30 Nov, 2017 2 commits
  15. 28 Nov, 2017 1 commit
  16. 08 Nov, 2017 14 commits
  17. 30 Oct, 2017 1 commit
    • Linus Walleij's avatar
      gpio: Make it possible for consumers to enforce open drain · f926dfc1
      Linus Walleij authored
      
      
      Some busses, like I2C, strictly need to have the line handled
      as open drain, i.e. not actively driven high. For this reason
      the i2c-gpio.c bit-banged I2C driver is reimplementing open
      drain handling outside of gpiolib.
      
      This is not very optimal. Instead make it possible for a
      consumer to explcitly express that the line must be handled
      as open drain instead of allowing local hacks papering over
      this issue.
      
      The descriptor tables, whether DT, ACPI or board files, should
      of course have flagged these lines as open drain. E.g.:
      enum gpio_lookup_flags GPIO_OPEN_DRAIN for a board file, or
      gpios = <&foo 42 GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN>; in a
      device tree using <dt-bindings/gpio/gpio.h>
      
      But more often than not, these descriptors are wrong. So
      we need to make it possible for consumers to enforce this
      open drain behaviour.
      
      We now have two new enumerated GPIO descriptor config flags:
      GPIOD_OUT_LOW_OPEN_DRAIN and GPIOD_OUT_HIGH_OPEN_DRAIN
      that will set up the lined enforced as open drain as output
      low or high, using open drain (if the driver supports it)
      or using open drain emulation (setting the line as input
      to drive it high) from the gpiolib core.
      
      Cc: linux-gpio@vger.kernel.org
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      f926dfc1
  18. 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