<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/tty/serial, branch v4.10</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Revert "tty: serial: 8250: add CON_CONSDEV to flags"</title>
<updated>2017-01-11T07:35:17+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2016-12-11T02:05:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6741f551a0b26479de2532ffa43a366747e6dbf3'/>
<id>6741f551a0b26479de2532ffa43a366747e6dbf3</id>
<content type='text'>
This commit needs to be reverted because it prevents people from
using the serial console as a secondary console with input being
directed to tty0.

IOW, if you boot with console=ttyS0 console=tty0 then all kernels
prior to this commit will produce output on both ttyS0 and tty0
but input will only be taken from tty0.  With this patch the serial
console will always be the primary console instead of tty0,
potentially preventing people from getting into their machines in
emergency situations.

Fixes: d03516df8375 ("tty: serial: 8250: add CON_CONSDEV to flags")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit needs to be reverted because it prevents people from
using the serial console as a secondary console with input being
directed to tty0.

IOW, if you boot with console=ttyS0 console=tty0 then all kernels
prior to this commit will produce output on both ttyS0 and tty0
but input will only be taken from tty0.  With this patch the serial
console will always be the primary console instead of tty0,
potentially preventing people from getting into their machines in
emergency situations.

Fixes: d03516df8375 ("tty: serial: 8250: add CON_CONSDEV to flags")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break</title>
<updated>2017-01-11T07:35:17+00:00</updated>
<author>
<name>Daniel Jedrychowski</name>
<email>avistel@gmail.com</email>
</author>
<published>2016-12-11T22:18:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2bed8a8e70729f996af92042d3ad0f11870acc1f'/>
<id>2bed8a8e70729f996af92042d3ad0f11870acc1f</id>
<content type='text'>
When in RS485 emulation mode, __do_stop_tx_rs485() calls
serial8250_clear_fifos().  This not only clears the FIFOs, but also sets
all bits in their control register (UART_FCR) to 0.

One of the effects of this is the disabling of the FIFOs, which turns
them into single-byte holding registers.  The rest of the driver doesn't
know this, which results in the lions share of characters passed into a
write call to be dropped.

(I can supply logic analyzer screenshots if necessary)

This fix replaces the serial8250_clear_fifos() call to
serial8250_clear_and_reinit_fifos() - this prevents the "dropped
characters" issue from manifesting again while retaining the requirement
of clearing the RX FIFO after transmission if the SER_RS485_RX_DURING_TX
flag is disabled.

Signed-off-by: Daniel Jedrychowski &lt;avistel@gmail.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When in RS485 emulation mode, __do_stop_tx_rs485() calls
serial8250_clear_fifos().  This not only clears the FIFOs, but also sets
all bits in their control register (UART_FCR) to 0.

One of the effects of this is the disabling of the FIFOs, which turns
them into single-byte holding registers.  The rest of the driver doesn't
know this, which results in the lions share of characters passed into a
write call to be dropped.

(I can supply logic analyzer screenshots if necessary)

This fix replaces the serial8250_clear_fifos() call to
serial8250_clear_and_reinit_fifos() - this prevents the "dropped
characters" issue from manifesting again while retaining the requirement
of clearing the RX FIFO after transmission if the SER_RS485_RX_DURING_TX
flag is disabled.

Signed-off-by: Daniel Jedrychowski &lt;avistel@gmail.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>8250_pci: Fix potential use-after-free in error path</title>
<updated>2017-01-11T07:35:17+00:00</updated>
<author>
<name>Gabriel Krisman Bertazi</name>
<email>krisman@linux.vnet.ibm.com</email>
</author>
<published>2016-12-28T18:42:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c130b666a9a711f985a0a44b58699ebe14bb7245'/>
<id>c130b666a9a711f985a0a44b58699ebe14bb7245</id>
<content type='text'>
Commit f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during
PCI error recovery") introduces a potential use-after-free in case the
pciserial_init_ports call in serial8250_io_resume fails, which may
happen if a memory allocation fails or if the .init quirk failed for
whatever reason).  If this happen, further pci_get_drvdata will return a
pointer to freed memory.

This patch reworks the PCI recovery resume hook to restore the old priv
structure in this case, which should be ok, since the ports were already
detached. Such error during recovery causes us to give up on the
recovery.

Fixes: f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during
  PCI error recovery")
Reported-by: Michal Suchanek &lt;msuchanek@suse.com&gt;
Signed-off-by: Gabriel Krisman Bertazi &lt;krisman@linux.vnet.ibm.com&gt;
Signed-off-by: Guilherme G. Piccoli &lt;gpiccoli@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during
PCI error recovery") introduces a potential use-after-free in case the
pciserial_init_ports call in serial8250_io_resume fails, which may
happen if a memory allocation fails or if the .init quirk failed for
whatever reason).  If this happen, further pci_get_drvdata will return a
pointer to freed memory.

This patch reworks the PCI recovery resume hook to restore the old priv
structure in this case, which should be ok, since the ports were already
detached. Such error during recovery causes us to give up on the
recovery.

Fixes: f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during
  PCI error recovery")
Reported-by: Michal Suchanek &lt;msuchanek@suse.com&gt;
Signed-off-by: Gabriel Krisman Bertazi &lt;krisman@linux.vnet.ibm.com&gt;
Signed-off-by: Guilherme G. Piccoli &lt;gpiccoli@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tty/serial: atmel: RS485 half duplex w/DMA: enable RX after TX is done</title>
<updated>2017-01-11T07:18:45+00:00</updated>
<author>
<name>Richard Genoud</name>
<email>richard.genoud@gmail.com</email>
</author>
<published>2016-12-06T12:05:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b389f173aaa1204d6dc1f299082a162eb0491545'/>
<id>b389f173aaa1204d6dc1f299082a162eb0491545</id>
<content type='text'>
When using RS485 in half duplex, RX should be enabled when TX is
finished, and stopped when TX starts.

Before commit 0058f0871efe7b01c6 ("tty/serial: atmel: fix RS485 half
duplex with DMA"), RX was not disabled in atmel_start_tx() if the DMA
was used. So, collisions could happened.

But disabling RX in atmel_start_tx() uncovered another bug:
RX was enabled again in the wrong place (in atmel_tx_dma) instead of
being enabled when TX is finished (in atmel_complete_tx_dma), so the
transmission simply stopped.

This bug was not triggered before commit 0058f0871efe7b01c6
("tty/serial: atmel: fix RS485 half duplex with DMA") because RX was
never disabled before.

Moving atmel_start_rx() in atmel_complete_tx_dma() corrects the problem.

Cc: stable@vger.kernel.org
Reported-by: Gil Weber &lt;webergil@gmail.com&gt;
Fixes: 0058f0871efe7b01c6
Tested-by: Gil Weber &lt;webergil@gmail.com&gt;
Signed-off-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Acked-by: Alexandre Belloni &lt;alexandre.belloni@free-electrons.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When using RS485 in half duplex, RX should be enabled when TX is
finished, and stopped when TX starts.

Before commit 0058f0871efe7b01c6 ("tty/serial: atmel: fix RS485 half
duplex with DMA"), RX was not disabled in atmel_start_tx() if the DMA
was used. So, collisions could happened.

But disabling RX in atmel_start_tx() uncovered another bug:
RX was enabled again in the wrong place (in atmel_tx_dma) instead of
being enabled when TX is finished (in atmel_complete_tx_dma), so the
transmission simply stopped.

This bug was not triggered before commit 0058f0871efe7b01c6
("tty/serial: atmel: fix RS485 half duplex with DMA") because RX was
never disabled before.

Moving atmel_start_rx() in atmel_complete_tx_dma() corrects the problem.

Cc: stable@vger.kernel.org
Reported-by: Gil Weber &lt;webergil@gmail.com&gt;
Fixes: 0058f0871efe7b01c6
Tested-by: Gil Weber &lt;webergil@gmail.com&gt;
Signed-off-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Acked-by: Alexandre Belloni &lt;alexandre.belloni@free-electrons.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx</title>
<updated>2017-01-11T07:18:45+00:00</updated>
<author>
<name>Richard Genoud</name>
<email>richard.genoud@gmail.com</email>
</author>
<published>2016-12-13T16:27:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=89d8232411a85b9a6b12fd5da4d07d8a138a8e0c'/>
<id>89d8232411a85b9a6b12fd5da4d07d8a138a8e0c</id>
<content type='text'>
If we don't disable the transmitter in atmel_stop_tx, the DMA buffer
continues to send data until it is emptied.
This cause problems with the flow control (CTS is asserted and data are
still sent).

So, disabling the transmitter in atmel_stop_tx is a sane thing to do.

Tested on at91sam9g35-cm(DMA)
Tested for regressions on sama5d2-xplained(Fifo) and at91sam9g20ek(PDC)

Cc: &lt;stable@vger.kernel.org&gt; (beware, this won't apply before 4.3)
Signed-off-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Acked-by: Nicolas Ferre &lt;nicolas.ferre@atmel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If we don't disable the transmitter in atmel_stop_tx, the DMA buffer
continues to send data until it is emptied.
This cause problems with the flow control (CTS is asserted and data are
still sent).

So, disabling the transmitter in atmel_stop_tx is a sane thing to do.

Tested on at91sam9g35-cm(DMA)
Tested for regressions on sama5d2-xplained(Fifo) and at91sam9g20ek(PDC)

Cc: &lt;stable@vger.kernel.org&gt; (beware, this won't apply before 4.3)
Signed-off-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Acked-by: Nicolas Ferre &lt;nicolas.ferre@atmel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Replace &lt;asm/uaccess.h&gt; with &lt;linux/uaccess.h&gt; globally</title>
<updated>2016-12-24T19:46:01+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-12-24T19:46:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7c0f6ba682b9c7632072ffbedf8d328c8f3c42ba'/>
<id>7c0f6ba682b9c7632072ffbedf8d328c8f3c42ba</id>
<content type='text'>
This was entirely automated, using the script by Al:

  PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*&lt;asm/uaccess.h&gt;'
  sed -i -e "s!$PATT!#include &lt;linux/uaccess.h&gt;!" \
        $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h)

to do the replacement at the end of the merge window.

Requested-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This was entirely automated, using the script by Al:

  PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*&lt;asm/uaccess.h&gt;'
  sed -i -e "s!$PATT!#include &lt;linux/uaccess.h&gt;!" \
        $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h)

to do the replacement at the end of the merge window.

Requested-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'dmaengine-4.10-rc1' of git://git.infradead.org/users/vkoul/slave-dma</title>
<updated>2016-12-15T04:42:45+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-12-15T04:42:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e3842cbfe0976b014288147b130551d8bf52b96c'/>
<id>e3842cbfe0976b014288147b130551d8bf52b96c</id>
<content type='text'>
Pull dmaengine updates from Vinod Koul:
 "Fairly routine update this time around with all changes specific to
  drivers:

   - New driver for STMicroelectronics FDMA
   - Memory-to-memory transfers on dw dmac
   - Support for slave maps on pl08x devices
   - Bunch of driver fixes to use dma_pool_zalloc
   - Bunch of compile and warning fixes spread across drivers"

[ The ST FDMA driver already came in earlier through the remoteproc tree ]

* tag 'dmaengine-4.10-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (68 commits)
  dmaengine: sirf-dma: remove unused ‘sdesc’
  dmaengine: pl330: remove unused ‘regs’
  dmaengine: s3c24xx: remove unused ‘cdata’
  dmaengine: stm32-dma: remove unused ‘src_addr’
  dmaengine: stm32-dma: remove unused ‘dst_addr’
  dmaengine: stm32-dma: remove unused ‘sfcr’
  dmaengine: pch_dma: remove unused ‘cookie’
  dmaengine: mic_x100_dma: remove unused ‘data’
  dmaengine: img-mdc: remove unused ‘prev_phys’
  dmaengine: usb-dmac: remove unused ‘uchan’
  dmaengine: ioat: remove unused ‘res’
  dmaengine: ioat: remove unused ‘ioat_dma’
  dmaengine: ioat: remove unused ‘is_raid_device’
  dmaengine: pl330: do not generate unaligned access
  dmaengine: k3dma: move to dma_pool_zalloc
  dmaengine: at_hdmac: move to dma_pool_zalloc
  dmaengine: at_xdmac: don't restore unsaved status
  dmaengine: ioat: set error code on failures
  dmaengine: ioat: set error code on failures
  dmaengine: DW DMAC: add multi-block property to device tree
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull dmaengine updates from Vinod Koul:
 "Fairly routine update this time around with all changes specific to
  drivers:

   - New driver for STMicroelectronics FDMA
   - Memory-to-memory transfers on dw dmac
   - Support for slave maps on pl08x devices
   - Bunch of driver fixes to use dma_pool_zalloc
   - Bunch of compile and warning fixes spread across drivers"

[ The ST FDMA driver already came in earlier through the remoteproc tree ]

* tag 'dmaengine-4.10-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (68 commits)
  dmaengine: sirf-dma: remove unused ‘sdesc’
  dmaengine: pl330: remove unused ‘regs’
  dmaengine: s3c24xx: remove unused ‘cdata’
  dmaengine: stm32-dma: remove unused ‘src_addr’
  dmaengine: stm32-dma: remove unused ‘dst_addr’
  dmaengine: stm32-dma: remove unused ‘sfcr’
  dmaengine: pch_dma: remove unused ‘cookie’
  dmaengine: mic_x100_dma: remove unused ‘data’
  dmaengine: img-mdc: remove unused ‘prev_phys’
  dmaengine: usb-dmac: remove unused ‘uchan’
  dmaengine: ioat: remove unused ‘res’
  dmaengine: ioat: remove unused ‘ioat_dma’
  dmaengine: ioat: remove unused ‘is_raid_device’
  dmaengine: pl330: do not generate unaligned access
  dmaengine: k3dma: move to dma_pool_zalloc
  dmaengine: at_hdmac: move to dma_pool_zalloc
  dmaengine: at_xdmac: don't restore unsaved status
  dmaengine: ioat: set error code on failures
  dmaengine: ioat: set error code on failures
  dmaengine: DW DMAC: add multi-block property to device tree
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_mid fix calltrace when hotplug 8250 serial controller</title>
<updated>2016-11-30T12:06:08+00:00</updated>
<author>
<name>Liwei Song</name>
<email>liwei.song@windriver.com</email>
</author>
<published>2016-11-30T06:25:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a9b01b5823f73dc741b623dfc52ccd68f8139b55'/>
<id>a9b01b5823f73dc741b623dfc52ccd68f8139b55</id>
<content type='text'>
Fix the following Calltrace:
[   77.768221] WARNING: CPU: 5 PID: 645 at drivers/dma/dmaengine.c:1069 dma_async_device_unregister+0xe2/0xf0
[   77.775058] dma_async_device_unregister called while 1 clients hold a reference
[   77.825048] CPU: 5 PID: 645 Comm: sh Not tainted 4.8.8-WR9.0.0.0_standard+ #3
[   77.832550] Hardware name: Intel Corp. Aspen Cove/Server, BIOS HAVLCRB1.X64.0012.D58.1604140405 04/14/2016
[   77.840396]  0000000000000000 ffffc90008adbc80 ffffffff81403456 ffffc90008adbcd0
[   77.848245]  0000000000000000 ffffc90008adbcc0 ffffffff8105e2e1 0000042d08adbf20
[   77.855934]  ffff88046a861c18 ffff88046a85c420 ffffffff820d4200 ffff88046ae92318
[   77.863601] Call Trace:
[   77.871113]  [&lt;ffffffff81403456&gt;] dump_stack+0x4f/0x69
[   77.878655]  [&lt;ffffffff8105e2e1&gt;] __warn+0xd1/0xf0
[   77.886102]  [&lt;ffffffff8105e34f&gt;] warn_slowpath_fmt+0x4f/0x60
[   77.893508]  [&lt;ffffffff814187a9&gt;] ? find_next_bit+0x19/0x20
[   77.900730]  [&lt;ffffffff814bf83e&gt;] ? dma_channel_rebalance+0x23e/0x270
[   77.907814]  [&lt;ffffffff814bfee2&gt;] dma_async_device_unregister+0xe2/0xf0
[   77.914992]  [&lt;ffffffff814c53aa&gt;] hsu_dma_remove+0x1a/0x60
[   77.921977]  [&lt;ffffffff814ee14c&gt;] dnv_exit+0x1c/0x20
[   77.928752]  [&lt;ffffffff814edff6&gt;] mid8250_remove+0x26/0x40
[   77.935607]  [&lt;ffffffff8144f1b9&gt;] pci_device_remove+0x39/0xc0
[   77.942292]  [&lt;ffffffff8160cfea&gt;] __device_release_driver+0x9a/0x140
[   77.948836]  [&lt;ffffffff8160d0b3&gt;] device_release_driver+0x23/0x30
[   77.955364]  [&lt;ffffffff81447dcc&gt;] pci_stop_bus_device+0x8c/0xa0
[   77.961769]  [&lt;ffffffff81447f0a&gt;] pci_stop_and_remove_bus_device_locked+0x1a/0x30
[   77.968113]  [&lt;ffffffff81450d4e&gt;] remove_store+0x5e/0x70
[   77.974267]  [&lt;ffffffff81607ed8&gt;] dev_attr_store+0x18/0x30
[   77.980243]  [&lt;ffffffff8123006a&gt;] sysfs_kf_write+0x3a/0x50
[   77.986180]  [&lt;ffffffff8122f5ab&gt;] kernfs_fop_write+0x10b/0x190
[   77.992118]  [&lt;ffffffff811bf1c8&gt;] __vfs_write+0x18/0x40
[   77.998032]  [&lt;ffffffff811bfdee&gt;] vfs_write+0xae/0x190
[   78.003747]  [&lt;ffffffff811c1016&gt;] SyS_write+0x46/0xb0
[   78.009234]  [&lt;ffffffff81a4c31b&gt;] entry_SYSCALL_64_fastpath+0x13/0x8f
[   78.014809] ---[ end trace 0c36dd73b7408eb2 ]---

This happens when the 8250 serial controller is hotplugged as follows:
echo 1 &gt; /sys/bus/pci/devices/0000:00:1a.0/remove

This trace happens due to the serial port still holding a reference when
the dma device is unregistered.
The dma unregister routine will check if there is still a reference exist,
if so it will give the WARNING(here serial port still was not unregister).

To fix this, We need to unregister the serial port first, then do DMA
device unregister to make sure there is no reference when to DMA routine.

Signed-off-by: Liwei Song &lt;liwei.song@windriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix the following Calltrace:
[   77.768221] WARNING: CPU: 5 PID: 645 at drivers/dma/dmaengine.c:1069 dma_async_device_unregister+0xe2/0xf0
[   77.775058] dma_async_device_unregister called while 1 clients hold a reference
[   77.825048] CPU: 5 PID: 645 Comm: sh Not tainted 4.8.8-WR9.0.0.0_standard+ #3
[   77.832550] Hardware name: Intel Corp. Aspen Cove/Server, BIOS HAVLCRB1.X64.0012.D58.1604140405 04/14/2016
[   77.840396]  0000000000000000 ffffc90008adbc80 ffffffff81403456 ffffc90008adbcd0
[   77.848245]  0000000000000000 ffffc90008adbcc0 ffffffff8105e2e1 0000042d08adbf20
[   77.855934]  ffff88046a861c18 ffff88046a85c420 ffffffff820d4200 ffff88046ae92318
[   77.863601] Call Trace:
[   77.871113]  [&lt;ffffffff81403456&gt;] dump_stack+0x4f/0x69
[   77.878655]  [&lt;ffffffff8105e2e1&gt;] __warn+0xd1/0xf0
[   77.886102]  [&lt;ffffffff8105e34f&gt;] warn_slowpath_fmt+0x4f/0x60
[   77.893508]  [&lt;ffffffff814187a9&gt;] ? find_next_bit+0x19/0x20
[   77.900730]  [&lt;ffffffff814bf83e&gt;] ? dma_channel_rebalance+0x23e/0x270
[   77.907814]  [&lt;ffffffff814bfee2&gt;] dma_async_device_unregister+0xe2/0xf0
[   77.914992]  [&lt;ffffffff814c53aa&gt;] hsu_dma_remove+0x1a/0x60
[   77.921977]  [&lt;ffffffff814ee14c&gt;] dnv_exit+0x1c/0x20
[   77.928752]  [&lt;ffffffff814edff6&gt;] mid8250_remove+0x26/0x40
[   77.935607]  [&lt;ffffffff8144f1b9&gt;] pci_device_remove+0x39/0xc0
[   77.942292]  [&lt;ffffffff8160cfea&gt;] __device_release_driver+0x9a/0x140
[   77.948836]  [&lt;ffffffff8160d0b3&gt;] device_release_driver+0x23/0x30
[   77.955364]  [&lt;ffffffff81447dcc&gt;] pci_stop_bus_device+0x8c/0xa0
[   77.961769]  [&lt;ffffffff81447f0a&gt;] pci_stop_and_remove_bus_device_locked+0x1a/0x30
[   77.968113]  [&lt;ffffffff81450d4e&gt;] remove_store+0x5e/0x70
[   77.974267]  [&lt;ffffffff81607ed8&gt;] dev_attr_store+0x18/0x30
[   77.980243]  [&lt;ffffffff8123006a&gt;] sysfs_kf_write+0x3a/0x50
[   77.986180]  [&lt;ffffffff8122f5ab&gt;] kernfs_fop_write+0x10b/0x190
[   77.992118]  [&lt;ffffffff811bf1c8&gt;] __vfs_write+0x18/0x40
[   77.998032]  [&lt;ffffffff811bfdee&gt;] vfs_write+0xae/0x190
[   78.003747]  [&lt;ffffffff811c1016&gt;] SyS_write+0x46/0xb0
[   78.009234]  [&lt;ffffffff81a4c31b&gt;] entry_SYSCALL_64_fastpath+0x13/0x8f
[   78.014809] ---[ end trace 0c36dd73b7408eb2 ]---

This happens when the 8250 serial controller is hotplugged as follows:
echo 1 &gt; /sys/bus/pci/devices/0000:00:1a.0/remove

This trace happens due to the serial port still holding a reference when
the dma device is unregistered.
The dma unregister routine will check if there is still a reference exist,
if so it will give the WARNING(here serial port still was not unregister).

To fix this, We need to unregister the serial port first, then do DMA
device unregister to make sure there is no reference when to DMA routine.

Signed-off-by: Liwei Song &lt;liwei.song@windriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dmaengine: DW DMAC: add multi-block property to device tree</title>
<updated>2016-11-30T03:27:50+00:00</updated>
<author>
<name>Eugeniy Paltsev</name>
<email>Eugeniy.Paltsev@synopsys.com</email>
</author>
<published>2016-11-25T14:59:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bd2c6636cc59c4626a04d9918953a107f88eaff9'/>
<id>bd2c6636cc59c4626a04d9918953a107f88eaff9</id>
<content type='text'>
Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add multi-block property, so it is possible to enable hardware
multi block transfers (if present) via DT.

Switch from per device is_nollp variable to multi_block array
to be able enable/disable multi block transfers separately per
channel.

Acked-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Eugeniy Paltsev &lt;Eugeniy.Paltsev@synopsys.com&gt;
Signed-off-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add multi-block property, so it is possible to enable hardware
multi block transfers (if present) via DT.

Switch from per device is_nollp variable to multi_block array
to be able enable/disable multi block transfers separately per
channel.

Acked-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Eugeniy Paltsev &lt;Eugeniy.Paltsev@synopsys.com&gt;
Signed-off-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_pci: Detach low-level driver during PCI error recovery</title>
<updated>2016-11-29T19:20:07+00:00</updated>
<author>
<name>Gabriel Krisman Bertazi</name>
<email>krisman@linux.vnet.ibm.com</email>
</author>
<published>2016-11-28T21:34:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f209fa03fc9d131b3108c2e4936181eabab87416'/>
<id>f209fa03fc9d131b3108c2e4936181eabab87416</id>
<content type='text'>
During a PCI error recovery, like the ones provoked by EEH in the ppc64
platform, all IO to the device must be blocked while the recovery is
completed.  Current 8250_pci implementation only suspends the port
instead of detaching it, which doesn't prevent incoming accesses like
TIOCMGET and TIOCMSET calls from reaching the device.  Those end up
racing with the EEH recovery, crashing it.  Similar races were also
observed when opening the device and when shutting it down during
recovery.

This patch implements a more robust IO blockage for the 8250_pci
recovery by unregistering the port at the beginning of the procedure and
re-adding it afterwards.  Since the port is detached from the uart
layer, we can be sure that no request will make through to the device
during recovery.  This is similar to the solution used by the JSM serial
driver.

I thank Peter Hurley &lt;peter@hurleysoftware.com&gt; for valuable input on
this one over one year ago.

Signed-off-by: Gabriel Krisman Bertazi &lt;krisman@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
During a PCI error recovery, like the ones provoked by EEH in the ppc64
platform, all IO to the device must be blocked while the recovery is
completed.  Current 8250_pci implementation only suspends the port
instead of detaching it, which doesn't prevent incoming accesses like
TIOCMGET and TIOCMSET calls from reaching the device.  Those end up
racing with the EEH recovery, crashing it.  Similar races were also
observed when opening the device and when shutting it down during
recovery.

This patch implements a more robust IO blockage for the 8250_pci
recovery by unregistering the port at the beginning of the procedure and
re-adding it afterwards.  Since the port is detached from the uart
layer, we can be sure that no request will make through to the device
during recovery.  This is similar to the solution used by the JSM serial
driver.

I thank Peter Hurley &lt;peter@hurleysoftware.com&gt; for valuable input on
this one over one year ago.

Signed-off-by: Gabriel Krisman Bertazi &lt;krisman@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
