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

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

gpio: pca953x: Move memcpy into mutex lock for set multiple

2016-11-08T09:29:47+00:00

Need to ensure that reg_output is not updated while setting multiple
bits. This makes the mutex locking behaviour for the set_multiple call
consistent with that of the set_value call.

Cc: stable@vger.kernel.org
Fixes: b4818afeacbd ("gpio: pca953x: Add set_multiple to allow multiple")
Signed-off-by: Phil Reid 
Signed-off-by: Linus Walleij

gpio: pca953x: Fix corruption of other gpios in set_multiple.

2016-11-08T09:29:42+00:00

gpiod_set_array_value_complex does not clear the bits field.
Therefore when the drivers set_multiple funciton is called bits outside
the mask are undefined and can be either set or not. So bank_val needs
to be masked with bank_mask before or with the reg_val cache.

Cc: stable@vger.kernel.org
Fixes: b4818afeacbd ("gpio: pca953x: Add set_multiple to allow multiple")
Signed-off-by: Phil Reid 
Signed-off-by: Linus Walleij

gpio/mvebu: Use irq_domain_add_linear

2016-11-01T18:31:49+00:00

This fixes the irq allocation in this driver to not print:
 irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
 irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated

Which happens because the driver already called irq_alloc_descs()
and so the change to use irq_domain_add_simple resulted in calling
irq_alloc_descs() twice.

Modernize the irq allocation in this driver to use the
irq_domain_add_linear flow directly and eliminate the use of
irq_domain_add_simple/legacy

Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()")
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Linus Walleij

gpio: of: fix GPIO drivers with multiple gpio_chip for a single node

2016-10-31T20:23:44+00:00

Sylvain Lemieux reports the LPC32xx GPIO driver is broken since
commit 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and
struct gg_data").  Probably, gpio-etraxfs.c and gpio-davinci.c are
broken too.

Those drivers register multiple gpio_chip that are associated to a
single OF node, and their own .of_xlate() checks if the passed
gpio_chip is valid.

Now, the problem is of_find_gpiochip_by_node() returns the first
gpio_chip found to match the given node.  So, .of_xlate() fails,
except for the first GPIO bank.

Reverting the commit could be a solution, but I do not want to go
back to the mess of struct gg_data.  Another solution here is to
take the match by a node pointer and the success of .of_xlate().
It is a bit clumsy to call .of_xlate twice; for gpio_chip matching
and for really getting the gpio_desc index.  Perhaps, our long-term
goal might be to convert the drivers to single chip registration,
but this commit will solve the problem until then.

Fixes: 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data")
Signed-off-by: Masahiro Yamada 
Reported-by: Sylvain Lemieux 
Tested-by: David Lechner 
Signed-off-by: Linus Walleij

gpio: GPIO_GET_LINE{HANDLE,EVENT}_IOCTL: Fix file descriptor leak

2016-10-31T20:23:44+00:00

When allocating a new line handle or event a file is allocated that it is
associated to. The file is attached to a file descriptor of the current
process and the file descriptor is returned to userspace using
copy_to_user(). If this copy operation fails the line handle or event
allocation is aborted, all acquired resources are freed and an error is
returned.

But the file struct is not freed and left attached to the userspace
application and even though the file descriptor number was not copied it is
trivial to guess. If a userspace application performs a IOCTL on such a
left over file descriptor it will trigger a use-after-free and if the file
descriptor is closed (latest when the application exits) a double-free is
triggered.

anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a
file descriptor for the current process and install the file struct in the
file descriptor. As soon as the file struct is installed in the file
descriptor it is accessible by userspace (even if the IOCTL itself hasn't
completed yet), this means uninstalling the fd on the error path is not an
option, since userspace might already got a reference to the file.

Instead anon_inode_getfd() needs to be broken into its individual steps.
The allocation of the file struct and file descriptor is done first, then
the copy_to_user() is executed and only if it succeeds the file is
installed.

Since the file struct is reference counted it can not be just freed, but
its reference needs to be dropped, which will also call the release()
callback, which will free the state attached to the file. So in this case
the normal error cleanup path should not be taken.

Cc: stable@vger.kernel.org
Fixes: d932cd49182f ("gpio: free handles in fringe cases")
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Linus Walleij