- Oct 18, 2011
-
-
Tomoya MORINAGA authored
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>
-
- Sep 26, 2011
-
-
Konrad Rzeszutek Wilk authored
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:
-
- Sep 22, 2011
-
-
Yong Zhang authored
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:
-
Ning Jiang authored
The following patch removed uart_change_pm() in uart_resume_port(): commit 5933a161 Author: Yin Kangkai <kangkai.yin@linux.intel.com> serial-core: reset the console speed on resume It will break the pxa serial driver when the system resumes from suspend mode as it will try to set baud rate divider register in set_termios but with clock off. The register value can not be set correctly on some platform if the clock is disabled. The pxa driver will check the value and report the following warning: ------------[ cut here ]------------ WARNING: at drivers/tty/serial/pxa.c:545 serial_pxa_set_termios+0x1dc/0x250() Modules linked in: [<c0281f30>] (unwind_backtrace+0x0/0xf0) from [<c029341c>] (warn_slowpath_common+0x4c/0x64) [<c029341c>] (warn_slowpath_common+0x4c/0x64) from [<c029344c>] (warn_slowpath_null+0x18/0x1c) [<c029344c>] (warn_slowpath_null+0x18/0x1c) from [<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250) [<c044b1e4>] (serial_pxa_set_termios+0x1dc/0x250) from [<c044a840>] (uart_resume_port+0x128/0x2dc) [<c044a840>] (uart_resume_port+0x128/0x2dc) from [<c044bbe0>] (serial_pxa_resume+0x18/0x24) [<c044bbe0>] (serial_pxa_resume+0x18/0x24) from [<c0454d34>] (platform_pm_resume+0x40/0x4c) [<c0454d34>] (platform_pm_resume+0x40/0x4c) from [<c0457ebc>] (pm_op+0x68/0xb4) [<c0457ebc>] (pm_op+0x68/0xb4) from [<c0458368>] (device_resume+0xb0/0xec) [<c0458368>] (device_resume+0xb0/0xec) from [<c04584c8>] (dpm_resume+0xe0/0x194) [<c04584c8>] (dpm_resume+0xe0/0x194) from [<c0458588>] (dpm_resume_end+0xc/0x18) [<c0458588>] (dpm_resume_end+0xc/0x18) from [<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac) [<c02c518c>] (suspend_devices_and_enter+0x16c/0x1ac) from [<c02c5278>] (enter_state+0xac/0xdc) [<c02c5278>] (enter_state+0xac/0xdc) from [<c02c48ec>] (state_store+0xa0/0xbc) [<c02c48ec>] (state_store+0xa0/0xbc) from [<c0408f7c>] (kobj_attr_store+0x18/0x1c) [<c0408f7c>] (kobj_attr_store+0x18/0x1c) from [<c034a6a4>] (sysfs_write_file+0x108/0x140) [<c034a6a4>] (sysfs_write_file+0x108/0x140) from [<c02fb798>] (vfs_write+0xac/0x134) [<c02fb798>] (vfs_write+0xac/0x134) from [<c02fb8cc>] (sys_write+0x3c/0x68) [<c02fb8cc>] (sys_write+0x3c/0x68) from [<c027c700>] (ret_fast_syscall+0x0/0x2c) ---[ end trace 88289eceb4675b04 ]--- This patch fix the problem by adding the power on opertion back for uart console when console_suspend_enabled is true. Signed-off-by:
Ning Jiang <ning.jiang@marvell.com> Tested-by:
Mayank Rana <mrana@codeaurora.org> Cc: stable <stable@kernel.org> Signed-off-by:
-
Andi Kleen authored
Cc: gregkh@suse.de Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Jiri Slaby authored
This driver has been broken at least since 2008. At that time, a88487c7 (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:
-
WANG Cong authored
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:
-
Søren Holm authored
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:
-
WANG Cong authored
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: -
Jiri Slaby authored
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 authored
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:
-
Nobuhiro Iwamatsu authored
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:
-
Marcus Folkesson authored
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:
-
- Aug 26, 2011
-
-
Jamie Iles authored
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:
-
Jamie Iles authored
Allow modules to use the normal 8250 irq handler inside their own. Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Alan Cox authored
We want to keep refcounts properly on this against hangup. Signed-off-by:
-
Alexander Shishkin authored
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:
-
Dirk Brandewie authored
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:
-
Kristen Carlson Accardi authored
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:
-
- Aug 25, 2011
-
-
Jiri Slaby authored
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:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Jiri Slaby authored
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 authored
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:
-
- Aug 24, 2011
-
-
Thadeu Lima de Souza Cascardo authored
Instead of printing the head of the buffer, we should print the tail, which is the byte we are sending to the device. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
jsm uses a write queue that copies from uart_core circular buffer. This copying however has some bugs, like not wrapping the head counter. Since this write queue is also a circular buffer, the consumer function is ready to use the uart_core circular buffer directly. This buggy copying function was making some bytes be dropped when transmitting to a raw tty, doing something like this. [root@hostname ~]$ cat /dev/ttyn1 > cascardo/dump & [1] 2658 [root@hostname ~]$ cat /proc/tty/drivers > /dev/ttyn0 [root@hostname ~]$ cat /proc/tty/drivers /dev/tty /dev/tty 5 0 system:/dev/tty /dev/console /dev/console 5 1 system:console /dev/ptmx /dev/ptmx 5 2 system /dev/vc/0 /dev/vc/0 4 0 system:vtmaster jsm /dev/ttyn 250 0-31 serial serial /dev/ttyS 4 64-95 serial hvc /dev/hvc 229 0-7 system pty_slave /dev/pts 136 0-1048575 pty:slave pty_master /dev/ptm 128 0-1048575 pty:master unknown /dev/tty 4 1-63 console [root@hostname ~]$ cat cascardo/dump /dev/tty /dev/tty 5 0 system:/dev/tty /dev/console /dev/console 5 1 system:console /dev/ptmx /dev/ptmx 5 2 system /dev/vc/0 /dev/vc/0 4 0 system:vtmaste[root@hostname ~]$ This patch drops the driver write queue entirely, using the circular buffer from uart_core only. Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
The flip buffer is not used anymore. Remove its allocation and declaration in the board structure. Signed-off-by:
-
Kukjin Kim authored
According to add support EXYNOS4212 SoC, we need to enable SERIAL_S5PV210 on EXYNOS4212. Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Bernhard Roth authored
By default the atmel_serial driver in RS485 mode disables receiving data until all data in the send buffer has been sent. This flag allows to receive data even whilst sending data. Signed-off-by:
Bernhard Roth <br@pwrnet.de> Signed-off-by:
Claudio Scordino <claudio@evidence.eu.com> Acked-by:
-
Hui Wang authored
The imx UART hardware controller can identify BREAK character and the imx_set_termios() can accept BRKINT set by users, but current existing imx_rxint() can't pass BREAK character and TTY_BREAK to the tty layer as other serial drivers do (8250.c omap_serial.c). Here add code to handle BREAK character and pass it to tty layer. To detect error occurrence, i use URXD_ERR to replace (URXD_OVRRUN | URXD_FRMERR | ...) because any kind of error occurs, URXD_ERR will always be set to 1. I put the URXD_BRK to the first place to check since when BREAK error occurs, not only URXD_BRK is set to 1, but also URXD_PRERR and URXD_FRMERR are all set to 1. This arrangement can filter out fake parity and frame errors when BREAK error occurs. Signed-off-by:
Hui Wang <jason77.wang@gmail.com> Acked-by:
Sascha Hauer <s.hauer@pengutronix.de> Acked-by:
-
Greg Kroah-Hartman authored
This reverts commit 6b1a98d1. It causes a build error that needs to be resolved differently. Cc: Alan Cox <alan@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jamie Iles <jamie@jamieiles.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 14a8d47d. It causes a build error that needs to be resolved differently. Cc: Alan Cox <alan@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jamie Iles <jamie@jamieiles.com> Signed-off-by:
-
- Aug 23, 2011
-
-
Jamie Iles authored
Support the DesignWare 8250 by a new compatible string and registering the DesignWare helpers. If the registration of the helpers fails, then continue as a normal 8250 as we may still get some useful debug out. Cc: Alan Cox <alan@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Jamie Iles authored
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 function serial8250_use_designware_io() that configures a uart_port with these accessors. Cc: Alan Cox <alan@linux.intel.com> Acked-by:
-
Jamie Iles authored
Now that platforms can override the port IRQ handler and the only user of these UPIO modes has been converted over, kill off UPIO_DWAPB and UPIO_DWAPB32. Acked-by:
-
Jamie Iles authored
Some ports (e.g. Synopsys DesignWare 8250) have special requirements for handling the interrupts. Allow these platforms to specify their own interrupt handler that will override the default. serial8250_handle_irq() is provided so that platforms can extend the IRQ handler rather than completely replacing it. Signed-off-by:
-
Thomas Abraham authored
s3c64xx and later SoC's include the interrupt mask and pending registers in the uart controller, unlike the s3c24xx SoC's which have these registers in the interrupt controller. When the mask and pending registers are part of the uart controller, a unified interrupt handler can handle the tx/rx interrupt. With this, the static reservation of interrupt numbers for the uart tx/rx/err interrupts in the linux irq space is not required and simplifies adding device tree support. Suggested-by:
Grant Likely <grant.likely@secretlab.ca> CC: Ben Dooks <ben-linux@fluff.org> Signed-off-by:
Thomas Abraham <thomas.abraham@linaro.org> Acked-by:
-
Sonic Zhang authored
Serial TX IRQ is not RX IRQ plus 1 in some blackfin chips. Give individual platform resources to both TX and RX irqs. Signed-off-by:
Sonic Zhang <sonic.zhang@analog.com> Signed-off-by:
-
Sonic Zhang authored
bfin_5xx.c is not a general name for all Blackfin chips. Signed-off-by:
-
Sonic Zhang authored
Signed-off-by:
-
Jiri Slaby authored
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 authored
tty_wakeup can be called from any context. So there is no need to have an extra tasklet for calling that. Hence save some space and remove the tasklet completely. Signed-off-by:
-
