kernel/linux.git/drivers/misc/ti-st, branch v4.7.3

ti-st: Fix complete_all() wrong usage

2016-05-01T21:20:04+00:00

complete_all() should only be called once, doing it twice is a clear bug. 8565adbc8214 ("drivers/misc/ti-st: fix read fw version cmd") added the additional complete_all() call. Since we call complete_all() when leaving the function we can drop the complete_all() call inside true branch of the if statement. Signed-off-by: Daniel Wagner Cc: Pavan Savoy Cc: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

misc: st_core: remove unreachable code

2016-02-08T07:01:45+00:00

The pr_debug() will never be executed. Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

ti-st: use worker instead of calling st_int_write in wake up

2015-09-21T05:52:13+00:00

The wake up method is called with the port lock held. The st_int_write method calls port->ops->write with tries to acquire the lock again, causing CPU to wait infinitely. Right way to do is to write data to port in worker thread. Signed-off-by: Muhammad Hamza Farooq Signed-off-by: Jacob Siverskog Signed-off-by: Greg Kroah-Hartman

ti-st: st_kim: use gpio_set_value_cansleep to fix warning

2015-08-05T20:24:36+00:00

GPIO accessor functions may sleep. Signed-off-by: Jürg Billeter Signed-off-by: Greg Kroah-Hartman

Revert "ti-st: add device tree support"

2015-08-05T20:24:12+00:00

This reverts commit 46d0d33350e9b32642d745a8b46a954910196b4d. This binding is horrible and never should have been merged. It is not documented nor are there any in tree users, so reverting it will not break anything we care about. Lets revert it before we do have users. The problems with it are: - It is not documented. - The GPIO connection is described with a custom property and uses Linux GPIO numbering. - The UART connection is described using the Linux tty device name. Cc: Gigi Joseph Cc: Greg Kroah-Hartman Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

misc: Drop owner assignment from i2c_driver

2015-07-27T17:30:48+00:00

i2c_driver does not need to set an owner because i2c_register_driver() will set it. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman

ti-st: handle null allocation return correctly.

2015-05-24T19:16:47+00:00

static analysis with smatch picked up the following error: get_platform_data() error: potential null dereference 'dt_pdata'. (kzalloc returns null) Instead, the code should return NULL to avoid the following null pointer deference. Also, remove the error message as it is redundant, the caller emits an error message to alert of a failure anyhow. Signed-off-by: Colin Ian King Signed-off-by: Greg Kroah-Hartman

ti-st: clean up data types (fix harmless memory corruption)

2015-02-03T23:48:51+00:00

The big issue here is: of_property_read_u32(np, "flow_cntrl", (u32 *)&dt_pdata->flow_cntrl); "->flow_cntrl" is a char so when we write a 32 bit number to it then it corrupts past the end of the char. It's probably hard to notice because the struct has padding so the code works on little endian systems. But on a big endian system the code would fail and on a 64 bit, big endian systems then "nshutdown_gpio" and "baud_rate" would be buggy as well. Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman

misc: ti-st: add handling of the signal case

2015-01-25T17:18:00+00:00

if(!wait_for_completion_interruptible_timeout(...)) only handles the timeout case - this patch adds handling the signal case the same as timeout. Only the timeout case was being handled, the signal case (-ERESTARTSYS) was treated just like the case of successful completion, which is most likely not reasonable. read_local_version() is called from download_firmware() where it checks for !=0 return, so the error handling logic should be preserved correctly. download_firmware() is called from st_kim_start() which is checking for !=0 return, so the error handling logic should be preserved correctly Signed-off-by: Nicholas Mc Guire Signed-off-by: Greg Kroah-Hartman

drivers:misc:ti-st: protect against bad packets

2015-01-12T13:04:11+00:00

We encounter situations where we got bad packet type from the UART (probably due to platform problem or UART driver issues) which caused us out of boundary array access, which eventually led to kernel panic. Signed-off-by: Amir Ayun Signed-off-by: Pavan Savoy Signed-off-by: Leonid Iziumtsev Signed-off-by: Gigi Joseph Signed-off-by: Greg Kroah-Hartman