- 08 6月, 2011 1 次提交
-
-
由 Steven Rostedt 提交于
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>
-
- 04 6月, 2011 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit b1c43f82. 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 a5660b41: "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 a5660b41. Milton Miller pointed out the 'unsigned int' issue. Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Reported-by: NMilton 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: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 4月, 2011 2 次提交
-
-
由 Felipe Balbi 提交于
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: NStefan Bigler <stefan.bigler@keymile.com> Tested-by: NToby Gray <toby.gray@realvnc.com> Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Pavan Savoy 提交于
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: NPavan Savoy <pavan_savoy@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 10 3月, 2011 1 次提交
-
-
由 Pavan Savoy 提交于
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: NPavan Savoy <pavan_savoy@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 05 2月, 2011 6 次提交
-
-
由 Pavan Savoy 提交于
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>
-
由 Pavan Savoy 提交于
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: NPavan Savoy <pavan_savoy@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Pavan Savoy 提交于
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>
-
由 Pavan Savoy 提交于
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: NPavan Savoy <pavan_savoy@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Pavan Savoy 提交于
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>
-
由 Pavan Savoy 提交于
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>
-
- 15 10月, 2010 1 次提交
-
-
由 Pavan Savoy 提交于
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>
-
- 06 10月, 2010 2 次提交
-
-
由 Pavan Savoy 提交于
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>
-
由 Pavan Savoy 提交于
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>
-
- 25 9月, 2010 1 次提交
-
-
由 Pavan Savoy 提交于
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>
-
- 21 9月, 2010 1 次提交
-
-
由 Pavan Savoy 提交于
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>
-
- 01 9月, 2010 2 次提交
-
-
由 Pavan Savoy 提交于
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>
-
由 Dan Carpenter 提交于
In the original source it would write past the end of the array before returning the error code. Signed-off-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 28 7月, 2010 1 次提交
-
-
由 Pavan Savoy 提交于
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>
-
- 23 7月, 2010 4 次提交
-
-
由 Pavan Savoy 提交于
protocol drivers such as BT, FM and GPS when registering to ST now provide their own private data which they expect when their functions namely registration completed & receive are called. Also upon tty_close, set protos_registered count to 0, although all protocols are marked un-registered. Signed-off-by: NPavan Savoy <pavan_savoy@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Pavan Savoy 提交于
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>
-
由 Pavan Savoy 提交于
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>
-
由 Pavan Savoy 提交于
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>
-
- 09 7月, 2010 1 次提交
-
-
由 Pavan Savoy 提交于
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>
-
- 19 6月, 2010 1 次提交
-
-
由 Naveen Jain 提交于
Older mechanism of counting the number of protocols registered with ST was slow, in-efficient. It used to check the protocol data for NULL for each registration/unregistration. With this change, counting protocols in maintained by a single counter protos_registered. Counting protocols is not just for debug purposes Signed-off-by: NNaveen Jain <naveen_jain@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 12 5月, 2010 1 次提交
-
-
由 Pavan Savoy 提交于
Texas Instruments BT, FM and GPS combo chips/drivers make use of a single TTY to communicate with the chip. This module constitutes the core logic, TTY ldisc driver and the exported symbols for registering/unregistering of the protocol drivers such as BT/FM/GPS. Signed-off-by: NPavan Savoy <pavan_savoy@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-