linux-toradex.git/drivers/tty/serial/sh-sci.c, branch v4.4.93 Linux kernel for Apalis and Colibri modules serial: sh-sci: Fix panic when serial console and DMA are enabled 2017-06-14T11:16:26+00:00 Takatoshi Akiyama takatoshi.akiyama.kj@ps.hitachi-solutions.com 2017-02-27T06:56:31+00:00 3c0fcb52674afb2a88097510203678fe3d441c71 commit 3c9101766b502a0163d1d437fada5801cf616be2 upstream. This patch fixes an issue that kernel panic happens when DMA is enabled and we press enter key while the kernel booting on the serial console. * An interrupt may occur after sci_request_irq(). * DMA transfer area is initialized by setup_timer() in sci_request_dma() and used in interrupt. If an interrupt occurred between sci_request_irq() and setup_timer() in sci_request_dma(), DMA transfer area has not been initialized yet. So, this patch changes the order of sci_request_irq() and sci_request_dma(). Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.") Signed-off-by: Takatoshi Akiyama <takatoshi.akiyama.kj@ps.hitachi-solutions.com> [Shimoda changes the commit log] Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3c9101766b502a0163d1d437fada5801cf616be2 upstream.

This patch fixes an issue that kernel panic happens when DMA is enabled
and we press enter key while the kernel booting on the serial console.

* An interrupt may occur after sci_request_irq().
* DMA transfer area is initialized by setup_timer() in sci_request_dma()
  and used in interrupt.

If an interrupt occurred between sci_request_irq() and setup_timer() in
sci_request_dma(), DMA transfer area has not been initialized yet.
So, this patch changes the order of sci_request_irq() and
sci_request_dma().

Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
Signed-off-by: Takatoshi Akiyama <takatoshi.akiyama.kj@ps.hitachi-solutions.com>
[Shimoda changes the commit log]
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: sh-sci: Remove cpufreq notifier to fix crash/deadlock 2016-05-04T21:48:52+00:00 Geert Uytterhoeven geert+renesas@glider.be 2016-01-05T18:36:37+00:00 447ea0a34b78213dd668bf7d0a2b7add1c5675e6 commit ff1cab374ad98f4b9f408525ca9c08992b4ed784 upstream. The BSP team noticed that there is spin/mutex lock issue on sh-sci when CPUFREQ is used. The issue is that the notifier function may call mutex_lock() while the spinlock is held, which can lead to a BUG(). This may happen if CPUFREQ is changed while another CPU calls clk_get_rate(). Taking the spinlock was added to the notifier function in commit e552de2413edad1a ("sh-sci: add platform device private data"), to protect the list of serial ports against modification during traversal. At that time the Common Clock Framework didn't exist yet, and clk_get_rate() just returned clk->rate without taking a mutex. Note that since commit d535a2305facf9b4 ("serial: sh-sci: Require a device per port mapping."), there's no longer a list of serial ports to traverse, and taking the spinlock became superfluous. To fix the issue, just remove the cpufreq notifier: 1. The notifier doesn't work correctly: all it does is update stored clock rates; it does not update the divider in the hardware. The divider will only be updated when calling sci_set_termios(). I believe this was broken back in 2004, when the old drivers/char/sh-sci.c driver (where the notifier did update the divider) was replaced by drivers/serial/sh-sci.c (where the notifier just updated port->uartclk). Cfr. full-history-linux commits 6f8deaef2e9675d9 ("[PATCH] sh: port sh-sci driver to the new API") and 3f73fe878dc9210a ("[PATCH] Remove old sh-sci driver"). 2. On modern SoCs, the sh-sci parent clock rate is no longer related to the CPU clock rate anyway, so using a cpufreq notifier is futile. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ff1cab374ad98f4b9f408525ca9c08992b4ed784 upstream.

The BSP team noticed that there is spin/mutex lock issue on sh-sci when
CPUFREQ is used.  The issue is that the notifier function may call
mutex_lock() while the spinlock is held, which can lead to a BUG().
This may happen if CPUFREQ is changed while another CPU calls
clk_get_rate().

Taking the spinlock was added to the notifier function in commit
e552de2413edad1a ("sh-sci: add platform device private data"), to
protect the list of serial ports against modification during traversal.
At that time the Common Clock Framework didn't exist yet, and
clk_get_rate() just returned clk->rate without taking a mutex.
Note that since commit d535a2305facf9b4 ("serial: sh-sci: Require a
device per port mapping."), there's no longer a list of serial ports to
traverse, and taking the spinlock became superfluous.

To fix the issue, just remove the cpufreq notifier:
  1. The notifier doesn't work correctly: all it does is update stored
     clock rates; it does not update the divider in the hardware.
     The divider will only be updated when calling sci_set_termios().
     I believe this was broken back in 2004, when the old
     drivers/char/sh-sci.c driver (where the notifier did update the
     divider) was replaced by drivers/serial/sh-sci.c (where the
     notifier just updated port->uartclk).
     Cfr. full-history-linux commits 6f8deaef2e9675d9 ("[PATCH] sh: port
     sh-sci driver to the new API") and 3f73fe878dc9210a ("[PATCH]
     Remove old sh-sci driver").
  2. On modern SoCs, the sh-sci parent clock rate is no longer related
     to the CPU clock rate anyway, so using a cpufreq notifier is
     futile.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: sh-sci: Fix length of scatterlist 2015-12-13T05:42:31+00:00 Yoshihiro Shimoda yoshihiro.shimoda.uh@renesas.com 2015-12-04T14:21:19+00:00 d09959e7529451a1c302197fb1396ed5b835f6d3 This patch fixes an issue that the "length" of scatterlist should be set using sg_dma_len(). Otherwise, a dmaengine driver cannot work correctly if CONFIG_NEED_SG_DMA_LENGTH=y. Fixes: 7b39d90184 (serial: sh-sci: Fix NULL pointer dereference if HIGHMEM is enabled) Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch fixes an issue that the "length" of scatterlist should be
set using sg_dma_len(). Otherwise, a dmaengine driver cannot work
correctly if CONFIG_NEED_SG_DMA_LENGTH=y.

Fixes: 7b39d90184 (serial: sh-sci: Fix NULL pointer dereference if HIGHMEM is enabled)
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: sh-sci: Add DT support to DMA setup 2015-10-04T16:36:10+00:00 Geert Uytterhoeven geert+renesas@glider.be 2015-09-18T11:08:33+00:00 ff4411296e99db2c0896580d8b47348abf3ad703 Add support for obtaining DMA channel information from the device tree. This requires switching from the legacy sh_dmae_slave structures with hardcoded channel numbers and the corresponding filter function to: 1. dma_request_slave_channel_compat(), - On legacy platforms, dma_request_slave_channel_compat() uses the passed DMA channel numbers that originate from platform device data, - On DT-based platforms, dma_request_slave_channel_compat() will retrieve the information from DT. 2. and the generic dmaengine_slave_config() configuration method, which requires filling in DMA register ports and slave bus widths. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Add support for obtaining DMA channel information from the device tree.

This requires switching from the legacy sh_dmae_slave structures with
hardcoded channel numbers and the corresponding filter function to:
  1. dma_request_slave_channel_compat(),
       - On legacy platforms, dma_request_slave_channel_compat() uses
	 the passed DMA channel numbers that originate from platform
	 device data,
       - On DT-based platforms, dma_request_slave_channel_compat() will
	 retrieve the information from DT.
  2. and the generic dmaengine_slave_config() configuration method,
     which requires filling in DMA register ports and slave bus widths.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: sh-sci: Pause DMA engine and get DMA status again 2015-10-04T16:36:10+00:00 Muhammad Hamza Farooq mfarooq@visteon.com 2015-09-18T11:08:32+00:00 e7327c09def48ccfd204025726f11b57a19a9c24 Occasionally, DMA transaction completes _after_ DMA engine is stopped. Verify if the transaction has not finished before forcing the engine to stop and push the data Signed-off-by: Muhammad Hamza Farooq <mfarooq@visteon.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Occasionally, DMA transaction completes _after_ DMA engine is stopped.
Verify if the transaction has not finished before forcing the engine to
stop and push the data

Signed-off-by: Muhammad Hamza Farooq <mfarooq@visteon.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: sh-sci: Do not terminate DMA engine when race condition occurs 2015-10-04T16:36:10+00:00 Muhammad Hamza Farooq mfarooq@visteon.com 2015-09-18T11:08:31+00:00 3b963042b64f5de3c63a1ebcbe2cad6b1597b8b9 When DMA packet completion and timer expiry take place at the same time, do not terminate the DMA engine, leading by submission of new descriptors, as the DMA communication hasn't necessarily stopped here. Signed-off-by: Muhammad Hamza Farooq <mfarooq@visteon.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
When DMA packet completion and timer expiry take place at the same time,
do not terminate the DMA engine, leading by submission of new
descriptors, as the DMA communication hasn't necessarily stopped here.

Signed-off-by: Muhammad Hamza Farooq <mfarooq@visteon.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: sh-sci: Call dma_async_issue_pending when transaction completes 2015-10-04T16:36:10+00:00 Muhammad Hamza Farooq mfarooq@visteon.com 2015-09-18T11:08:30+00:00 1d3db608f933605d2dce44a0262ea94da3407465 dmaengine_submit() will not start the DMA operation, it merely adds it to the pending queue. If the queue is no longer running, it won't be restarted until dma_async_issue_pending() is called. Signed-off-by: Muhammad Hamza Farooq <mfarooq@visteon.com> [geert: Add more description] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
dmaengine_submit() will not start the DMA operation, it merely adds
it to the pending queue.  If the queue is no longer running, it won't be
restarted until dma_async_issue_pending() is called.

Signed-off-by: Muhammad Hamza Farooq <mfarooq@visteon.com>
[geert: Add more description]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: sh-sci: Redirect port interrupts to CPU _only_ when DMA stops 2015-10-04T16:36:10+00:00 Muhammad Hamza Farooq mfarooq@visteon.com 2015-09-18T11:08:29+00:00 371cfed3116bc2ebd173fe55870f77ea1413edac Since the DMA engine is not stopped everytime rx_timer_fn is called, the interrupts have to be redirected back to CPU only when incomplete DMA transaction is handled Signed-off-by: Muhammad Hamza Farooq <mfarooq@visteon.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Since the DMA engine is not stopped everytime rx_timer_fn is called, the
interrupts have to be redirected back to CPU only when incomplete DMA
transaction is handled

Signed-off-by: Muhammad Hamza Farooq <mfarooq@visteon.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: sh-sci: Remove timer on shutdown of port 2015-10-04T16:36:10+00:00 Aleksandar Mitev amitev@visteon.com 2015-09-18T11:08:28+00:00 9ab76556608665c35080f641c73025297d0a2813 This prevents DMA timer timeout that can trigger after the port has been closed. Signed-off-by: Aleksandar Mitev <amitev@visteon.com> [geert: Move del_timer_sync() outside spinlock to avoid circular locking dependency between rx_timer_fn() and del_timer_sync()] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This prevents DMA timer timeout that can trigger after the port has
been closed.

Signed-off-by: Aleksandar Mitev <amitev@visteon.com>
[geert: Move del_timer_sync() outside spinlock to avoid circular locking
        dependency between rx_timer_fn() and del_timer_sync()]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: sh-sci: Stop calling sci_start_rx() from sci_request_dma() 2015-10-04T16:36:10+00:00 Geert Uytterhoeven geert+renesas@glider.be 2015-09-18T11:08:27+00:00 0e5c4b4d154ee0a34e39e1a587f71d4671783abf There's no need to call sci_start_rx() from sci_request_dma() when DMA setup fails, as sci_startup() will call sci_start_rx() anyway. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
There's no need to call sci_start_rx() from sci_request_dma() when DMA
setup fails, as sci_startup() will call sci_start_rx() anyway.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>