1. 29 4月, 2014 2 次提交
    • L
      gpio: put GPIO IRQs into their own lock class · e45d1c80
      Linus Walleij 提交于
      Another feature that is duplicated in a number of GPIO irqchips
      is that these cascades IRQs are assigned their own lock class
      so as to avoid warnings about lockdep recursions. Do this also
      in the generic GPIO irqchip helpers for smooth transition to
      this core infrastructure.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      e45d1c80
    • L
      gpio: support threaded interrupts in irqchip helpers · 1c8732bb
      Linus Walleij 提交于
      Some off-chip GPIO expanders need to be communicated by I2C or
      SPI traffic, but may still support IRQs. By the sleeping nature
      of such buses, such IRQ handlers need to be threaded. Support
      such handlers in the gpiochip irqchip helpers by flagging IRQs
      as threaded if the .can_sleep property of the gpiochip is
      true.
      
      Helpfully deny registration of chained IRQ handlers if the
      .can_sleep property is set, as such chips will invariably need
      a nested handler rather than a chained handler.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      1c8732bb
  2. 14 4月, 2014 1 次提交
  3. 29 3月, 2014 1 次提交
  4. 26 3月, 2014 1 次提交
  5. 14 3月, 2014 1 次提交
    • A
      gpio: clamp returned values to the boolean range · 23600969
      Alexandre Courbot 提交于
      Nothing prevents GPIO drivers from returning values outside the
      boolean range, and as it turns out a few drivers are actually doing so.
      These values were passed as-is to unsuspecting consumers and created
      confusion.
      
      This patch makes the internal _gpiod_get_raw_value() function return a
      bool, effectively clamping the GPIO value to the boolean range no
      matter what the driver does.
      
      While we are at it, we also change the value parameter of
      _gpiod_set_raw_value() to bool type before drivers start doing funny
      things with it as well.
      
      Another way to fix this would be to change the prototypes of the driver
      interface to use bool directly, but this would require a huge
      cross-systems patch so this simpler solution is preferred.
      
      Changes since v1:
      - Change local variable type to bool as well, use boolean values in
        code
      - Also change prototype of open drain/open source setting functions
        since they are only called from _gpiod_set_raw_value()
      
      This probably calls for a larger booleanization of gpiolib, but let's
      keep that for a latter change - right now we need to address the issue
      of non-boolean values returned by drivers.
      Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      23600969
  6. 13 3月, 2014 2 次提交
    • M
      gpio / ACPI: Rework ACPI GPIO event handling · 6072b9dc
      Mika Westerberg 提交于
      The current ACPI GPIO event handling code was never tested against real
      hardware with functioning GPIO triggered events (at the time such hardware
      wasn't available). Thus it misses certain things like requesting the GPIOs
      properly, passing correct flags to the interrupt handler and so on.
      
      This patch reworks ACPI GPIO event handling so that we:
      
       1) Use struct acpi_gpio_event for all GPIO signaled events.
       2) Switch to use GPIO descriptor API and request GPIOs by calling
          gpiochip_request_own_desc() that we added in a previous patch.
       3) Pass proper flags from ACPI GPIO resource to request_threaded_irq().
      
      Also instead of open-coding the _AEI iteration loop we can use
      acpi_walk_resources(). This simplifies the code a bit and fixes memory leak
      that was caused by missing kfree() for buffer returned by
      acpi_get_event_resources().
      
      Since the remove path now calls gpiochip_free_own_desc() which takes GPIO
      spinlock we need to call acpi_gpiochip_remove() outside of that lock
      (analogous to acpi_gpiochip_add() path where the lock is released before
      those funtions are called).
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      6072b9dc
    • M
      gpiolib: Allow GPIO chips to request their own GPIOs · 77c2d792
      Mika Westerberg 提交于
      Sometimes it is useful to allow GPIO chips themselves to request GPIOs they
      own through gpiolib API. One use case is ACPI ASL code that should be able
      to toggle GPIOs through GPIO operation regions.
      
      We can't use gpio_request() because it will pin the module to the kernel
      forever (it calls try_module_get()). To solve this we move module refcount
      manipulation to gpiod_request() and let __gpiod_request() handle the actual
      request. This changes the sequence a bit as now try_module_get() is called
      outside of gpio_lock (I think this is safe, try_module_get() handles
      serialization it needs already).
      
      Then we provide gpiolib internal functions gpiochip_request/free_own_desc()
      that do the same as gpio_request() but don't manipulate module refrence
      count. This allows the GPIO chip driver to request and free descriptors it
      owns without being pinned to the kernel forever.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      77c2d792
  7. 07 3月, 2014 1 次提交
  8. 13 2月, 2014 2 次提交
  9. 07 2月, 2014 1 次提交
  10. 08 1月, 2014 2 次提交
  11. 13 12月, 2013 1 次提交
  12. 12 12月, 2013 1 次提交
    • T
      kernfs: s/sysfs_dirent/kernfs_node/ and rename its friends accordingly · 324a56e1
      Tejun Heo 提交于
      kernfs has just been separated out from sysfs and we're already in
      full conflict mode.  Nothing can make the situation any worse.  Let's
      take the chance to name things properly.
      
      This patch performs the following renames.
      
      * s/sysfs_elem_dir/kernfs_elem_dir/
      * s/sysfs_elem_symlink/kernfs_elem_symlink/
      * s/sysfs_elem_attr/kernfs_elem_file/
      * s/sysfs_dirent/kernfs_node/
      * s/sd/kn/ in kernfs proper
      * s/parent_sd/parent/
      * s/target_sd/target/
      * s/dir_sd/parent/
      * s/to_sysfs_dirent()/rb_to_kn()/
      * misc renames of local vars when they conflict with the above
      
      Because md, mic and gpio dig into sysfs details, this patch ends up
      modifying them.  All are sysfs_dirent renames and trivial.  While we
      can avoid these by introducing a dummy wrapping struct sysfs_dirent
      around kernfs_node, given the limited usage outside kernfs and sysfs
      proper, I don't think such workaround is called for.
      
      This patch is strictly rename only and doesn't introduce any
      functional difference.
      
      - mic / gpio renames were missing.  Spotted by kbuild test robot.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
      Cc: kbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      324a56e1
  13. 09 12月, 2013 4 次提交
  14. 04 12月, 2013 2 次提交
  15. 03 12月, 2013 3 次提交
  16. 25 11月, 2013 4 次提交
  17. 15 11月, 2013 1 次提交
    • R
      ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node · 7b199811
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
      7b199811
  18. 20 10月, 2013 4 次提交
  19. 16 10月, 2013 2 次提交
  20. 11 10月, 2013 2 次提交
  21. 27 9月, 2013 1 次提交
    • T
      sysfs: clean up sysfs_get_dirent() · 388975cc
      Tejun Heo 提交于
      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
      likely.
      
      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: NTejun 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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      388975cc
  22. 20 9月, 2013 1 次提交