kernel/drivers/gpio/gpio-max732x.c, branch linux-4.3.y

gpio: max732x: Fix error handling in probe()

2015-08-26T11:34:55Z

This fixes error handling in the function max732x_probe by checking if the calls to the function max732x_readb fail by returning a error code. Signed-off-by: Nicholas Krause Signed-off-by: Linus Walleij

gpio: max732x: Add missing dev reference to gpiochip

2015-07-16T11:42:46Z

In case the gpiochip doesn't have the .dev field set, as is the case in here, it is not possible to reference this device in DT as a GPIO controller. A good example of this problem is that gpio-leds can not be used when connected to this chip, the gpio-leds driver bails out with -EPROBE_DEFER. Fix this problem by setting the .dev field of the gpio_chip to the parent i2c device. Signed-off-by: Marek Vasut Cc: Alexandre Courbot Cc: Linus Walleij Cc: Mans Rullgard Cc: Olaf Mandel Cc: Semen Protsenko Signed-off-by: Linus Walleij

gpio: max732x: Fix irq-events handler

2015-05-06T13:08:54Z

MAX732X clears all pending interrupts on I2C read (when interrupts register is being read). Driver doesn't need to send any ACKs when interrupt was handled. So replace handle_edge_irq() with handle_simple_irq(). Using handle_edge_irq() (w/o .irq_ack callback set) may lead to NULL pointer dereference in some cases. E.g. this was observed on hibernation process: Unable to handle kernel NULL pointer dereference at virtual address 0 Backtrace: (handle_edge_irq) from (resend_irqs) (resend_irqs) from (tasklet_action) (tasklet_action) from (__do_softirq) (__do_softirq) from (run_ksoftirqd) (run_ksoftirqd) from (smpboot_thread_fn) (smpboot_thread_fn) from (kthread) (kthread) from (ret_from_fork) Signed-off-by: Semen Protsenko Reviewed-by: Grygorii Strashko Signed-off-by: Linus Walleij

gpio: max732x: Add IRQF_SHARED to irq flags

2015-05-06T13:05:54Z

It's possible that multiple MAX732X can be hooked up to the same interrupt line with the processor. So add IRQF_SHARED in requesting irq. Signed-off-by: Semen Protsenko Signed-off-by: Linus Walleij

gpio: max732x: Propagate wake-up setting to parent irq controller

2015-05-04T13:31:20Z

Set .irq_set_wake callback to prevent possible issues on wake-up. This patch was inspired by this commit: b80eef95beb04760629822fa130aeed54cdfafca Signed-off-by: Semen Protsenko Signed-off-by: Linus Walleij

gpio: max732x: convert to GPIOLIB_IRQCHIP

2015-03-02T14:44:08Z

Take a sweep to bring the irq support for the MAX732x expanders into the gpiolib core to cut down on duplicated code. Only compile tested! I need some feedback from people using this expander with interrupts to tell me if things go right or wrong when I do this. Cc: Semen Protsenko Cc: Mans Rullgard Signed-off-by: Linus Walleij

gpio: max732x: use an inline function for container cast

2015-02-03T12:35:57Z

Cast the struct gpio_chip into a max732x_chip using an inline macro and move the assignment to the variable declaration to save lines and simplify things. Cc: Semen Protsenko Acked-by: Mans Rullgard Signed-off-by: Linus Walleij

gpio: max732x: add set_multiple function

2015-01-30T09:45:56Z

This adds a set_multiple function to the MAX732x GPIO driver, allowing for performance gains when using gpiod_set_array(). Signed-off-by: Mans Rullgard Signed-off-by: Linus Walleij

gpio: max732x: Fix possible deadlock

2015-01-15T17:03:49Z

This patch was derived from next one: "gpio: fix pca953x set_type 'scheduling while atomic' bug". After adding entry that consumes max732x GPIO as interrupt line to dts file, deadlock appears somewhere in max732x probe function. Deadlock caught by lockdep (from kernel log): <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< cut here >>>>>>>>>>>>>>>>>>>>>>>>>>> [ 0.473419] ====================================================== [ 0.473419] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] [ 0.473449] 3.x.xx-xxxxx-xxxxxxxx-dirty #2 Tainted: G W [ 0.473449] ------------------------------------------------------ [ 0.473449] swapper/0/1 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 0.473449] (&lock->wait_lock){+.+...}, at: [] rt_mutex_trylock+0xc/0x74 [ 0.473480] [ 0.473480] and this task is already holding: [ 0.473510] (&chip->lock){......}, at: [] max732x_gpio_set_value+0x2c/0xa4 [ 0.473541] which would create a new lock dependency: [ 0.473541] (&chip->lock){......} -> (&lock->wait_lock){+.+...} ... [ 0.474273] *** DEADLOCK *** [ 0.474273] [ 0.474273] 5 locks held by swapper/0/1: [ 0.474273] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x48/0x98 [ 0.474304] #1: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x58/0x98 [ 0.474334] #2: (&chip->irq_lock){+.+...}, at: [] max732x_irq_bus_lock+0x14/0x20 [ 0.474365] #3: (&irq_desc_lock_class){-.....}, at: [] __irq_get_desc_lock+0x48/0x88 [ 0.474365] #4: (&chip->lock){......}, at: [] max732x_gpio <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< cut here >>>>>>>>>>>>>>>>>>>>>>>>>>> Signed-off-by: Semen Protsenko Signed-off-by: Linus Walleij

gpio: max732x: Rewrite IRQ code to use irq_domain API

2015-01-15T16:53:56Z

Signed-off-by: Semen Protsenko Signed-off-by: Linus Walleij