summaryrefslogtreecommitdiff
path: root/drivers/tty
AgeCommit message (Collapse)Author
2013-05-30TTY: Fix tty miss restart after we turn off flow-controlWang YanQing
commit dab73b4eb9ef924a2b90dab84e539076d82b256f upstream. I meet emacs hang in start if I do the operation below: 1: echo 3 > /proc/sys/vm/drop_caches 2: emacs BigFile 3: Press CTRL-S follow 2 immediately Then emacs hang on, CTRL-Q can't resume, the terminal hang on, you can do nothing with this terminal except close it. The reason is before emacs takeover control the tty, we use CTRL-S to XOFF it. Then when emacs takeover the control, it may don't use the flow-control, so emacs hang. This patch fix it. This patch will fix a kind of strange tty relation hang problem, I believe I meet it with vim in ssh, and also see below bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465823 Signed-off-by: Wang YanQing <udknight@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-05-13tty: fix up atime/mtime mess, take threeLinus Torvalds
commit b0b885657b6c8ef63a46bc9299b2a7715d19acde upstream. We first tried to avoid updating atime/mtime entirely (commit b0de59b5733d: "TTY: do not update atime/mtime on read/write"), and then limited it to only update it occasionally (commit 37b7f3c76595: "TTY: fix atime/mtime regression"), but it turns out that this was both insufficient and overkill. It was insufficient because we let people attach to the shared ptmx node to see activity without even reading atime/mtime, and it was overkill because the "only once a minute" means that you can't really tell an idle person from an active one with 'w'. So this tries to fix the problem properly. It marks the shared ptmx node as un-notifiable, and it lowers the "only once a minute" to a few seconds instead - still long enough that you can't time individual keystrokes, but short enough that you can tell whether somebody is active or not. Reported-by: Simon Kirby <sim@hostway.ca> Acked-by: Jiri Slaby <jslaby@suse.cz> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-05-13TTY: fix atime/mtime regressionJiri Slaby
commit 37b7f3c76595e23257f61bd80b223de8658617ee upstream. In commit b0de59b5733d ("TTY: do not update atime/mtime on read/write") we removed timestamps from tty inodes to fix a security issue and waited if something breaks. Well, 'w', the utility to find out logged users and their inactivity time broke. It shows that users are inactive since the time they logged in. To revert to the old behaviour while still preventing attackers to guess the password length, we update the timestamps in one-minute intervals by this patch. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [bwh: For 3.2, use Greg's backported version] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-05-13TTY: do not update atime/mtime on read/writeJiri Slaby
commit b0de59b5733d18b0d1974a060860a8b5c1b36a2e upstream. On http://vladz.devzero.fr/013_ptmx-timing.php, we can see how to find out length of a password using timestamps of /dev/ptmx. It is documented in "Timing Analysis of Keystrokes and Timing Attacks on SSH". To avoid that problem, do not update time when reading from/writing to a TTY. I am afraid of regressions as this is a behavior we have since 0.97 and apps may expect the time to be current, e.g. for monitoring whether there was a change on the TTY. Now, there is no change. So this would better have a lot of testing before it goes upstream. References: CVE-2013-0160 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-05-13serial_core.c: add put_device() after device_find_child()Federico Vaga
commit 5a65dcc04cda41f4122aacc37a5a348454645399 upstream. The serial core uses device_find_child() but does not drop the reference to the retrieved child after using it. This patch add the missing put_device(). What I have done to test this issue. I used a machine with an AMBA PL011 serial driver. I tested the patch on next-20120408 because the last branch [next-20120415] does not boot on this board. For test purpose, I added some pr_info() messages to print the refcount after device_find_child() (lines: 1937,2009), and after put_device() (lines: 1947, 2021). Boot the machine *without* put_device(). Then: echo reboot > /sys/power/disk echo disk > /sys/power/state [ 87.058575] uart_suspend_port:1937 refcount 4 [ 87.058582] uart_suspend_port:1947 refcount 4 [ 87.098083] uart_resume_port:2009refcount 5 [ 87.098088] uart_resume_port:2021 refcount 5 echo disk > /sys/power/state [ 103.055574] uart_suspend_port:1937 refcount 6 [ 103.055580] uart_suspend_port:1947 refcount 6 [ 103.095322] uart_resume_port:2009 refcount 7 [ 103.095327] uart_resume_port:2021 refcount 7 echo disk > /sys/power/state [ 252.459580] uart_suspend_port:1937 refcount 8 [ 252.459586] uart_suspend_port:1947 refcount 8 [ 252.499611] uart_resume_port:2009 refcount 9 [ 252.499616] uart_resume_port:2021 refcount 9 The refcount continuously increased. Boot the machine *with* this patch. Then: echo reboot > /sys/power/disk echo disk > /sys/power/state [ 159.333559] uart_suspend_port:1937 refcount 4 [ 159.333566] uart_suspend_port:1947 refcount 3 [ 159.372751] uart_resume_port:2009 refcount 4 [ 159.372755] uart_resume_port:2021 refcount 3 echo disk > /sys/power/state [ 185.713614] uart_suspend_port:1937 refcount 4 [ 185.713621] uart_suspend_port:1947 refcount 3 [ 185.752935] uart_resume_port:2009 refcount 4 [ 185.752940] uart_resume_port:2021 refcount 3 echo disk > /sys/power/state [ 207.458584] uart_suspend_port:1937 refcount 4 [ 207.458591] uart_suspend_port:1947 refcount 3 [ 207.498598] uart_resume_port:2009 refcount 4 [ 207.498605] uart_resume_port:2021 refcount 3 The refcount correctly handled. Signed-off-by: Federico Vaga <federico.vaga@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-04-10vt: synchronize_rcu() under spinlock is not nice...Al Viro
commit e8cd81693bbbb15db57d3c9aa7dd90eda4842874 upstream. vcs_poll_data_free() calls unregister_vt_notifier(), which calls atomic_notifier_chain_unregister(), which calls synchronize_rcu(). Do it *after* we'd dropped ->f_lock. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-04-10tty: atmel_serial_probe(): index of atmel_ports[] fixPawel Wieczorkiewicz
commit 503bded92da283b2f31d87e054c4c6d30c3c2340 upstream. Index of atmel_ports[ATMEL_MAX_UART] should be smaller than ATMEL_MAX_UART. Signed-off-by: Pawel Wieczorkiewicz <wpawel@gmail.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-27sunsu: Fix panic in case of nonexistent port at "console=ttySY" cmdline optionTkhai Kirill
[ Upstream commit cb29529ea0030e60ef1bbbf8399a43d397a51526 ] If a machine has X (X < 4) sunsu ports and cmdline option "console=ttySY" is passed, where X < Y <= 4, than the following panic happens: Unable to handle kernel NULL pointer dereference TPC: <sunsu_console_setup+0x78/0xe0> RPC: <sunsu_console_setup+0x74/0xe0> I7: <register_console+0x378/0x3e0> Call Trace: [0000000000453a38] register_console+0x378/0x3e0 [0000000000576fa0] uart_add_one_port+0x2e0/0x340 [000000000057af40] su_probe+0x160/0x2e0 [00000000005b8a4c] platform_drv_probe+0xc/0x20 [00000000005b6c2c] driver_probe_device+0x12c/0x220 [00000000005b6da8] __driver_attach+0x88/0xa0 [00000000005b4df4] bus_for_each_dev+0x54/0xa0 [00000000005b5a54] bus_add_driver+0x154/0x260 [00000000005b7190] driver_register+0x50/0x180 [00000000006d250c] sunsu_init+0x18c/0x1e0 [00000000006c2668] do_one_initcall+0xe8/0x160 [00000000006c282c] kernel_init_freeable+0x12c/0x1e0 [0000000000603764] kernel_init+0x4/0x100 [0000000000405f64] ret_from_syscall+0x1c/0x2c [0000000000000000] (null) 1)Fix the panic; 2)Increment registered port number every successful probe. Signed-off-by: Kirill Tkhai <tkhai@yandex.ru> CC: David Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-27TTY: do not reset master's packet modeJiri Slaby
commit b81273a132177edd806476b953f6afeb17b786d5 upstream. Now that login from util-linux is forced to drop all references to a TTY which it wants to hangup (to reach reference count 1) we are seeing issues with telnet. When login closes its last reference to the slave PTY, it also resets packet mode on the *master* side. And we have a race here. What telnet does is fork+exec of `login'. Then there are two scenarios: * `login' closes the slave TTY and resets thus master's packet mode, but even now telnet properly sets the mode, or * `telnetd' sets packet mode on the master, `login' closes the slave TTY and resets master's packet mode. The former case is OK. However the latter happens in much more cases, by the order of magnitude to be precise. So when one tries to login to such a messed telnet setup, they see the following: inux login: ogin incorrect Note the missing first letters -- telnet thinks it is still in the packet mode, so when it receives "linux login" from `login', it considers "l" as the type of the packet and strips it. SuS does not mention how the implementation should behave. Both BSDs I checked (Free and Net) do not reset the flag upon the last close. By this I am resurrecting an old bug, see References. We are hitting it regularly now, i.e. with updated util-linux, ergo login. Here, I am changing a behavior introduced back in 2.1 times. It would better have a long time testing before goes upstream. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Bryan Mason <bmason@redhat.com> References: https://lkml.org/lkml/2009/11/11/223 References: https://bugzilla.redhat.com/show_bug.cgi?id=504703 References: https://bugzilla.novell.com/show_bug.cgi?id=797042 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-20tty: serial: fix typo "ARCH_S5P6450"Paul Bolle
commit 827aa0d36d486f359808c8fb931cf7a71011a09d upstream. This could have been either ARCH_S5P64X0 or CPU_S5P6450. Looking at commit 2555e663b367b8d555e76023f4de3f6338c28d6c ("ARM: S5P64X0: Add UART serial support for S5P6450") - which added this typo - makes clear this should be CPU_S5P6450. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-20serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 ↵Wang YanQing
Multi-I/O Controller commit 8d2f8cd424ca0b99001f3ff4f5db87c4e525f366 upstream. 01:08.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O Controller (rev 01) Subsystem: Device [1000:0012] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 20 Region 0: I/O ports at e050 [size=8] Region 1: I/O ports at e040 [size=8] Region 2: I/O ports at e030 [size=8] Region 3: I/O ports at e020 [size=8] Region 4: I/O ports at e010 [size=8] Region 5: I/O ports at e000 [size=16] Signed-off-by: Wang YanQing <udknight@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-20Fix 4 port and add support for 8 port 'Unknown' PCI serial port cardsScott Ashcroft
commit d13402a4a944e72612a9ec5c9190e35717c02a9d upstream. I've managed to find an 8 port version of the card 4 port card which was discussed here: http://marc.info/?l=linux-serial&m=120760744205314&w=2 Looking back at that thread there were two issues in the original patch. 1) The I/O ports for the UARTs are within BAR2 not BAR0. This can been seen in the original post. 2) A serial quirk isn't needed as these cards have no memory in BAR0 which makes pci_plx9050_init just return. This patch fixes the 4 port support to use BAR2, removes the bogus quirk and adds support for the 8 port card. $ lspci -vvv -n -s 00:08.0 00:08.0 0780: 10b5:9050 (rev 01) Subsystem: 10b5:1588 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 17 Region 1: I/O ports at ff00 [size=128] Region 2: I/O ports at fe00 [size=64] Region 3: I/O ports at fd00 [size=8] Capabilities: <access denied> Kernel driver in use: serial $ dmesg | grep 0000:00:08.0: [ 0.083320] pci 0000:00:08.0: [10b5:9050] type 0 class 0x000780 [ 0.083355] pci 0000:00:08.0: reg 14: [io 0xff00-0xff7f] [ 0.083369] pci 0000:00:08.0: reg 18: [io 0xfe00-0xfe3f] [ 0.083382] pci 0000:00:08.0: reg 1c: [io 0xfd00-0xfd07] [ 0.083460] pci 0000:00:08.0: PME# supported from D0 D3hot [ 1.212867] 0000:00:08.0: ttyS4 at I/O 0xfe00 (irq = 17) is a 16550A [ 1.233073] 0000:00:08.0: ttyS5 at I/O 0xfe08 (irq = 17) is a 16550A [ 1.253270] 0000:00:08.0: ttyS6 at I/O 0xfe10 (irq = 17) is a 16550A [ 1.273468] 0000:00:08.0: ttyS7 at I/O 0xfe18 (irq = 17) is a 16550A [ 1.293666] 0000:00:08.0: ttyS8 at I/O 0xfe20 (irq = 17) is a 16550A [ 1.313863] 0000:00:08.0: ttyS9 at I/O 0xfe28 (irq = 17) is a 16550A [ 1.334061] 0000:00:08.0: ttyS10 at I/O 0xfe30 (irq = 17) is a 16550A [ 1.354258] 0000:00:08.0: ttyS11 at I/O 0xfe38 (irq = 17) is a 16550A Signed-off-by: Scott Ashcroft <scott.ashcroft@talk21.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-20tty/serial: Add support for Altera serial portLey Foon Tan
commit e06c93cacb82dd147266fd1bdb2d0a0bd45ff2c1 upstream. Add support for Altera 8250/16550 compatible serial port. Signed-off-by: Ley Foon Tan <lftan@altera.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust filenames, context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-20tty: Correct tty buffer flush.Ilya Zykov
commit 64325a3be08d364a62ee8f84b2cf86934bc2544a upstream. The root of problem is carelessly zeroing pointer(in function __tty_buffer_flush()), when another thread can use it. It can be cause of "NULL pointer dereference". Main idea of the patch, this is never free last (struct tty_buffer) in the active buffer. Only flush the data for ldisc(buf->head->read = buf->head->commit). At that moment driver can collect(write) data in buffer without conflict. It is repeat behavior of flush_to_ldisc(), only without feeding data to ldisc. Signed-off-by: Ilya Zykov <ilya@ilyx.ru> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-068250: use correct value for PORT_BRCM_TRUMANAGEBen Hutchings
When backporting commit ebebd49a8eab ('8250/16?50: Add support for Broadcom TruManage redirected serial port') I took the next available port type number for PORT_BRCM_TRUMANAGE (22). However, the 8250 port type numbers are exposed to userland through the TIOC{G,S}SERIAL ioctls and so must remain stable. Redefine PORT_BRCM_TRUMANAGE as 25, matching mainline as of commit 85f024401bf807. This leaves port types 22-24 within the valid range for 8250 but not implemented there. Change serial8250_verify_port() to specifically reject these and change serial8250_type() to return "unknown" for them (though I'm not sure why it would ever see them). Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-06fb: Yet another band-aid for fixing lockdep messTakashi Iwai
commit e93a9a868792ad71cdd09d75e5a02d8067473c4e upstream. I've still got lockdep warnings even after Alan's patch, and it seems that yet more band aids are required to paper over similar paths for unbind_con_driver() and unregister_con_driver(). After this hack, lockdep warnings are finally gone. Signed-off-by: Takashi Iwai <tiwai@suse.de> Cc: Alan Cox <alan@linux.intel.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Jiri Kosina <jkosina@suse.cz> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-06fb: rework locking to fix lock ordering on takeoverAlan Cox
commit 50e244cc793d511b86adea24972f3a7264cae114 upstream. Adjust the console layer to allow a take over call where the caller already holds the locks. Make the fb layer lock in order. This is partly a band aid, the fb layer is terminally confused about the locking rules it uses for its notifiers it seems. [akpm@linux-foundation.org: remove stray non-ascii char, tidy comment] [akpm@linux-foundation.org: export do_take_over_console()] [airlied: cleanup another non-ascii char] Signed-off-by: Alan Cox <alan@linux.intel.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Jiri Kosina <jkosina@suse.cz> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-06vgacon/vt: clear buffer attributes when we load a 512 character font (v2)Dave Airlie
commit 2a2483072393b27f4336ab068a1f48ca19ff1c1e upstream. When we switch from 256->512 byte font rendering mode, it means the current contents of the screen is being reinterpreted. The bit that holds the high bit of the 9-bit font, may have been previously set, and thus the new font misrenders. The problem case we see is grub2 writes spaces with the bit set, so it ends up with data like 0x820, which gets reinterpreted into 0x120 char which the font translates into G with a circumflex. This flashes up on screen at boot and is quite ugly. A current side effect of this patch though is that any rendering on the screen changes color to a slightly darker color, but at least the screen no longer corrupts. v2: as suggested by hpa, always clear the attribute space, whether we are are going to or from 512 chars. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-06tty: set_termios/set_termiox should not return -EINTROleg Nesterov
commit 183d95cdd834381c594d3aa801c1f9f9c0c54fa9 upstream. See https://bugzilla.redhat.com/show_bug.cgi?id=904907 read command causes bash to abort with double free or corruption (out). A simple test-case from Roman: // Compile the reproducer and send sigchld ti that process. // EINTR occurs even if SA_RESTART flag is set. void handler(int sig) { } main() { struct sigaction act; act.sa_handler = handler; act.sa_flags = SA_RESTART; sigaction (SIGCHLD, &act, 0); struct termio ttp; ioctl(0, TCGETA, &ttp); while(1) { if (ioctl(0, TCSETAW, ttp) < 0) { if (errno == EINTR) { fprintf(stderr, "BUG!"); return(1); } } } } Change set_termios/set_termiox to return -ERESTARTSYS to fix this particular problem. I didn't dare to change other EINTR's in drivers/tty/, but they look equally wrong. Reported-by: Roman Rakus <rrakus@redhat.com> Reported-by: Lingzhu Xiang <lxiang@redhat.com> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-02-068250/16?50: Add support for Broadcom TruManage redirected serial portStephen Hurd
commit ebebd49a8eab5e9aa1b1f8f1614ccc3c2120f886 upstream. Add support for the UART device present in Broadcom TruManage capable NetXtreme chips (ie: 5761m 5762, and 5725). This implementation has a hidden transmit FIFO, so running in single-byte interrupt mode results in too many interrupts. The UART_CAP_HFIFO capability was added to track this. It continues to reload the THR as long as the THRE and TSRE bits are set in the LSR up to a specified limit (1024 is used here). Signed-off-by: Stephen Hurd <shurd@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: - Adjust filenames - Adjust context - First available port type number is 22 not 24 - s/uart_8250_port/uart_port/ - Use serial_in() not serial_port_in()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-02-06tty: 8250_dw: Fix inverted arguments to serial_out in IRQ handlerMaxime Ripard
commit 68e56cb3a068f9c30971c6117fbbd1e32918e49e upstream. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-02-06serial:ifx6x60:Delete SPI timer when shut down portchao bi
commit 014b9b4ce84281ccb3d723c792bed19815f3571a upstream. When shut down SPI port, it's possible that MRDY has been asserted and a SPI timer was activated waiting for SRDY assert, in the case, it needs to delete this timer. Signed-off-by: Chen Jun <jun.d.chen@intel.com> Signed-off-by: channing <chao.bi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-17serial: pl011: handle corruption at high clock speedsLinus Walleij
commit c5dd553b9fd069892c9e2de734f4f604e280fa7a upstream. This works around a few glitches in the ST version of the PL011 serial driver when using very high baud rates, as we do in the Ux500: 3, 3.25, 4 and 4.05 Mbps. Problem Observed/rootcause: When using high baud-rates, and the baudrate*8 is getting close to the provided clock frequency (so a division factor close to 1), when using bursts of characters (so they are abutted), then it seems as if there is not enough time to detect the beginning of the start-bit which is a timing reference for the entire character, and thus the sampling moment of character bits is moving towards the end of each bit, instead of the middle. Fix: Increase slightly the RX baud rate of the UART above the theoretical baudrate by 5%. This will definitely give more margin time to the UART_RX to correctly sample the data at the middle of the bit period. Also fix the ages old copy-paste error in the very stressed comment, it's referencing the registers used in the PL010 driver rather than the PL011 ones. Signed-off-by: Guillaume Jaunet <guillaume.jaunet@stericsson.com> Signed-off-by: Christophe Arnal <christophe.arnal@stericsson.com> Signed-off-by: Matthias Locher <matthias.locher@stericsson.com> Signed-off-by: Rajanikanth HV <rajanikanth.hv@stericsson.com> Cc: Bibek Basu <bibek.basu@stericsson.com> Cc: Par-Gunnar Hjalmdahl <par-gunnar.hjalmdahl@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-17serial: set correct baud_base for EXSYS EX-41092 Dual 16950Flavio Leitner
commit 26e8220adb0aec43b7acafa0f1431760eee28522 upstream. Apparently the same card model has two IDs, so this patch complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2 adding the missing one. Signed-off-by: Flavio Leitner <fbl@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-17n_gsm: memory leak in uplink error pathRuss Gorby
commit 88ed2a60610974443335c924d7cb8e5dcf9dbdc1 upstream. Uplink (TX) network data will go through gsm_dlci_data_output_framed there is a bug where if memory allocation fails, the skb which has already been pulled off the list will be lost. In addition TX skbs were being processed in LIFO order Fixed the memory leak, and changed to FIFO order processing Signed-off-by: Russ Gorby <russ.gorby@intel.com> Tested-by: Kappel, LaurentX <laurentx.kappel@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-17n_gsm: replace kfree_skb w/ appropriate dev_* versionsRuss Gorby
commit 329e56780e514a7ab607bcb51a52ab0dc2669414 upstream. Drivers are supposed to use the dev_* versions of the kfree_skb interfaces. In a couple of cases we were called with IRQs disabled as well which kfree_skb() does not expect. Replaced kfree_skb calls w/ dev_kfree_skb and dev_kfree_skb_any Signed-off-by: Russ Gorby <russ.gorby@intel.com> Tested-by: Yin, Fengwei <fengwei.yin@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-17n_gsm: avoid accessing freed memory during CMD_FCOFF conditionRuss Gorby
commit b4338e1efc339986cf6c0a3652906e914a86e2d3 upstream. gsm_data_kick was recently modified to allow messages on the tx queue bound for DLCI0 to flow even during FCOFF conditions. Unfortunately we introduced a bug discovered by code inspection where subsequent list traversers can access freed memory if the DLCI0 messages were not all at the head of the list. Replaced singly linked tx list w/ a list_head and used provided interfaces for traversing and deleting members. Signed-off-by: Russ Gorby <russ.gorby@intel.com> Tested-by: Yin, Fengwei <fengwei.yin@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-17n_gsm: added interlocking for gsm_data_lock for certain code pathsRuss Gorby
commit 5e44708f75b0f8712da715d6babb0c21089b2317 upstream. There were some locking holes in the management of the MUX's message queue for 2 code paths: 1) gsmld_write_wakeup 2) receipt of CMD_FCON flow-control message In both cases gsm_data_kick is called w/o locking so it can collide with other other instances of gsm_data_kick (pulling messages tx_tail) or potentially other instances of __gsm_data_queu (adding messages to tx_head) Changed to take the tx_lock in these 2 cases Signed-off-by: Russ Gorby <russ.gorby@intel.com> Tested-by: Yin, Fengwei <fengwei.yin@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-17char: n_gsm: remove message filtering for contipated DLCIsamix.lebsir
commit 10c6c383e43565c9c6ec07ff8eb2825f8091bdf0 upstream. The design of uplink flow control in the mux driver is that for constipated channels data will backup into the per-channel fifos, and any messages that make it to the outbound message queue will still go out. Code was added to also stop messages that were in the outbound queue but this requires filtering through all the messages on the queue for stopped dlcis and changes some of the mux logic unneccessarily. The message fiiltering was removed to be in line w/ the original design as the message filtering does not provide any solution. Extra debug messages used during investigation were also removed. Signed-off-by: samix.lebsir <samix.lebsir@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-17n_gsm : Flow control handling in Mux driverFrederic Berat
commit c01af4fec2c8f303d6b3354d44308d9e6bef8026 upstream. - Correcting handling of FCon/FCoff in order to respect 27.010 spec - Consider FCon/off will overide all dlci flow control except for dlci0 as we must be able to send control frames. - Dlci constipated handling according to FC, RTC and RTR values. - Modifying gsm_dlci_data_kick and gsm_dlci_data_sweep according to dlci constipated value Signed-off-by: Frederic Berat <fredericx.berat@intel.com> Signed-off-by: Russ Gorby <russ.gorby@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-17n_gsm: uplink SKBs accumulate on listRuss Gorby
commit 192b6041e75bb4a2aae73834037038cea139a92d upstream. gsm_dlci_data_kick will not call any output function if tx_bytes > THRESH_LO furthermore it will call the output function only once if tx_bytes == 0 If the size of the IP writes are on the order of THRESH_LO we can get into a situation where skbs accumulate on the outbound list being starved for events to call the output function. gsm_dlci_data_kick now calls the sweep function when tx_bytes==0 Signed-off-by: Russ Gorby <russ.gorby@intel.com> Tested-by: Kappel, LaurentX <laurentx.kappel@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-17n_gsm.c: Implement 3GPP27.010 DLC start-up procedure in MUXxiaojin
commit 7e8ac7b23b67416700dfb8b4136a4e81ce675b48 upstream. In 3GPP27.010 5.8.1, it defined: The TE multiplexer initiates the establishment of the multiplexer control channel by sending a SABM frame on DLCI 0 using the procedures of clause 5.4.1. Once the multiplexer channel is established other DLCs may be established using the procedures of clause 5.4.1. This patch implement 5.8.1 in MUX level, it make sure DLC0 is the first channel to be setup. [or for those not familiar with the specification: it was possible to try and open a data connection while the control channel was not yet fully open, which is a spec violation and confuses some modems] Signed-off-by: xiaojin <jin.xiao@intel.com> Tested-by: Yin, Fengwei <fengwei.yin@intel.com> [tweaked the order we check things and error code] Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-17Remove BUG_ON from n_tty_read()Stanislav Kozina
commit e9490e93c1978b6669f3e993caa3189be13ce459 upstream. Change the BUG_ON to WARN_ON and return in case of tty->read_buf==NULL. We want to track a couple of long standing reports of this but at the same time we can avoid killing the box. Signed-off-by: Stanislav Kozina <skozina@redhat.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-10pch_uart: Add eg20t_port lock field, avoid recursive spinlocksDarren Hart
commit 2588aba002d14e938c2f56d299ecf3e7ce1302a5 upstream. pch_uart_interrupt() takes priv->port.lock which leads to two recursive spinlock calls if low_latency==1 or CONFIG_PREEMPT_RT_FULL=y (one otherwise): pch_uart_interrupt spin_lock_irqsave(priv->port.lock, flags) case PCH_UART_IID_RDR_TO (data ready) handle_rx_to push_rx tty_port_tty_get spin_lock_irqsave(&port->lock, flags) <--- already hold this lock ... tty_flip_buffer_push ... flush_to_ldisc spin_lock_irqsave(&tty->buf.lock) spin_lock_irqsave(&tty->buf.lock) disc->ops->receive_buf(tty, char_buf) n_tty_receive_buf tty->ops->flush_chars() uart_flush_chars uart_start spin_lock_irqsave(&port->lock) <--- already hold this lock Avoid this by using a dedicated lock to protect the eg20t_port structure and IO access to its membase. This is more consistent with the 8250 driver. Ensure priv->lock is always take prior to priv->port.lock when taken at the same time. V2: Remove inadvertent whitespace change. V3: Account for oops_in_progress for the private lock in pch_console_write(). Note: Like the 8250 driver, if a printk is introduced anywhere inside the pch_console_write() critical section, the kernel will hang on a recursive spinlock on the private lock. The oops case is handled by using a trylock in the oops_in_progress case. Signed-off-by: Darren Hart <dvhart@linux.intel.com> CC: Tomoya MORINAGA <tomoya.rohm@gmail.com> CC: Feng Tang <feng.tang@intel.com> CC: Alexander Stein <alexander.stein@systec-electronic.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: - Adjust context - Drop changes to pch_console_write()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-09-19tty: serial: imx: don't reinit clock in imx_setup_ufcr()Dirk Behme
commit 7be0670f7b9198382938a03ff3db7f47ef6b4780 upstream. Remove the clock configuration from imx_setup_ufcr(). This isn't needed here and will cause garbage output if done. To be be sure that we only touch the bits we want (TXTL and RXTL) we have to mask out all other bits of the UFCR register. Add one non-existing bit macro for this, too (bit 6, DCEDTE on i.MX6). Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> CC: Shawn Guo <shawn.guo@linaro.org> CC: Sascha Hauer <s.hauer@pengutronix.de> CC: Troy Kisky <troy.kisky@boundarydevices.com> CC: Xinyu Chen <xinyu.chen@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: deleted code in imx_setup_ufcr() refers to sport->clk not sport->clk_per] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-09-19tty: serial: imx: console write routing is unsafe on SMPXinyu Chen
commit 9ec1882df244c4ee1baa692676fef5e8b0f5487d upstream. The console feature's write routing is unsafe on SMP with the startup/shutdown call. There could be several consumers of the console * the kernel printk * the init process using /dev/kmsg to call printk to show log * shell, which open /dev/console and write with sys_write() The shell goes into the normal uart open/write routing, but the other two go into the console operations. The open routing calls imx serial startup, which will write USR1/2 register without any lock and critical with imx_console_write call. Add a spin_lock for startup/shutdown/console_write routing. This patch is a port from Freescale's Android kernel. Signed-off-by: Xinyu Chen <xinyu.chen@freescale.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> CC: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-09-12pmac_zilog,kdb: Fix console poll hook to return instead of loopJason Wessel
commit 38f8eefccf3a23c4058a570fa2938a4f553cf8e0 upstream. kdb <-> kgdb transitioning does not work properly with this UART driver because the get character routine loops indefinitely as opposed to returning NO_POLL_CHAR per the expectation of the KDB I/O driver API. The symptom is a kernel hang when trying to switch debug modes. Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-08-10pch_uart: Fix parity setting issueTomoya MORINAGA
commit 38bd2a1ac736901d1cf4971c78ef952ba92ef78b upstream. Parity Setting value is reverse. E.G. In case of setting ODD parity, EVEN value is set. This patch inverts "if" condition. Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-08-10pch_uart: Fix rx error interrupt setting issueTomoya MORINAGA
commit 9539dfb7ac1c84522fe1f79bb7dac2990f3de44a upstream. Rx Error interrupt(E.G. parity error) is not enabled. So, when parity error occurs, error interrupt is not occurred. As a result, the received data is not dropped. This patch adds enable/disable rx error interrupt code. Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [Backported by Tomoya MORINGA: adjusted context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-08-10pch_uart: Fix missing break for 16 byte fifoAlan Cox
commit 9bc03743fff0770dc5a5324ba92e67cc377f16ca upstream. Otherwise we fall back to the wrong value. Reported-by: <dcb314@hotmail.com> Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44091 Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-31tty: Allow uart_register/unregister/registerAlan Cox
commit 1e66cded334e6cea596c72f6f650eec351b1e959 upstream. This is legitimate but because we don't clear the drv->state pointer in the unregister code causes a bogus BUG(). Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42880 Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-31Add missing call to uart_update_timeout()Lothar Waßmann
commit 8b979f7c6bf13a57e7b6002f1175312a44773960 upstream. This patch fixes a problem reported here: http://article.gmane.org/gmane.linux.ports.arm.kernel/155242/match=auart Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-318250.c: less than 2400 baud fix.Christian Melki
commit f9a9111b540fd67db5dab332f4b83d86c90e27b1 upstream. We noticed that we were loosing data at speed less than 2400 baud. It turned out our (TI16750 compatible) uart with 64 byte outgoing fifo was truncated to 16 byte (bit 5 sets fifo len) when modifying the fcr reg. The input code still fills the buffer with 64 bytes if I remember correctly and thus data is lost. Our fix was to remove whiping of the fcr content and just add the TRIGGER_1 which we want for latency. I can't see why this would not work on less than 2400 always, for all uarts ... Otherwise one would have to make sure the filling of the fifo re-checks the current state of available fifo size (urrk). Signed-off-by: Christian Melki <christian.melki@ericsson.se> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust filename; replace *port with up->port] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-318250_pci: fix pch uart matchingArnaud Patard
commit aaa10eb1d0034eccc096f583fe308f0921617598 upstream. The rules used to make 8250_pci "ignore" the PCH uarts are lacking pci subids entries, preventing it to match and thus is breaking serial port support for theses systems. This has been tested on a nanoETXexpress-TT, which has a specifici uart clock. Tested-by: Erwan Velu <Erwan.Velu@zodiacaerospace.com> Signed-off-by: Arnaud Patard <apatard@hupstream.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-11drivers/tty/amiserial.c: add missing tty_unlockJulia Lawall
commit d3a7b83f865b46bb7b5e1ed18a129ce1af349db4 upstream. tty_unlock is used on all other exits from the function. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Acked-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-11pch_uart: Fix dma channel unallocated issueTomoya MORINAGA
commit af6d17cdc8c89aeb3101f0d27cd32fc0592b40b2 upstream. This driver anticipates pch_uart_verify_port() is not called during installation. However, actually pch_uart_verify_port() is called during installation. As a result, memory access violation occurs like below. 0. initial value: use_dma=0 1. starup() - dma channel is not allocated because use_dma=0 2. pch_uart_verify_port() - Set use_dma=1 3. UART processing acts DMA mode because use_dma=1 - memory access violation occurs! This patch fixes the issue. Solution: Whenever pch_uart_verify_port() is called and then dma channel is not allocated, the channel should be allocated. Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-11ARM: clps711x: serial driver hungs are a result of call disable_irq within ISRAlexander Shiyan
commit 7a6fbc9a887193a1e9f8658703881c528040afbc upstream. Since 2.6.30-rc1 clps711x serial driver hungs system. This is a result of call disable_irq from ISR. synchronize_irq waits for end of interrupt and goes to infinite loop. This patch fix this problem. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-04-22serial: PL011: move interrupt clearingLinus Walleij
commit c3d8b76f61586714cdc5f219ba45592a54caaa55 upstream. Commit 360f748b204275229f8398cb2f9f53955db1503b "serial: PL011: clear pending interrupts" attempts to clear interrupts by writing to a yet-unassigned memory address. This fixes the issue. The breaking patch is marked for stable so should be carried along with the other patch. Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Nicolas Pitre <nico@fluxnic.net> Reported-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-22serial: PL011: clear pending interruptsLinus Walleij
commit 9b96fbacda34079dea0638ee1e92c56286f6114a upstream. Chanho Min reported that when the boot loader transfers control to the kernel, there may be pending interrupts causing the UART to lock up in an eternal loop trying to pick tokens from the FIFO (since the RX interrupt flag indicates there are tokens) while in practice there are no tokens - in fact there is only a pending IRQ flag. This patch address the issue with a combination of two patches suggested by Russell King that clears and mask all interrupts at probe() and clears any pending error and RX interrupts at port startup time. We suspect the spurious interrupts are a side-effect of switching the UART from FIFO to non-FIFO mode. Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Reported-by: Chanho Min <chanho0207@gmail.com> Suggested-by: Russell King <linux@arm.linux.org.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Jong-Sung Kim <neidhard.kim@lge.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-22pch_uart: Fix MSI setting issueTomoya MORINAGA
commit 867c902e07d5677e2a5b54c0435e589513abde48 upstream. The following patch (MSI setting) is not enough. commit e463595fd9c752fa4bf06b47df93ef9ade3c7cf0 Author: Alexander Stein <alexander.stein@systec-electronic.com> Date: Mon Jul 4 08:58:31 2011 +0200 pch_uart: Add MSI support Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> To enable MSI mode, PCI bus-mastering must be enabled. This patch enables the setting. cc: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2026-03-07 18:39:06 +0000