linux-stable.git/drivers/staging, branch v3.18.52

staging: unisys: correctly handle return value from queue_delayed_work()

2017-05-08T05:44:12+00:00

commit f84bd6267d623b49f196d54ba9edc41ff1c4d5e3 upstream.

Properly handle the return value from queue_delayed_work() - it's a
bool, not an int, so using a less than comparison isn't appropriate.

This mistake was found by David Binderman .

[arnd: the fix is from 4.4 but needed some minor fixup to adapt
 to context changes]

Signed-off-by: Benjamin Romer 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Arnd Bergmann

staging: bcm: add 32-bit host dependency

2017-05-08T05:44:11+00:00

The driver uses a 32-bit variable to store a pointer, causing a couple of
warnings:

../drivers/staging/bcm/CmHost.c: In function 'StoreCmControlResponseMessage':
../drivers/staging/bcm/CmHost.c:1503:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
   (struct bcm_connect_mgr_params *) ntohl(
   ^
../drivers/staging/bcm/CmHost.c:1546:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
   (struct bcm_connect_mgr_params *) ntohl(
   ^
../drivers/staging/bcm/CmHost.c:1564:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
   (struct bcm_connect_mgr_params *) ntohl(

I fixed other warnings in an earlier commit 9f1c75ac2dba ("staging/bcm: fix most
build warnings"), but couldn't figure out what was the intended behavior on
64-bit machines here.

The driver was removed in linux-3.19, commit d09e9b160fc1 ("staging: bcm: remove
driver") which explains that it never worked on 64-bit machines. This adds
a Kconfig dependency instead to prevent it from being built in the known
broken configuration. This workaround applies to v2.6.37 or higher.

Fixes: f8942e07a3db ("staging: Beeceem USB Wimax driver")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

staging: imx-drm: fix indentation warning

2017-05-08T05:44:11+00:00

gcc-6 produces a harmless warning:

drivers/staging/imx-drm/imx-hdmi.c: In function 'hdmi_config_AVI':
drivers/staging/imx-drm/imx-hdmi.c:967:2: error: this 'else' clause does not guard... [-Werror=misleading-indentation]

Commit d083c312cba2 ("drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a little")
in linux-4.3 fixes this with a larger rewrite that is not applicable here.
After that rewrite, the variable that gets assigned here no longer exists.

The assignment is rather pointless here, as we just set a variable to zero
that is later added into another variable using a bitwise or operator, and
that has no effect, so I'm just changing the indentation here to shut up
the warning.

The driver was originally merged in linux-3.13, and the fix applies
to all versions between that and 4.2.

Fixes: 9aaf880ed4ee ("imx-drm: Add mx6 hdmi transmitter support")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

staging: vt6655: fix overly large stack usage

2017-05-08T05:44:11+00:00

We get a warning for the large stack usage in some configurations:

drivers/staging/vt6655/device_main.c: In function 'device_ioctl':
drivers/staging/vt6655/device_main.c:2974:1: warning: the frame size of 1304 bytes is larger than 1024 bytes [-Wframe-larger-than=]

This is addressed in linux-3.19 with commit 67013f2c0e58 ("staging: vt6655:
mac80211 conversion add main mac80211 functions"), which obsoletes the
device_ioctl() function, but as that does not apply to stable kernels,
this picks an easier way out by using dynamic allocation.

The driver was merged in 2.6.31, and the fix applies to all versions
before 3.19.

Fixes: 5449c685a4b3 ("Staging: Add pristine upstream vt6655 driver sources")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

staging/android/ion : fix a race condition in the ion driver

2017-04-30T03:49:17+00:00

commit 9590232bb4f4cc824f3425a6e1349afbe6d6d2b7 upstream.

There is a use-after-free problem in the ion driver.
This is caused by a race condition in the ion_ioctl()
function.

A handle has ref count of 1 and two tasks on different
cpus calls ION_IOC_FREE simultaneously.

cpu 0                                   cpu 1
-------------------------------------------------------
ion_handle_get_by_id()
(ref == 2)
                            ion_handle_get_by_id()
                            (ref == 3)

ion_free()
(ref == 2)

ion_handle_put()
(ref == 1)

                            ion_free()
                            (ref == 0 so ion_handle_destroy() is
                            called
                            and the handle is freed.)

                            ion_handle_put() is called and it
                            decreases the slub's next free pointer

The problem is detected as an unaligned access in the
spin lock functions since it uses load exclusive
 instruction. In some cases it corrupts the slub's
free pointer which causes a mis-aligned access to the
next free pointer.(kmalloc returns a pointer like
ffffc0745b4580aa). And it causes lots of other
hard-to-debug problems.

This symptom is caused since the first member in the
ion_handle structure is the reference count and the
ion driver decrements the reference after it has been
freed.

To fix this problem client->lock mutex is extended
to protect all the codes that uses the handle.

Signed-off-by: Eun Taik Lee 
Reviewed-by: Laura Abbott 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

index 7ff2a7ec871f..33b390e7ea31

staging: android: ashmem: lseek failed due to no FMODE_LSEEK.

2017-04-18T05:55:48+00:00

commit 97fbfef6bd597888485b653175fb846c6998b60c upstream.

vfs_llseek will check whether the file mode has
FMODE_LSEEK, no return failure. But ashmem can be
lseek, so add FMODE_LSEEK to ashmem file.

Comment From Greg Hackmann:
	ashmem_llseek() passes the llseek() call through to the backing
	shmem file.  91360b02ab48 ("ashmem: use vfs_llseek()") changed
	this from directly calling the file's llseek() op into a VFS
	layer call.  This also adds a check for the FMODE_LSEEK bit, so
	without that bit ashmem_llseek() now always fails with -ESPIPE.

Fixes: 91360b02ab48 ("ashmem: use vfs_llseek()")
Signed-off-by: Shuxiao Zhang 
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman

Revert "staging: nvec: ps2: change serio type to passthrough"

2017-04-18T05:55:47+00:00

commit 17c1c9ba15b238ef79b51cf40d855c05b58d5934 upstream.

This reverts commit 36b30d6138f4677514aca35ab76c20c1604baaad.

This is necessary to detect paz00 (ac100) touchpad properly as one
speaking ETPS/2 protocol. Without it X.org's synaptics driver doesn't
work as the touchpad is detected as an ImPS/2 mouse instead.

Commit ec6184b1c717b8768122e25fe6d312f609cc1bb4 changed the way
auto-detection is performed on ports marked as pass through and made the
issue apparent.

A pass through port is an additional PS/2 port used to connect a slave
device to a master device that is using PS/2 to communicate with the
host (so slave's PS/2 communication is tunneled over master's PS/2
link). "Synaptics PS/2 TouchPad Interfacing Guide" describes such a
setup (PS/2 PASS-THROUGH OPTION section).

Since paz00's embedded controller is not connected to a PS/2 port
itself, the PS/2 interface it exposes is not a pass-through one.

Signed-off-by: Paul Fertser 
Acked-by: Marc Dietrich 
Fixes: 36b30d6138f4 ("staging: nvec: ps2: change serio type to passthrough")
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

drivers: staging: nvec: remove bogus reset command for PS/2 interface

2017-04-18T05:55:47+00:00

commit d8f8a74d5fece355d2234e1731231d1aebc66b38 upstream.

This command was sent behind serio's back and the answer to it was
confusing atkbd probe function which lead to the elantech touchpad
getting detected as a keyboard.

To prevent this from happening just let every party do its part of the
job.

Signed-off-by: Paul Fertser 
Acked-by: Marc Dietrich 
Signed-off-by: Greg Kroah-Hartman

staging: iio: ad5933: avoid uninitialized variable in error case

2017-04-18T05:55:47+00:00

commit 34eee70a7b82b09dbda4cb453e0e21d460dae226 upstream.

The ad5933_i2c_read function returns an error code to indicate
whether it could read data or not. However ad5933_work() ignores
this return code and just accesses the data unconditionally,
which gets detected by gcc as a possible bug:

drivers/staging/iio/impedance-analyzer/ad5933.c: In function 'ad5933_work':
drivers/staging/iio/impedance-analyzer/ad5933.c:649:16: warning: 'status' may be used uninitialized in this function [-Wmaybe-uninitialized]

This adds minimal error handling so we only evaluate the
data if it was correctly read.

Link: https://patchwork.kernel.org/patch/8110281/
Signed-off-by: Arnd Bergmann 
Acked-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

ANDROID: binder: Clear binder and cookie when setting handle in flat binder struct

2017-04-18T05:55:45+00:00

commit 4afb604e2d14d429ac9e1fd84b952602853b2df5 upstream.

Prevents leaking pointers between processes

Signed-off-by: Arve Hjønnevåg 
Signed-off-by: Martijn Coenen 
Signed-off-by: Greg Kroah-Hartman