Before the incrementing of ptr in skip_change_remote_baud,
it points to cur_action, but the increment is done by
the size of nxt_action instead. This could cause ptr
to not point to a bts_action structure, which is
harmful for the increment of ptr done in download_firmware.
Therefore, the skipping is first done for cur_action.
Signed-off-by: NShahar Lev <shahar@wizery.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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-gcaebc160-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: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

st_drv uses skb*() interfaces, so it should depend on NET.
It also uses GPIO interfaces, so it should depend on GPIOLIB.

st_kim.c uses syss_*() calls, so it should #include
<linux/sysfs.h>.

Fixes these observed build errors:
ERROR: "skb_queue_purge" [drivers/misc/ti-st/st_drv.ko] undefined!
ERROR: "skb_pull" [drivers/misc/ti-st/st_drv.ko] undefined!
ERROR: "skb_queue_tail" [drivers/misc/ti-st/st_drv.ko] undefined!
ERROR: "__alloc_skb" [drivers/misc/ti-st/st_drv.ko] undefined!
ERROR: "kfree_skb" [drivers/misc/ti-st/st_drv.ko] undefined!
ERROR: "skb_dequeue" [drivers/misc/ti-st/st_drv.ko] undefined!
ERROR: "skb_put" [drivers/misc/ti-st/st_drv.ko] undefined!
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

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: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The communication between ST KIM and UIM was interfaced
over the /dev/rfkill device node.
Move the interface to a simpler less abusive sysfs entry
mechanism and document it in Documentation/ABI/testing/
under sysfs-platform-kim.

Shared transport driver would now read the UART details
originally received by bootloader or firmware as platform
data.
The data read will be shared over sysfs entries for the user-space
UIM or other n/w manager/plugins to be read, and assist the driver
by opening up the UART, setting the baud-rate and installing the
line discipline.
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Move the header to a standard linux device driver location.
This should pave the way for other drivers to be moved into the relevant
directories.

ti_wilink_st.h is a common header file used by the TI's shared transport device
driver for WiLink chipsets. Each individual protocol drivers like bluetooth
driver, FM V4L2 driver and GPS drivers will make use of this header.
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In order to support multiple ST platform devices, a new symbol
'st_get_plat_device' earlier needed to be exported by the arch/XX/brd-XX.c
file which intends to add the ST platform device.

On removing this dependency, now inside ST driver maintain the array of
ST platform devices that would be registered.
As of now let id=0, as and when we end up having such platforms
where mutliple ST devices can exist, id would come from
protocol drivers (BT, FM and GPS) as to on which platform device
they want to register to.
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Anca Emanuel <anca.emanuel@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

move all the header information to ti_wilink_st.h.
This header would then not only serve the local modules like the st_core.c,
st_kim.c and st_ll.c but also the external modules/protocol drivers that are
dependent on the shared transport driver.
Modify the source files to include the new header ti_wilink_st.h,
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Platform devices tend to have id as -1 when only 1 device exist and
a value >=0 when multiple devices exist, since we plan to store all
these platform devices if multiple exist, there was a requirement to
have id to be >=0.
The patch fixes this problem.
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In order to support multiple ST platform devices, a new symbol
'st_get_plat_device' earlier needed to be exported by the arch/XX/brd-XX.c
file which intends to add the ST platform device.

On removing this dependency, now inside ST driver maintain the array of
ST platform devices that would be registered.
As of now let id=0, as and when we end up having such platforms
where mutliple ST devices can exist, id would come from
protocol drivers (BT, FM and GPS) as to on which platform device
they want to register to.
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When the chip is in use, information like the chip's ROM version and the
protocols currently making use of the chip needs to be made known to
user-space.
Earlier the version and the protocol-list were exposed as sysfs entries
now cleanup by making them as debugfs entries, also in process remove
any unwanted/previously unused sysfs entries.
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

cleanup the code commenting in the headers/structures,
also cleanup few inline commenting in the function
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Replace looping on the data buffers and printk-ing by
print_hex_dump.
Also replace most of the pr_info by pr_debug to reduce logging at
default loglevels (7 in our case..)
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

remove custom error code definitions from the header and
make use of the agreed upon linux error codes.
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Providing a context which can be passed around the driver, the KIM's platform
driver's struct device to be used to dev_set_drvdata and dev_get_drvdata.
The ST core's data is passed around using tty's disc_data and in other
cases the ST KIM's platform device is exposed from the board-XX.c which
adds KIM platform device whose dev is used.

Thereby remove the need for the global reference struct kim_data_s *kim_gdata;
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add version information to be available under the sysfs group
for kim.
Signed-off-by: NNaveen Jain <naveen_jain@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Remove the older way of communicating with user-space
daemon UIM.
The older way involved creating of a new kobj and pid
sysfs file under it, and sending signal using that pid.

Now we communicate via rfkill to user-space UIM.

Background: UIM is the user-space daemon which upon
notification from ldisc driver, opens the tty, sets
default baud and then installs (tiocsetd) the ldisc.
Signed-off-by: NNaveen Jain <naveen_jain@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Kernel Space Init-Manager works along with User-Mode
Init Manager daemon running to maintain the UART state.

Communication between user-space daemon and this module can be
	1. Via the pid written onto sysfs entry
	2. Via the rfkill subsystem

It also is a platform driver with a relevant platform device
in the board-*.c along with the list of BT/FM/GPS chip enable
gpio configuration
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>