user/sven/linux.git/include/linux/tty.h, branch v3.2.83

Merge branch 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

2011-10-26T13:11:09Z

* 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (79 commits) TTY: serial_core: Fix crash if DCD drop during suspend tty/serial: atmel_serial: bootconsole removed from auto-enumerates Revert "TTY: call tty_driver_lookup_tty unconditionally" tty/serial: atmel_serial: add device tree support tty/serial: atmel_serial: auto-enumerate ports tty/serial: atmel_serial: whitespace and braces modifications tty/serial: atmel_serial: change platform_data variable name tty/serial: RS485 bindings for device tree TTY: call tty_driver_lookup_tty unconditionally TTY: pty, release tty in all ptmx_open fail paths TTY: make tty_add_file non-failing TTY: drop driver reference in tty_open fail path 8250_pci: Fix kernel panic when pch_uart is disabled h8300: drivers/serial/Kconfig was moved parport_pc: release IO region properly if unsupported ITE887x card is found tty: Support compat_ioctl get/set termios_locked hvc_console: display printk messages on console. TTY: snyclinkmp: forever loop in tx_load_dma_buffer() tty/n_gsm: avoid fifo overflow in gsm_dlci_data_output tty/n_gsm: fix a bug in gsm_dlci_data_output (adaption = 2 case) ... Fix up Conflicts in: - drivers/tty/serial/8250_pci.c Trivial conflict with removed duplicate device ID - drivers/tty/serial/atmel_serial.c Annoying silly conflict between "specify the port num via platform_data" and other changes to atmel_console_init

TTY: make tty_add_file non-failing

2011-10-18T21:22:37Z

If tty_add_file fails at the point it is now, we have to revert all the changes we did to the tty. It means either decrease all refcounts if this was a tty reopen or delete the tty if it was newly allocated. There was a try to fix this in v3.0-rc2 using tty_release in 0259894c7 (TTY: fix fail path in tty_open). But instead it introduced a NULL dereference. It's because tty_release dereferences filp->private_data, but that one is set even in our tty_add_file. And when tty_add_file fails, it's still NULL/garbage. Hence tty_release cannot be called there. To circumvent the original leak (and the current NULL deref) we split tty_add_file into two functions, making the latter non-failing. In that case we may do the former early in open, where handling failures is easy. The latter stays as it is now. So there is no change in functionality. The original bug (leak) was introduced by f573bd176 (tty: Remove __GFP_NOFAIL from tty_add_file()). Thanks Dan for reporting this. Later, we may split tty_release into more functions and call only some of them in this fail path instead. (If at all possible.) Introduced-in: v2.6.37-rc2 Signed-off-by: Jiri Slaby Reported-by: Dan Carpenter Cc: stable Cc: Alan Cox Cc: Pekka Enberg Signed-off-by: Greg Kroah-Hartman

tty: Support compat_ioctl get/set termios_locked

2011-10-18T21:17:11Z

When running a Fedora 15 (x86) on an x86_64 kernel, in the boot process plymouthd complains about those two missing ioctls: [ 2.581783] ioctl32(plymouthd:186): Unknown cmd fd(10) cmd(00005457){t:'T';sz:0} arg(ffb6a5d0) on /dev/tty1 [ 2.581803] ioctl32(plymouthd:186): Unknown cmd fd(10) cmd(00005456){t:'T';sz:0} arg(ffb6a680) on /dev/tty1 both ioctl functions work on the 'struct termios' resp. 'struct termios2', which has the same size (36 bytes resp. 44 bytes) on x86 and x86_64, so it's just a matter of converting the pointer from userland. Signed-off-by: Thomas Meyer Cc: Arnd Bergmann Cc: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

TTY: define tty_wait_until_sent_from_close

2011-08-25T16:00:40Z

We need this helper to fix system stalls. The issue is that the rest of the system TTYs wait for us to finish waiting. This wasn't an issue with BKL. BKL used to unlock implicitly. This is based on the Arnd suggestion. Signed-off-by: Jiri Slaby Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman

TTY: remove tty_locked

2011-08-23T17:34:07Z

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: Jiri Slaby Acked-by: Arnd Bergmann Cc: Alan Cox 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

TTY: export NR_LDISC and N_* line discipline numbers to user-space

2011-06-07T16:37:01Z

Since commit (4564f9e5: consolidate line discipline number definitions) the patch moved all line discipline number from a per-architecture termios.h to a shared one: tty.h. However, prior to this consolidation work, the line discipline numbers were outside of an ifdef __KERNEL__/endif block so these numbers used to be exported to user-space. Since such numbers are kernel ABI anyway, and tty.h is already included for user- space header processing, just move these relevant defines outside of the ifdef __KERNEL__/endif block in include/linux/tty.h. CC: Maxime Bizon Signed-off-by: Florian Fainelli Acked-by: Tilman Schmidt Signed-off-by: Greg Kroah-Hartman

n_tracerouter and n_tracesink ldisc additions.

2011-05-13T23:31:00Z

The n_tracerouter and n_tracesink line discpline drivers use the Linux tty line discpline framework to route trace data coming from a tty port (say UART for example) to the trace sink line discipline driver and to another tty port(say USB). Those these two line discipline drivers can be used together, independently from pti.c, they are part of the original implementation solution of the MIPI P1149.7, compact JTAG, PTI solution for Intel mobile platforms starting with the Medfield platform. Signed-off-by: J Freyensee Signed-off-by: Greg Kroah-Hartman

TTY: introduce deinit helpers for proper ldisc shutdown

2011-04-19T21:43:01Z

Introduce deinitialize_tty_struct which should be called after initialize_tty_struct and before successfull tty_ldisc_setup. It calls tty_ldisc_deinit which is opposite of tty_ldisc_init. It only puts a reference to ldisc and assigns NULL to tty->ldisc. It will be used to shut down ldisc when tty_release cannot be called yet. Signed-off-by: Jiri Slaby Cc: Alan Cox Cc: Julian Anastasov Signed-off-by: Greg Kroah-Hartman

tty: stop using "delayed_work" in the tty layer

2011-03-22T23:17:32Z

Using delayed-work for tty flip buffers ends up causing us to wait for the next tick to complete some actions. That's usually not all that noticeable, but for certain latency-critical workloads it ends up being totally unacceptable. As an extreme case of this, passing a token back-and-forth over a pty will take two ticks per iteration, so even just a thousand iterations will take 8 seconds assuming a common 250Hz configuration. Avoiding the whole delayed work issue brings that ping-pong test-case down to 0.009s on my machine. In more practical terms, this latency has been a performance problem for things like dive computer simulators (simulating the serial interface using the ptys) and for other environments (Alan mentions a CP/M emulator). Reported-by: Jef Driesen Acked-by: Greg KH Acked-by: Alan Cox Signed-off-by: Linus Torvalds