<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/tty/serial/sh-sci.c, branch v4.14.263</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-07-20T14:17:30+00:00</updated>
<entry>
<title>serial: sh-sci: Stop dmaengine transfer in sci_stop_tx()</title>
<updated>2021-07-20T14:17:30+00:00</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2021-06-10T11:08:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=13b5a80be5443d81b3ccd0e5bb3c5110f326a004'/>
<id>urn:sha1:13b5a80be5443d81b3ccd0e5bb3c5110f326a004</id>
<content type='text'>
commit 08a84410a04f05c7c1b8e833f552416d8eb9f6fe upstream.

Stop dmaengine transfer in sci_stop_tx(). Otherwise, the following
message is possible output when system enters suspend and while
transferring data, because clearing TIE bit in SCSCR is not able to
stop any dmaengine transfer.

    sh-sci e6550000.serial: ttySC1: Unable to drain transmitter

Note that this driver has already used some #ifdef in the .c file
so that this patch also uses #ifdef to fix the issue. Otherwise,
build errors happens if the CONFIG_SERIAL_SH_SCI_DMA is disabled.

Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
Cc: &lt;stable@vger.kernel.org&gt; # v4.9+
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Link: https://lore.kernel.org/r/20210610110806.277932-1-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial: sh-sci: Fix off-by-one error in FIFO threshold register setting</title>
<updated>2021-06-03T06:36:16+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2021-05-10T12:07:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e635b8ab29ca5551a7494df64f30202d8df97e44'/>
<id>urn:sha1:e635b8ab29ca5551a7494df64f30202d8df97e44</id>
<content type='text'>
commit 2ea2e019c190ee3973ef7bcaf829d8762e56e635 upstream.

The Receive FIFO Data Count Trigger field (RTRG[6:0]) in the Receive
FIFO Data Count Trigger Register (HSRTRGR) of HSCIF can only hold values
ranging from 0-127.  As the FIFO size is equal to 128 on HSCIF, the user
can write an out-of-range value, touching reserved bits.

Fix this by limiting the trigger value to the FIFO size minus one.
Reverse the order of the checks, to avoid rx_trig becoming zero if the
FIFO size is one.

Note that this change has no impact on other SCIF variants, as their
maximum supported trigger value is lower than the FIFO size anyway, and
the code below takes care of enforcing these limits.

Fixes: a380ed461f66d1b8 ("serial: sh-sci: implement FIFO threshold register setting")
Reported-by: Linh Phung &lt;linh.phung.jy@renesas.com&gt;
Reviewed-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Reviewed-by: Ulrich Hecht &lt;uli+renesas@fpond.eu&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/5eff320aef92ffb33d00e57979fd3603bbb4a70f.1620648218.git.geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: sh-sci: Make sure status register SCxSR is read in correct sequence</title>
<updated>2020-05-02T15:24:38+00:00</updated>
<author>
<name>Kazuhiro Fujita</name>
<email>kazuhiro.fujita.jg@renesas.com</email>
</author>
<published>2020-03-27T18:17:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c7dd89cafddb1434a9e4475049d1ba74e443b1d6'/>
<id>urn:sha1:c7dd89cafddb1434a9e4475049d1ba74e443b1d6</id>
<content type='text'>
commit 3dc4db3662366306e54ddcbda4804acb1258e4ba upstream.

For SCIF and HSCIF interfaces the SCxSR register holds the status of
data that is to be read next from SCxRDR register, But where as for
SCIFA and SCIFB interfaces SCxSR register holds status of data that is
previously read from SCxRDR register.

This patch makes sure the status register is read depending on the port
types so that errors are caught accordingly.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Kazuhiro Fujita &lt;kazuhiro.fujita.jg@renesas.com&gt;
Signed-off-by: Hao Bui &lt;hao.bui.yg@renesas.com&gt;
Signed-off-by: KAZUMI HARADA &lt;kazumi.harada.rh@renesas.com&gt;
Signed-off-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt;
Tested-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Link: https://lore.kernel.org/r/1585333048-31828-1-git-send-email-kazuhiro.fujita.jg@renesas.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial: sh-sci: Fix TX DMA buffer flushing and workqueue races</title>
<updated>2019-07-31T05:28:54+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2019-06-24T12:35:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b2be79183176e3116ad660c74d923e6528c6a79b'/>
<id>urn:sha1:b2be79183176e3116ad660c74d923e6528c6a79b</id>
<content type='text'>
[ Upstream commit 8493eab02608b0e82f67b892aa72882e510c31d0 ]

When uart_flush_buffer() is called, the .flush_buffer() callback zeroes
the tx_dma_len field.  This may race with the work queue function
handling transmit DMA requests:

  1. If the buffer is flushed before the first DMA API call,
     dmaengine_prep_slave_single() may be called with a zero length,
     causing the DMA request to never complete, leading to messages
     like:

        rcar-dmac e7300000.dma-controller: Channel Address Error happen

     and, with debug enabled:

	sh-sci e6e88000.serial: sci_dma_tx_work_fn: ffff800639b55000: 0...0, cookie 126

     and DMA timeouts.

  2. If the buffer is flushed after the first DMA API call, but before
     the second, dma_sync_single_for_device() may be called with a zero
     length, causing the transmit data not to be flushed to RAM, and
     leading to stale data being output.

Fix this by:
  1. Letting sci_dma_tx_work_fn() return immediately if the transmit
     buffer is empty,
  2. Extending the critical section to cover all DMA preparational work,
     so tx_dma_len stays consistent for all of it,
  3. Using local copies of circ_buf.head and circ_buf.tail, to make sure
     they match the actual operation above.

Reported-by: Eugeniu Rosca &lt;erosca@de.adit-jv.com&gt;
Suggested-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Reviewed-by: Eugeniu Rosca &lt;erosca@de.adit-jv.com&gt;
Tested-by: Eugeniu Rosca &lt;erosca@de.adit-jv.com&gt;
Link: https://lore.kernel.org/r/20190624123540.20629-2-geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>serial: sh-sci: Terminate TX DMA during buffer flushing</title>
<updated>2019-07-31T05:28:54+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2019-06-24T12:35:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=484b44614f16207225dac466a548797158fe29b2'/>
<id>urn:sha1:484b44614f16207225dac466a548797158fe29b2</id>
<content type='text'>
[ Upstream commit 775b7ffd7d6d5db320d99b0a485c51e04dfcf9f1 ]

While the .flush_buffer() callback clears sci_port.tx_dma_len since
commit 1cf4a7efdc71cab8 ("serial: sh-sci: Fix race condition causing
garbage during shutdown"), it does not terminate a transmit DMA
operation that may be in progress.

Fix this by terminating any pending DMA operations, and resetting the
corresponding cookie.

Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Reviewed-by: Eugeniu Rosca &lt;erosca@de.adit-jv.com&gt;
Tested-by: Eugeniu Rosca &lt;erosca@de.adit-jv.com&gt;

Link: https://lore.kernel.org/r/20190624123540.20629-3-geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>serial: sh-sci: disable DMA for uart_console</title>
<updated>2019-06-09T07:18:18+00:00</updated>
<author>
<name>George G. Davis</name>
<email>george_davis@mentor.com</email>
</author>
<published>2019-05-15T03:29:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b69101c243a20781c7c0839c0026bc5dfe18fcea'/>
<id>urn:sha1:b69101c243a20781c7c0839c0026bc5dfe18fcea</id>
<content type='text'>
commit 099506cbbc79c0bd52b19cb6b930f256dabc3950 upstream.

As noted in commit 84b40e3b57ee ("serial: 8250: omap: Disable DMA for
console UART"), UART console lines use low-level PIO only access functions
which will conflict with use of the line when DMA is enabled, e.g. when
the console line is also used for systemd messages. So disable DMA
support for UART console lines.

Reported-by: Michael Rodin &lt;mrodin@de.adit-jv.com&gt;
Link: https://patchwork.kernel.org/patch/10929511/
Tested-by: Eugeniu Rosca &lt;erosca@de.adit-jv.com&gt;
Reviewed-by: Simon Horman &lt;horms+renesas@verge.net.au&gt;
Reviewed-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Cc: stable@vger.kernel.org
Signed-off-by: George G. Davis &lt;george_davis@mentor.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial: sh-sci: Fix setting SCSCR_TIE while transferring data</title>
<updated>2019-04-03T04:25:18+00:00</updated>
<author>
<name>Hoan Nguyen An</name>
<email>na-hoan@jinso.co.jp</email>
</author>
<published>2019-03-18T09:26:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=be8c93469b723a77168953bced05bc33048f5af5'/>
<id>urn:sha1:be8c93469b723a77168953bced05bc33048f5af5</id>
<content type='text'>
commit 93bcefd4c6bad4c69dbc4edcd3fbf774b24d930d upstream.

We disable transmission interrupt (clear SCSCR_TIE) after all data has been transmitted
(if uart_circ_empty(xmit)). While transmitting, if the data is still in the tty buffer,
re-enable the SCSCR_TIE bit, which was done at sci_start_tx().
This is unnecessary processing, wasting CPU operation if the data transmission length is large.
And further, transmit end, FIFO empty bits disabling have also been performed in the step above.

Signed-off-by: Hoan Nguyen An &lt;na-hoan@jinso.co.jp&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial: sh-sci: Stop RX FIFO timer during port shutdown</title>
<updated>2018-10-04T00:00:46+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2018-07-06T09:08:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=72bad20e9316bf6203def57256a5ade158585558'/>
<id>urn:sha1:72bad20e9316bf6203def57256a5ade158585558</id>
<content type='text'>
[ Upstream commit c5a9262fa8bfed0dddc7466ef10fcd292e2af61b ]

The RX FIFO timer may be armed when the port is shut down, hence the
timer function may still be called afterwards.

Fix this race condition by deleting the timer during port shutdown.

Fixes: 039403765e5da3c6 ("serial: sh-sci: SCIFA/B RX FIFO software timeout")
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Reviewed-by: Simon Horman &lt;horms+renesas@verge.net.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: sh-sci: Use spin_{try}lock_irqsave instead of open coding version</title>
<updated>2018-07-03T09:24:47+00:00</updated>
<author>
<name>Daniel Wagner</name>
<email>daniel.wagner@siemens.com</email>
</author>
<published>2018-05-08T08:55:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=980899da5dc9249aef2329ae662f16a97062e8b1'/>
<id>urn:sha1:980899da5dc9249aef2329ae662f16a97062e8b1</id>
<content type='text'>
commit 8afb1d2c12163f77777f84616a8e9444d0050ebe upstream.

Commit 40f70c03e33a ("serial: sh-sci: add locking to console write
function to avoid SMP lockup") copied the strategy to avoid locking
problems in conjuncture with the console from the UART8250
driver. Instead using directly spin_{try}lock_irqsave(),
local_irq_save() followed by spin_{try}lock() was used. While this is
correct on mainline, for -rt it is a problem. spin_{try}lock() will
check if it is running in a valid context. Since the local_irq_save()
has already been executed, the context has changed and
spin_{try}lock() will complain. The reason why spin_{try}lock()
complains is that on -rt the spin locks are turned into mutexes and
therefore can sleep. Sleeping with interrupts disabled is not valid.

BUG: sleeping function called from invalid context at /home/wagi/work/rt/v4.4-cip-rt/kernel/locking/rtmutex.c:995
in_atomic(): 0, irqs_disabled(): 128, pid: 778, name: irq/76-eth0
CPU: 0 PID: 778 Comm: irq/76-eth0 Not tainted 4.4.126-test-cip22-rt14-00403-gcd03665c8318 #12
Hardware name: Generic RZ/G1 (Flattened Device Tree)
Backtrace:
[&lt;c00140a0&gt;] (dump_backtrace) from [&lt;c001424c&gt;] (show_stack+0x18/0x1c)
 r7:c06b01f0 r6:60010193 r5:00000000 r4:c06b01f0
[&lt;c0014234&gt;] (show_stack) from [&lt;c01d3c94&gt;] (dump_stack+0x78/0x94)
[&lt;c01d3c1c&gt;] (dump_stack) from [&lt;c004c134&gt;] (___might_sleep+0x134/0x194)
 r7:60010113 r6:c06d3559 r5:00000000 r4:ffffe000
[&lt;c004c000&gt;] (___might_sleep) from [&lt;c04ded60&gt;] (rt_spin_lock+0x20/0x74)
 r5:c06f4d60 r4:c06f4d60
[&lt;c04ded40&gt;] (rt_spin_lock) from [&lt;c02577e4&gt;] (serial_console_write+0x100/0x118)
 r5:c06f4d60 r4:c06f4d60
[&lt;c02576e4&gt;] (serial_console_write) from [&lt;c0061060&gt;] (call_console_drivers.constprop.15+0x10c/0x124)
 r10:c06d2894 r9:c04e18b0 r8:00000028 r7:00000000 r6:c06d3559 r5:c06d2798
 r4:c06b9914 r3:c02576e4
[&lt;c0060f54&gt;] (call_console_drivers.constprop.15) from [&lt;c0062984&gt;] (console_unlock+0x32c/0x430)
 r10:c06d30d8 r9:00000028 r8:c06dd518 r7:00000005 r6:00000000 r5:c06d2798
 r4:c06d2798 r3:00000028
[&lt;c0062658&gt;] (console_unlock) from [&lt;c0062e1c&gt;] (vprintk_emit+0x394/0x4f0)
 r10:c06d2798 r9:c06d30ee r8:00000006 r7:00000005 r6:c06a78fc r5:00000027
 r4:00000003
[&lt;c0062a88&gt;] (vprintk_emit) from [&lt;c0062fa0&gt;] (vprintk+0x28/0x30)
 r10:c060bd46 r9:00001000 r8:c06b9a90 r7:c06b9a90 r6:c06b994c r5:c06b9a3c
 r4:c0062fa8
[&lt;c0062f78&gt;] (vprintk) from [&lt;c0062fb8&gt;] (vprintk_default+0x10/0x14)
[&lt;c0062fa8&gt;] (vprintk_default) from [&lt;c009cd30&gt;] (printk+0x78/0x84)
[&lt;c009ccbc&gt;] (printk) from [&lt;c025afdc&gt;] (credit_entropy_bits+0x17c/0x2cc)
 r3:00000001 r2:decade60 r1:c061a5ee r0:c061a523
 r4:00000006
[&lt;c025ae60&gt;] (credit_entropy_bits) from [&lt;c025bf74&gt;] (add_interrupt_randomness+0x160/0x178)
 r10:466e7196 r9:1f536000 r8:fffeef74 r7:00000000 r6:c06b9a60 r5:c06b9a3c
 r4:dfbcf680
[&lt;c025be14&gt;] (add_interrupt_randomness) from [&lt;c006536c&gt;] (irq_thread+0x1e8/0x248)
 r10:c006537c r9:c06cdf21 r8:c0064fcc r7:df791c24 r6:df791c00 r5:ffffe000
 r4:df525180
[&lt;c0065184&gt;] (irq_thread) from [&lt;c003fba4&gt;] (kthread+0x108/0x11c)
 r10:00000000 r9:00000000 r8:c0065184 r7:df791c00 r6:00000000 r5:df791d00
 r4:decac000
[&lt;c003fa9c&gt;] (kthread) from [&lt;c00101b8&gt;] (ret_from_fork+0x14/0x3c)
 r8:00000000 r7:00000000 r6:00000000 r5:c003fa9c r4:df791d00

Cc: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Daniel Wagner &lt;daniel.wagner@siemens.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>serial: sh-sci: Stop using printk format %pCr</title>
<updated>2018-06-16T07:45:16+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2018-06-01T09:28:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=95b8204b4491ae54c9024e695e6b327013e53fe0'/>
<id>urn:sha1:95b8204b4491ae54c9024e695e6b327013e53fe0</id>
<content type='text'>
commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.

Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.

Replace it by open-coding the operation.  This is safe here, as the code
runs in task context.

Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas@glider.be
To: Jia-Ju Bai &lt;baijiaju1990@gmail.com&gt;
To: Jonathan Corbet &lt;corbet@lwn.net&gt;
To: Michael Turquette &lt;mturquette@baylibre.com&gt;
To: Stephen Boyd &lt;sboyd@kernel.org&gt;
To: Zhang Rui &lt;rui.zhang@intel.com&gt;
To: Eduardo Valentin &lt;edubezval@gmail.com&gt;
To: Eric Anholt &lt;eric@anholt.net&gt;
To: Stefan Wahren &lt;stefan.wahren@i2se.com&gt;
To: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Sergey Senozhatsky &lt;sergey.senozhatsky.work@gmail.com&gt;
Cc: Petr Mladek &lt;pmladek@suse.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: linux-doc@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Cc: stable@vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Petr Mladek &lt;pmladek@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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