- 26 Aug, 2011 6 commits
-
-
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: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Feng Tang authored
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>
-
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: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Cox authored
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>
-
Alan Cox authored
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>
-
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: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
- 25 Aug, 2011 5 commits
-
-
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: Jiri Slaby <jslaby@suse.cz> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
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>
-
Jiri Slaby authored
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>
-
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 <jslaby@suse.cz> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Jiri Slaby <jslaby@suse.cz> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
- 24 Aug, 2011 8 commits
-
-
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: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <cascardo@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <gregkh@suse.de>
-
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: Greg Kroah-Hartman <gregkh@suse.de>
-
- 23 Aug, 2011 21 commits
-
-
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 <jamie@jamieiles.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Alan Cox <alan@linux.intel.com> Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jamie Iles authored
The Synopsys DesignWare UART in pmc-sierra msp71xx has an extra feature where the UART detects a write attempt to the LCR whilst busy and raises an interrupt. The driver needs to clear the interrupt and rewrite the LCR. Move this into platform code and out of the 8250 driver. Acked-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jamie Iles authored
Convert to pr_foo() helpers rather than printk(KERN_.*). Acked-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: Anoop P A<Anoop_P.A@pmc-sierra.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Jamie Iles <jamie@jamieiles.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jamie Iles authored
Some serial ports may have unusal requirements for interrupt handling (e.g. the Synopsys DesignWare 8250-alike port and it's busy detect interrupt). Add a .handle_irq callback that can be used for platforms to override the interrupt behaviour in a similar fashion to the .serial_out and .serial_in callbacks. Signed-off-by: Jamie Iles <jamie@jamieiles.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Thomas Abraham authored
With uart tx/rx/err interrupt handling moved into the driver for s3c64xx and later SoC's, the uart interrupt handling in plaform code can be removed. The uart device irq resources is reduced to one and the related unused macros are removed. Suggested-by: Grant Likely <grant.likely@secretlab.ca> CC: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Greg Kroah-Hartman <gregkh@suse.de>
-
Mathias Krause authored
Even though this is valid C we should not mix C99 initializers with obfuscated ANSI C. Stick to C99 and initialize c by its name. Found by clang: drivers/tty/vt/vt.c:262:55: warning: explicitly assigning a variable of type 'unsigned int' to itself [-Wself-assign] struct vt_notifier_param param = { .vc = vc, unicode = unicode }; ~~~~~~~ ^ ~~~~~~~ Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Sonic Zhang authored
bfin_5xx.c is not a general name for all Blackfin chips. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Sonic Zhang authored
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
It makes the code really ugly. And since it can be enabled only before building and only in the source files, it can be barely used by users. That said, I've not seen anybody to use it in the past few years. This crap is copied to some more drivers over the tty tree. Since I'm not their maintainer, I'm not sure if I should remove them too? Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <jslaby@suse.cz> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
The same as in "TTY: serial, remove BTM from wait_until_sent" we don't need to take BTM in wait_until_sent of ami_serial. Exactly the same as serial, ami_serial accesses some "info" members (xmit_fifo_size, timeout), but their assignment on other places in the code is not protected by BTM anyway. So the BTM protects nothing here. This removal helps us to get rid of tty_locked() and __big_tty_mutex_owner in the following patch. This was suggested by Arnd. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@linux.intel.com> Cc: Andreas Bombe <aeb@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
It doesn't make sense to set console to uart_port in console->setup. At that time the console is set by uart_add_one_port already. The call chain looked like: uart_add_one_port() uport->cons = drv->cons; <= once uart_configure_port() register_console() console->setup() port->cons = co; <= second time Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
During the BKL removal process, the BKL was switched to tty_lock (BTM). Now we should start pruning the BTM further. Let's start with wait_until_sent of the serial layer. This will allow us to switch to the tty port helpers and thus clean it up much. In wait_until_sent there are some uport members accessed, but neither of them is protected by BTM at the location they are set ('=>' means function call): * uport->fifosize (set in tty_ioctl => uart_ioctl => uart_set_info) * uport->type (set in add_one_port prior to tty_register_device) * uport->timeout (set usually in tty_ioctl => tty_mode_ioctl => tty_set_termios => uart_set_termios => uart_change_speed => uport->ops->set_termios => uart_update_timeout) * call to uport->ops->tx_empty() If the tx_empty hook needs some lock to protect accesses to registers, it should take &uport->lock spinlock like 8250 does. Otherwise there still might be races e.g. with ISRs. This should also fix the issue Andreas is seeing (BTM in comparison to BKL doesn't have any hidden functionality like unlocking during sleeping). Signed-off-by: Jiri Slaby <jslaby@suse.cz> References: https://lkml.org/lkml/2011/5/25/562 Cc: Alan Cox <alan@linux.intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Andreas Bombe <aeb@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Edwin van Vliet authored
Redundant comment line was removed Signed-off-by: Edwin van Vliet <edwin@cheatah.nl> Reviewed-by: Jesper Juhl <jj@chaosbits.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Timur Tabi authored
The ePAPR embedded hypervisor specification provides an API for "byte channels", which are serial-like virtual devices for sending and receiving streams of bytes. This driver provides Linux kernel support for byte channels via three distinct interfaces: 1) An early-console (udbg) driver. This provides early console output through a byte channel. The byte channel handle must be specified in a Kconfig option. 2) A normal console driver. Output is sent to the byte channel designated for stdout in the device tree. The console driver is for handling kernel printk calls. 3) A tty driver, which is used to handle user-space input and output. The byte channel used for the console is designated as the default tty. Signed-off-by: Timur Tabi <timur@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-