summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* TTY: serial_core: Fix crash if DCD drop during suspendDoug Anderson2011-10-191-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Doug Anderson <dianders@chromium.org> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty/serial: atmel_serial: bootconsole removed from auto-enumeratesNicolas Ferre2011-10-191-1/+0
| | | | | | | | Auto-enumerate mechanism conflicts with bootconsoles: remove the usage counter for this type of consoles. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Revert "TTY: call tty_driver_lookup_tty unconditionally"Greg Kroah-Hartman2011-10-191-9/+12
| | | | | | | | | | | | | This reverts commit 631180aca723cb92e128fdac5fd144e913ca84e5. It caused problems when /dev/tty is a pty: https://lkml.org/lkml/2011/10/12/401 Cc: Jiri Slaby <jslaby@suse.cz> Cc: stable <stable@vger.kernel.org> Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com> Cc: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty/serial: atmel_serial: add device tree supportNicolas Ferre2011-10-181-8/+71
| | | | | | | | Will use aliases to enumerate ports, if available. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty/serial: atmel_serial: auto-enumerate portsNicolas Ferre2011-10-181-8/+36
| | | | | | | | | | If no platform data provided to enumerate ports, use a bit field to choose port number and check if port is already initialized. Use this mechanism for both console and plain serial ports. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty/serial: atmel_serial: whitespace and braces modificationsNicolas Ferre2011-10-181-4/+5
| | | | | | Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty/serial: atmel_serial: change platform_data variable nameNicolas Ferre2011-10-181-7/+7
| | | | | | | | Easier to follow if platform_data name is pdata. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty/serial: RS485 bindings for device treeNicolas Ferre2011-10-183-0/+63
| | | | | | | | | | Generic bindings for RS485 feature included in some UARTs. Those bindings have to be used withing an UART device tree node. Documentation updated to link to the bindings definition. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: call tty_driver_lookup_tty unconditionallyJiri Slaby2011-10-181-12/+9
| | | | | | | | | | | | | | | | | | | | | Commit 4a2b5fddd5 (Move tty lookup/reopen to caller) made the call to tty_driver_lookup_tty conditional in tty_open. It doesn't look like it was an intention. Or if it was, it was not documented in the changelog and the code now looks weird. For example there would be no need to remember the tty driver and tty index. Further the condition depends on a tty which we drop a reference of already. If I'm looking correctly, this should not matter thanks to the locking currently done there. Thus, tty_driver->ttys[idx] cannot change under our hands. But anyway, it makes sense to change that to the old behaviour. Introduced-in: v2.6.28-rc2 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: stable <stable@vger.kernel.org> Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com> Cc: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: pty, release tty in all ptmx_open fail pathsJiri Slaby2011-10-181-5/+5
| | | | | | | | | | | | | | | | Mistakenly, commit 64ba3dc3143d (tty: never hold BTM while getting tty_mutex) switched one fail path in ptmx_open to not free the newly allocated tty. Fix that by jumping to the appropriate place. And rename the labels so that it's clear what is going on there. Introduced-in: v2.6.36-rc2 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: stable <stable@vger.kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: make tty_add_file non-failingJiri Slaby2011-10-183-18/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <jslaby@suse.cz> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Pekka Enberg <penberg@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: drop driver reference in tty_open fail pathJiri Slaby2011-10-181-0/+1
| | | | | | | | | | | | | | | | | | When tty_driver_lookup_tty fails in tty_open, we forget to drop a reference to the tty driver. This was added by commit 4a2b5fddd5 (Move tty lookup/reopen to caller). Fix that by adding tty_driver_kref_put to the fail path. I will refactor the code later. This is for the ease of backporting to stable. Introduced-in: v2.6.28-rc2 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: stable <stable@vger.kernel.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Acked-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 8250_pci: Fix kernel panic when pch_uart is disabledTomoya MORINAGA2011-10-181-0/+10
| | | | | | | | | | | | | | | | | Currently, ".setup" function is not set. As a result, when detecting our IOH's uart device without pch_uart, kernel panic occurs at the following of pciserial_init_ports(). for (i = 0; i < nr_ports; i++) { if (quirk->setup(priv, board, &serial_port, i)) break; So, this patch adds the ".setup" function. We can use pci_default_setup because our IOH's uart is compatible with 16550. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* h8300: drivers/serial/Kconfig was movedPaul Bolle2011-10-181-1/+1
| | | | | | | | | commit ab4382d27412e7e3e7c936e8d50d8888dfac3df8 moved drivers/serial/Kconfig to drivers/tty/serial/Kconfig, so we need to source the latter file. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* parport_pc: release IO region properly if unsupported ITE887x card is foundJiri Kosina2011-10-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | sio_ite_8872_probe() bails out if it detects no-parallel (1S, 2S) or unknown card. It doesn't call release_region() on the previously allocated resource though. This causes (a) leak of the resource (b) kernel oops when parport module is removed and /proc/ioports is read. This is because the string that has been associated to the IO port region is a static char array inside the already removed module. Let's call release_region() properly before baling out. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Niels de Vos <ndevos@redhat.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Joe Krahn <krahn@niehs.nih.gov> Signed-off-by: Andrew Morton <akpm@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty: Support compat_ioctl get/set termios_lockedThomas Meyer2011-10-183-0/+21
| | | | | | | | | | | | | | | | | 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 <thomas@m3y3r.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* hvc_console: display printk messages on console.Miche Baker-Harvey2011-10-181-1/+6
| | | | | | | | | | | | | | printk only works for "registered consoles." Currently, the hvc_console code calls register_console() from hvc_instantiate(), but that's only used in the early console case. In hvc_alloc(), register_console() was not called. Add a call to register_console() in hvc_alloc(), set up the index in the hvc_console, and set up the necessary vtermnos[] and cons_op[] entries so that printk functions work. Signed-off-by: Miche Baker-Harvey <miche@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: snyclinkmp: forever loop in tx_load_dma_buffer()Dan Carpenter2011-09-291-3/+3
| | | | | | | | | | | | | | | My main concern here was the line that said: copy_count = min_t(unsigned short,count,SCABUFSIZE); "count" is an unsigned int here so the cast to unsigned short truncates the upper bits. So if count is 0x10000 then copy_count is 0 and the loop never exits. "count" comes from skb->len in hdlcdev_xmit(). The other min_t() changes are just cleanups. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty/n_gsm: avoid fifo overflow in gsm_dlci_data_outputMikhail Kshevetskiy2011-09-261-27/+31
| | | | | | | | | | | | | | | n_gsm use a simple approach: every writing to fifo correspond exactly one reading from fifo. There are no problem in this approach until we read less bytes then we write. As result fifo may owerflow. This leads to packet loss and very slow responce. For example, this happens with ping packets (about 96 byte each) and default gsm->mtu = 64. As result we get 50 sec ping timeout and 20% packet loss. Fix the problem by reading and sending all data from the fifo Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty/n_gsm: fix a bug in gsm_dlci_data_output (adaption = 2 case)Mikhail Kshevetskiy2011-09-261-2/+1
| | | | | | | | | | | | | | | | | in adaption=2 case we should put 1 or 2 byte with modem status bits at the beginning of a buffer pointed by "dp". n_gsm use 1 byte case, so it allocate a buffer of len + 1 size. As result we should: * put 1 byte of modem status bits * increase data pointer * put "len" bytes of data but actually we have: * increase first byte with the value of modem status bits * decrease "len" * put orig_len - 1 bytes of data starting from the buffer beggining This is evidently wrong. Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 8250: ratelimit LSR safety check engaged warning.Konrad Rzeszutek Wilk2011-09-261-2/+2
| | | | | | | | | | | | | | | | | On my BIOSTAR TA890FXE the ttyS0 ends up spewing: [904682.485933] ttyS0: LSR safety check engaged! [904692.505895] ttyS0: LSR safety check engaged! [904702.525972] ttyS0: LSR safety check engaged! [904712.545967] ttyS0: LSR safety check engaged! [904722.566125] ttyS0: LSR safety check engaged! .. lets limit it so it won't be the only thing visible in the ring buffer. CC: Alan Cox <alan@linux.intel.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty/n_gsm: fix bug in tiocmsetNikola Diklic-Perin2011-09-261-1/+1
| | | | | | | | | | | | | | | | | Clear bitmask was not inverted before masking modem_tx. Calling ioctl(fd, TIOCMBIC, TIOCM_RTS) results in: [ 197.430000] pre_modem_tx: 0x00000006 [ 197.430000] clear: 0x00000004 [ 197.430000] set: 0x00000000 [ 197.440000] post_modem_tx: 0x00000004 which is wrong. Signed-off-by: Nikola Diklic-Perin <diklic.perin.nikola@gmail.com> Acked-by: Alan Cox <alan@linx.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* drivers/tty: don't use the byte channel handle as a parameter in ehv_bytechan.cTimur Tabi2011-09-261-5/+2
| | | | | | | | | | | The ePAPR hypervisor byte channel console driver only supports one byte channel as a console, and the byte channel handle is stored in a global variable. It doesn't make any sense to pass that handle as a parameter to the console functions, since these functions already have access to the global variable. Signed-off-by: Timur Tabi <timur@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: irq: Remove IRQF_DISABLEDYong Zhang2011-09-2219-35/+35
| | | | | | | | | | | | | | Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled], We run all interrupt handlers with interrupts disabled and we even check and yell when an interrupt handler returns with interrupts enabled (see commit [b738a50a: genirq: Warn when handler enables interrupts]). So now this flag is a NOOP and can be removed. Signed-off-by: Yong Zhang <yong.zhang0@gmail.com> Acked-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* serial-core: power up uart port early before we do set_termios when resumingNing Jiang2011-09-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following patch removed uart_change_pm() in uart_resume_port(): commit 5933a161abcb8d83a2c145177f48027c3c0a8995 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: Ning Jiang <ning.jiang@marvell.com> Tested-by: Mayank Rana <mrana@codeaurora.org> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* serial: mfd: Initconst section fixesAndi Kleen2011-09-221-1/+1
| | | | | | Cc: gregkh@suse.de Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* keyboard: Do not include <linux/irq.>Geert Uytterhoeven2011-09-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The top of <linux/irq.h> has this comment: * Please do not include this file in generic code. There is currently * no requirement for any architecture to implement anything held * within this file. * * Thanks. --rmk Remove inclusion of <linux/irq.>, to prevent the following compile error from happening soon: | include/linux/irq.h:132: error: redefinition of ‘struct irq_data’ | include/linux/irq.h:286: error: redefinition of ‘struct irq_chip’ drivers/tty/vt/keyboard.c needs to include <asm/irq_regs.h> for get_irq_regs(): | drivers/tty/vt/keyboard.c:497: error: implicit declaration of function ‘get_irq_regs’ | drivers/tty/vt/keyboard.c:497: warning: initialization makes pointer from integer without a cast Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: serial, move 68360 driver to stagingJiri Slaby2011-09-228-18/+26
| | | | | | | | | | | | | | | This driver has been broken at least since 2008. At that time, a88487c79b (Fix compile errors in SGI console drivers) broke this driver completely. And since nobody noticed for the past 3 years, move it into staging. I think this will rot there and we will throw it away completely after some time. Or maybe someone will volunteer to fix it ;). Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* cris: lower the printk level in cris serial driverWANG Cong2011-09-221-6/+6
| | | | | | | | | | KERN_CRIT is too high, replace those KERN_CRIT with KERN_ERR or KERN_WARNING. Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* serial: Support the EFR-register of XR1715x uarts.Søren Holm2011-09-224-2/+56
| | | | | | | | | | | The EFR (Enhenced-Features-Register) is located at a different offset than the other devices supporting UART_CAP_EFR. This change add a special setup quick to set UPF_EXAR_EFR on the port. UPF_EXAR_EFR is then used to the port type to PORT_XR17D15X since it is for sure a XR17D15X uart. Signed-off-by: Søren Holm <sgh@sgh.dk> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* cris: fix a build error in drivers/tty/serial/crisv10.cWANG Cong2011-09-221-2/+2
| | | | | | | | | | | | | | | | | | | This patch fixes the following build error: drivers/tty/serial/crisv10.c:4453: error: 'if_ser0' undeclared (first use in this function): 2 errors in 2 logs v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig drivers/tty/serial/crisv10.c:4453: error: (Each undeclared identifier is reported only once: 2 errors in 2 logs v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig drivers/tty/serial/crisv10.c:4453: error: for each function it appears in.): 2 errors in 2 logs v3.1-rc4/cris/cris-allmodconfig v3.1-rc4/cris/cris-allyesconfig "if_ser0" is a typo, it should be "if_serial_0". Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: serial, fix includes in some driversJiri Slaby2011-09-2222-2/+33
| | | | | | | | | | | | | | | linux/tty_flip.h is included in linux/serial_core.h. But this may (and will) change in the future. Then we would get build errors such as: .../tty/serial/max3107.c: In function ‘put_data_to_circ_buf’: .../tty/serial/max3107.c:149:2: error: implicit declaration of function ‘tty_insert_flip_string’ So fix all the drviers which call tty flip buffer helpers to really include linux/tty_flip.h. And also make sure that those include linux/tty.h when operating with struct tty_struct. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: serial, remove dead code from 68328Jiri Slaby2011-09-222-36/+0
| | | | | | | | | | | | The code is dead at least since 2002. So remove it to not distort git grep output (about port.tty usage). Remove the whole do_softirq tasklet as it's noop now. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: serial: Move mutex_unlock in uart_close functionNobuhiro Iwamatsu2011-09-221-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* serial: pxa: work around for errata #20Marcus Folkesson2011-09-221-0/+20
| | | | | | | | | | | Errata E20: UART: Character Timeout interrupt remains set under certain software conditions. Implication: The software servicing the UART can be trapped in an infinite loop. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty: add a DesignWare 8250 driverJamie Iles2011-08-264-0/+227
| | | | | | | | | | | | The Synopsys DesignWare 8250 is an 8250 that has an extra interrupt that gets raised when writing to the LCR when busy. To handle this we need special serial_out, serial_in and handle_irq methods. Add a new platform driver that uses these accessors. Cc: Alan Cox <alan@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty: 8250: export serial8250_handle_irqJamie Iles2011-08-261-0/+1
| | | | | | | | Allow modules to use the normal 8250 irq handler inside their own. Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tty/powerpc: fix build break with ehv_bytechan.c on allyesconfigTimur Tabi2011-08-261-6/+2
| | | | | | | | | | | | The ePAPR hypervisor byte channel driver is supposed to work on all ePAPR-compliant embedded PowerPC systems, but it had a reference to the MSR_GS bit, which is available only on Book-E systems. Also fix a couple integer-to-pointer typecast problems. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Timur Tabi <timur@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* max3110: Fix up port->tty backreferencingAlan Cox2011-08-261-2/+5
| | | | | | | We want to keep refcounts properly on this against hangup. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* max3110: add sysrq supportAlexander Shishkin2011-08-262-56/+44
| | | | | | | | | | This patch moves several occurences of similar code inside receive_chars(), which now also takes care of checking for break and calling sysrq handling code. Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* x86/mrst: Add platform data for Max3110 devicesFeng Tang2011-08-261-0/+3
| | | | | | | | | | Those info will be used when spi controller driver setup max3110 as a slave device Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* max3110: wake up fixesDirk Brandewie2011-08-261-4/+7
| | | | | | | | | | | | The main thread is waiting on on a wait_queue but wake_up_process() is used to wake the thread. This reads weirdly. Change wake_up_process() to wake_up(). Tested on the Moorestown tablet build Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* n_gsm: Send CLD command on exitAlan Cox2011-08-261-0/+8
| | | | | | | | | A DISC on DLCI 0 should close down the mux but Michael Lauer reports this is not the case for some modems. Send a CLD as well. Signed-off-by: Alan Cox <alan@linux.intel.com> Tested-by: Michael Lauer Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* n_gsm: update TODO listAlan Cox2011-08-261-1/+0
| | | | | | | This is now out of date so fix it Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* hsu: add runtime pm supportKristen Carlson Accardi2011-08-261-0/+47
| | | | | | | | | Doesn't appear to be much to do here, however having the suspend/resume functions will allow the d3/d0 transitions to be sent by the pci core. Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: use tty_wait_until_sent_from_close in other driversJiri Slaby2011-08-255-5/+6
| | | | | | | | | | | | | | 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: Jiri Slaby <jslaby@suse.cz> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: use tty_wait_until_sent_from_close in tty_port_close_startJiri Slaby2011-08-251-1/+1
| | | | | | | | | | | | | Let's use the newly added helper to avoid stalls in drivers which are already ported to tty_port helpers. We have to ensure here, that there is no user of tty_port_close_start and tty_port_close which holds port->mutex (or other) lock over them. And sure, there is none. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: define tty_wait_until_sent_from_closeJiri Slaby2011-08-251-0/+18
| | | | | | | | | | | | 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 <jslaby@suse.cz> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: serial, move locking in uart_closeJiri Slaby2011-08-251-1/+1
| | | | | | | | | | | | | | | | | | | | | 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: Jiri Slaby <jslaby@suse.cz> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* TTY: serial, use ASYNCB_CLOSING in uart_closeJiri Slaby2011-08-251-0/+3
| | | | | | | | | | | | | | | | | | | 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: Jiri Slaby <jslaby@suse.cz> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
OpenPOWER on IntegriCloud