- Jan 18, 2013
-
-
Kevin Cernekee authored
This driver supports the RocketPort EXPRESS and RocketPort INFINITY families of PCI/PCIe multiport serial adapters. These adapters use a "RocketPort 2" ASIC that is not compatible with the original RocketPort driver (CONFIG_ROCKETPORT). Tested with the RocketPort EXPRESS Octa DB9 and Quad DB9. Also added an old RocketPort 8J PCI card to the same system to verify that rocket.c and rp2.c coexist peacefully. Signed-off-by:
Kevin Cernekee <cernekee@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kevin Cernekee authored
Matching PCI_ANY_ID causes conflicts with RocketPort 2 adapters, which are supported by a different driver. Signed-off-by:
-
Tony Prisk authored
Memory mapped via ioremap call is never released. Rather than add an iounmap call, change allocation function to devm_request_and_ioremap. Also, change the error on failure for this call to -EADDRNOTAVAIL rather than -ENOMEM. Signed-off-by:
Tony Prisk <linux@prisktech.co.nz> Signed-off-by:
-
Tony Prisk authored
Fix two instances where the index to vt8500_uart_ports is tested against > VT8500_MAX_PORTS. Correct usage should be >= VT8500_MAX_PORTS. Signed-off-by:
-
Cong Ding authored
The pointer tty is dereferened in line 3135, so it is not necessary to check null again in line 3140. Signed-off-by:
Cong Ding <dinggnu@gmail.com> Signed-off-by:
-
Cong Ding authored
The pointer info is dereferened in line 1009, so it is not necessary to check null again in line 1012. Signed-off-by:
-
Alexey Pelykh authored
Original table in OMAP TRM named "UART Mode Baud Rates, Divisor Values, and Error Rates" determines modes not for all common baud rates. E.g. for 1000000 baud rate mode should be 16x, but according to that table it's determined as 13x. According to current implementation of mode divisor selection, after requesting 1000000 baudrate from driver, later one will configure chip to use MODE13 divisor. Assuming 48Mhz as common UART clock speed, MODE13 divisor will effectively give 1230769 baudrate, what is quite far from desired 1000000 baudrate. While with MODE16 divisor, chip will produce exact 1000000 baudrate. In old driver that served UART devices (8250.c and serial_core.c) this divisor could have been configured by user-space program, but in omap_serial.c driver implementation this ability was not implemented (afaik, by design) thus disallowing proper usage of MODE16-compatible baudrates. Signed-off-by:
Alexey Pelykh <alexey.pelykh@gmail.com> Signed-off-by:
-
Vineet Gupta authored
Commit "serial/arc-uart: split probe from probe_earlyprintk" introduced a build time warning: "WARNING: vmlinux.o(.data+0x5baa0): Section mismatch in reference from the variable early_arc_platform_driver to the function .init.text:arc_serial_probe_earlyprintk()" While at it - fixed another incorrectly placed initdata annotation. Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: fengguang.wu@intel.com Cc: linux-serial@vger.kernel.org Signed-off-by:
-
Barry Song authored
The fast lookup table to set baudrate is only right when ioclk is 150MHz. for most platforms, ioclk is 150MHz, but some boards might set ioclk to other frequency. so re-calc the clk_div_reg when ioclk is not 150MHz. this patch also gets clk in probe and puts it in remove. Signed-off-by:
Barry Song <Baohua.Song@csr.com> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by:
-
- Jan 16, 2013
-
-
Greg Kroah-Hartman authored
It isn't using the port logic, and breaks the build at the moment, so mark it BROKEN. Cc: Jiri Slaby <jslaby@suse.cz> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: -
Jiri Slaby authored
By the recent `switch flipping' patches we introduced a build failure in the driver: mn10300-serial.c:527:19: error: 'port' redeclared as different kind of symbol I did not notice because I did not even find a compiler for that new architecture. Hopefully everything is all right now as I cannot test it. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Jiri Slaby authored
This one was omitted by the "TTY: switch tty_flip_buffer_push" patch because I did not compile-test mips driver. Now I do. Signed-off-by:
-
Heikki Krogerus authored
The default burst is often 1 byte which is not very optimal. The ideal burst size when using 16550A type port would be 1/2 of fifosize, but this does not work with all Designware implementations. Setting it to 1/4 fifosize. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
Heikki Krogerus authored
There are no stubs for ACPI functions so the driver needs to have this ifdef or it will not compile without ACPI. Signed-off-by:
-
Heikki Krogerus authored
Remove one useless wakeup, and do not use DMA with zero byte transfers. Signed-off-by:
-
Heikki Krogerus authored
The tty buffer functions are converted to using tty_port structure instead of struct tty, so we must do the same. Signed-off-by:
-
Sebastian Andrzej Siewior authored
Since commit 89c8d91e ("tty: localise the lock") I see a dead lock in one of my dummy_hcd + g_nokia test cases. The first run was usually okay, the second often resulted in a splat by lockdep and the third was usually a dead lock. Lockdep complained about tty->hangup_work and tty->legacy_mutex taken both ways: | ====================================================== | [ INFO: possible circular locking dependency detected ] | 3.7.0-rc6+ #204 Not tainted | ------------------------------------------------------- | kworker/2:1/35 is trying to acquire lock: | (&tty->legacy_mutex){+.+.+.}, at: [<c14051e6>] tty_lock_nested+0x36/0x80 | | but task is already holding lock: | ((&tty->hangup_work)){+.+...}, at: [<c104f6e4>] process_one_work+0x124/0x5e0 | | which lock already depends on the new lock. | | the existing dependency chain (in reverse order) is: | | -> #2 ((&tty->hangup_work)){+.+...}: | [<c107fe74>] lock_acquire+0x84/0x190 | [<c104d82d>] flush_work+0x3d/0x240 | [<c12e6986>] tty_ldisc_flush_works+0x16/0x30 | [<c12e7861>] tty_ldisc_release+0x21/0x70 | [<c12e0dfc>] tty_release+0x35c/0x470 | [<c1105e28>] __fput+0xd8/0x270 | [<c1105fcd>] ____fput+0xd/0x10 | [<c1051dd9>] task_work_run+0xb9/0xf0 | [<c1002a51>] do_notify_resume+0x51/0x80 | [<c140550a>] work_notifysig+0x35/0x3b | | -> #1 (&tty->legacy_mutex/1){+.+...}: | [<c107fe74>] lock_acquire+0x84/0x190 | [<c140276c>] mutex_lock_nested+0x6c/0x2f0 | [<c14051e6>] tty_lock_nested+0x36/0x80 | [<c1405279>] tty_lock_pair+0x29/0x70 | [<c12e0bb8>] tty_release+0x118/0x470 | [<c1105e28>] __fput+0xd8/0x270 | [<c1105fcd>] ____fput+0xd/0x10 | [<c1051dd9>] task_work_run+0xb9/0xf0 | [<c1002a51>] do_notify_resume+0x51/0x80 | [<c140550a>] work_notifysig+0x35/0x3b | | -> #0 (&tty->legacy_mutex){+.+.+.}: | [<c107f3c9>] __lock_acquire+0x1189/0x16a0 | [<c107fe74>] lock_acquire+0x84/0x190 | [<c140276c>] mutex_lock_nested+0x6c/0x2f0 | [<c14051e6>] tty_lock_nested+0x36/0x80 | [<c140523f>] tty_lock+0xf/0x20 | [<c12df8e4>] __tty_hangup+0x54/0x410 | [<c12dfcb2>] do_tty_hangup+0x12/0x20 | [<c104f763>] process_one_work+0x1a3/0x5e0 | [<c104fec9>] worker_thread+0x119/0x3a0 | [<c1055084>] kthread+0x94/0xa0 | [<c140ca37>] ret_from_kernel_thread+0x1b/0x28 | |other info that might help us debug this: | |Chain exists of: | &tty->legacy_mutex --> &tty->legacy_mutex/1 --> (&tty->hangup_work) | | Possible unsafe locking scenario: | | CPU0 CPU1 | ---- ---- | lock((&tty->hangup_work)); | lock(&tty->legacy_mutex/1); | lock((&tty->hangup_work)); | lock(&tty->legacy_mutex); | | *** DEADLOCK *** Before the path mentioned tty_ldisc_release() look like this: | tty_ldisc_halt(tty); | tty_ldisc_flush_works(tty); | tty_lock(); As it can be seen, it first flushes the workqueue and then grabs the tty_lock. Now we grab the lock first: | tty_lock_pair(tty, o_tty); | tty_ldisc_halt(tty); | tty_ldisc_flush_works(tty); so lockdep's complaint seems valid. The earlier version of this patch took the ldisc_mutex since the other user of tty_ldisc_flush_works() (tty_set_ldisc()) did this. Peter Hurley then said that it is should not be requried. Since it wasn't done earlier, I dropped this part. The code under tty_ldisc_kill() was executed earlier with the tty lock taken so it is taken again. I was able to reproduce the deadlock on v3.8-rc1, this patch fixes the problem in my testcase. I didn't notice any problems so far. Cc: Alan Cox <alan@linux.intel.com> Cc: Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Heikki Krogerus authored
With ACPI 5.0 we can use the FixedDMA Resource Descriptor to extract the needed information for DMA support. Signed-off-by:
-
Heikki Krogerus authored
Add support for dmaengine API. The drivers can implement the struct uart_8250_dma member in struct uart_8250_port and 8250.c can take care of the rest. Signed-off-by:
-
Heikki Krogerus authored
This adds support for ACPI 5.0 enumerated Designware UARTs. ACPI does not deliver information about uart clk, so delivering it with the driver_data. Signed-off-by:
-
Heikki Krogerus authored
Designware UART provides optional Component Parameter Register that lists most of the capabilities of the UART, including FIFO size. This uses that register to set FIFO size for the port before registering it. Signed-off-by:
Jamie Iles <jamie@jamieiles.com> Acked-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Heikki Krogerus authored
Trivial cleanup. This makes it easier to add different methods to enumerate the device, for example ACPI 5.0 enumeration. Signed-off-by:
-
Heikki Krogerus authored
This needs to be done in order to later access the Designware specific registers. Signed-off-by:
-
Heikki Krogerus authored
Allow 8250.c to determine the port type for us. This allows the driver take advantage of FIFO on Designware UARTs that have it. Signed-off-by:
-
Heikki Krogerus authored
Modern UARTs are able to provide information about their capabilities such as FIFO size. This allows the drivers to deliver this information to 8250.c when they are registering ports. Signed-off-by:
-
Ivo Sieben authored
Before waking up the tty line discipline idle queue first check if the queue is active (non empty). This prevents unnecessary entering the critical section in the wake_up() function and therefore avoid needless scheduling overhead on a PREEMPT_RT system caused by two processes being in the same critical section. Signed-off-by:
Ivo Sieben <meltedpianoman@gmail.com> Signed-off-by:
-
Chen Gang authored
for extern function uart_remove_one_port: need check pointer whether be NULL, before the main work. just like what the other extern function uart_add_one_port has done. uart_add_one_port and uart_remove_one_port are pair information: for the callers (such as drivers/tty/serial/jsm: jsm_tty.c, jsm_driver.c) they realy assume that: they still can call uart_remove_one_port, after uart_add_one_port failed we (as an extern function), have to understand it (just like kfree). Signed-off-by:Chen Gang <gang.chen@asianux.com> Signed-off-by:
-
Wei Yongjun authored
Use for_each_compatible_node() macro instead of open coding it. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Acked-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
-
Alexander Shiyan authored
Signed-off-by:
Alexander Shiyan <shc_work@mail.ru> Signed-off-by:
-
Alexander Shiyan authored
This patch adds support for polling work mode, i.e. system is perform periodical check chip status when IRQ-line is not connected to CPU. Signed-off-by:
-
Quoc-Viet Nguyen authored
Signed-off-by:
Quoc-Viet Nguyen <afelion@gmail.com> Signed-off-by:
-
Jiri Slaby authored
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: -
Cong Ding authored
Macros should be enclosed in parenthesis Signed-off-by:
-
Cong Ding authored
spaces are used for indent in 3 places of tty/pty.c, we change it to tab. Signed-off-by:
-
Cong Ding authored
the "\n" in panic message is excess, so we remove it in tty/pty.c as what it is used in other places. Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit f96f7f7f , at the request of Jin. Cc: xiaojin <jin.xiao@intel.com> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Greg Kroah-Hartman authored
Some __devexit markings came in from an older patch, this removes them. Reported-by:
-
Jiri Slaby authored
We test for !dc twice, remove the second test. Coverity found this. Signed-off-by:
-
Jiri Slaby authored
info in synclink bottom-halves cannot be NULL because it is taken from work_struct using container_of. Remove the tests. Signed-off-by:
-
Jiri Slaby authored
Now, the tty is not needed at all places in the ISR. So we can just request in on demand when really needed. This cleans TX and RX paths a bit as the indentation level can be dropped by two now when we also invert the char_count if condition. Signed-off-by:
-
