1. 25 Nov, 2013 1 commit
  2. 14 Nov, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node · 7b199811
      Rafael J. Wysocki authored
      Modify struct acpi_dev_node to contain a pointer to struct acpi_device
      associated with the given device object (that is, its ACPI companion
      device) instead of an ACPI handle corresponding to it.  Introduce two
      new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
      ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
      ACPI_HANDLE() macro to take the above changes into account.
      Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
      use ACPI_COMPANION_SET() instead.  For some of them who used to
      pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
      introduce a helper routine acpi_preset_companion() doing an
      equivalent thing.
      The main motivation for doing this is that there are things
      represented by struct acpi_device objects that don't have valid
      ACPI handles (so called fixed ACPI hardware features, such as
      power and sleep buttons) and we would like to create platform
      device objects for them and "glue" them to their ACPI companions
      in the usual way (which currently is impossible due to the
      lack of valid ACPI handles).  However, there are more reasons
      why it may be useful.
      First, struct acpi_device pointers allow of much better type checking
      than void pointers which are ACPI handles, so it should be more
      difficult to write buggy code using modified struct acpi_dev_node
      and the new macros.  Second, the change should help to reduce (over
      time) the number of places in which the result of ACPI_HANDLE() is
      passed to acpi_bus_get_device() in order to obtain a pointer to the
      struct acpi_device associated with the given "physical" device,
      because now that pointer is returned by ACPI_COMPANION() directly.
      Finally, the change should make it easier to write generic code that
      will build both for CONFIG_ACPI set and unset without adding explicit
      compiler directives to it.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
      Reviewed-by: Mika Westerberg's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
  3. 19 Oct, 2013 4 commits
  4. 16 Oct, 2013 2 commits
  5. 11 Oct, 2013 2 commits
  6. 26 Sep, 2013 1 commit
    • Tejun Heo's avatar
      sysfs: clean up sysfs_get_dirent() · 388975cc
      Tejun Heo authored
      The pre-existing sysfs interfaces which take explicit namespace
      argument are weird in that they place the optional @ns in front of
      @name which is contrary to the established convention.  For example,
      we end up forcing vast majority of sysfs_get_dirent() users to do
      sysfs_get_dirent(parent, NULL, name), which is silly and error-prone
      especially as @ns and @name may be interchanged without causing
      compilation warning.
      This renames sysfs_get_dirent() to sysfs_get_dirent_ns() and swap the
      positions of @name and @ns, and sysfs_get_dirent() is now a wrapper
      around sysfs_get_dirent_ns().  This makes confusions a lot less
      There are other interfaces which take @ns before @name.  They'll be
      updated by following patches.
      This patch doesn't introduce any functional changes.
      v2: EXPORT_SYMBOL_GPL() wasn't updated leading to undefined symbol
          error on module builds.  Reported by build test robot.  Fixed.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Kay Sievers <kay@vrfy.org>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. 20 Sep, 2013 1 commit
  8. 19 Sep, 2013 2 commits
  9. 04 Sep, 2013 1 commit
    • Linus Walleij's avatar
      gpio: return -ENOTSUPP if debounce cannot be set · 65d87656
      Linus Walleij authored
      It appears some drivers are using gpio_set_debounce()
      opportunistically, i.e. without knowing whether it works or
      not. (Example: input/keyboard/gpio_keys.c) to account for
      this use case, return -ENOTSUPP and do not print any
      warnings in this case.
      Took a round over the other gpio_set_debounce() consumers
      to make sure that none of them are relying on the returned
      error code to be something specific.
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
  10. 03 Sep, 2013 1 commit
  11. 20 Jul, 2013 1 commit
  12. 20 Jun, 2013 1 commit
  13. 02 Mar, 2013 3 commits
  14. 28 Feb, 2013 1 commit
  15. 11 Feb, 2013 3 commits
  16. 09 Feb, 2013 5 commits
  17. 06 Feb, 2013 1 commit
  18. 04 Feb, 2013 2 commits
  19. 21 Nov, 2012 5 commits
  20. 11 Nov, 2012 2 commits
    • Linus Walleij's avatar
      gpiolib: separation of pin concerns · 1e63d7b9
      Linus Walleij authored
      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
      - Use pinctrl_dev_get_name() to get the name of the retrieved
        pin controller and use that to call back into the generic
      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's avatarLinus Walleij <linus.walleij@linaro.org>
    • Linus Walleij's avatar
      gpiolib: call pin removal in chip removal function · 9ef0d6f7
      Linus Walleij authored
      This makes us call gpiochio_remove_pin_ranges() in the
      gpiochip_remove() function, so we get rid of ranges when
      freeing the chip.
      Reviewed-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>