linux/drivers/tty, branch v3.1-rc9

cris: fix a build error in drivers/tty/serial/crisv10.c

2011-09-15T01:09:38Z

Fix these errors: drivers/tty/serial/crisv10.c:4453: error: 'if_ser0' undeclared (first use in this function): 2 errors in 2 logs drivers/tty/serial/crisv10.c:4453: error: (Each undeclared identifier is reported only once: 2 errors in 2 logs drivers/tty/serial/crisv10.c:4453: error: for each function it appears in.): 2 errors in 2 logs "if_ser0" is a typo, it should be "if_serial_0". Signed-off-by: WANG Cong Cc: Mikael Starvik Cc: Jesper Nilsson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge branch 'sh-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-3.x

2011-08-29T20:34:48Z

* 'sh-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-3.x: sh: fix the compile error in setup-sh7757.c serial: sh-sci: report CTS as active for get_mctrl sh: Add unaligned memory access for PC relative intructions sh: Fix unaligned memory access for branches without delay slots sh: Fix up fallout from cpuidle changes. serial: sh-sci: console Runtime PM support sh: Fix conflicting definitions of ptrace_triggered serial: sh-sci: fix DMA build by including dma-mapping.h serial: sh-sci: Fix up default regtype probing. sh: intc: enable both edges GPIO interrupts on sh7372 shwdt: fix usage of mod_timer clocksource: sh_cmt: wait for CMCNT on init V2

serial: sh-sci: report CTS as active for get_mctrl

2011-08-29T06:47:33Z

sh-sci.c sets hardware up and then let the HW do all flow controls. There is no software code, nor needs to get/set real CTS signal. But, when turning CRTSCTS on through termios, uart_set_termios() in serial_core.c checks CTS, and stops TX if it is inactive at the moment. Because sci_get_mctrl() returns a fixed value DTR|RTS|DSR but CTS, the sequence open -> set CRTSCTS -> write hit the case and stop working, no more outputs. This patch makes sci_get_mctrl() report CTS in addition. Signed-off-by: Takashi YOSHII Signed-off-by: Paul Mundt

Merge branch 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2011-08-28T17:05:39Z

* 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ARM: mach-shmobile: sh7372 LCDC1 suspend fix V2 (incremental) OMAP: omap_device: only override _noirq methods, not normal suspend/resume PM / Runtime: Correct documentation of pm_runtime_irq_safe() ARM: mach-shmobile: sh7372 LCDC1 suspend fix sh-sci / PM: Use power.irq_safe PM: Use spinlock instead of mutex in clock management functions

sh-sci / PM: Use power.irq_safe

2011-08-24T19:41:08Z

Since sci_port_enable() and sci_port_disable() may be run with interrupts off and they execute pm_runtime_get_sync() and pm_runtime_put_sync(), respectively, the SCI device's power.irq_safe flag has to be set to indicate that it is safe to execute runtime PM callbacks for this device with interrupts off. Signed-off-by: Rafael J. Wysocki Acked-by: Magnus Damm

omap-serial: Allow IXON and IXOFF to be disabled.

2011-08-23T17:58:38Z

Fixes logic bug that software flow control cannot be disabled, because serial_omap_configure_xonxoff() is not called if both IXON and IXOFF bits are cleared. Signed-off-by: Nick Pelly Acked-by: Govindraj.R Tested-by: Govindraj.R Cc: stable Signed-off-by: Greg Kroah-Hartman

TTY: serial, document ignoring of uart->ops->startup error

2011-08-23T17:10:38Z

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: Jiri Slaby Cc: Alan Cox Cc: Russel King Signed-off-by: Greg Kroah-Hartman

TTY: pty, fix pty counting

2011-08-23T17:10:38Z

tty_operations->remove is normally called like: queue_release_one_tty ->tty_shutdown ->tty_driver_remove_tty ->tty_operations->remove However tty_shutdown() is called from queue_release_one_tty() only if tty_operations->shutdown is NULL. But for pty, it is not. pty_unix98_shutdown() is used there as ->shutdown. So tty_operations->remove of pty (i.e. pty_unix98_remove()) is never called. This results in invalid pty_count. I.e. what can be seen in /proc/sys/kernel/pty/nr. I see this was already reported at: https://lkml.org/lkml/2009/11/5/370 But it was not fixed since then. This patch is kind of a hackish way. The problem lies in ->install. We allocate there another tty (so-called tty->link). So ->install is called once, but ->remove twice, for both tty and tty->link. The fix here is to count both tty and tty->link and divide the count by 2 for user. And to have ->remove called, let's make tty_driver_remove_tty() global and call that from pty_unix98_shutdown() (tty_operations->shutdown). While at it, let's document that when ->shutdown is defined, tty_shutdown() is not called. Signed-off-by: Jiri Slaby Cc: Alan Cox Cc: "H. Peter Anvin" Cc: stable Signed-off-by: Greg Kroah-Hartman

8250: Fix race condition in serial8250_backup_timeout().

2011-08-23T17:10:37Z

This is to fix an issue where output will suddenly become very slow. The problem occurs on 8250 UARTS with the hardware bug UART_BUG_THRE. BACKGROUND For normal UARTs (without UART_BUG_THRE): When the serial core layer gets new transmit data and the transmitter is idle, it buffers the data and calls the 8250s' serial8250_start_tx() routine which will simply enable the TX interrupt in the IER register and return. This should immediately fire a THRE interrupt and begin transmitting the data. For buggy UARTs (with UART_BUG_THRE): merely enabling the TX interrupt in IER does not necessarily generate a new THRE interrupt. Therefore, a background timer periodically checks to see if there is pending data, and starts transmission if that is the case. The bug happens on SMP systems when the system has nothing to transmit, the transmit interrupt is disabled and the following sequence occurs: - CPU0: The background timer routine serial8250_backup_timeout() starts and saves the state of the interrupt enable register (IER) and then disables all interrupts in IER. NOTE: The transmit interrupt (TI) bit is saved as disabled. - CPU1: The serial core gets data to transmit, grabs the port lock and calls serial8250_start_tx() which enables the TI in IER. - CPU0: serial8250_backup_timeout() waits for the port lock. - CPU1: finishes (with TI enabled) and releases the port lock. - CPU0: serial8250_backup_timeout() calls the interrupt routine which will transmit the next fifo's worth of data and then restores the IER from the previously saved value (TI disabled). At this point, as long as the serial core has more transmit data buffered, it will not call serial8250_start_tx() again and the background timer routine will slowly transmit the data. The fix is to have serial8250_start_tx() get the port lock before it saves the IER state and release it after restoring IER. This will prevent serial8250_start_tx() from running in parallel. Signed-off-by: Al Cooper Cc: stable Signed-off-by: Greg Kroah-Hartman

serial/8250_pci: delete duplicate data definition

2011-08-23T17:06:28Z

Data definiton "VendorID=10DB, device_id=800D" is already defined. This patch deletes the duplicate definition. Signed-off-by: Tomoya MORINAGA Signed-off-by: Greg Kroah-Hartman