1. 24 7月, 2013 2 次提交
  2. 01 7月, 2013 2 次提交
  3. 29 6月, 2013 1 次提交
  4. 26 6月, 2013 2 次提交
  5. 25 6月, 2013 3 次提交
  6. 20 6月, 2013 1 次提交
  7. 19 6月, 2013 2 次提交
  8. 18 6月, 2013 11 次提交
    • P
      tty: Reset itty for other pty · 64e377dc
      Peter Hurley 提交于
      Commit 19ffd68f
      ('pty: Remove redundant itty reset') introduced a regression
      whereby the other pty's linkage is not cleared on teardown.
      This triggers a false positive diagnostic in testing.
      
      Properly reset the itty linkage.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Cc: stable <stable@vger.kernel.org> # 3.10
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      64e377dc
    • P
      n_tty: Buffer work should not reschedule itself · 7879a9f9
      Peter Hurley 提交于
      Although the driver-side input path must update the available
      buffer space, it should not reschedule itself. If space is still
      available and the flip buffers are not empty, flush_to_ldisc()
      will loop again.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7879a9f9
    • P
      n_tty: Fix unsafe update of available buffer space · b8483052
      Peter Hurley 提交于
      receive_room is used to control the amount of data the flip
      buffer work can push to the read buffer. This update is unsafe:
      
        CPU 0                        |  CPU 1
                                     |
                                     | n_tty_read()
                                     |   n_tty_set_room()
                                     |     left = <calc of space>
      n_tty_receive_buf()            |
        <push data to buffer>        |
        n_tty_set_room()             |
          left = <calc of space>     |
          tty->receive_room = left   |
                                     |     tty->receive_room = left
      
      receive_room is now updated with a stale calculation of the
      available buffer space, and the subsequent work loop will likely
      overwrite unread data in the input buffer.
      
      Update receive_room atomically with the calculation of the
      available buffer space.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8483052
    • P
      a6e54319
    • P
      n_tty: Encapsulate minimum_to_wake within N_TTY · f6c8dbe6
      Peter Hurley 提交于
      minimum_to_wake is unique to N_TTY processing, and belongs in
      per-ldisc data.
      
      Add the ldisc method, ldisc_ops::fasync(), to notify line disciplines
      when signal-driven I/O is enabled or disabled. When enabled for N_TTY
      (by fcntl(F_SETFL, O_ASYNC)), blocking reader/polls will be woken
      for any readable input. When disabled, blocking reader/polls are not
      woken until the read buffer is full.
      
      Canonical mode (L_ICANON(tty), n_tty_data::icanon) is not affected by
      the minimum_to_wake setting.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f6c8dbe6
    • T
      serial: omap: Fix device tree based PM runtime · a630fbfb
      Tony Lindgren 提交于
      In the runtime_suspend function pdata is not being used, and
      also blocks the function in device tree based booting. Fix it
      by removing the unused pdata from the runtime_suspend function.
      
      Further, context loss count is not being passed in pdata, so
      let's just reinitialize the port every time for those case.
      This can be further optimized later on for the device tree
      case by adding detection for the hardware state and possibly
      by adding a driver specific autosuspend timeout.
      
      And doing this, we can then make the related dev_err into a
      dev_dbg message instead of an error.
      
      In order for the wake-up events to work, we also need to set
      autosuspend_timeout to -1 if 0, and also device_init_wakeup()
      as that's not being done by the platform init code for the
      device tree case.
      
      Note that this does not affect legacy booting, and in fact
      might make it work for the cases where the context loss info
      is not being passed in pdata.
      
      Thanks to Kevin Hilman <khilman@linaro.org> for debugging
      and suggesting fixes for the autosuspend_timeout and
      device_init_wakeup() related initializiation.
      Reviewed-by: NKevin Hilman <khilman@linaro.org>
      Tested-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a630fbfb
    • F
      serial: imx: Fix serial clock unbalance · 80c48497
      Fabio Estevam 提交于
      Since commit 0c375501 (serial: imx: enable the clocks for console), the
      imx_startup() function calls clk_prepare_enable conditionally, so we
      need to call clk_disable_unprepare inside imx_shutdown() under the same
      condition to avoid unbalanced clock calls.
      
      This avoids the following warning:
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 70 at drivers/clk/clk.c:780 __clk_disable+0x68/0x84()
      Modules linked in:
      CPU: 0 PID: 70 Comm: mountall Not tainted 3.10.0-rc4-next-20130607+ #435
      Backtrace:
      [<800116a4>] (dump_backtrace+0x0/0x10c) from [<80011844>] (show_stack+0x18/0x1c)
       r6:8069f4e8 r5:0000030c r4:00000000 r3:00000000
      [<8001182c>] (show_stack+0x0/0x1c) from [<8053bce0>] (dump_stack+0x78/0x94)
      [<8053bc68>] (dump_stack+0x0/0x94) from [<80023df8>] (warn_slowpath_common+0x6c/0x8c)
       r4:00000000 r3:00000000
      [<80023d8c>] (warn_slowpath_common+0x0/0x8c) from [<80023e3c>] (warn_slowpath_null+0x24/0x2c)
       r8:bf2ed008 r7:bfaa9810 r6:000f0013 r5:bf824b80 r4:bf824b80
      [<80023e18>] (warn_slowpath_null+0x0/0x2c) from [<8041af84>] (__clk_disable+0x68/0x84)
      [<8041af1c>] (__clk_disable+0x0/0x84) from [<8041b098>] (clk_disable+0x20/0x2c)
       r4:600f0013 r3:00000001
      [<8041b078>] (clk_disable+0x0/0x2c) from [<802c93e8>] (imx_shutdown+0xbc/0xec)
       r5:bf824b80 r4:bfaa9810
      [<802c932c>] (imx_shutdown+0x0/0xec) from [<802c63a0>] (uart_port_shutdown+0x34/0x40)
       r5:bf86f860 r4:bfaa9810
      [<802c636c>] (uart_port_shutdown+0x0/0x40) from [<802c68c0>] (uart_shutdown+0x98/0xc4)
       r4:bf86f800 r3:00000000
      [<802c6828>] (uart_shutdown+0x0/0xc4) from [<802c7514>] (uart_close+0x5c/0x198)
       r7:bfaa9810 r6:bf274400 r5:bf86f86c r4:bf86f800
      [<802c74b8>] (uart_close+0x0/0x198) from [<802ac648>] (tty_release+0xf8/0x500)
      [<802ac550>] (tty_release+0x0/0x500) from [<800c5a30>] (__fput+0x9c/0x208)
      [<800c5994>] (__fput+0x0/0x208) from [<800c5bac>] (____fput+0x10/0x14)
      [<800c5b9c>] (____fput+0x0/0x14) from [<80040234>] (task_work_run+0xb4/0xec)
      [<80040180>] (task_work_run+0x0/0xec) from [<80029238>] (do_exit+0x2b0/0x920)
       r8:8000e144 r7:000000f8 r6:bf306300 r5:00000000 r4:bfac1180
      [<80028f88>] (do_exit+0x0/0x920) from [<80029a4c>] (do_group_exit+0x50/0xd4)
       r7:000000f8
      [<800299fc>] (do_group_exit+0x0/0xd4) from [<80029ae8>] (__wake_up_parent+0x0/0x28)
       r7:000000f8 r6:00000001 r5:0006f7ae r4:0006f79a
      [<80029ad0>] (SyS_exit_group+0x0/0x18) from [<8000dfc0>] (ret_fast_syscall+0x0/0x30)
      ---[ end trace 16d080eb7efea4e9 ]---
      Reported-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Tested-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80c48497
    • M
      serial/mpc52xx_uart: fix kernel panic when system reboot · 8a29dfb8
      Matteo Facchinetti 提交于
      This bug appear when a second PSC based driver appends an interrupt
      routine to the FIFO controller shared interrupt (like spi-mpc512x-psc).
      When reboot, uart_shutdown() remove the serial console interrupt handler
      while spi-mpc512x-psc isr is still activate and cause the following kernel
      panic:
      
      The system is going down for reboot NOW!rpc (ttyPSC0) (Mon Jun 10 12:26:07 20
      INIT: Sending processirq 40: nobody cared (try booting with the "irqpoll" option)
      CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-rc4-next-20130607-00001-ga0bceb3-dirty #5
      Call Trace:
      [cfff9f00] [c0007910] show_stack+0x48/0x150 (unreliable)
      [cfff9f40] [c005ae60] __report_bad_irq.isra.6+0x34/0xe0
      [cfff9f60] [c005b194] note_interrupt+0x214/0x26c
      [cfff9f90] [c00590fc] handle_irq_event_percpu+0xd0/0x1bc
      [cfff9fd0] [c005921c] handle_irq_event+0x34/0x54
      [cfff9fe0] [c005b8f4] handle_level_irq+0x90/0xf4
      [cfff9ff0] [c000cb98] call_handle_irq+0x18/0x28
      [c050dd60] [c000575c] do_IRQ+0xcc/0x124
      [c050dd90] [c000eb04] ret_from_except+0x0/0x14
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a29dfb8
    • F
      serial: mfd: Add sysrq support · fcd2bb9b
      Feng Tang 提交于
      When using MFD HSU based console, sometime we need the sysrq function
      to help debugging kernel. The sysrq code is basically there, this
      patch just simply enable it.
      Signed-off-by: NFeng Tang <feng.tang@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcd2bb9b
    • P
      tty: Fix transient pty write() EIO · 7c61c3d8
      Peter Hurley 提交于
      Commit 69939035
      ('pty: Ignore slave pty close() if never successfully opened')
      introduced a bug with ptys whereby a write() in parallel with an
      open() on an existing pty could mistakenly indicate an I/O error.
      
      Only indicate an I/O error if the condition on open() actually exists.
      Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Tested-by: NMikael Pettersson <mikpe@it.uu.se>
      Cc: stable <stable@vger.kernel.org> # 3.9
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c61c3d8
    • R
      tty/vt: Return EBUSY if deallocating VT1 and it is busy · ef223fb3
      Ross Lagerwall 提交于
      Commit 421b40a6 ("tty/vt: Fix vc_deallocate() lock order") changed
      the behavior when deallocating VT 1.  Previously if trying to
      deallocate VT1 and it is busy, we would return EBUSY.  The commit
      changed this to return 0 (success).
      
      This commit restores the old behavior.
      Signed-off-by: NRoss Lagerwall <rosslagerwall@gmail.com>
      Tested-by: NMikael Pettersson <mikpe@it.uu.se>
      Acked-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef223fb3
  9. 17 6月, 2013 1 次提交
  10. 16 6月, 2013 1 次提交
  11. 09 6月, 2013 2 次提交
  12. 07 6月, 2013 8 次提交
  13. 04 6月, 2013 4 次提交