<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/tty/serial, branch v3.0.85</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/tty/serial?h=v3.0.85</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/tty/serial?h=v3.0.85'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-07-03T18:03:24Z</updated>
<entry>
<title>pch_uart: fix a deadlock when pch_uart as console</title>
<updated>2013-07-03T18:03:24Z</updated>
<author>
<name>Liang Li</name>
<email>liang.li@windriver.com</email>
</author>
<published>2013-01-19T09:52:10Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=db61e4ec623437237d05b5ab8ce97d9377682de2'/>
<id>urn:sha1:db61e4ec623437237d05b5ab8ce97d9377682de2</id>
<content type='text'>
commit 384e301e3519599b000c1a2ecd938b533fc15d85 upstream.

When we use pch_uart as system console like 'console=ttyPCH0,115200',
then 'send break' to it. We'll encounter the deadlock on a cpu/core,
with interrupts disabled on the core. When we happen to have all irqs
affinity to cpu0 then the deadlock on cpu0 actually deadlock whole
system.

In pch_uart_interrupt, we have spin_lock_irqsave(&amp;priv-&gt;lock, flags)
then call pch_uart_err_ir when break is received. Then the call to
dev_err would actually call to pch_console_write then we'll run into
another spin_lock(&amp;priv-&gt;lock), with interrupts disabled.

So in the call sequence lead by pch_uart_interrupt, we should be
carefully to call functions that will 'print message to console' only
in case the uart port is not being used as serial console.

Signed-off-by: Liang Li &lt;liang.li@windriver.com&gt;
Cc: Yijing Wang &lt;wangyijing@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial_core.c: add put_device() after device_find_child()</title>
<updated>2013-05-08T02:57:22Z</updated>
<author>
<name>Federico Vaga</name>
<email>federico.vaga@gmail.com</email>
</author>
<published>2013-04-15T14:01:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=70f4184b8eeb04a2b8ad2778a76ffac3a0d4e4d2'/>
<id>urn:sha1:70f4184b8eeb04a2b8ad2778a76ffac3a0d4e4d2</id>
<content type='text'>
commit 5a65dcc04cda41f4122aacc37a5a348454645399 upstream.

The serial core uses device_find_child() but does not drop the reference to
the retrieved child after using it. This patch add the missing put_device().

What I have done to test this issue.

I used a machine with an AMBA PL011 serial driver. I tested the patch on
next-20120408 because the last branch [next-20120415] does not boot on this
board.

For test purpose, I added some pr_info() messages to print the refcount
after device_find_child() (lines: 1937,2009), and after put_device()
(lines: 1947, 2021).

Boot the machine *without* put_device(). Then:

echo reboot &gt; /sys/power/disk
echo disk &gt; /sys/power/state
[   87.058575] uart_suspend_port:1937 refcount 4
[   87.058582] uart_suspend_port:1947 refcount 4
[   87.098083] uart_resume_port:2009refcount 5
[   87.098088] uart_resume_port:2021 refcount 5

echo disk &gt; /sys/power/state
[  103.055574] uart_suspend_port:1937 refcount 6
[  103.055580] uart_suspend_port:1947 refcount 6
[  103.095322] uart_resume_port:2009 refcount 7
[  103.095327] uart_resume_port:2021 refcount 7

echo disk &gt; /sys/power/state
[  252.459580] uart_suspend_port:1937 refcount 8
[  252.459586] uart_suspend_port:1947 refcount 8
[  252.499611] uart_resume_port:2009 refcount 9
[  252.499616] uart_resume_port:2021 refcount 9

The refcount continuously increased.

Boot the machine *with* this patch. Then:

echo reboot &gt; /sys/power/disk
echo disk &gt; /sys/power/state
[  159.333559] uart_suspend_port:1937 refcount 4
[  159.333566] uart_suspend_port:1947 refcount 3
[  159.372751] uart_resume_port:2009 refcount 4
[  159.372755] uart_resume_port:2021 refcount 3

echo disk &gt; /sys/power/state
[  185.713614] uart_suspend_port:1937 refcount 4
[  185.713621] uart_suspend_port:1947 refcount 3
[  185.752935] uart_resume_port:2009 refcount 4
[  185.752940] uart_resume_port:2021 refcount 3

echo disk &gt; /sys/power/state
[  207.458584] uart_suspend_port:1937 refcount 4
[  207.458591] uart_suspend_port:1947 refcount 3
[  207.498598] uart_resume_port:2009 refcount 4
[  207.498605] uart_resume_port:2021 refcount 3

The refcount correctly handled.

Signed-off-by: Federico Vaga &lt;federico.vaga@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sunsu: Fix panic in case of nonexistent port at "console=ttySY" cmdline option</title>
<updated>2013-03-28T19:05:59Z</updated>
<author>
<name>Tkhai Kirill</name>
<email>tkhai@yandex.ru</email>
</author>
<published>2013-02-23T23:01:15Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bf40057118cc5392a0fe4bd77b1f65dd49bcc8d2'/>
<id>urn:sha1:bf40057118cc5392a0fe4bd77b1f65dd49bcc8d2</id>
<content type='text'>
[ Upstream commit cb29529ea0030e60ef1bbbf8399a43d397a51526 ]

If a machine has X (X &lt; 4) sunsu ports and cmdline
option "console=ttySY" is passed, where X &lt; Y &lt;= 4,
than the following panic happens:

Unable to handle kernel NULL pointer dereference
TPC: &lt;sunsu_console_setup+0x78/0xe0&gt;
RPC: &lt;sunsu_console_setup+0x74/0xe0&gt;
I7: &lt;register_console+0x378/0x3e0&gt;
Call Trace:
 [0000000000453a38] register_console+0x378/0x3e0
 [0000000000576fa0] uart_add_one_port+0x2e0/0x340
 [000000000057af40] su_probe+0x160/0x2e0
 [00000000005b8a4c] platform_drv_probe+0xc/0x20
 [00000000005b6c2c] driver_probe_device+0x12c/0x220
 [00000000005b6da8] __driver_attach+0x88/0xa0
 [00000000005b4df4] bus_for_each_dev+0x54/0xa0
 [00000000005b5a54] bus_add_driver+0x154/0x260
 [00000000005b7190] driver_register+0x50/0x180
 [00000000006d250c] sunsu_init+0x18c/0x1e0
 [00000000006c2668] do_one_initcall+0xe8/0x160
 [00000000006c282c] kernel_init_freeable+0x12c/0x1e0
 [0000000000603764] kernel_init+0x4/0x100
 [0000000000405f64] ret_from_syscall+0x1c/0x2c
 [0000000000000000]           (null)

1)Fix the panic;
2)Increment registered port number every successful
probe.

Signed-off-by: Kirill Tkhai &lt;tkhai@yandex.ru&gt;
CC: David Miller &lt;davem@davemloft.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: serial: fix typo "ARCH_S5P6450"</title>
<updated>2013-03-20T19:58:51Z</updated>
<author>
<name>Paul Bolle</name>
<email>pebolle@tiscali.nl</email>
</author>
<published>2013-03-09T22:16:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e88da4a932b6f524afdf26dadb8a63f0afcfcd14'/>
<id>urn:sha1:e88da4a932b6f524afdf26dadb8a63f0afcfcd14</id>
<content type='text'>
commit 827aa0d36d486f359808c8fb931cf7a71011a09d upstream.

This could have been either ARCH_S5P64X0 or CPU_S5P6450. Looking at
commit 2555e663b367b8d555e76023f4de3f6338c28d6c ("ARM: S5P64X0: Add UART
serial support for S5P6450") - which added this typo - makes clear this
should be CPU_S5P6450.

Signed-off-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
Acked-by: Kukjin Kim &lt;kgene.kim@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial: 8250, increase PASS_LIMIT</title>
<updated>2013-01-28T04:46:29Z</updated>
<author>
<name>Jiri Slaby</name>
<email>jirislaby@gmail.com</email>
</author>
<published>2011-06-05T20:51:49Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c9d332c77f72e7d9643116e53ae0c1e2bebd3156'/>
<id>urn:sha1:c9d332c77f72e7d9643116e53ae0c1e2bebd3156</id>
<content type='text'>
commit e7328ae1848966181a7ac47e8ae6cddbd2cf55f3 upstream.

With virtual machines like qemu, it's pretty common to see "too much
work for irq4" messages nowadays. This happens when a bunch of output
is printed on the emulated serial console. This is caused by too low
PASS_LIMIT. When ISR loops more than the limit, it spits the message.

I've been using a kernel with doubled the limit and I couldn't see no
problems. Maybe it's time to get rid of the message now?

Signed-off-by: Jiri Slaby &lt;jirislaby@gmail.com&gt;
Cc: Alan Cox &lt;alan@linux.intel.com&gt;
Cc: Ram Gupta &lt;ram.gupta5@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial:ifx6x60:Delete SPI timer when shut down port</title>
<updated>2013-01-21T19:45:00Z</updated>
<author>
<name>chao bi</name>
<email>chao.bi@intel.com</email>
</author>
<published>2012-12-12T03:40:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=904e718cc7b18ea8db425d51e9601fb21699892e'/>
<id>urn:sha1:904e718cc7b18ea8db425d51e9601fb21699892e</id>
<content type='text'>
commit 014b9b4ce84281ccb3d723c792bed19815f3571a upstream.

When shut down SPI port, it's possible that MRDY has been asserted and a SPI
timer was activated waiting for SRDY assert, in the case, it needs to delete
this timer.

Signed-off-by: Chen Jun &lt;jun.d.chen@intel.com&gt;
Signed-off-by: channing &lt;chao.bi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial: set correct baud_base for EXSYS EX-41092 Dual 16950</title>
<updated>2012-10-07T15:27:25Z</updated>
<author>
<name>Flavio Leitner</name>
<email>fbl@redhat.com</email>
</author>
<published>2012-09-22T00:04:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d482e8f2f8afc2f6fd0a1e450b0516c9ae7fef82'/>
<id>urn:sha1:d482e8f2f8afc2f6fd0a1e450b0516c9ae7fef82</id>
<content type='text'>
commit 26e8220adb0aec43b7acafa0f1431760eee28522 upstream.

Apparently the same card model has two IDs, so this patch
complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2
adding the missing one.

Signed-off-by: Flavio Leitner &lt;fbl@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial: pl011: handle corruption at high clock speeds</title>
<updated>2012-10-07T15:27:25Z</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2012-09-26T15:21:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f580d511e9fd963d75464de030c3b8de5715ee09'/>
<id>urn:sha1:f580d511e9fd963d75464de030c3b8de5715ee09</id>
<content type='text'>
commit c5dd553b9fd069892c9e2de734f4f604e280fa7a upstream.

This works around a few glitches in the ST version of the PL011
serial driver when using very high baud rates, as we do in the
Ux500: 3, 3.25, 4 and 4.05 Mbps.

Problem Observed/rootcause:

When using high baud-rates, and the baudrate*8 is getting close to
the provided clock frequency (so a division factor close to 1), when
using bursts of characters (so they are abutted), then it seems as if
there is not enough time to detect the beginning of the start-bit which
is a timing reference for the entire character, and thus the sampling
moment of character bits is moving towards the end of each bit, instead
of the middle.

Fix:
Increase slightly the RX baud rate of the UART above the theoretical
baudrate by 5%. This will definitely give more margin time to the
UART_RX to correctly sample the data at the middle of the bit period.

Also fix the ages old copy-paste error in the very stressed comment,
it's referencing the registers used in the PL010 driver rather than
the PL011 ones.

Signed-off-by: Guillaume Jaunet &lt;guillaume.jaunet@stericsson.com&gt;
Signed-off-by: Christophe Arnal &lt;christophe.arnal@stericsson.com&gt;
Signed-off-by: Matthias Locher &lt;matthias.locher@stericsson.com&gt;
Signed-off-by: Rajanikanth HV &lt;rajanikanth.hv@stericsson.com&gt;
Cc: Bibek Basu &lt;bibek.basu@stericsson.com&gt;
Cc: Par-Gunnar Hjalmdahl &lt;par-gunnar.hjalmdahl@stericsson.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>pch_uart: Fix parity setting issue</title>
<updated>2012-10-02T16:47:53Z</updated>
<author>
<name>Tomoya MORINAGA</name>
<email>tomoya.rohm@gmail.com</email>
</author>
<published>2012-07-06T08:19:43Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b960ba52595157ae215c4e899e9da99fbc81959a'/>
<id>urn:sha1:b960ba52595157ae215c4e899e9da99fbc81959a</id>
<content type='text'>
commit 38bd2a1ac736901d1cf4971c78ef952ba92ef78b upstream.

Parity Setting value is reverse.
E.G. In case of setting ODD parity, EVEN value is set.
This patch inverts "if" condition.

Signed-off-by: Tomoya MORINAGA &lt;tomoya.rohm@gmail.com&gt;
Acked-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>pch_uart: Fix rx error interrupt setting issue</title>
<updated>2012-10-02T16:47:53Z</updated>
<author>
<name>Tomoya MORINAGA</name>
<email>tomoya.rohm@gmail.com</email>
</author>
<published>2012-07-06T08:19:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4b14f6f47a76380216419e70a3d569eed730a47b'/>
<id>urn:sha1:4b14f6f47a76380216419e70a3d569eed730a47b</id>
<content type='text'>
commit 9539dfb7ac1c84522fe1f79bb7dac2990f3de44a upstream.

Rx Error interrupt(E.G. parity error) is not enabled.
So, when parity error occurs, error interrupt is not occurred.
As a result, the received data is not dropped.

This patch adds enable/disable rx error interrupt code.

Signed-off-by: Tomoya MORINAGA &lt;tomoya.rohm@gmail.com&gt;
Acked-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
