1. 06 9月, 2012 2 次提交
  2. 14 8月, 2012 1 次提交
    • J
      TTY: use tty_port_register_device · 734cc178
      Jiri Slaby 提交于
      Currently we have no way to assign tty->port while performing tty
      installation. There are two ways to provide the link tty_struct =>
      tty_port. Either by calling tty_port_install from tty->ops->install or
      tty_port_register_device called instead of tty_register_device when
      the device is being set up after connected.
      
      In this patch we modify most of the drivers to do the latter. When the
      drivers use tty_register_device and we have tty_port already, we
      switch to tty_port_register_device. So we have the tty_struct =>
      tty_port link for free for those.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      734cc178
  3. 27 7月, 2012 1 次提交
  4. 17 7月, 2012 1 次提交
  5. 13 6月, 2012 1 次提交
  6. 16 5月, 2012 1 次提交
  7. 15 5月, 2012 1 次提交
  8. 10 5月, 2012 1 次提交
  9. 09 3月, 2012 1 次提交
  10. 25 1月, 2012 1 次提交
    • S
      serial: Fix wakeup init logic to speed up startup · 77359835
      Simon Glass 提交于
      The synchronize_rcu() call resulting from making every serial driver
      wake-up capable (commit b3b708fa) slows boot down on my Tegra2x system
      (with CONFIG_PREEMPT disabled).
      
      But this is avoidable since it is the device_set_wakeup_enable() and then
      subsequence disable which causes the delay. We might as well just make
      the device wakeup capable but not actually enable it for wakeup until
      needed.
      
      Effectively the current code does this:
      
      	device_set_wakeup_capable(dev, 1);
      	device_set_wakeup_enable(dev, 1);
      	device_set_wakeup_enable(dev, 0);
      
      We can just drop the last two lines.
      
      Before this change my boot log says:
      [    0.227062] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
      [    0.702928] serial8250.0: ttyS0 at MMIO 0x70006040 (irq = 69) is a Tegra
      
      after:
      [    0.227264] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
      [    0.227983] serial8250.0: ttyS0 at MMIO 0x70006040 (irq = 69) is a Tegra
      
      for saving of 450ms.
      Suggested-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      77359835
  11. 05 1月, 2012 1 次提交
  12. 16 11月, 2011 9 次提交
  13. 20 10月, 2011 1 次提交
    • D
      TTY: serial_core: Fix crash if DCD drop during suspend · d208a3bf
      Doug Anderson 提交于
      This crash was showing up 100% of the time on Tegra CPUs when an
      agetty was running on the serial port and the console was not running
      on the serial port.  The reason the Tegra saw it so reliably is that
      the Tegra CPU internally ties DTR to DCD/DSR.  That means when we
      dropped DTR during suspend we would get always get an immediate DCD
      drop.
      
      The specific order of operations that were running:
      * uart_suspend_port() would be called to put the uart in suspend mode
      * we'd drop DTR (ops->set_mctrl(uport, 0)).
      * the DTR drop would be looped back in the CPU to be a DCD drop.
      * the DCD drop would look to the serial driver as a hangup
      * the hangup would call uart_shutdown()
      * ... suspend / resume happens ...
      * uart_resume_port() would be called and run the code in the
        (port->flags & ASYNC_SUSPENDED) block, which would startup the port
        (and enable tx again).
      * Since the UART would be available for tx, we'd immediately get
        an interrupt, eventually calling transmit_chars()
      * The transmit_chars() function would crash.  The first crash would
        be a dereference of a NULL tty member, but since the port has been
        shutdown that was just a symptom.
      
      I have proposed a patch that would fix the Tegra CPUs here (see
      https://lkml.org/lkml/2011/10/11/444 - tty/serial: Prevent drop of DCD
      on suspend for Tegra UARTs).  However, even with that fix it is still
      possible for systems that have an externally visible DCD line to see a
      crash if the DCD drops at just the right time during suspend: thus
      this patch is still useful.
      Signed-off-by: NDoug Anderson <dianders@chromium.org>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d208a3bf
  14. 23 9月, 2011 2 次提交
    • N
      serial-core: power up uart port early before we do set_termios when resuming · 94abc56f
      Ning Jiang 提交于
      The following patch removed uart_change_pm() in uart_resume_port():
      
      commit 5933a161
      Author: Yin Kangkai <kangkai.yin@linux.intel.com>
          serial-core: reset the console speed on resume
      
      It will break the pxa serial driver when the system resumes from suspend mode
      as it will try to set baud rate divider register in set_termios but with
      clock off. The register value can not be set correctly on some platform if
      the clock is disabled. The pxa driver will check the value and report the
      following warning:
      
      ------------[ cut here ]------------
      WARNING: at drivers/tty/serial/pxa.c:545 serial_pxa_set_termios+0x1dc/0x250()
      Modules linked in:
      [<c0281f30>] (unwind_backtrace+0x0/0xf0) from [<c029341c>] (warn_slowpath_common+0x4c/0x64)
      [<c029341c>] (warn_slowpath_common+0x4c/0x64) from [<c029344c>] (warn_slowpath_null+0x18/0x1c)
      [<c029344c>] (warn_slowpath_null+0x18/0x1c) from [<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250)
      [<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250) from [<c044a840>] (uart_resume_port+0x128/0x2dc)
      [<c044a840>] (uart_resume_port+0x128/0x2dc) from [<c044bbe0>] (serial_pxa_resume+0x18/0x24)
      [<c044bbe0>] (serial_pxa_resume+0x18/0x24) from [<c0454d34>] (platform_pm_resume+0x40/0x4c)
      [<c0454d34>] (platform_pm_resume+0x40/0x4c) from [<c0457ebc>] (pm_op+0x68/0xb4)
      [<c0457ebc>] (pm_op+0x68/0xb4) from [<c0458368>] (device_resume+0xb0/0xec)
      [<c0458368>] (device_resume+0xb0/0xec) from [<c04584c8>] (dpm_resume+0xe0/0x194)
      [<c04584c8>] (dpm_resume+0xe0/0x194) from [<c0458588>] (dpm_resume_end+0xc/0x18)
      [<c0458588>] (dpm_resume_end+0xc/0x18) from [<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac)
      [<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac) from [<c02c5278>] (enter_state+0xac/0xdc)
      [<c02c5278>] (enter_state+0xac/0xdc) from [<c02c48ec>] (state_store+0xa0/0xbc)
      [<c02c48ec>] (state_store+0xa0/0xbc) from [<c0408f7c>] (kobj_attr_store+0x18/0x1c)
      [<c0408f7c>] (kobj_attr_store+0x18/0x1c) from [<c034a6a4>] (sysfs_write_file+0x108/0x140)
      [<c034a6a4>] (sysfs_write_file+0x108/0x140) from [<c02fb798>] (vfs_write+0xac/0x134)
      [<c02fb798>] (vfs_write+0xac/0x134) from [<c02fb8cc>] (sys_write+0x3c/0x68)
      [<c02fb8cc>] (sys_write+0x3c/0x68) from [<c027c700>] (ret_fast_syscall+0x0/0x2c)
      ---[ end trace 88289eceb4675b04 ]---
      
      This patch fix the problem by adding the power on opertion back for uart
      console when console_suspend_enabled is true.
      Signed-off-by: NNing Jiang <ning.jiang@marvell.com>
      Tested-by: NMayank Rana <mrana@codeaurora.org>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      94abc56f
    • N
      TTY: serial: Move mutex_unlock in uart_close function · 55956216
      Nobuhiro Iwamatsu 提交于
      When mutex_lock is not called, mutex_unlock is sometimes called.
      This deletes unnecessary goto and makes modifications so that
      mutex_unlock is called.
      
      [    8.304000] WARNING: at kernel/muex-debug.c:78
      [    8.304000] Modules linked in:
      [    8.304000]
      [    8.304000] Pid : 114, Comm:                 modprobe
      [    8.304000] CPU : 0                  Not tainted  (3.1.0-rc3-next-20110826 #810)
      [    8.304000]
      [    8.304000] PC is at debug_mutex_unlock+0xf4/0x120
      [    8.304000] PR is at debug_mutex_unlock+0xe6/0x120
      [    8.304000] PC  : 80051114 SP  : 9f02de58 SR  : 400081f1 TEA : 295cf4f2
      [    8.304000] R0  : 00000001 R1  : 00000000 R2  : 0000000f R3  : 00000000
      [    8.304000] R4  : 9fc63158 R5  : 00000000 R6  : 00000001 R7  : 9fe1de78
      [    8.304000] R8  : 805c6b2c R9  : 80003920 R10 : 00000000 R11 : 805c6b2c
      [    8.304000] R12 : 80425ca0 R13 : 00000000 R14 : 9f02de58
      [    8.304000] MACH: 00000003 MACL: 00000000 GBR : 296e1678 PR  : 80051106
      [    8.304000]
      [    8.304000] Call trace:
      [    8.304000]  [<804236c6>] __mutex_unlock_slowpath+0x46/0x120
      [    8.304000]  [<804237aa>] mutex_unlock+0xa/0x20
      [    8.304000]  [<80240ed6>] uart_close+0x76/0x2c0
      [    8.304000]  [<80223b98>] tty_release+0xf8/0x5c0
      [    8.304000]  [<800a93a6>] lookup_object+0x26/0xa0
      [    8.304000]  [<80063f6a>] call_rcu+0x8a/0xc0
      [    8.304000]  [<800a944a>] put_object+0x2a/0x60
      [    8.304000]  [<80003920>] arch_local_irq_restore+0x0/0x40
      [    8.304000]  [<800af320>] fput+0x180/0x2c0
      [    8.304000]  [<800af248>] fput+0xa8/0x2c0
      [    8.304000]  [<800ab1a8>] filp_close+0x48/0xc0
      [    8.304000]  [<800ab29a>] sys_close+0x7a/0x100
      [    8.304000]  [<8000825a>] syscall_call+0xc/0x10
      [    8.304000]  [<800ab220>] sys_close+0x0/0x100
      [    8.304000]
      [    8.304000] Code:
      [    8.304000]   8005110e:  mov.l     @r1, r1
      [    8.304000]   80051110:  tst       r1, r1
      [    8.304000]   80051112:  bf        80051116
      [    8.304000] ->80051114:  trapa     #62
      [    8.304000]   80051116:  mov.l     @r8, r1
      [    8.304000]   80051118:  tst       r1, r1
      [    8.304000]   8005111a:  bt.s      8005104c
      [    8.304000]   8005111c:  mov       #0, r1
      [    8.304000]   8005111e:  bra       80051056
      [    8.304000]
      [    8.304000] ---[ end trace e8f8e04c313f429b ]---
      Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      55956216
  15. 26 8月, 2011 3 次提交
    • J
      TTY: use tty_wait_until_sent_from_close in other drivers · 0b058353
      Jiri Slaby 提交于
      Let's use the newly added helper to avoid stalls in drivers which are
      not yet ported to tty_port helpers.
      
      Those which are broken (call tty_wait_until_sent with irqs disabled)
      are left untouched. They are in a deeper trouble than we are trying to
      solve here. This includes amiserial, 68328serial, 68360serial and
      crisv10.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0b058353
    • J
      TTY: serial, move locking in uart_close · bafb0bd2
      Jiri Slaby 提交于
      So now, when we handle CLOSING flag, there is no point to hold
      port->mutex over the start of uart_close.
      
      Yes, there are still several things to reason about:
      * port->count etc is and always was protected by a spinlock
      * ->stop_rx is protected by a spinlock. Otherwise it would
        race with interrupts.
      * uart_wait_until_sent -- that one is already called without
        port->mutex from set_termios and tty_set_ldisc. Should anything
        be protected there, it would be tx_empty. And by a spinlock.
        8250 does this internally...
      
      This step is needed to fix system stalls. To not create an AB-BA lock
      dependency (see next patches).
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bafb0bd2
    • J
      TTY: serial, use ASYNCB_CLOSING in uart_close · 426929f8
      Jiri Slaby 提交于
      We need to move port->mutex locking after wait_until_sent in
      uart_close (for rationale see next patches). But if we did it now, we
      would introduce a race between close and open. This is exactly why
      port->mutex is locked at the top of uart_close.
      
      To avoid the race, we add ASYNCB_CLOSING to uart_close. Like every
      other sane TTY driver. Thanks to tty_port_block_til_ready used in
      uart_open we will have this for free. Then we can move the port->mutex
      lock.
      
      Also note that this will make the conversion to tty_port helpers
      easier. They are currently handling ASYNC_CLOSING flag correctly.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      426929f8
  16. 24 8月, 2011 5 次提交
    • J
      tty: serial8250: remove UPIO_DWAPB{,32} · 4834d028
      Jamie Iles 提交于
      Now that platforms can override the port IRQ handler and the only user
      of these UPIO modes has been converted over, kill off UPIO_DWAPB and
      UPIO_DWAPB32.
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NJamie Iles <jamie@jamieiles.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4834d028
    • J
      TTY: remove tty_locked · 906cbe13
      Jiri Slaby 提交于
      We used it really only serial and ami_serial. The rest of the
      callsites were BUG/WARN_ONs to check if BTM is held. Now that we
      pruned tty_locked from both of the real users, we can get rid of
      tty_lock along with __big_tty_mutex_owner.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Alan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      906cbe13
    • J
      TTY: serial, remove tasklet for tty_wakeup · 6a3e492b
      Jiri Slaby 提交于
      tty_wakeup can be called from any context. So there is no need to have
      an extra tasklet for calling that. Hence save some space and remove
      the tasklet completely.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Alan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6a3e492b
    • J
      TTY: serial, remove BTM from wait_until_sent · 1f33a51d
      Jiri Slaby 提交于
      During the BKL removal process, the BKL was switched to tty_lock
      (BTM). Now we should start pruning the BTM further. Let's start with
      wait_until_sent of the serial layer. This will allow us to switch to
      the tty port helpers and thus clean it up much.
      
      In wait_until_sent there are some uport members accessed, but neither
      of them is protected by BTM at the location they are set ('=>' means
      function call):
      * uport->fifosize (set in tty_ioctl => uart_ioctl => uart_set_info)
      * uport->type (set in add_one_port prior to tty_register_device)
      * uport->timeout (set usually in tty_ioctl => tty_mode_ioctl =>
        tty_set_termios => uart_set_termios => uart_change_speed =>
        uport->ops->set_termios => uart_update_timeout)
      * call to uport->ops->tx_empty()
      
      If the tx_empty hook needs some lock to protect accesses to registers,
      it should take &uport->lock spinlock like 8250 does. Otherwise there
      still might be races e.g. with ISRs.
      
      This should also fix the issue Andreas is seeing (BTM in comparison to
      BKL doesn't have any hidden functionality like unlocking during
      sleeping).
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      References: https://lkml.org/lkml/2011/5/25/562
      Cc: Alan Cox <alan@linux.intel.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Andreas Bombe <aeb@debian.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1f33a51d
    • J
      TTY: serial, document ignoring of uart->ops->startup error · 0055197e
      Jiri Slaby 提交于
      When a user has SYS_ADMIN capabilities and uart->ops->startup returns
      an error in uart_startup, we silently drop the error. We then return 0
      and behave as if it didn't fail. (Not quite, since we set TTY_IO_ERROR
      bit and leave ASYNC_INITIALIZED bit cleared.)
      
      This all is to allow setserial to work with improperly configured or
      unconfigured ports. User can thus set port properties and reconfigure
      properly.
      
      This patch only documents this behavior.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Russel King <linux@arm.linux.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0055197e
  17. 26 4月, 2011 2 次提交
  18. 20 4月, 2011 6 次提交