- 20 Aug, 2013 3 commits
-
-
Qipan Li authored
fix the typo in commit 2eb5618d which uses two gpios for rts/cts. Signed-off-by:
Qipan Li <Qipan.Li@csr.com> Signed-off-by:
Barry Song <Baohua.Song@csr.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Julia Lawall authored
Use devm_ioremap_resource instead of devm_request_and_ioremap. This was done using the semantic patch scripts/coccinelle/api/devm_ioremap_resource.cocci and various manual modifications to move associated calls to platform_get_resource closer to the resulting call to devm_ioremap_resource and to remove the associated error handling code. The initialization of port->mapbase is also moved lower, to take advantage of the NULL test on res performed by devm_ioremap_resource. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Tim Kryger authored
When a serial port is configured for RTS/CTS flow control, serial core will disable the transmitter if it observes CTS is de-asserted. This is perfectly reasonable and appropriate when the UART lacks the ability to automatically perform CTS flow control. However, if the UART hardware can manage flow control automatically, it is important that software not get involved. When the DesignWare UART enables 16C750 style auto-RTS/CTS it stops generating interrupts for changes in CTS state so software mostly stays out of the way. However, it does report the true state of CTS in the MSR so software may notice it is de-asserted and respond by improperly disabling the transmitter. Once this happens the transmitter will be blocked forever. To avoid this situation, we simply lie to the 8250 and serial core by reporting that CTS is asserted whenever auto-RTS/CTS mode is enabled. Signed-off-by:
Tim Kryger <tim.kryger@linaro.org> Reviewed-by:
Matt Porter <matt.porter@linaro.org> Reviewed-by:
Markus Mayer <markus.mayer@linaro.org> Signed-off-by:
-
- 16 Aug, 2013 1 commit
-
-
Mark Jackson authored
The recent patch to add RS485 contained a bug whereby the IER interrupt was cleared down incorrectly. This patch fixes the problem. Signed-off-by:
Mark Jackson <mpfj@newflow.co.uk> Signed-off-by:
-
- 15 Aug, 2013 4 commits
-
-
Luis Henriques authored
Function wait_for_xmitr is invoked only on functions that either depend on CONFIG_CONSOLE_POLL or CONFIG_SERIAL_PCH_UART_CONSOLE. This patch fixes the following warning: drivers/tty/serial/pch_uart.c:1504:13: warning: ‘wait_for_xmitr’ defined but not used [-Wunused-function] Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
-
Qipan Li authored
we defined some special properties for hardware flow control, document them for DT-binding. Signed-off-by:
-
Qipan Li authored
for USP-based UART, we use two gpios as RTS and CST pins. Signed-off-by:
-
Barry Song authored
pinctrl core will get default pinmux, so drop it in the sirfsoc serial driver. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 14 Aug, 2013 2 commits
-
-
Mark Jackson authored
This patch adds RS485 support to the OMAP serial driver, as defined in:- Documentation/devicetree/bindings/serial/rs485.txt When a UART transmitter is connected to (eg) a RS485 driver, it is necessary to turn the driver on/off as quickly as possible. This is best achieved in the serial driver itself (rather than in userspace where the latency can be quite large). This patch allows a GPIO pin to be defined (via DT) that controls the enabling of the driver at the start of a message, and disables the driver when the message has been completed. When RS485 is disabled, the RTS pin is set to on. Signed-off-by:
-
Julia Lawall authored
Remove unneeded error handling on the result of a call to platform_get_resource when the value is passed to devm_ioremap_resource. Move the call to platform_get_resource adjacent to the call to devm_ioremap_resource to make the connection between them more clear. A simplified version of the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression pdev,res,n,e,e1; expression ret != 0; identifier l; @@ - res = platform_get_resource(pdev, IORESOURCE_MEM, n); ... when != res - if (res == NULL) { ... \(goto l;\|return ret;\) } ... when != res + res = platform_get_resource(pdev, IORESOURCE_MEM, n); e = devm_ioremap_resource(e1, res); // </smpl> Signed-off-by:
-
- 12 Aug, 2013 22 commits
-
-
Fabio Estevam authored
Fix the following sparse warnings: drivers/tty/serial/amba-pl011.c:687:20: warning: context imbalance in 'pl011_dma_flush_buffer' - unexpected unlock drivers/tty/serial/amba-pl011.c:1200:13: warning: context imbalance in 'pl011_rx_chars' - unexpected unlock Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
John Crispin authored
The clock should be checked with the proper IS_ERR() api before using it. Signed-off-by:
John Crispin <blogic@openwrt.org> Signed-off-by:
-
Thomas Langer authored
Enable the clock if one is present when setting up the console. Signed-off-by:
Thomas Langer <thomas.langer@lantiq.com> Acked-by:
-
Sachin Kamat authored
__initdata should be placed between the variable name and equal sign for the variable to be placed in the intended section. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by:
-
Sachin Kamat authored
__initdata should be placed between the variable name and equal sign for the variable to be placed in the intended section. Signed-off-by:
Sonic Zhang <sonic.zhang@analog.com> Signed-off-by:
-
Jingoo Han authored
'cons' is a pointer; thus NULL should be used instead of 0. Also, local symbols are staticized. Fix the following sparse warnings: drivers/tty/serial/serial-tegra.c:1209:27: warning: Using plain integer as NULL pointer drivers/tty/serial/serial-tegra.c:1240:29: warning: symbol 'tegra20_uart_chip_data' was not declared. Should it be static? drivers/tty/serial/serial-tegra.c:1246:29: warning: symbol 'tegra30_uart_chip_data' was not declared. Should it be static? Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Jingoo Han authored
Fix the following sparse warning: drivers/tty/serial/msm_serial.c:237:37: error: incompatible types in comparison expression (different type sizes) Signed-off-by:
-
Jingoo Han authored
ioc4_serial_attach_one() is used only in this file. Also, ioc4_serial is not used; it can be removed. Fix the following sparse warnings: drivers/tty/serial/ioc4_serial.c:300:3: warning: symbol 'ioc4_serial' was not declared. Should it be static? drivers/tty/serial/ioc4_serial.c:2771:1: warning: symbol 'ioc4_serial_attach_one' was not declared. Should it be static? Signed-off-by:
Patrick Gefre <pfg@sgi.com> Signed-off-by:
-
Jingoo Han authored
icom_port->uart_port.membase is (unsigned char __iomem *); thus, casting (unsigned char __iomem *) is necessary to fix the following warning. Also, local symbols are staticized. drivers/tty/serial/icom.c:108:26: warning: symbol 'start_proc' was not declared. Should it be static? drivers/tty/serial/icom.c:116:26: warning: symbol 'stop_proc' was not declared. Should it be static? drivers/tty/serial/icom.c:123:25: warning: symbol 'int_mask_tbl' was not declared. Should it be static? drivers/tty/serial/icom.c:1569:54: warning: incorrect type in assignment (different address spaces) drivers/tty/serial/icom.c:1569:54: expected unsigned char [noderef] <asn:2>*membase drivers/tty/serial/icom.c:1569:54: got char *<noident> drivers/tty/serial/icom.c:1090:9: warning: cast truncates bits from constant value (ffffff7f becomes 7f) Signed-off-by:
-
Jingoo Han authored
These local symbols are used only in this file. Fix the following sparse warnings: drivers/tty/serial/timbuart.c:165:6: warning: symbol 'timbuart_handle_rx_port' was not declared. Should it be static? drivers/tty/serial/timbuart.c:187:6: warning: symbol 'timbuart_tasklet' was not declared. Should it be static? Signed-off-by:
-
Jingoo Han authored
max->port.membase is (unsigned char __iomem *); thus, casting (unsigned char __iomem *) is necessary to fix the following warning. Also, serial_m3110_ops() is staticized. drivers/tty/serial/mrst_max3110.c:716:17: warning: symbol 'serial_m3110_ops' was not declared. Should it be static? drivers/tty/serial/mrst_max3110.c:847:27: warning: incorrect type in assignment (different address spaces) drivers/tty/serial/mrst_max3110.c:847:27: expected unsigned char [noderef] <asn:2>*membase drivers/tty/serial/mrst_max3110.c:847:27: got void *<noident> Signed-off-by:
-
Jingoo Han authored
Fix the following sparse warning: drivers/tty/serial/8250/8250_early.c:196:26: error: incompatible types in comparison expression (different type sizes) Signed-off-by:
-
Jingoo Han authored
port->membase is (unsigned char __iomem *), not (unsigned long *) __set_bit() uses (unsigned long *) as the second argument. Thus, casting (unsigned long *)(unsigned long) is necessary to fix the following sparse warnings. drivers/tty/serial/samsung.c:142:33: warning: cast removes address space of expression drivers/tty/serial/samsung.c:161:33: warning: cast removes address space of expression drivers/tty/serial/samsung.c:176:33: warning: cast removes address space of expression drivers/tty/serial/samsung.c:526:40: warning: cast removes address space of expression Signed-off-by:
-
Jingoo Han authored
These local symbols are used only in this file. Fix the following sparse warnings: drivers/tty/serial/sirfsoc_uart.c:147:6: warning: symbol 'sirfsoc_uart_start_tx' was not declared. Should it be static? drivers/tty/serial/sirfsoc_uart.c:636:5: warning: symbol 'sirfsoc_uart_probe' was not declared. Should it be static? Signed-off-by:
-
Qipan Li authored
Universal Serial Ports (USP) can be used as PCM, UART, SPI, I2S etc. this makes the USP work as UART. the basic work flow is same with UART controller, the main difference will be offset of registers and bits. this patch makes the old sirfsoc uart driver support both sirf UART and USP-based UART by making their differences become private data. Signed-off-by:
-
Barry Song authored
the marco and coming new CSR multiple SoCs have SET/CLR pair for INTEN registers to avoid some read-modify-write. this patch adds support for this and make the driver support current up and coming mp SoCs. Signed-off-by:
-
Sascha Hauer authored
devicetrees may have the linux,stdout-path property to specify the console. This patch adds support to the i.MX serial driver for this. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Sascha Hauer authored
devicetrees may have a linux,stdout-path property in the chosen node describing the console device. This adds a helper function to match a device against this property so a driver can call add_preferred_console for a matching device. Signed-off-by:
Rob Herring <rob.herring@calxeda.com> Signed-off-by:
-
Gabor Juhos authored
Use devm_* functions in order to simplify cleanup paths. Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Signed-off-by:
-
Peter Hurley authored
Lockdep reports a circular lock dependency between atomic_read_lock and termios_rwsem [1]. However, a lock order deadlock is not possible since CPU1 only holds a read lock which cannot prevent CPU0 from also acquiring a read lock on the same r/w semaphore. Unfortunately, lockdep cannot currently distinguish whether the locks are read or write for any particular lock graph, merely that the locks _were_ previously read and/or write. Until lockdep is fixed, re-order atomic_read_lock so termios_rwsem can be dropped and reacquired without triggering lockdep. Patch based on original posted here https://lkml.org/lkml/2013/8/1/510 by Sergey Senozhatsky <sergey.senozhatsky@gmail.com> [1] Initial lockdep report from Artem Savkov <artem.savkov@gmail.com> ====================================================== [ INFO: possible circular locking dependency detected ] 3.11.0-rc3-next-20130730+ #140 Tainted: G W ------------------------------------------------------- bash/1198 is trying to acquire lock: (&tty->termios_rwsem){++++..}, at: [<ffffffff816aa3bb>] n_tty_read+0x49b/0x660 but task is already holding lock: (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff816aa0f0>] n_tty_read+0x1d0/0x660 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&ldata->atomic_read_lock){+.+...}: [<ffffffff811111cc>] validate_chain+0x73c/0x850 [<ffffffff811117e0>] __lock_acquire+0x500/0x5d0 [<ffffffff81111a29>] lock_acquire+0x179/0x1d0 [<ffffffff81d34b9c>] mutex_lock_interruptible_nested+0x7c/0x540 [<ffffffff816aa0f0>] n_tty_read+0x1d0/0x660 [<ffffffff816a3bb6>] tty_read+0x86/0xf0 [<ffffffff811f21d3>] vfs_read+0xc3/0x130 [<ffffffff811f2702>] SyS_read+0x62/0xa0 [<ffffffff81d45259>] system_call_fastpath+0x16/0x1b -> #0 (&tty->termios_rwsem){++++..}: [<ffffffff8111064f>] check_prev_add+0x14f/0x590 [<ffffffff811111cc>] validate_chain+0x73c/0x850 [<ffffffff811117e0>] __lock_acquire+0x500/0x5d0 [<ffffffff81111a29>] lock_acquire+0x179/0x1d0 [<ffffffff81d372c1>] down_read+0x51/0xa0 [<ffffffff816aa3bb>] n_tty_read+0x49b/0x660 [<ffffffff816a3bb6>] tty_read+0x86/0xf0 [<ffffffff811f21d3>] vfs_read+0xc3/0x130 [<ffffffff811f2702>] SyS_read+0x62/0xa0 [<ffffffff81d45259>] system_call_fastpath+0x16/0x1b other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ldata->atomic_read_lock); lock(&tty->termios_rwsem); lock(&ldata->atomic_read_lock); lock(&tty->termios_rwsem); *** DEADLOCK *** 2 locks held by bash/1198: #0: (&tty->ldisc_sem){.+.+.+}, at: [<ffffffff816ade04>] tty_ldisc_ref_wait+0x24/0x60 #1: (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff816aa0f0>] n_tty_read+0x1d0/0x660 stack backtrace: CPU: 1 PID: 1198 Comm: bash Tainted: G W 3.11.0-rc3-next-20130730+ #140 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 0000000000000000 ffff880019acdb28 ffffffff81d34074 0000000000000002 0000000000000000 ffff880019acdb78 ffffffff8110ed75 ffff880019acdb98 ffff880019fd0000 ffff880019acdb78 ffff880019fd0638 ffff880019fd0670 Call Trace: [<ffffffff81d34074>] dump_stack+0x59/0x7d [<ffffffff8110ed75>] print_circular_bug+0x105/0x120 [<ffffffff8111064f>] check_prev_add+0x14f/0x590 [<ffffffff81d3ab5f>] ? _raw_spin_unlock_irq+0x4f/0x70 [<ffffffff811111cc>] validate_chain+0x73c/0x850 [<ffffffff8110ae0f>] ? trace_hardirqs_off_caller+0x1f/0x190 [<ffffffff811117e0>] __lock_acquire+0x500/0x5d0 [<ffffffff81111a29>] lock_acquire+0x179/0x1d0 [<ffffffff816aa3bb>] ? n_tty_read+0x49b/0x660 [<ffffffff81d372c1>] down_read+0x51/0xa0 [<ffffffff816aa3bb>] ? n_tty_read+0x49b/0x660 [<ffffffff816aa3bb>] n_tty_read+0x49b/0x660 [<ffffffff810e4130>] ? try_to_wake_up+0x210/0x210 [<ffffffff816a3bb6>] tty_read+0x86/0xf0 [<ffffffff811f21d3>] vfs_read+0xc3/0x130 [<ffffffff811f2702>] SyS_read+0x62/0xa0 [<ffffffff815e24ee>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff81d45259>] system_call_fastpath+0x16/0x1b Reported-by:
Artem Savkov <artem.savkov@gmail.com> Reported-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Jingoo Han authored
These local symbols are used only in this file. Fix the following sparse warnings: drivers/tty/serial/pxa.c:793:17: warning: symbol 'serial_pxa_pops' was not declared. Should it be static? drivers/tty/serial/pxa.c:971:12: warning: symbol 'serial_pxa_init' was not declared. Should it be static? drivers/tty/serial/pxa.c:986:13: warning: symbol 'serial_pxa_exit' was not declared. Should it be static? Signed-off-by:
-
Daniel Mack authored
This #if-0'd block wouldn't compile, so let's dispose it. Signed-off-by:
Daniel Mack <zonque@gmail.com> Signed-off-by:
-
- 05 Aug, 2013 5 commits
-
-
Andreas Bießmann authored
This patch guards the console_drivers list to be corrupted. The for_each_console() macro insist on a strictly forward list ended by NULL: con0->next->con1->next->NULL Without this patch it may happen easily to destroy this list for example by adding 'earlyprintk' twice, especially on embedded devices where the early console is often a single static instance. This will result in the following list: con0->next->con0 This in turn will result in an endless loop in console_unlock() later on by printing the first __log_buf line endlessly. Signed-off-by:
Andreas Bießmann <andreas@biessmann.de> Cc: Kay Sievers <kay@vrfy.org> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Clemens Ladisch authored
The virtual console has (undocumented) module parameters to set the colors for italic and underlined text, but the default text color was hardcoded for some reason. This made it impossible to change the color for startup messages, or to set the default for new virtual consoles. Add a module parameter for that, and document the entire bunch. Any hacker who thinks that a command prompt on a "black screen with white font" is not supicious enough can now use the kernel parameter vt.color=10 to get a nice, evil green. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Huang Shijie authored
Add the RTS/CTS property for auart0 which means we enable the DMA support for it. Signed-off-by:
Huang Shijie <b32955@freescale.com> Acked-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Huang Shijie authored
The MXS_AUART_DMA_CONFIG is originally used to check if the DT node is configured with the DMA property. But now, the MXS_AUART_DMA_CONFIG is set unconditionally in the serial_mxs_probe_dt(), so the check in the mxs_auart_settermios() is not necessary anymore. This patch removes this macro. Signed-off-by:
Huang Shijie <shijie8@gmail.com> Acked-by:
-
Huang Shijie authored
The original DMA support works only when RTS/CTS is enabled. (see the "e8001632 serial: mxs-auart: add the DMA support for mx28") But after several patches, DMA support has lost this limit. (see the "bcc20f9e serial: mxs-auart: move to use generic DMA helper") So an UART without the RTS/CTS lines may also enables the DMA support, in which case the UART may gets unpredictable results. This patch adds an optional property for the UART DT node which indicates the UART has RTS and CTS lines, and it also means you enable the DMA support for this UART. This patch also adds a macro MXS_AUART_RTSCTS, and uses it to check RTS/CTS before we enable the DMA for the UART. Signed-off-by:
-
- 04 Aug, 2013 3 commits
-
-
Greg Kroah-Hartman authored
We want the tty fixes in here as well. Signed-off-by: -
Linus Torvalds authored
-
git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds authored
Pull dmaengine fixes from Vinod Koul: "Two fixes for slave dmaengine. The first fixes cyclic dma transfers for pl330 and the second one makes us return the correct error code on probe" * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: dma: pl330: Fix cyclic transfers pch_dma: fix error return code in pch_dma_probe()
-
