Commit Graph

17 Commits

Author SHA1 Message Date
Pavan Savoy
651d62a8b0 drivers:misc: ti-st: fix unexpected UART close
If suppose the UIM were to die and hence UART were to close when the
Bluetooth/FM or GPS is turned on, prep the ST for a state where-in if
the UIM comes back up, Bluetooth/FM/GPS can be turned on.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-22 14:13:35 -07:00
Vijay Badawadagi
78bb9697e2 drivers:misc: ti-st: fail-safe on wrong pkt type
Texas Instrument's shared transport driver interpret incoming data from the
UART based on the various protocol drivers registered to the driver such as
btwilink driver or FM or GPS driver which provide logical channel IDs.

In case of bad-behavior from chip such as HCI Event response for a GPS command
or a HCI Event (h/w error event) for a FM response & In case of bad-behavior
from UART driver such as dropping data bytes a fail-safe is required to avoid
kernel panic.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Vijay Badawadagi <bvijay@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-22 14:13:33 -07:00
Pavan Savoy
5926cef26c drivers:misc: ti-st: avoid a misleading dbg msg
Previously the private data of each protocol registered to use ST was
used to determine whether the protocol was registered to use shared
transport or otherwise.
However, now a flag is_registered is maintained to identify whether a
protocol intends to use ST.
Upon closing of the UART the error message relevant to this lack of
un-registration was misleading and this patch fixes that.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-22 14:13:31 -07:00
Steven Rostedt
7316a9f2a9 st_kim: Handle case of no device found for ID 0
Running ktest.pl, I hit this bug:

[   19.780654] BUG: unable to handle kernel NULL pointer dereference at 0000000c
[   19.780660] IP: [<c112efcd>] dev_get_drvdata+0xc/0x46
[   19.780669] *pdpt = 0000000031daf001 *pde = 0000000000000000
[   19.780673] Oops: 0000 [#1] SMP
[   19.780680] Dumping ftrace buffer:^M
[   19.780685]    (ftrace buffer empty)
[   19.780687] Modules linked in: ide_pci_generic firewire_ohci firewire_core evbug crc_itu_t e1000 ide_core i2c_i801 iTCO_wdt
[   19.780697]
[   19.780700] Pid: 346, comm: v4l_id Not tainted 2.6.39-test-02740-gcaebc16-dirty #4                  /DG965MQ
[   19.780706] EIP: 0060:[<c112efcd>] EFLAGS: 00010202 CPU: 0
[   19.780709] EIP is at dev_get_drvdata+0xc/0x46
[   19.780712] EAX: 00000008 EBX: f1e37da4 ECX: 00000000 EDX: 00000000
[   19.780715] ESI: f1c3f200 EDI: c33ec95c EBP: f1e37d80 ESP: f1e37d80
[   19.780718]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   19.780721] Process v4l_id (pid: 346, ti=f1e36000 task=f2bc2a60 task.ti=f1e36000)
[   19.780723] Stack:
[   19.780725]  f1e37d8c c117d395 c33ec93c f1e37db4 c117a0f9 00000002 00000000 c1725e54
[   19.780732]  00000001 00000007 f2918c90 f1c3f200 c33ec95c f1e37dd4 c1789d3d 22222222
[   19.780740]  22222222 22222222 f2918c90 f1c3f200 f29194f4 f1e37de8 c178d5c4 c1725e54
[   19.780747] Call Trace:
[   19.780752]  [<c117d395>] st_kim_ref+0x28/0x41
[   19.780756]  [<c117a0f9>] st_register+0x29/0x562
[   19.780761]  [<c1725e54>] ? v4l2_open+0x111/0x1e3
[   19.780766]  [<c1789d3d>] fmc_prepare+0x97/0x424
[   19.780770]  [<c178d5c4>] fm_v4l2_fops_open+0x70/0x106
[   19.780773]  [<c1725e54>] ? v4l2_open+0x111/0x1e3
[   19.780777]  [<c1725e9b>] v4l2_open+0x158/0x1e3
[   19.780782]  [<c065173b>] chrdev_open+0x22c/0x276
[   19.780787]  [<c0647c4e>] __dentry_open+0x35c/0x581
[   19.780792]  [<c06498f9>] nameidata_to_filp+0x7c/0x96
[   19.780795]  [<c065150f>] ? cdev_put+0x57/0x57
[   19.780800]  [<c0660cad>] do_last+0x743/0x9d4
[   19.780804]  [<c065d5fc>] ? path_init+0x1ee/0x596
[   19.780808]  [<c0661481>] path_openat+0x10c/0x597
[   19.780813]  [<c05204a1>] ? trace_hardirqs_off+0x27/0x37
[   19.780817]  [<c0509651>] ? local_clock+0x78/0xc7
[   19.780821]  [<c0661945>] do_filp_open+0x39/0xc2
[   19.780827]  [<c1cabc76>] ? _raw_spin_unlock+0x4c/0x5d^M
[   19.780831]  [<c0674ccd>] ? alloc_fd+0x19e/0x1b7
[   19.780836]  [<c06499ca>] do_sys_open+0xb7/0x1bd
[   19.780840]  [<c0608eea>] ? sys_munmap+0x78/0x8d
[   19.780844]  [<c0649b06>] sys_open+0x36/0x58
[   19.780849]  [<c1cb809f>] sysenter_do_call+0x12/0x38
[   19.780852] Code: d8 2f 20 c3 01 83 15 dc 2f 20 c3 00 f0 ff 00 83 05 e0 2f 20 c3 01 83 15 e4 2f 20 c3 00 5d c3 55 89 e5 3e 8d 74 26 00 85 c0 74 28 <8b> 40 04 83 05 e8 2f 20 c3 01 83 15 ec 2f 20 c3 00 85 c0 74 13 ^M
[   19.780889] EIP: [<c112efcd>] dev_get_drvdata+0xc/0x46 SS:ESP 0068:f1e37d80
[   19.780894] CR2: 000000000000000c
[   19.780898] ---[ end trace e7d1d0f6a2d1d390 ]---

The id of 0 passed to st_kim_ref() found no device, keeping pdev null,
and causing pdev->dev cause a NULL pointer dereference. After having
st_kim_ref() check for NULL, the st_unregister() function needed to be
updated to handle the case that st_gdata was not set by the
st_kim_ref().

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-06-07 10:01:16 -07:00
Linus Torvalds
55db4c64ed Revert "tty: make receive_buf() return the amout of bytes received"
This reverts commit b1c43f82c5.

It was broken in so many ways, and results in random odd pty issues.

It re-introduced the buggy schedule_work() in flush_to_ldisc() that can
cause endless work-loops (see commit a5660b41af: "tty: fix endless
work loop when the buffer fills up").

It also used an "unsigned int" return value fo the ->receive_buf()
function, but then made multiple functions return a negative error code,
and didn't actually check for the error in the caller.

And it didn't actually work at all.  BenH bisected down odd tty behavior
to it:
  "It looks like the patch is causing some major malfunctions of the X
   server for me, possibly related to PTYs.  For example, cat'ing a
   large file in a gnome terminal hangs the kernel for -minutes- in a
   loop of what looks like flush_to_ldisc/workqueue code, (some ftrace
   data in the quoted bits further down).

   ...

   Some more data: It -looks- like what happens is that the
   flush_to_ldisc work queue entry constantly re-queues itself (because
   the PTY is full ?) and the workqueue thread will basically loop
   forver calling it without ever scheduling, thus starving the consumer
   process that could have emptied the PTY."

which is pretty much exactly the problem we fixed in a5660b41af.

Milton Miller pointed out the 'unsigned int' issue.

Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reported-by: Milton Miller <miltonm@bga.com>
Cc: Stefan Bigler <stefan.bigler@keymile.com>
Cc: Toby Gray <toby.gray@realvnc.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-06-04 06:33:24 +09:00
Linus Torvalds
99dff58562 Merge branch 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6
* 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6: (48 commits)
  serial: 8250_pci: add support for Cronyx Omega PCI multiserial board.
  tty/serial: Fix break handling for PORT_TEGRA
  tty/serial: Add explicit PORT_TEGRA type
  n_tracerouter and n_tracesink ldisc additions.
  Intel PTI implementaiton of MIPI 1149.7.
  Kernel documentation for the PTI feature.
  export kernel call get_task_comm().
  tty: Remove to support serial for S5P6442
  pch_phub: Support new device ML7223
  8250_pci: Add support for the Digi/IBM PCIe 2-port Adapter
  ASoC: Update cx20442 for TTY API change
  pch_uart: Support new device ML7223 IOH
  parport: Use request_muxed_region for IT87 probe and lock
  tty/serial: add support for Xilinx PS UART
  n_gsm: Use print_hex_dump_bytes
  drivers/tty/moxa.c: Put correct tty value
  TTY: tty_io, annotate locking functions
  TTY: serial_core, remove superfluous set_task_state
  TTY: serial_core, remove invalid test
  Char: moxa, fix locking in moxa_write
  ...

Fix up trivial conflicts in drivers/bluetooth/hci_ldisc.c and
drivers/tty/serial/Makefile.

I did the hci_ldisc thing as an evil merge, cleaning things up.
2011-05-23 12:23:20 -07:00
Felipe Balbi
b1c43f82c5 tty: make receive_buf() return the amout of bytes received
it makes it simpler to keep track of the amount of
bytes received and simplifies how flush_to_ldisc counts
the remaining bytes. It also fixes a bug of lost bytes
on n_tty when flushing too many bytes via the USB
serial gadget driver.

Tested-by: Stefan Bigler <stefan.bigler@keymile.com>
Tested-by: Toby Gray <toby.gray@realvnc.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-22 17:31:53 -07:00
Pavan Savoy
764b0c4b32 drivers:misc:ti-st: handle delayed tty receive
When certain technologies shutdown their interface without waiting for
the acknowledgement from the chip. The receive_buf from the TTY would be
invoked a while after the relevant technology is unregistered.

This patch introduces a new flag "is_registered" which maintains the
state of protocols BT, FM or GPS and thereby removes the need to clear
the protocol data from ST when protocols gets unregistered.

This fixes corner cases when HCI RESET is sent down from bluetooth stack
and the receive_buf is called from tty after 250ms before which
bluetooth would have unregistered from the system.
OR - when FM application decides to close down the device without
sending a power-off FM command resulting in some RDS data or interrupt
data coming in after the driver is unregistered.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-04-22 17:01:09 -07:00
Pavan Savoy
c1605f2e33 drivers:misc: ti-st: fix debugging code
debug code in TI-ST driver can be enabled by #defining
DEBUG in the first line of the code and in case debugfs
is mounted, the 2 entries in /sys/kernel/debug/ti-st/ will
also provide useful information.
These 2 were broken because of the recent changes to the parsing
logic and the registration mechanism of the protocol drivers,
this patch fixes them.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-03-09 16:10:00 -08:00
Pavan Savoy
781a7395d2 drivers:misc: ti-st: remove multiple gpio handling
TI shared transport driver previously intended to expose rfkill
entries for each of the protocol gpio that the chip would have.
However now in case such gpios exist, which requires to be enabled
for a specific protocol, the responsibility lay on protocol driver.
This patch removes the request/free of multiple gpios, rfkill struct
references and also removes the chip_toggle function.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-04 12:41:21 -08:00
Pavan Savoy
6d71ba2105 drivers:misc: ti-st: fix hci-ll on wake_ind collision
Where file-transfer stops/pauses in between, is
result of a HCI-LL anamoly in ST LL driver.
ST LL did not copy the contents of WaitQ into the TxQ, when a WAKEUP_IND
collision happened.
Make also sure, that the copying mechanism is safe, by wrapping it around
spin locks inside st_int_recv().
This was easily reproduced when the sleep timeout was reduced to 100ms
for HCI-LL.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-04 12:41:21 -08:00
Pavan Savoy
ef04d121f0 drivers:misc: ti-st: firmware download optimization
To fasten the process of firmware download, the chip allows
disabling of the command complete event generation from host.
In these cases, only few very essential commands would have
the command complete events and hence the wait associated with
them.

So now the driver would wait for a command complete event, only
when it comes across a wait event during firmware parsing.
This would also mean we need to skip not just the change baud
rate command but also the wait for it.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-04 12:41:21 -08:00
Pavan Savoy
6710fcff66 drivers:misc: ti-st: set right debug levels for logs
pr_debug-ing few pr_infos from the data paths such as tty receive and
write so as to reduce debugs when we have higher logging levels enabled
undef VERBOSE in receive to avoid huge logs when log level 8 is set.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-04 12:41:21 -08:00
Pavan Savoy
704426649d drivers:misc: ti-st: fix error codes
set-right the error codes that the shared transport driver
returns.
Instead of magic numbers like -1, return relevant codes such as
ETIMEDOUT or EIO, EAGAIN when wait times out or uart write bytes don't
match expected value or when registration fails and needs to be
attempted again.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-04 12:41:20 -08:00
Pavan Savoy
5c88b02196 drivers:misc: ti-st: register with channel IDs
The architecture of shared transport had begun with individual
protocols like bluetooth, fm and gps telling the shared transport
what sort of protocol they are and then expecting the ST driver
to parse the incoming data from chip and forward data only
relevant to the protocol drivers.

This change would mean each protocol drivers would also send
information to ST driver as to how to intrepret their protocol
data coming out of the chip.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-04 12:41:20 -08:00
Pavan Savoy
73f12e8d3d drivers: misc: ti-st: fix review comments
Based on comments from Jiri Slaby, drop the register
storage specifier, remove the unused code, cleanup
the const to non-const type casting.
Also make the line discipline ops structure static, since
its a singleton, unmodified structure which need not be
in heap.

Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-10-14 12:41:10 -07:00
Pavan Savoy
a0cc2f3b51 staging: ti-st: move TI_ST from staging to misc/
move the 3 source files st_core.c, st_kim.c and st_ll.c
from staging to drivers/misc/.

Texas Instrument's WiLink 7 chipset packs wireless technologies like
Bluetooth, FM, GPS and WLAN into a single die.
Among these the Bluetooth, FM Rx/Tx and GPS are interfaced to a apps processor
over a single UART.

This line discipline driver allows various protocol drivers such as Bluetooth
BlueZ driver, FM V4L2 driver and GPS simple character device driver
to communicate with its relevant core in the chip.

Each protocol or technologies use a logical channel to communicate with chip.
Bluetooth uses the HCI-H4 [channels 1-4], FM uses a CH-8 and
GPS a CH-9 protocol. The driver also constitutes the TI HCI-LL Power
Management protocol which use channels 30-33.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-10-06 08:25:06 -07:00