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

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

gpio: Remove GPIO_DEVRES option

2016-11-16T19:46:32+00:00

This option was added in 6a89a314ab107a12af08c71420c19a37a30fc2d3 to
allow use of the devm_gpio_* functions without CONFIG_GPIOLIB.

However, only a few months later in
b69ac52449c658b7ac40034dc3c5f5f4a71a723d, CONFIG_GPIOLIB was added
as a dependency, defeating the original purpose of this option.
Instead of that patch, the original commit could have just been
reverted (and in fact was partially so in
403c1d0be5ccbd750d25c59d8358843a81e52e3b). Further, since this
option has a dependency on HAS_IOMEM, even though it does not
require it, it causes build failures when !HAS_IOMEM (e.g. in a
uml build).

Fix that by completely removing the option, in essence completing
the reversion of the original commit.

Signed-off-by: Keno Fischer 
Signed-off-by: Linus Walleij

gpio: tc3589x: fix up .get_direction()

2016-11-15T09:33:30+00:00

The bit in the TC3589x direction register is 0 for input
and 1 for output, but the gpiolib expects the reverse.
Fix up the logic.

Cc: stable@vger.kernel.org
Fixes: 14063d71e5e6 ("gpio: tc3589x: add .get_direction() and small cleanup")
Signed-off-by: Linus Walleij

gpio: do not double-check direction on sleeping chips

2016-11-15T09:26:34+00:00

When locking a GPIO line as IRQ, we go to lengths to
double-check that the line is really set as input before
marking it as used for IRQ. This is not good on GPIO chips
that can sleep, because this function is called in IRQ-safe
context. Just skip this if it can't be checked quickly.

Currently this happens on sleeping expanders such as STMPE
or TC3589x:

BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc1+ #38
Hardware name: Nomadik STn8815
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (__schedule_bug+0x54/0x80)
[] (__schedule_bug) from [] (__schedule+0x3a0/0x460)
[] (__schedule) from [] (schedule+0x54/0xb8)
(...)

This patch fixes that problem and relies on the direction
read from the chip when it was added.

Cc: stable@vger.kernel.org
Fixes: 9c10280d85c1 ("gpio: flush direction status in gpiochip_lock_as_irq()")
Cc: Patrice Chotard 
Signed-off-by: Linus Walleij