linux-toradex.git/drivers/gpio, branch v4.9.78

gpio: altera: Use handle_level_irq when configured as a level_high

2017-12-14T08:28:18+00:00

[ Upstream commit f759921cfbf4847319d197a6ed7c9534d593f8bc ]

When a threaded irq handler is chained attached to one of the gpio
pins when configure for level irq the altera_gpio_irq_leveL_high_handler
does not mask the interrupt while being handled by the chained irq.
This resulting in the threaded irq not getting enough cycles to complete
quickly enough before the irq was disabled as faulty. handle_level_irq
should be used in this situation instead of handle_simple_irq.

In gpiochip_irqchip_add set default handler to handle_bad_irq as
per Documentation/gpio/driver.txt. Then set the correct handler in
the set_type callback.

Signed-off-by: Phil Reid 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

gpio: mockup: dynamically allocate memory for chip name

2017-11-30T08:39:13+00:00

[ Upstream commit ad6d8004fa29a8958381b60215e32d1e903b0492 ]

Currently the chip name buffer is allocated on the stack and the
address of the buffer is passed to the gpio framework. It's invalid
after probe() returns, so the sysfs label attribute displays garbage.

Use devm_kasprintf() for each string instead.

Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

gpio: mcp23s08: Select REGMAP/REGMAP_I2C to fix build error

2017-11-08T09:08:35+00:00

[ Upstream commit e8e1a5b5679b1ae1ff03a3883b011b84e7226171 ]

This driver now using devm_regmap_init/devm_regmap_init_i2c, so it needs
to select REGMAP/REGMAP_I2C accordingly.

Fixes: ("3d84fdb3f0b5 gpio: mcp23s08: use regmap")
Signed-off-by: Axel Lin 
Acked-By: Sebastian Reichel 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

gpiolib: skip unwanted events, don't convert them to opposite edge

2017-08-11T15:49:30+00:00

commit df1e76f28ffe87d1b065eecab2d0fbb89e6bdee5 upstream.

The previous fix for filtering out of unwatched events was not entirely
correct. Instead of skipping the events we don't want, they are now
interpreted as events with opposing edge.

In order to fix it: always read the GPIO line value on interrupt and
only emit the event if it corresponds with the event type we requested.

Fixes: ad537b822577 ("gpiolib: fix filtering out unwanted events")
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpiolib: fix filtering out unwanted events

2017-07-05T12:40:18+00:00

commit ad537b822577fcc143325786cd6ad50d7b9df31c upstream.

GPIOEVENT_REQUEST_BOTH_EDGES is not a single flag, but a binary OR of
GPIOEVENT_REQUEST_RISING_EDGE and GPIOEVENT_REQUEST_FALLING_EDGE.

The expression 'le->eflags & GPIOEVENT_REQUEST_BOTH_EDGES' we'll get
evaluated to true even if only one event type was requested.

Fix it by checking both RISING & FALLING flags explicitly.

Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: omap: return error if requested debounce time is not possible

2017-05-25T13:44:36+00:00

commit 83977443938122baeed28dc9f078db3da9855f7c upstream.

omap_gpio_debounce() does not validate that the requested debounce
is within a range it can handle. Instead it lets the register value
wrap silently, and always returns success.

This can lead to all sorts of unexpected behavior, such as gpio_keys
asking for a too-long debounce, but getting a very short debounce in
practice.

Fix this by returning -EINVAL if the requested value does not fit into
the register field. If there is no debounce clock available at all,
return -ENOTSUPP.

Fixes: e85ec6c3047b ("gpio: omap: fix omap2_set_gpio_debounce")
Signed-off-by: David Rivshin 
Acked-by: Grygorii Strashko 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

ACPI / gpio: do not fall back to parsing _CRS when we get a deferral

2017-04-12T10:41:12+00:00

commit 693bdaa164b40b7aa6018b98af6f7e40dbd52457 upstream.

If, while locating GPIOs by name, we get probe deferral, we should
immediately report it to caller rather than trying to fall back to parsing
unnamed GPIOs from _CRS block.

Signed-off-by: Dmitry Torokhov 
Acked-by: Mika Westerberg 
Acked-and-Tested-by: Hans de Goede 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: Move freeing of GPIO hogs before numbing of the device

2017-01-19T19:18:00+00:00

commit 5018ada69a04c8ac21d74bd682fceb8e42dc0f96 upstream.

When removing a gpiochip that uses GPIO hogging (e.g. by unloading the
chip's DT overlay), a warning is printed:

    gpio gpiochip8: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED

This happens because gpiochip_free_hogs() is called after the gdev->chip
pointer is reset to NULL. Hence __gpiod_free() cannot determine the
chip in use, and cannot clear flags nor call the optional chip-specific
.free() callback.

Move the call to gpiochip_free_hogs() up to fix this.

Fixes: ff2b135922992756 ("gpio: make the gpiochip a real device")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: chardev: Return error for seek operations

2017-01-09T07:32:18+00:00

commit f4e81c529767b9a33d1b27695c54dc84a14af30d upstream.

The GPIO chardev is used for management tasks (allocating line and event
handles) and does neither support read() nor write() operations. Hence it
does not make much sense to allow seek operations.

Currently the chardev uses noop_llseek() for its seek implementation. This
function does not move the pointer and simply returns the current position
(always 0 for the GPIO chardev). noop_llseek() is primarily meant for
devices that can not support seek, but where there might be a user that
depends on the seek() operation succeeding. For newly added devices that
can not support seek operations it is recommended to use no_llseek(), which
will return an error. For more information see commit 6038f373a3dc
("llseek: automatically add .llseek fop").

Unfortunately this was overlooked when the GPIO chardev ABI was introduced.
But it is highly unlikely that since then userspace applications have
appeared that rely on being able to perform non-failing seek operations on
a GPIO chardev file descriptor. So it should be safe to change from
noop_llseel() to no_seek(). Also use nonseekable_open() in the chardev
open() callback to clear the FMODE_SEEK, FMODE_PREAD and FMODE_PWRITE flags
from the file. Neither of these should be set on a file that does not
support seek operations.

Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs")
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: stmpe: fix interrupt handling bug

2017-01-09T07:32:17+00:00

commit 1516c6350aa2770b8a5e36d40c3ec5078f92ba70 upstream.

commit 43db289d00c6 ("gpio: stmpe: Rework registers access")
reworked the STMPE register access so as to use
[STMPE_IDX_*_LSB + i] to access the 8bit register for a
certain bank, assuming the CSB and MSB will follow after
the enumerator. For this to work the index needs to go from
(size-1) to 0 not 0 to (size-1).

However for the GPIO IRQ handler, the status registers we read
register MSB + 3 bytes ahead for the 24 bit GPIOs and index
registers from MSB upwards and run an index i over the
registers UNLESS we are STMPE1600.

This is not working when we get to clearing the interrupt
EDGE status register STMPE_IDX_GPEDR_[LCM]SB: it is indexed
like all other registers [STMPE_IDX_*_LSB + i] but in this
loop we index from 0 to get the right bank index for the
calculations, and we need to just add i to the MSB.

Before this, interrupts on the STMPE2401 were broken, this
patch fixes it so it works again.

Cc: Patrice Chotard 
Fixes: 43db289d00c6 ("gpio: stmpe: Rework registers access")
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman