1. 10 9月, 2018 3 次提交
    • H
      gpiolib: add flag to indicate if the irq is disabled · 4e9439dd
      Hans Verkuil 提交于
      GPIO drivers call gpiochip_(un)lock_as_irq whenever they want to use a gpio
      as an interrupt. This is done when the irq is requested and it marks the
      gpio as in use by an interrupt.
      
      This is problematic for cases where a gpio pin is used as an interrupt
      pin, then, after the irq is disabled, is used as a regular gpio pin.
      Currently it is not possible to do this other than by first freeing
      the interrupt so gpiochip_unlock_as_irq is called, since an attempt to
      switch the gpio direction for output will fail since gpiolib believes
      that the gpio is in use for an interrupt and it does not know that it
      the irq is actually disabled.
      
      There are currently two drivers that would like to be able to do this:
      the tda998x_drv.c driver where a regular gpio pin needs to be temporarily
      reconfigured as an interrupt pin during CEC calibration, and the cec-gpio
      driver where you want to configure the gpio pin as an interrupt while
      waiting for traffic over the CEC bus, or as a regular pin when receiving or
      transmitting a CEC message.
      
      The solution is to add a new flag that is set when the irq is enabled,
      and have gpiod_direction_output check for that flag.
      
      We also add functions that drivers that do not use GPIOLIB_IRQCHIP
      can call when they enable/disable the irq.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      4e9439dd
    • H
      gliolib: set hooks in gpiochip_set_irq_hooks() · ca620f2d
      Hans Verkuil 提交于
      Centralize setting the irq_request/release_resources callbacks
      in one function since we'll be adding more callbacks to that.
      
      Also fix the removal of the callback overrides: this should
      only be done if we actually installed our own callback there.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      ca620f2d
    • H
      gpiolib: export gpiochip_irq_reqres/relres() · 4e6b8238
      Hans Verkuil 提交于
      GPIO drivers that do not use GPIOLIB_IRQCHIP can hook these into
      the irq_request_resource and irq_release_resource callbacks of the
      irq_chip so they correctly 'get' the module and lock the gpio line
      for IRQ use.
      
      This will simplify driver code.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      4e6b8238
  2. 11 8月, 2018 2 次提交
  3. 07 8月, 2018 1 次提交
  4. 30 7月, 2018 1 次提交
  5. 16 7月, 2018 2 次提交
  6. 13 7月, 2018 2 次提交
  7. 09 7月, 2018 3 次提交
  8. 18 6月, 2018 1 次提交
    • L
      gpio: Add API to explicitly name a consumer · 90b39402
      Linus Walleij 提交于
      The GPIO (descriptor) API registers a "label" naming what is
      currently using the GPIO line. Typically this is taken from
      things like the device tree node, so "reset-gpios" will result
      in he line being labeled "reset".
      
      The technical effect is pretty much zero: the use is for
      debug and introspection, such as "lsgpio" and debugfs files.
      
      However sometimes the user want this cuddly feeling of
      listing all GPIO lines and seeing exactly what they are for
      and it gives a very fulfilling sense of control. Especially
      in the cases when the device tree node doesn't provide a
      good name, or anonymous GPIO lines assigned just to
      "gpios" in the device tree because the usage is implicit.
      
      For these cases it may be nice to be able to label the
      line directly and explicitly.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      90b39402
  9. 07 6月, 2018 1 次提交
    • K
      treewide: Use struct_size() for kmalloc()-family · acafe7e3
      Kees Cook 提交于
      One of the more common cases of allocation size calculations is finding
      the size of a structure that has a zero-sized array at the end, along
      with memory for some number of elements for that array. For example:
      
      struct foo {
          int stuff;
          void *entry[];
      };
      
      instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
      
      Instead of leaving these open-coded and prone to type mistakes, we can
      now use the new struct_size() helper:
      
      instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);
      
      This patch makes the changes for kmalloc()-family (and kvmalloc()-family)
      uses. It was done via automatic conversion with manual review for the
      "CHECKME" non-standard cases noted below, using the following Coccinelle
      script:
      
      // pkey_cache = kmalloc(sizeof *pkey_cache + tprops->pkey_tbl_len *
      //                      sizeof *pkey_cache->table, GFP_KERNEL);
      @@
      identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
      expression GFP;
      identifier VAR, ELEMENT;
      expression COUNT;
      @@
      
      - alloc(sizeof(*VAR) + COUNT * sizeof(*VAR->ELEMENT), GFP)
      + alloc(struct_size(VAR, ELEMENT, COUNT), GFP)
      
      // mr = kzalloc(sizeof(*mr) + m * sizeof(mr->map[0]), GFP_KERNEL);
      @@
      identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
      expression GFP;
      identifier VAR, ELEMENT;
      expression COUNT;
      @@
      
      - alloc(sizeof(*VAR) + COUNT * sizeof(VAR->ELEMENT[0]), GFP)
      + alloc(struct_size(VAR, ELEMENT, COUNT), GFP)
      
      // Same pattern, but can't trivially locate the trailing element name,
      // or variable name.
      @@
      identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
      expression GFP;
      expression SOMETHING, COUNT, ELEMENT;
      @@
      
      - alloc(sizeof(SOMETHING) + COUNT * sizeof(ELEMENT), GFP)
      + alloc(CHECKME_struct_size(&SOMETHING, ELEMENT, COUNT), GFP)
      Signed-off-by: NKees Cook <keescook@chromium.org>
      acafe7e3
  10. 24 5月, 2018 1 次提交
  11. 23 5月, 2018 1 次提交
  12. 16 5月, 2018 2 次提交
  13. 27 4月, 2018 1 次提交
  14. 26 4月, 2018 1 次提交
  15. 27 3月, 2018 3 次提交
  16. 02 3月, 2018 1 次提交
  17. 12 2月, 2018 1 次提交
    • L
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds 提交于
      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: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
  18. 23 1月, 2018 2 次提交
  19. 17 1月, 2018 2 次提交
  20. 12 1月, 2018 2 次提交
    • L
      gpio: Export devm_gpiod_get_from_of_node() for consumers · 92542edc
      Linus Walleij 提交于
      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: NLinus Walleij <linus.walleij@linaro.org>
      92542edc
    • L
      gpio: Break out code to get a descriptor from a DT node · 6392cca4
      Linus Walleij 提交于
      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: NLinus Walleij <linus.walleij@linaro.org>
      6392cca4
  21. 10 1月, 2018 2 次提交
  22. 09 1月, 2018 1 次提交
  23. 05 1月, 2018 1 次提交
    • L
      gpio: label descriptors using the device name · 24e78079
      Linus Walleij 提交于
      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: NJason Kridner <jkridner@beagleboard.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      24e78079
  24. 02 1月, 2018 3 次提交