1. 26 Jan, 2017 3 commits
  2. 07 Dec, 2016 10 commits
  3. 25 Nov, 2016 2 commits
    • Linus Walleij's avatar
      gpio: set explicit nesting on drivers · 35ca3f61
      Linus Walleij authored
      The ADNP, CrystalCove and WhiskeyCove are all nested GPIO
      irqchips, but were avoiding to connect the parent IRQ to
      the gpiochip. This works, but is kind of sloppy as the
      child IRQs are not marked as having the parent IRQ as
      parent.
      
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>
      Cc: Bin Gao <bin.gao@linux.intel.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      35ca3f61
    • Linus Walleij's avatar
      gpio: simplify adding threaded interrupts · d245b3f9
      Linus Walleij authored
      This tries to simplify the use of CONFIG_GPIOLIB_IRQCHIP when
      using threaded interrupts: add a new call
      gpiochip_irqchip_add_nested() to indicate that we're dealing
      with a nested rather than a chained irqchip, then create a
      separate gpiochip_set_nested_irqchip() to mirror
      the gpiochip_set_chained_irqchip() call to connect the
      parent and child interrupts.
      
      In the nested case gpiochip_set_nested_irqchip() does nothing
      more than call irq_set_parent() on each valid child interrupt,
      which has little semantic effect in the kernel, but this is
      probably still formally correct.
      
      Update all drivers using nested interrupts to use
      gpiochip_irqchip_add_nested() so we can now see clearly
      which these users are.
      
      The DLN2 driver can drop its specific hack with
      .irq_not_threaded as we now recognize whether a chip is
      threaded or not from its use of gpiochip_irqchip_add_nested()
      signature rather than from inspecting .can_sleep.
      
      We rename the .irq_parent to .irq_chained_parent since this
      parent IRQ is only really kept around for the chained
      interrupt handlers.
      
      Cc: Lars Poeschel <poeschel@lemonage.de>
      Cc: Octavian Purdila <octavian.purdila@intel.com>
      Cc: Daniel Baluta <daniel.baluta@intel.com>
      Cc: Bin Gao <bin.gao@linux.intel.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com>
      Cc: Semen Protsenko <semen.protsenko@globallogic.com>
      Cc: Alexander Stein <alexander.stein@systec-electronic.com>
      Cc: Phil Reid <preid@electromag.com.au>
      Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
      Cc: Patrice Chotard <patrice.chotard@st.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      d245b3f9
  4. 24 Nov, 2016 4 commits
  5. 22 Nov, 2016 4 commits
  6. 16 Nov, 2016 2 commits
  7. 15 Nov, 2016 5 commits
    • Geliang Tang's avatar
      gpio: intel-mid: use builtin_pci_driver · 5261bee8
      Geliang Tang authored
      Use builtin_pci_driver() helper to simplify the code.
      Signed-off-by: default avatarGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      5261bee8
    • Linus Walleij's avatar
      gpio: tc3589x: fix up .get_direction() · 220a04f0
      Linus Walleij authored
      The bit in the TC3589x direction register is 0 for input
      and 1 for output, but the gpiolib expects the reverse.
      Fix up the logic.
      
      Cc: stable@vger.kernel.org
      Fixes: 14063d71 ("gpio: tc3589x: add .get_direction() and small cleanup")
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      220a04f0
    • Linus Walleij's avatar
      gpio: tag line labels used for interrupts · 3940c34a
      Linus Walleij authored
      When a GPIO line is marked as used for an interrupt, it is
      helpful to set the label to "interrupt" so we know what is
      going on when inspecting the lines.
      
      If a GPIO is already properly named by gpiod_get*() we don't
      need to do this. It only happens when a line is used from
      the irqchip side of a GPIO driver without communicating
      with the GPIO side, such as when gpiochip is used as interrupt
      provider in the device tree.
      
      If the line is still marked as used by "interrupt" when we
      unmark it as used by an interrupt, also remove this label
      from the descriptor.
      
      Also shape up the code around unmarking IRQ lines.
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      3940c34a
    • Linus Walleij's avatar
      gpio: clamp values on gpio[d]_direction_output() · ad17731d
      Linus Walleij authored
      I saw weird values != [0,1] being passed down to drivers
      in their .set_direction_output() callbacks. Go over the
      gpiolib and make sure to hammer it to [0,1] before hitting
      the driver to avoid undesired side effects.
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      ad17731d
    • Linus Walleij's avatar
      gpio: do not double-check direction on sleeping chips · 60f8339e
      Linus Walleij authored
      When locking a GPIO line as IRQ, we go to lengths to
      double-check that the line is really set as input before
      marking it as used for IRQ. This is not good on GPIO chips
      that can sleep, because this function is called in IRQ-safe
      context. Just skip this if it can't be checked quickly.
      
      Currently this happens on sleeping expanders such as STMPE
      or TC3589x:
      
      BUG: scheduling while atomic: swapper/1/0x00000002
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc1+ #38
      Hardware name: Nomadik STn8815
      [<c000f2e0>] (unwind_backtrace) from [<c000d244>] (show_stack+0x10/0x14)
      [<c000d244>] (show_stack) from [<c0037b78>] (__schedule_bug+0x54/0x80)
      [<c0037b78>] (__schedule_bug) from [<c042df14>] (__schedule+0x3a0/0x460)
      [<c042df14>] (__schedule) from [<c042e028>] (schedule+0x54/0xb8)
      (...)
      
      This patch fixes that problem and relies on the direction
      read from the chip when it was added.
      
      Cc: stable@vger.kernel.org
      Fixes: 9c10280d ("gpio: flush direction status in gpiochip_lock_as_irq()")
      Cc: Patrice Chotard <patrice.chotard@st.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      60f8339e
  8. 13 Nov, 2016 1 commit
  9. 12 Nov, 2016 1 commit
  10. 09 Nov, 2016 2 commits
  11. 08 Nov, 2016 2 commits
  12. 04 Nov, 2016 1 commit
    • Paul Gortmaker's avatar
      gpio: htc-egpio: Make it explicitly non-modular · 43bbf94c
      Paul Gortmaker authored
      The Kconfig currently controlling compilation of this code is:
      
      drivers/gpio/Kconfig:config HTC_EGPIO
      drivers/gpio/Kconfig:   bool "HTC EGPIO support"
      
      ...meaning that it currently is not being built as a module by anyone.
      
      Lets remove the modular code that is essentially orphaned, so that
      when reading the driver there is no doubt it is builtin-only.
      
      We explicitly disallow a driver unbind, since that doesn't have a
      sensible use case anyway, and it allows us to drop the ".remove"
      code for non-modular drivers.
      
      Since module_init was not in use by this code, the init ordering
      remains unchanged with this commit.
      
      We also delete the MODULE_LICENSE tag etc. since all that information
      is already contained at the top of the file in the comments.
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Kevin O'Connor <kevin@koconnor.net>
      Cc: linux-gpio@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      43bbf94c
  13. 01 Nov, 2016 1 commit
    • Jason Gunthorpe's avatar
      gpio/mvebu: Use irq_domain_add_linear · 812d4788
      Jason Gunthorpe authored
      This fixes the irq allocation in this driver to not print:
       irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
       irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
      
      Which happens because the driver already called irq_alloc_descs()
      and so the change to use irq_domain_add_simple resulted in calling
      irq_alloc_descs() twice.
      
      Modernize the irq allocation in this driver to use the
      irq_domain_add_linear flow directly and eliminate the use of
      irq_domain_add_simple/legacy
      
      Fixes: ce931f57 ("gpio/mvebu: convert to use irq_domain_add_simple()")
      Signed-off-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      812d4788
  14. 31 Oct, 2016 2 commits
    • Masahiro Yamada's avatar
      gpio: of: fix GPIO drivers with multiple gpio_chip for a single node · c7e9d398
      Masahiro Yamada authored
      Sylvain Lemieux reports the LPC32xx GPIO driver is broken since
      commit 762c2e46 ("gpio: of: remove of_gpiochip_and_xlate() and
      struct gg_data").  Probably, gpio-etraxfs.c and gpio-davinci.c are
      broken too.
      
      Those drivers register multiple gpio_chip that are associated to a
      single OF node, and their own .of_xlate() checks if the passed
      gpio_chip is valid.
      
      Now, the problem is of_find_gpiochip_by_node() returns the first
      gpio_chip found to match the given node.  So, .of_xlate() fails,
      except for the first GPIO bank.
      
      Reverting the commit could be a solution, but I do not want to go
      back to the mess of struct gg_data.  Another solution here is to
      take the match by a node pointer and the success of .of_xlate().
      It is a bit clumsy to call .of_xlate twice; for gpio_chip matching
      and for really getting the gpio_desc index.  Perhaps, our long-term
      goal might be to convert the drivers to single chip registration,
      but this commit will solve the problem until then.
      
      Fixes: 762c2e46 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data")
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reported-by: default avatarSylvain Lemieux <slemieux.tyco@gmail.com>
      Tested-by: default avatarDavid Lechner <david@lechnology.com>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      c7e9d398
    • Lars-Peter Clausen's avatar
      gpio: GPIO_GET_LINE{HANDLE,EVENT}_IOCTL: Fix file descriptor leak · 953b956a
      Lars-Peter Clausen authored
      When allocating a new line handle or event a file is allocated that it is
      associated to. The file is attached to a file descriptor of the current
      process and the file descriptor is returned to userspace using
      copy_to_user(). If this copy operation fails the line handle or event
      allocation is aborted, all acquired resources are freed and an error is
      returned.
      
      But the file struct is not freed and left attached to the userspace
      application and even though the file descriptor number was not copied it is
      trivial to guess. If a userspace application performs a IOCTL on such a
      left over file descriptor it will trigger a use-after-free and if the file
      descriptor is closed (latest when the application exits) a double-free is
      triggered.
      
      anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a
      file descriptor for the current process and install the file struct in the
      file descriptor. As soon as the file struct is installed in the file
      descriptor it is accessible by userspace (even if the IOCTL itself hasn't
      completed yet), this means uninstalling the fd on the error path is not an
      option, since userspace might already got a reference to the file.
      
      Instead anon_inode_getfd() needs to be broken into its individual steps.
      The allocation of the file struct and file descriptor is done first, then
      the copy_to_user() is executed and only if it succeeds the file is
      installed.
      
      Since the file struct is reference counted it can not be just freed, but
      its reference needs to be dropped, which will also call the release()
      callback, which will free the state attached to the file. So in this case
      the normal error cleanup path should not be taken.
      
      Cc: stable@vger.kernel.org
      Fixes: d932cd49 ("gpio: free handles in fringe cases")
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      953b956a