linux-toradex.git/drivers/misc/ti-st, branch v4.5 Linux kernel for Apalis and Colibri modules ti-st: use worker instead of calling st_int_write in wake up 2015-09-21T05:52:13+00:00 Muhammad Hamza Farooq mfarooq@visteon.com 2015-09-11T14:42:38+00:00 b05b7c7cc0324524dcda7fa7c2be1255290ee416 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 <mfarooq@visteon.com> Signed-off-by: Jacob Siverskog <jacob@teenage.engineering> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <mfarooq@visteon.com>
Signed-off-by: Jacob Siverskog <jacob@teenage.engineering>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ti-st: st_kim: use gpio_set_value_cansleep to fix warning 2015-08-05T20:24:36+00:00 Jürg Billeter j@bitron.ch 2015-06-24T10:24:06+00:00 513da46d4b72bf6c4c956c57044fcbcfe321deeb GPIO accessor functions may sleep. Signed-off-by: Jürg Billeter <j@bitron.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
GPIO accessor functions may sleep.

Signed-off-by: Jürg Billeter <j@bitron.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "ti-st: add device tree support" 2015-08-05T20:24:12+00:00 Rob Herring robh@kernel.org 2015-07-22T18:17:15+00:00 c0bd1b9e58959c51a4c939505f89721dfbc73c44 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 <gigi.joseph@ti.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <gigi.joseph@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
misc: Drop owner assignment from i2c_driver 2015-07-27T17:30:48+00:00 Krzysztof Kozlowski k.kozlowski@samsung.com 2015-07-10T06:23:17+00:00 14e51e599db0b5bd7d2fc11f144b68c38aa9d0c9 i2c_driver does not need to set an owner because i2c_register_driver() will set it. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ti-st: handle null allocation return correctly. 2015-05-24T19:16:47+00:00 Colin Ian King colin.king@canonical.com 2015-05-12T21:37:23+00:00 0810f18fce92afc827d5c7c1d4f146b72b8052d6 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 <colin.king@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <colin.king@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ti-st: clean up data types (fix harmless memory corruption) 2015-02-03T23:48:51+00:00 Dan Carpenter dan.carpenter@oracle.com 2015-01-15T11:42:27+00:00 63e144c9d6ffa791c1402f4ee4551c1b9f5a336a 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 <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
misc: ti-st: add handling of the signal case 2015-01-25T17:18:00+00:00 Nicholas Mc Guire der.herr@hofr.at 2015-01-20T05:27:45+00:00 3f46d81ae1cf8f20f25c39ae1ab3f1b064698361 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 <der.herr@hofr.at> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <der.herr@hofr.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers:misc:ti-st: protect against bad packets 2015-01-12T13:04:11+00:00 Gigi Joseph gigi.joseph@gmail.com 2015-01-09T03:49:03+00:00 0ec0cf19201da36af858a6bc052a13e88866f341 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 <amira@ti.com> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com> Signed-off-by: Leonid Iziumtsev <x0153368@ti.com> Signed-off-by: Gigi Joseph <gigi.joseph@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <amira@ti.com>
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Leonid Iziumtsev <x0153368@ti.com>
Signed-off-by: Gigi Joseph <gigi.joseph@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers: misc: ti-st: fix null pointer exception in st_kim_ref() 2015-01-12T13:04:11+00:00 Gigi Joseph gigi.joseph@gmail.com 2015-01-09T03:48:29+00:00 868eba8e13d592f2eb9774777c9f3d9286482154 st_kim_ref() does not take care of the fact that platform_get_drvdata() might return NULL. On AM437x EVM, this causes the platform to stop booting as soon as the module is inserted. This patch fixes the issue by checking for NULL return value. Oops log follows. I have not tested BT functionality after this patch. But at least the platform boots now. [ 12.675697] Unable to handle kernel NULL pointer dereference at virtual address 0000005c [ 12.684310] pgd = c0004000 [ 12.687157] [0000005c] *pgd=00000000 [ 12.690927] Internal error: Oops: 17 [#1] SMP ARM [ 12.695873] Modules linked in: btwilink bluetooth ti_vpfe dwc3(+) ov2659 videobuf2_core v4l2_common videodev ti_am335x_adc 6lowpan_iphc matrix_keypad panel_dpi kfifo_buf pixcir_i2c_ts media industrialio videobuf2_dma_contig c_can_platform videobuf2_memops dwc3_omap c_can can_dev [ 12.721969] CPU: 0 PID: 1235 Comm: kworker/u3:0 Not tainted 3.14.25-02445-g9036ac6daed6 #128 [ 12.730937] Workqueue: hci0 hci_power_on [bluetooth] [ 12.736165] task: ebd93b40 ti: ecd7c000 task.ti: ecd7c000 [ 12.741856] PC is at st_kim_ref+0x30/0x40 [ 12.746071] LR is at st_kim_ref+0x30/0x40 [ 12.750289] pc : [<c03caf58>] lr : [<c03caf58>] psr: a0000013 [ 12.750289] sp : ecd7de08 ip : ecd7de08 fp : ecd7de1c [ 12.762365] r10: bf1e710c r9 : bf1e70ec r8 : bf1e7964 [ 12.767858] r7 : ebd2fd50 r6 : bf1e7964 r5 : 00000000 r4 : ecd7de24 [ 12.774723] r3 : c0957208 r2 : 00000000 r1 : c0957208 r0 : 00000000 [ 12.781589] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 12.789274] Control: 10c5387d Table: abde4059 DAC: 00000015 [ 12.795315] Process kworker/u3:0 (pid: 1235, stack limit = 0xecd7c248) Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Gigi Joseph <gigi.joseph@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
st_kim_ref() does not take care of the fact that platform_get_drvdata() might return NULL. On AM437x EVM, this causes the platform to stop booting as soon as the module is inserted.

This patch fixes the issue by checking for NULL return value. Oops log follows.

I have not tested BT functionality after this patch. But at least the platform boots now.

[   12.675697] Unable to handle kernel NULL pointer dereference at virtual address 0000005c
[   12.684310] pgd = c0004000
[   12.687157] [0000005c] *pgd=00000000
[   12.690927] Internal error: Oops: 17 [#1] SMP ARM
[   12.695873] Modules linked in: btwilink bluetooth ti_vpfe dwc3(+) ov2659 videobuf2_core v4l2_common videodev ti_am335x_adc 6lowpan_iphc matrix_keypad panel_dpi kfifo_buf pixcir_i2c_ts media industrialio videobuf2_dma_contig c_can_platform videobuf2_memops dwc3_omap c_can can_dev
[   12.721969] CPU: 0 PID: 1235 Comm: kworker/u3:0 Not tainted 3.14.25-02445-g9036ac6daed6 #128
[   12.730937] Workqueue: hci0 hci_power_on [bluetooth]
[   12.736165] task: ebd93b40 ti: ecd7c000 task.ti: ecd7c000
[   12.741856] PC is at st_kim_ref+0x30/0x40
[   12.746071] LR is at st_kim_ref+0x30/0x40
[   12.750289] pc : [<c03caf58>]    lr : [<c03caf58>]    psr: a0000013
[   12.750289] sp : ecd7de08  ip : ecd7de08  fp : ecd7de1c
[   12.762365] r10: bf1e710c  r9 : bf1e70ec  r8 : bf1e7964
[   12.767858] r7 : ebd2fd50  r6 : bf1e7964  r5 : 00000000  r4 : ecd7de24
[   12.774723] r3 : c0957208  r2 : 00000000  r1 : c0957208  r0 : 00000000
[   12.781589] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   12.789274] Control: 10c5387d  Table: abde4059  DAC: 00000015
[   12.795315] Process kworker/u3:0 (pid: 1235, stack limit = 0xecd7c248)

Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Gigi Joseph <gigi.joseph@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers: misc: ti-st: fix debugfs creation error handling 2015-01-12T13:04:11+00:00 Gigi Joseph gigi.joseph@gmail.com 2015-01-09T03:47:51+00:00 c6ec0fb4006d1d8110b3166f2cc2b04b8002d210 In case the debugfs creation fails the whole init process was failing. There is no need to do this as the shared transport can work without it. Fix it so it just reports the failure and continue. Signed-off-by: Eyal Reizer <eyalr@ti.com> Signed-off-by: Gigi Joseph <gigi.joseph@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
In case the debugfs creation fails the whole init process was failing.
There is no need to do this as the shared transport can work without it.
Fix it so it just reports the failure and continue.

Signed-off-by: Eyal Reizer <eyalr@ti.com>
Signed-off-by: Gigi Joseph <gigi.joseph@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>