12 Feb, 2019

18 commits

  • During the time window of noirq suspend and noirq resume, if a GPIO
    pin is enabled as system wakeup source, the corresponding GPIO line's
    IRQ will be unmasked, and GPIO bank will NOT lost power, when GPIO irq
    arrives, generic irq handler will mask it until GPIO driver is ready
    to handle it, but in GPIO noirq resume callback, current
    implementation will restore the IMR register using the value saved in
    previous noirq suspend callback which is unmasked, so this GPIO line
    with IRQ pending will be unmasked again after GPIO IMR regitster is
    restored, ARM will be triggered to handle this IRQ again, because of
    the change of commit bf22ff45bed6 ("genirq: Avoid unnecessary low
    level irq function calls"), the mask_irq function will check the
    status of irq_data to decide whether to mask the irq, in this
    scenario, since the GPIO IRQ is being masked before GPIO noirq resume,
    IRQD_IRQ_MASKED flag is set, so the second time GPIO IRQ triggered by
    restoring GPIO IMR register, the irq_mask callback will be skipped and
    cause ARM busy handling the GPIO IRQ come all the way and no response to
    user anymore.

    Signed-off-by: Bai Ping
    Reviewed-by: Anson Huang

    Bai Ping
     
  • This patch adds line 0 PAD wakeup support, it is missed previously,
    also protect the PAD wakeup interrupt handle with spin lock to
    avoid possible race condition of GPIO interrupt arriving during
    PAD wakeup interrupt handling.

    Signed-off-by: Anson Huang
    Reviewed-by: Fugang Duan
    (cherry picked from commit db842471137ef2758de6192f8f400e4b56da5d01)

    Anson Huang
     
  • This patch enables gpio pin's pad wakeup function which
    is supported by SCFW, with pad wakeup enabled, GPIO's
    power is no need to be enabled after suspend, hence
    save a sub-system's power.

    To enable pad wakeup, dtb needs to provide pad wakeup
    number for each gpio port, and each pin has to provide
    , they should be inside each gpio node,
    this is for calling SCFW APIs to enable/disable pad wakeup,
    example of adding GPIO4_22 pad wakeup in dtb:

    gpio4: gpio@5d0c0000 {
    compatible = "fsl,imx8qm-gpio", "fsl,imx35-gpio";
    reg = ;
    interrupts = ;
    gpio-controller;
    #gpio-cells = ;
    power-domains = ;
    interrupt-controller;
    #interrupt-cells = ;
    /* total pad wakeup number in gpio4 */
    pad-wakeup-num = ;
    /* SC_P_USDHC1_CD_B, SC_PAD_WAKEUP_LOW_LVL, LINE 22 */
    pad-wakeup = ;
    };

    Pad wakeup will be enabled after GPIO port suspend, and
    once any pad wakes up system, gpio driver will get the
    wakeup line and handles the event during noirq resume
    phase.

    Signed-off-by: Anson Huang
    Reviewed-by: Bai Ping
    (cherry picked from commit 1c7ffe9bf3a115031cec8c759a4cd0e09146de09)

    Anson Huang
     
  • Add output IOs defalut voltage set in device tree by add property like:
    out-default = /bits/ 16 ;

    Reviewed-by: Haibo Chen
    Signed-off-by: Fugang Duan

    Andy Duan
     
  • In system resume phase, the runtime resume will be called
    after noirq resume, and the GPIO could be operated between
    the noirq resume phase and the runtime resume phase, current
    implementation of noirq suspend/resume shares same save
    regs array with runtime suspend/resume, the GPIO operation
    will be overwritten by runtime resume using old save regs
    array, so adding independent gpio save regs for noirq
    suspend/resume ONLY, and use noirq suspend/resume callback
    instead of sharing runtime suspend/resume callback.

    Signed-off-by: Anson Huang
    Reviewed-by: Richard Zhu

    Anson Huang
     
  • On some i.MX platforms, GPIO banks may lose power
    when system suspend, and some peripheral devices
    resume may need to use GPIO during resume phase
    before GPIO resume, so GPIO needs to be restored
    as early as possible, this patch moves GPIO
    restore operation to noirq resume phase.

    Signed-off-by: Anson Huang
    Reviewed-by: Bai Ping

    Anson Huang
     
  • Add gpio interrupt chip support that only support wakeup feature
    by M4 core.

    Reviewed-by: Robin Gong
    Signed-off-by: Fugang Duan

    Fugang Duan
     
  • On MX7ULP, GPIO controller needs two necessary clocks:
    Port module clock and GPIO module clock.

    Add them as optional clocks to use.

    Acked-by: Fugang Duan
    Signed-off-by: Dong Aisheng

    Dong Aisheng
     
  • Add device reset for max732x driver.

    Signed-off-by: Fugang Duan
    Acked-by: Gao Pan

    Fugang Duan
     
  • Save gpio controller registers before power off, and then restore these
    registers after power on. There have two cases need to save/restore regs:
    a. If sub_irqs/sub_gpios are not free/released, device suspend() force
    runtime suspend and power domain off in suspended stage, it needs to
    keep the previous registers value after device resume back.
    b. If some sub_irqs set irq type just one time, then irqchip should restore
    the registers for correct irq type.

    Signed-off-by: Fugang Duan
    Tested-by: Guoniu.Zhou
    Reviewed-by: Frank Li

    Fugang Duan
     
  • Add runtime pm support to automatically enable the ipg clock and power
    domain if present.

    To save power, suggest all sub-devices of the gpiochip/irq domain should
    dynamically manage gpio/irq resouces like:
    gpio:
    gpiod_request()
    ... //set gpio direction
    gpiod_free()
    irq:
    devm_request_irq() //=> module active
    devm_free_irq() //=>module is non-active or runtime idle

    Since the driver support irqchip and gpiochip, any irq/gpio resouce requested
    by other modules the gpio controller clock and power domain should be enabled.
    And the irqchip's parent's clock and power also should be enabled if irq resouce
    requested.

    Signed-off-by: Fugang Duan
    Tested-by: Guoniu.Zhou
    Reviewed-by: Frank Li

    Fugang Duan
     
  • Add rpmsg virtual gpio driver support.
    i.MX7ULP GPIO PTA and PTB resource are managed by M4 core, setup one
    simple protocol with M4 core based on RPMSG virtual IO to let A core
    access such GPIOs that is what the driver do.

    Reviewed-by: Richard Zhu
    Reviewed-by: Robin Gong
    Signed-off-by: Fugang Duan

    Fugang Duan
     
  • Add build dependency for i.MX gpio driver.

    Signed-off-by: Anson Huang

    Anson Huang
     
  • Remove dependency of ARCH_MXC to support GPIO driver on
    both ARMv7 and ARMv8 i.MX platforms.

    Signed-off-by: Anson Huang
    Signed-off-by: Peng Fan

    Anson Huang
     
  • At imx7ulp, any interrupts can wake system up from suspend at "standby"
    mode, so we mask interrupt for gpio by default. The user can still
    enable wakeup through /sys entry.

    Signed-off-by: Peter Chen

    Peter Chen
     
  • Correct device_reset() return value checking.

    Signed-off-by: Fugang Duan

    Andy Duan
     
  • For some platform such as imx7D SDB, one pin of 74x164 to
    control all peripheral power supply(PERI_3V_EN).
    The pin should keep in high voltage level when 74x164 loading,
    otherwise the module depend on PERI_3V3 will lose power.
    So add new property registers-default into 74x164 driver.

    Signed-off-by: Sandor Yu
    Signed-off-by: Fugang Duan
    (cherry picked from commit: 61fe7af7e47dd8bf6acc91ceabd9e660d28de28a)

    Sandor Yu
     
  • The pca953x type of devices, e.g. max7310, may have a reset which needs
    to be handled to get the device start working. Add a device_reset()
    call for that, and defer the probe if the reset controller for that is
    not ready yet.

    Signed-off-by: Shawn Guo
    Signed-off-by: Fugang Duan

    Shawn Guo
     

07 Feb, 2019

2 commits

  • commit 2486e67374aa8b7854c2de32869642c2873b3d53 upstream.

    When multiple instances of pcf857x chips are present, a fix up
    message [1] is printed during the probe of the 2nd and later
    instances.

    The issue is that the driver is using the same irq_chip data
    structure between multiple instances.

    Fix this by allocating the irq_chip data structure per instance.

    [1] fix up message addressed by this patch
    [ 1.212100] gpio gpiochip9: (pcf8575): detected irqchip that is shared with multiple gpiochips: please fix the driver.

    Cc: Stable
    Signed-off-by: Roger Quadros
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Greg Kroah-Hartman

    Roger Quadros
     
  • commit 2095a45e345e669ea77a9b34bdd7de5ceb422f93 upstream.

    The altr_a10sr_gpio_direction_output should set proper output level
    based on the value argument.

    Fixes: 26a48c4cc2f1 ("gpio: altera-a10sr: Add A10 System Resource Chip GPIO support.")
    Cc:
    Signed-off-by: Axel Lin
    Tested by: Thor Thayer
    Reviewed by: Thor Thayer
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Greg Kroah-Hartman

    Axel Lin
     

26 Jan, 2019

1 commit

  • [ Upstream commit ed8dce4c6f726b7f3c6bf40859b92a9e32f189c1 ]

    Keeping the irq_chip definition static will make it shared with multiple
    giochips in the system. This practice is considered to be bad and now we
    will get the below warning from gpiolib core:

    "detected irqchip that is shared with multiple gpiochips: please fix the
    driver."

    Hence, move the irq_chip definition from static to `struct pl061` for
    using a unique irq_chip for each gpiochip.

    Signed-off-by: Manivannan Sadhasivam
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin

    Manivannan Sadhasivam
     

13 Jan, 2019

1 commit

  • [ Upstream commit c8da642d41a6811c21177c9994aa7dc35be67d46 ]

    The gpio IP on Armada 370 at offset 0x18180 has neither a clk nor pwm
    registers. So there is no need for a clk as the pwm isn't used anyhow.
    So only check for the clk in the presence of the pwm registers. This fixes
    a failure to probe the gpio driver for the above mentioned gpio device.

    Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support")
    Signed-off-by: Uwe Kleine-König
    Reviewed-by: Gregory CLEMENT
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin

    Uwe Kleine-König
     

29 Dec, 2018

2 commits

  • commit e59f5e08ece1060073d92c66ded52e1f2c43b5bb upstream.

    Commit 78d3a92edbfb ("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: 78d3a92edbfb ("gpiolib-acpi: Register GpioInt ACPI event ...")
    Signed-off-by: Hans de Goede
    Reviewed-by: Andy Shevchenko
    Acked-by: Mika Westerberg
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     
  • commit abf221d2f51b8ce7b9959a8953f880a8b0a1400d upstream.

    spi_read() and spi_write() require DMA-safe memory. When
    CONFIG_VMAP_STACK is selected, those functions cannot be used
    with buffers on stack.

    This patch replaces calls to spi_read() and spi_write() by
    spi_write_then_read() which doesn't require DMA-safe buffers.

    Fixes: 0c36ec314735 ("gpio: gpio driver for max7301 SPI GPIO expander")
    Cc:
    Signed-off-by: Christophe Leroy
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Christophe Leroy
     

13 Dec, 2018

1 commit

  • [ Upstream commit bff466bac59994cfcceabe4d0be5fdc1c20cd5b8 ]

    Commit 3edfb7bd76bd ("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: Bartosz Golaszewski
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin

    Bartosz Golaszewski
     

01 Dec, 2018

1 commit

  • commit a05a14049999598a3bb6fab12db6b768a0215522 upstream.

    The change corrects the error path in gpiochip_add_data_with_key()
    by avoiding to call ida_simple_remove(), if ida_simple_get() returns
    an error.

    Note that ida_simple_remove()/ida_free() throws a BUG(), if id argument
    is negative, it allows to easily check the correctness of the fix by
    fuzzing the return value from ida_simple_get().

    Fixes: ff2b13592299 ("gpio: make the gpiochip a real device")
    Cc: stable@vger.kernel.org # v4.6+
    Signed-off-by: Vladimir Zapolskiy
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Vladimir Zapolskiy
     

21 Nov, 2018

1 commit

  • commit 142c168e0e50164e67c9399c28dedd65a307cfe5 upstream.

    The basic memory-mapped GPIO controller lock must be released
    before calling the registered GPIO interrupt handlers to allow
    the interrupt handlers to access the hardware.

    Examples of why a GPIO interrupt handler might want to access
    the GPIO hardware include an interrupt that is configured to
    trigger on rising and falling edges that needs to read the
    current level of the input to know how to respond, or an
    interrupt that causes a change in a GPIO output in the same
    bank. If the lock is not released before enterring the handler
    the hardware accesses will deadlock when they attempt to grab
    the lock.

    Since the lock is only needed to protect the calculation of
    unmasked pending interrupts create a dedicated function to
    perform this and hide the complexity.

    Fixes: 19a7b6940b78 ("gpio: brcmstb: Add interrupt and wakeup source support")
    Signed-off-by: Doug Berger
    Reviewed-by: Florian Fainelli
    Acked-by: Gregory Fong
    Signed-off-by: Linus Walleij
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Doug Berger
     

10 Nov, 2018

1 commit

  • [ Upstream commit 833eacc7b5913da9896bacd30db7d490aa777868 ]

    The MXS driver was calling back into the GPIO API from
    its irqchip. This is not very elegant, as we are a driver,
    let's just shortcut back into the gpio_chip .get() function
    instead.

    This is a tricky case since the .get() callback is not in
    this file, instead assigned by bgpio_init(). Calling the
    function direcly in the gpio_chip is however the lesser
    evil.

    Cc: Sascha Hauer
    Cc: Janusz Uzycki
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin

    Linus Walleij
     

10 Oct, 2018

5 commits

  • commit 19a4fbffc94e41abaa2a623a25ce2641d69eccf0 upstream.

    The current code only frees N-1 gpios if an error occurs during
    gpiod_set_transitory, gpiod_direction_output or gpiod_direction_input.
    Leading to gpios that cannot be used by userspace nor other drivers.

    Cc: Timur Tabi
    Cc: stable@vger.kernel.org
    Fixes: ab3dbcf78f60f46d ("gpioib: do not free unrequested descriptors)
    Reported-by: Jan Lorenzen
    Reported-by: Jim Paris
    Signed-off-by: Ricardo Ribalda Delgado
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Ricardo Ribalda Delgado
     
  • [ Upstream commit d49b48f088c323dbacae44dfbe56d9c985c8a2a1 ]

    gpiochip_add_data_with_key() adds the gpiochip to the gpio_devices list
    before of_gpiochip_add() is called, but it's only the latter which sets
    the ->of_xlate function pointer. gpiochip_find() can be called by
    someone else between these two actions, and it can find the chip and
    call of_gpiochip_match_node_and_xlate() which leads to the following
    crash due to a NULL ->of_xlate().

    Unhandled prefetch abort: page domain fault (0x01b) at 0x00000000
    Modules linked in: leds_gpio(+) gpio_generic(+)
    CPU: 0 PID: 830 Comm: insmod Not tainted 4.18.0+ #43
    Hardware name: ARM-Versatile Express
    PC is at (null)
    LR is at of_gpiochip_match_node_and_xlate+0x2c/0x38
    Process insmod (pid: 830, stack limit = 0x(ptrval))
    (of_gpiochip_match_node_and_xlate) from (gpiochip_find+0x48/0x84)
    (gpiochip_find) from (of_get_named_gpiod_flags+0xa8/0x238)
    (of_get_named_gpiod_flags) from (gpiod_get_from_of_node+0x2c/0xc8)
    (gpiod_get_from_of_node) from (devm_fwnode_get_index_gpiod_from_child+0xb8/0x144)
    (devm_fwnode_get_index_gpiod_from_child) from (gpio_led_probe+0x208/0x3c4 [leds_gpio])
    (gpio_led_probe [leds_gpio]) from (platform_drv_probe+0x48/0x9c)
    (platform_drv_probe) from (really_probe+0x1d0/0x3d4)
    (really_probe) from (driver_probe_device+0x78/0x1c0)
    (driver_probe_device) from (__driver_attach+0x120/0x13c)
    (__driver_attach) from (bus_for_each_dev+0x68/0xb4)
    (bus_for_each_dev) from (bus_add_driver+0x1a8/0x268)
    (bus_add_driver) from (driver_register+0x78/0x10c)
    (driver_register) from (do_one_initcall+0x54/0x1fc)
    (do_one_initcall) from (do_init_module+0x64/0x1f4)
    (do_init_module) from (load_module+0x2198/0x26ac)
    (load_module) from (sys_finit_module+0xe0/0x110)
    (sys_finit_module) from (ret_fast_syscall+0x0/0x54)

    One way to fix this would be to rework the hairy registration sequence
    in gpiochip_add_data_with_key(), but since I'd probably introduce a
    couple of new bugs if I attempted that, simply add a check for a
    non-NULL of_xlate function pointer in
    of_gpiochip_match_node_and_xlate(). This works since the driver looking
    for the gpio will simply fail to find the gpio and defer its probe and
    be reprobed when the driver which is registering the gpiochip has fully
    completed its probe.

    Signed-off-by: Vincent Whitchurch
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Vincent Whitchurch
     
  • [ Upstream commit 78d3a92edbfb02e8cb83173cad84c3f2d5e1f070 ]

    GpioInt ACPI event handlers may see there IRQ triggered immediately
    after requesting the IRQ (esp. level triggered ones). This means that they
    may run before any other (builtin) drivers have had a chance to register
    their OpRegion handlers, leading to errors like this:

    [ 1.133274] ACPI Error: No handler for Region [PMOP] ((____ptrval____)) [UserDefinedRegion] (20180531/evregion-132)
    [ 1.133286] ACPI Error: Region UserDefinedRegion (ID=141) has no handler (20180531/exfldio-265)
    [ 1.133297] ACPI Error: Method parse/execution failed \_SB.GPO2._L01, AE_NOT_EXIST (20180531/psparse-516)

    We already defer the manual initial trigger of edge triggered interrupts
    by running it from a late_initcall handler, this commit replaces this with
    deferring the entire acpi_gpiochip_request_interrupts() call till then,
    fixing the problem of some OpRegions not being registered yet.

    Note that this removes the need to have a list of edge triggered handlers
    which need to run, since the entire acpi_gpiochip_request_interrupts() call
    is now delayed, acpi_gpiochip_request_interrupt() can call these directly
    now.

    Acked-by: Mika Westerberg
    Signed-off-by: Hans de Goede
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     
  • [ Upstream commit 993b9bc5c47fda86f8ab4e53d68c6fea5ff2764a ]

    The commit ca876c7483b6

    ("gpiolib-acpi: make sure we trigger edge events at least once on boot")

    added a initial value check for pin which is about to be locked as IRQ.
    Unfortunately, not all GPIO drivers can do that atomically. Thus,
    switch to cansleep version of the call. Otherwise we have a warning:

    ...
    WARNING: CPU: 2 PID: 1408 at drivers/gpio/gpiolib.c:2883 gpiod_get_value+0x46/0x50
    ...
    RIP: 0010:gpiod_get_value+0x46/0x50
    ...

    The change tested on Intel Broxton with Whiskey Cove PMIC GPIO controller.

    Fixes: ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events at least once on boot")
    Signed-off-by: Andy Shevchenko
    Cc: Hans de Goede
    Cc: Benjamin Tissoires
    Acked-by: Mika Westerberg
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Andy Shevchenko
     
  • [ Upstream commit 6537886cdc9a637711fd6da980dbb87c2c87c9aa ]

    This fixes:
    [BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug
    in adp5588_gpio_write()
    [BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug
    in adp5588_gpio_direction_input()

    Reported-by: Jia-Ju Bai
    Signed-off-by: Michael Hennerich
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Michael Hennerich
     

04 Oct, 2018

1 commit

  • [ Upstream commit 7279d9917560bbd0d82813d6bf00490a82c06783 ]

    men_z127_debounce() tries to round up and down, but uses functions which
    are only suitable when the divider is a power of two, which is not the
    case. Use the appropriate ones.

    Found by static check. Compile tested.

    Fixes: f436bc2726c64 ("gpio: add driver for MEN 16Z127 GPIO controller")
    Signed-off-by: Nadav Amit
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Nadav Amit
     

26 Sep, 2018

2 commits

  • [ Upstream commit b23ec59926faf05b0c43680d05671c484e810ac4 ]

    Since we put static variable to a header file it's copied to each module
    that includes the header. But not all of them are actually used it.

    Mark gpio_suffixes array with __maybe_unused to hide a compiler warning:

    In file included from
    drivers/gpio/gpiolib-legacy.c:6:0:
    drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=]
    static const char * const gpio_suffixes[] = { "gpios", "gpio" };
    ^~~~~~~~~~~~~
    In file included from drivers/gpio/gpiolib-devprop.c:17:0:
    drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=]
    static const char * const gpio_suffixes[] = { "gpios", "gpio" };
    ^~~~~~~~~~~~~

    Signed-off-by: Andy Shevchenko
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Andy Shevchenko
     
  • [ Upstream commit 9506755633d0b32ef76f67c345000178e9b0dfc4 ]

    platform_get_resource() may fail and return NULL, so we should
    better check it's return value to avoid a NULL pointer dereference
    a bit later in the code.

    This is detected by Coccinelle semantic patch.

    @@
    expression pdev, res, n, t, e, e1, e2;
    @@

    res = platform_get_resource(pdev, t, n);
    + if (!res)
    + return -EINVAL;
    ... when != res == NULL
    e = devm_ioremap(e1, res->start, e2);

    Signed-off-by: Wei Yongjun
    Acked-by: Robert Jarzmik
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Wei Yongjun
     

20 Sep, 2018

2 commits

  • [ Upstream commit 4bf4eed44bfe288f459496eaf38089502ef91a79 ]

    If ioh_gpio_probe() fails on devm_irq_alloc_descs() then chip may point
    to any element of chip_save array, so reverse iteration from pointer chip
    may become chip_save[-1] and gpiochip_remove() will operate with wrong
    memory.

    The patch fix the error path of ioh_gpio_probe() to correctly bypass
    chip_save array.

    Found by Linux Driver Verification project (linuxtesting.org).

    Signed-off-by: Anton Vasilyev
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Anton Vasilyev
     
  • [ Upstream commit 40b25bce0adbe641a744d1291bc0e51fb7f3c3d8 ]

    There is a bug in regards to deferred probing within the drivers core
    that causes GPIO-driver to suspend after its users. The bug appears if
    GPIO-driver probe is getting deferred, which happens after introducing
    dependency on PINCTRL-driver for the GPIO-driver by defining "gpio-ranges"
    property in device-tree. The bug in the drivers core is old (more than 4
    years now) and is well known, unfortunately there is no easy fix for it.
    The good news is that we can workaround the deferred probe issue by
    changing GPIO / PINCTRL drivers registration order and hence by moving
    PINCTRL driver registration to the arch_init level and GPIO to the
    subsys_init.

    Signed-off-by: Dmitry Osipenko
    Acked-by: Stefan Agner
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Dmitry Osipenko
     

05 Sep, 2018

1 commit

  • [ Upstream commit ca876c7483b697b498868b1f575997191b077885 ]

    On some systems using edge triggered ACPI Event Interrupts, the initial
    state at boot is not setup by the firmware, instead relying on the edge
    irq event handler running at least once to setup the initial state.

    2 known examples of this are:

    1) The Surface 3 has its _LID state controlled by an ACPI operation region
    triggered by a GPIO event:

    OperationRegion (GPOR, GeneralPurposeIo, Zero, One)
    Field (GPOR, ByteAcc, NoLock, Preserve)
    {
    Connection (
    GpioIo (Shared, PullNone, 0x0000, 0x0000, IoRestrictionNone,
    "\\_SB.GPO0", 0x00, ResourceConsumer, ,
    )
    { // Pin list
    0x004C
    }
    ),
    HELD, 1
    }

    Method (_E4C, 0, Serialized) // _Exx: Edge-Triggered GPE
    {
    If ((HELD == One))
    {
    ^^LID.LIDB = One
    }
    Else
    {
    ^^LID.LIDB = Zero
    Notify (LID, 0x80) // Status Change
    }

    Notify (^^PCI0.SPI1.NTRG, One) // Device Check
    }

    Currently, the state of LIDB is wrong until the user actually closes or
    open the cover. We need to trigger the GPIO event once to update the
    internal ACPI state.

    Coincidentally, this also enables the Surface 2 integrated HID sensor hub
    which also requires an ACPI gpio operation region to start initialization.

    2) Various Bay Trail based tablets come with an external USB mux and
    TI T1210B USB phy to enable USB gadget mode. The mux is controlled by a
    GPIO which is controlled by an edge triggered ACPI Event Interrupt which
    monitors the micro-USB ID pin.

    When the tablet is connected to a PC (or no cable is plugged in), the ID
    pin is high and the tablet should be in gadget mode. But the GPIO
    controlling the mux is initialized by the firmware so that the USB data
    lines are muxed to the host controller.

    This means that if the user wants to use gadget mode, the user needs to
    first plug in a host-cable to force the ID pin low and then unplug it
    and connect the tablet to a PC, to get the ACPI event handler to run and
    switch the mux to device mode,

    This commit fixes both by running the event-handler once on boot.

    Note that the running of the event-handler is done from a late_initcall,
    this is done because the handler AML code may rely on OperationRegions
    registered by other builtin drivers. This avoids errors like these:

    [ 0.133026] ACPI Error: No handler for Region [XSCG] ((____ptrval____)) [GenericSerialBus] (20180531/evregion-132)
    [ 0.133036] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20180531/exfldio-265)
    [ 0.133046] ACPI Error: Method parse/execution failed \_SB.GPO2._E12, AE_NOT_EXIST (20180531/psparse-516)

    Signed-off-by: Benjamin Tissoires
    [hdegoede: Document BYT USB mux reliance on initial trigger]
    [hdegoede: Run event handler from a late_initcall, rather then immediately]
    Signed-off-by: Hans de Goede
    Reviewed-by: Andy Shevchenko
    Acked-by: Mika Westerberg
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Benjamin Tissoires
     

16 Jun, 2018

1 commit

  • commit 7d18f0a14aa6a0d6bad39111c1fb655f07f71d59 upstream.

    Sometimes a GPIO is fetched with NULL as parent device, and
    that is just fine. So under these circumstances, avoid using
    dev_name() to provide a name for the GPIO line.

    Signed-off-by: Linus Walleij
    Cc: Daniel Rosenberg
    Signed-off-by: Greg Kroah-Hartman

    Linus Walleij