1. 27 Feb, 2019 2 commits
  2. 20 Feb, 2019 1 commit
  3. 12 Feb, 2019 3 commits
  4. 06 Feb, 2019 5 commits
  5. 26 Jan, 2019 1 commit
  6. 21 Dec, 2018 3 commits
  7. 07 Dec, 2018 1 commit
    • Hans de Goede's avatar
      gpiolib-acpi: Only defer request_irq for GpioInt ACPI event handlers · e59f5e08
      Hans de Goede authored
      Commit 78d3a92e ("gpiolib-acpi: Register GpioInt ACPI event handlers
      from a late_initcall") deferred the entire acpi_gpiochip_request_interrupt
      call for each event resource.
      
      This means it also delays the gpiochip_request_own_desc(..., "ACPI:Event")
      call. This is a problem if some AML code reads the GPIO pin before we
      run the deferred acpi_gpiochip_request_interrupt, because in that case
      acpi_gpio_adr_space_handler() will already have called
      gpiochip_request_own_desc(..., "ACPI:OpRegion") causing the call from
      acpi_gpiochip_request_interrupt to fail with -EBUSY and we will fail to
      register an event handler.
      
      acpi_gpio_adr_space_handler is prepared for acpi_gpiochip_request_interrupt
      already having claimed the pin, but the other way around does not work.
      
      One example of a problem this causes, is the event handler for the OTG
      ID pin on a Prowise PT301 tablet not registering, keeping the port stuck
      in whatever mode it was in during boot and e.g. only allowing charging
      after a reboot.
      
      This commit fixes this by only deferring the request_irq call and the
      initial run of edge-triggered IRQs instead of deferring all of
      acpi_gpiochip_request_interrupt.
      
      Cc: stable@vger.kernel.org
      Fixes: 78d3a92e ("gpiolib-acpi: Register GpioInt ACPI event ...")
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      e59f5e08
  8. 26 Nov, 2018 1 commit
  9. 16 Nov, 2018 2 commits
    • Bartosz Golaszewski's avatar
      gpio: mockup: fix indicated direction · bff466ba
      Bartosz Golaszewski authored
      Commit 3edfb7bd ("gpiolib: Show correct direction from the
      beginning") fixed an existing issue but broke libgpiod tests by
      changing the default direction of dummy lines to output.
      
      We don't break user-space so make gpio-mockup behave as before.
      Signed-off-by: default avatarBartosz Golaszewski <brgl@bgdev.pl>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      bff466ba
    • Robert Jarzmik's avatar
      gpio: pxa: fix legacy non pinctrl aware builds again · 70cdb6ad
      Robert Jarzmik authored
      As pointed out by Gregor, spitz keyboard matrix is broken, with or
      without CONFIG_PINCTRL set, quoting :
      "The gpio matrix keypard on the Zaurus C3x00 (see spitz.c) does not work
      properly. Noticeable are that rshift+c does nothing where as lshift+c
      creates C.  Opposite it is for rshift+a vs lshift+a, here only rshift
      works. This affects a few other combinations using the rshift or lshift
      buttons."
      
      As a matter of fact, as for platform_data based builds CONFIG_PINCTRL=n
      is required for now (as opposed for devicetree builds where it should be
      set), this means gpio driver should change the direction, which is what
      was attempted by commit c4e5ffb6 ("gpio: pxa: fix legacy non pinctrl
      aware builds").
      
      Unfortunately, the input case was inverted, and the direction change was
      never done. This wasn't seen up until now because the initial platform
      setup (MFP) was setting this direction. Yet in Gregory's case, the
      matrix-keypad driver changes back and forth the direction dynamically,
      and this is why he's the first to report it.
      
      Fixes: c4e5ffb6 ("gpio: pxa: fix legacy non pinctrl aware builds")
      Tested-by: greguu's avatarGreg <greguu@null.net>
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      70cdb6ad
  10. 09 Nov, 2018 1 commit
  11. 16 Oct, 2018 4 commits
  12. 15 Oct, 2018 1 commit
    • Randy Dunlap's avatar
      gpio: fix SNPS_CREG kconfig dependency warning · a7c0b4b8
      Randy Dunlap authored
      Fix kconfig warning for GPIO_SNPS_CREG:
      
      WARNING: unmet direct dependencies detected for OF_GPIO
        Depends on [n]: GPIOLIB [=y] && OF [=n] && HAS_IOMEM [=y]
        Selected by [y]:
        - GPIO_SNPS_CREG [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && (ARC || COMPILE_TEST [=y])
      
      Drivers in drivers/gpio/Kconfig depend on OF_GPIO, not select it.
      This prevents attempting to build when OF is not enabled.
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: linux-gpio@vger.kernel.org
      Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      a7c0b4b8
  13. 12 Oct, 2018 2 commits
  14. 10 Oct, 2018 6 commits
    • Stephen Boyd's avatar
      gpio: Assign gpio_irq_chip::parents to non-stack pointer · 3e779a2e
      Stephen Boyd authored
      gpiochip_set_cascaded_irqchip() is passed 'parent_irq' as an argument
      and then the address of that argument is assigned to the gpio chips
      gpio_irq_chip 'parents' pointer shortly thereafter. This can't ever
      work, because we've just assigned some stack address to a pointer that
      we plan to dereference later in gpiochip_irq_map(). I ran into this
      issue with the KASAN report below when gpiochip_irq_map() tried to setup
      the parent irq with a total junk pointer for the 'parents' array.
      
      BUG: KASAN: stack-out-of-bounds in gpiochip_irq_map+0x228/0x248
      Read of size 4 at addr ffffffc0dde472e0 by task swapper/0/1
      
      CPU: 7 PID: 1 Comm: swapper/0 Not tainted 4.14.72 #34
      Call trace:
      [<ffffff9008093638>] dump_backtrace+0x0/0x718
      [<ffffff9008093da4>] show_stack+0x20/0x2c
      [<ffffff90096b9224>] __dump_stack+0x20/0x28
      [<ffffff90096b91c8>] dump_stack+0x80/0xbc
      [<ffffff900845a350>] print_address_description+0x70/0x238
      [<ffffff900845a8e4>] kasan_report+0x1cc/0x260
      [<ffffff900845aa14>] __asan_report_load4_noabort+0x2c/0x38
      [<ffffff900897e098>] gpiochip_irq_map+0x228/0x248
      [<ffffff900820cc08>] irq_domain_associate+0x114/0x2ec
      [<ffffff900820d13c>] irq_create_mapping+0x120/0x234
      [<ffffff900820da78>] irq_create_fwspec_mapping+0x4c8/0x88c
      [<ffffff900820e2d8>] irq_create_of_mapping+0x180/0x210
      [<ffffff900917114c>] of_irq_get+0x138/0x198
      [<ffffff9008dc70ac>] spi_drv_probe+0x94/0x178
      [<ffffff9008ca5168>] driver_probe_device+0x51c/0x824
      [<ffffff9008ca6538>] __device_attach_driver+0x148/0x20c
      [<ffffff9008ca14cc>] bus_for_each_drv+0x120/0x188
      [<ffffff9008ca570c>] __device_attach+0x19c/0x2dc
      [<ffffff9008ca586c>] device_initial_probe+0x20/0x2c
      [<ffffff9008ca18bc>] bus_probe_device+0x80/0x154
      [<ffffff9008c9b9b4>] device_add+0x9b8/0xbdc
      [<ffffff9008dc7640>] spi_add_device+0x1b8/0x380
      [<ffffff9008dcbaf0>] spi_register_controller+0x111c/0x1378
      [<ffffff9008dd6b10>] spi_geni_probe+0x4dc/0x6f8
      [<ffffff9008cab058>] platform_drv_probe+0xdc/0x130
      [<ffffff9008ca5168>] driver_probe_device+0x51c/0x824
      [<ffffff9008ca59cc>] __driver_attach+0x100/0x194
      [<ffffff9008ca0ea8>] bus_for_each_dev+0x104/0x16c
      [<ffffff9008ca58c0>] driver_attach+0x48/0x54
      [<ffffff9008ca1edc>] bus_add_driver+0x274/0x498
      [<ffffff9008ca8448>] driver_register+0x1ac/0x230
      [<ffffff9008caaf6c>] __platform_driver_register+0xcc/0xdc
      [<ffffff9009c4b33c>] spi_geni_driver_init+0x1c/0x24
      [<ffffff9008084cb8>] do_one_initcall+0x240/0x3dc
      [<ffffff9009c017d0>] kernel_init_freeable+0x378/0x468
      [<ffffff90096e8240>] kernel_init+0x14/0x110
      [<ffffff9008086fcc>] ret_from_fork+0x10/0x18
      
      The buggy address belongs to the page:
      page:ffffffbf037791c0 count:0 mapcount:0 mapping:          (null) index:0x0
      flags: 0x4000000000000000()
      raw: 4000000000000000 0000000000000000 0000000000000000 00000000ffffffff
      raw: ffffffbf037791e0 ffffffbf037791e0 0000000000000000 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffffffc0dde47180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffffffc0dde47200: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2
      >ffffffc0dde47280: f2 f2 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3
                                                             ^
       ffffffc0dde47300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffffffc0dde47380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Let's leave around one unsigned int in the gpio_irq_chip struct for the
      single parent irq case and repoint the 'parents' array at it. This way
      code is left mostly intact to setup parents and we waste an extra few
      bytes per structure of which there should be only a handful in a system.
      
      Cc: Evan Green <evgreen@chromium.org>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Fixes: e0d89728 ("gpio: Implement tighter IRQ chip integration")
      Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      3e779a2e
    • Uwe Kleine-König's avatar
      gpio: fix doc string for devm_gpiochip_add_data() to not talk about irq_chip · 3925b90f
      Uwe Kleine-König authored
      The function is about adding a gpio_chip so dev has to belong to this
      one. Fix wording to be more grammatically correct (but attention, I'm
      not a native speaker).
      Signed-off-by: default avatarUwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      3925b90f
    • Marek Vasut's avatar
      gpio: syscon: Fix possible NULL ptr usage · 70728c29
      Marek Vasut authored
      The priv->data->set can be NULL while flags contains GPIO_SYSCON_FEAT_OUT
      and chip->set is valid pointer. This happens in case the controller uses
      the default GPIO setter. Always use chip->set to access the setter to avoid
      possible NULL pointer dereferencing.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      70728c29
    • Ricardo Ribalda Delgado's avatar
      gpiolib: Show correct direction from the beginning · 3edfb7bd
      Ricardo Ribalda Delgado authored
      Current code assumes that the direction is input if direction_input
      function is set.
      This might not be the case on GPIOs with programmable direction.
      Signed-off-by: Ricardo Ribalda Delgado's avatarRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      3edfb7bd
    • Ricardo Ribalda Delgado's avatar
      gpiolib: Add init_valid_mask exported function · f8ec92a9
      Ricardo Ribalda Delgado authored
      Add a function that allows initializing the valid_mask from
      gpiochip_add_data.
      
      This prevents race conditions during gpiochip initialization.
      
      If the function is not exported, then the old behaviour is respected,
      this is, set all gpios as valid.
      Signed-off-by: Ricardo Ribalda Delgado's avatarRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      f8ec92a9
    • Eugeniy Paltsev's avatar
      GPIO: add single-register GPIO via CREG driver · 2505c7b0
      Eugeniy Paltsev authored
      Add single-register MMIO GPIO driver for complex cases where
      only several fields in register belong to GPIO lines and each GPIO
      line owns a field with different length and on/off value.
      
      Such CREG GPIOs are used in Synopsys AXS10x and HSDK boards.
      Signed-off-by: default avatarEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      2505c7b0
  15. 03 Oct, 2018 1 commit
  16. 02 Oct, 2018 2 commits
  17. 01 Oct, 2018 4 commits