1. 27 3月, 2018 10 次提交
  2. 26 3月, 2018 7 次提交
  3. 19 3月, 2018 13 次提交
  4. 06 3月, 2018 1 次提交
  5. 05 3月, 2018 1 次提交
    • G
      gpio: rcar: Use wakeup_path i.s.o. explicit clock handling · 9ac79ba9
      Geert Uytterhoeven 提交于
      Since commit ab82fa7d ("gpio: rcar: Prevent module clock disable
      when wake-up is enabled"), when a GPIO is used for wakeup, the GPIO
      block's module clock (if exists) is manually kept running during system
      suspend, to make sure the device stays active.
      
      However, this explicit clock handling is merely a workaround for a
      failure to properly communicate wakeup information to the device core.
      
      Instead, set the device's power.wakeup_path field, to indicate this
      device is part of the wakeup path.  Depending on the PM Domain's
      active_wakeup configuration, the genpd core code will keep the device
      enabled (and the clock running) during system suspend when needed.
      This allows for the removal of all explicit clock handling code from the
      driver.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      9ac79ba9
  6. 02 3月, 2018 4 次提交
    • B
      gpio: raspberrypi-exp: explain Kconfig dependency · 94337b72
      Baruch Siach 提交于
      Commit 7ed91505 (gpio: raspberrypi-ext: fix firmware dependency)
      fixed the Kconfig dependency to ensure that gpio-raspberrypi-exp is not
      built-in when the firmware is a module. But the Kconfig syntax for doing
      so is cryptic. Add a comment to make it a little easier.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      94337b72
    • B
      gpio: Add GPIO driver for Spreadtrum SC9860 platform · 9a3821c2
      Baolin Wang 提交于
      The Spreadtrum SC9860 platform GPIO controller contains 16 groups and
      each group contains 16 GPIOs. Each GPIO can set input/output and has
      the interrupt capability.
      Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
      Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      9a3821c2
    • A
      gpio: raspberrypi-ext: fix firmware dependency · 7ed91505
      Arnd Bergmann 提交于
      When the firmware driver is a loadable module, the gpio driver cannot be
      built-in:
      
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_set':
      gpio-raspberrypi-exp.c:(.text+0xb4): undefined reference to `rpi_firmware_property'
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_get':
      gpio-raspberrypi-exp.c:(.text+0x1ec): undefined reference to `rpi_firmware_property'
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_get_direction':
      gpio-raspberrypi-exp.c:(.text+0x360): undefined reference to `rpi_firmware_property'
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_get_polarity':
      gpio-raspberrypi-exp.c:(.text+0x4d4): undefined reference to `rpi_firmware_property'
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_dir_out':
      gpio-raspberrypi-exp.c:(.text+0x670): undefined reference to `rpi_firmware_property'
      drivers/gpio/gpio-raspberrypi-exp.o:gpio-raspberrypi-exp.c:(.text+0x7fc): more undefined references to `rpi_firmware_property' follow
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_dir_in':
      drivers/gpio/gpio-raspberrypi-exp.o: In function `rpi_exp_gpio_probe':
      gpio-raspberrypi-exp.c:(.text+0x93c): undefined reference to `rpi_firmware_get'
      
      We already have a Kconfig dependency for it, but when compile-testing, it
      is disregarded.
      
      This changes the dependency so that compile-testing is only done when the
      firmware driver is completely disabled.
      
      Fixes: a98d90e7 ("gpio: raspberrypi-exp: Driver for RPi3 GPIO expander via mailbox service")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      7ed91505
    • W
      gpiolib: friendly debug information for consumer · 9d5a1f2c
      Wang Dongsheng 提交于
      "failed" maybe makes observer confuse when a consumer can not
      lookup, so change to a friendly information.
      Signed-off-by: NWang Dongsheng <dongsheng.wang@hxt-semitech.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      9d5a1f2c
  7. 01 3月, 2018 1 次提交
  8. 27 2月, 2018 2 次提交
    • C
      gpio: Handle deferred probing in of_find_gpio() properly · ce27fb2c
      Chen-Yu Tsai 提交于
      of_get_named_gpiod_flags() used directly in of_find_gpio() or indirectly
      through of_find_spi_gpio() or of_find_regulator_gpio() can return
      -EPROBE_DEFER. This gets overwritten by the subsequent of_find_*_gpio()
      calls.
      
      This patch fixes this by trying of_find_spi_gpio() or
      of_find_regulator_gpio() only if deferred probing was not requested by
      the previous of_get_named_gpiod_flags() call.
      
      Fixes: 6a537d48 ("gpio: of: Support regulator nonstandard GPIO properties")
      Fixes: c8582339 ("gpio: of: Support SPI nonstandard GPIO properties")
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      [Augmented to fit with Maxime's patch]
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      ce27fb2c
    • M
      gpiolib: Keep returning EPROBE_DEFER when we should · 6662ae6a
      Maxime Ripard 提交于
      Commits c8582339 ("gpio: of: Support SPI nonstandard GPIO properties")
      and 6a537d48 ("gpio: of: Support regulator nonstandard GPIO
      properties") have introduced a regression in the way error codes from
      of_get_named_gpiod_flags are handled.
      
      Previously, those errors codes were returned immediately, but the two
      commits mentioned above are now overwriting the error pointer, meaning that
      whatever value has been returned will be dropped in favor of whatever the
      two new functions will return.
      
      This might not be a big deal except for EPROBE_DEFER, on which GPIOlib
      customers will depend on, and that will now be returned as an hard error
      which means that they will not probe anymore, instead of gently deferring
      their probe.
      
      Since EPROBE_DEFER basically means that we have found a valid property but
      there was no GPIO controller registered to handle it, fix this issues by
      returning it as soon as we encounter it.
      
      Fixes: c8582339 ("gpio: of: Support SPI nonstandard GPIO properties")
      Fixes: 6a537d48 ("gpio: of: Support regulator nonstandard GPIO properties")
      Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      [Fold in fix to the fix]
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      6662ae6a
  9. 26 2月, 2018 1 次提交