1. 08 6月, 2011 1 次提交
    • S
      st_kim: Handle case of no device found for ID 0 · 7316a9f2
      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>
      7316a9f2
  2. 04 6月, 2011 1 次提交
    • L
      Revert "tty: make receive_buf() return the amout of bytes received" · 55db4c64
      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>
      55db4c64
  3. 23 4月, 2011 2 次提交
  4. 10 3月, 2011 1 次提交
  5. 05 2月, 2011 6 次提交
  6. 15 10月, 2010 1 次提交
  7. 06 10月, 2010 2 次提交
    • P
      staging: ti-st: move TI_ST from staging to misc/ · a0cc2f3b
      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>
      a0cc2f3b
    • P
      staging: ti-st: mv ti_wilink_st header · e5558679
      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>
      e5558679
  8. 25 9月, 2010 1 次提交
    • P
      Staging: ti-st: remove st_get_plat_device · d3654cd2
      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>
      d3654cd2
  9. 21 9月, 2010 1 次提交
  10. 01 9月, 2010 2 次提交
  11. 28 7月, 2010 1 次提交
  12. 23 7月, 2010 4 次提交
  13. 09 7月, 2010 1 次提交
    • P
      Staging: ti-st: remove global references · 38d9df49
      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>
      38d9df49
  14. 19 6月, 2010 1 次提交
  15. 12 5月, 2010 1 次提交