Skip to content

L
linux
Switch branch/tag
  1. 21 Oct, 2021 8 commits
    • Erwan Le Ray's avatar
      serial: stm32: update throttle and unthrottle ops for dma mode · d1ec8a2e
      Erwan Le Ray authored 
      Disable DMA request line (if enabled) to switch in PIO mode in throttle
ops, so the RX data gets queues into the FIFO. The hardware flow control
is triggered when the RX FIFO is full.

Switch back to DMA mode (re-enable DMA request line) in unthrottle ops.
Hardware flow control is stopped when FIFO is not full anymore.
Signed-off-by: default avatarValentin Caron <valentin.caron@foss.st.com>
Signed-off-by: default avatarErwan Le Ray <erwan.leray@foss.st.com>
Link: https://lore.kernel.org/r/20211020150332.10214-4-erwan.leray@foss.st.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1ec8a2e
    • Erwan Le Ray's avatar
      serial: stm32: rework RX over DMA · 33bb2f6a
      Erwan Le Ray authored 
      This patch reworks RX support over DMA to improve reliability:
- change dma buffer cyclic configuration by using 2 periods. DMA buffer
data are handled by a flip-flop between the 2 periods in order to avoid
risk of data loss/corruption
- change the size of dma buffer to 4096 to limit overruns
- add rx errors management (breaks, parity, framing and overrun).
  When an error occurs on the uart line, the dma request line is masked at
  HW level. The SW must 1st clear DMAR (dma request line enable), to
  handle the error, then re-enable DMAR to recover. So, any correct data
  is taken from the DMA buffer, before handling the error itself. Then
  errors are handled from RDR/ISR/FIFO (e.g. in PIO mode). Last, DMA
  reception is resumed.
- add a condition on DMA request line in DMA RX routines in order to
switch to PIO mode when no DMA request line is disabled, even if the DMA
channel is still enabled.
  When the UART is wakeup source and is configured to use DMA for RX, any
  incoming data that wakes up the system isn't correctly received.
  At data reception, the irq_handler handles the WUF irq, and then the
  data reception over DMA.
  As the DMA transfer has been terminated at suspend, and will be restored
  by resume callback (which has no yet been called by system), the data
  can't be received.
  The wake-up data has to be handled in PIO mode while suspend callback
  has not been called.
Signed-off-by: default avatarValentin Caron <valentin.caron@foss.st.com>
Signed-off-by: default avatarErwan Le Ray <erwan.leray@foss.st.com>
Link: https://lore.kernel.org/r/20211020150332.10214-3-erwan.leray@foss.st.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33bb2f6a
    • Erwan Le Ray's avatar
      serial: stm32: re-introduce an irq flag condition in usart_receive_chars · cc58d0a3
      Erwan Le Ray authored 
      Re-introduce an irq flag condition in usart_receive_chars.
This condition has been deleted by commit 75f4e830 ("serial: do not
restore interrupt state in sysrq helper").
This code was present to handle threaded case, and has been removed
because it is no more needed in this case. Nevertheless an irq safe lock
is still needed in some cases, when DMA should be stopped to receive errors
or breaks in PIO mode.
This patch is a precursor to the complete rework or stm32 serial driver
DMA implementation.
Signed-off-by: default avatarErwan Le Ray <erwan.leray@foss.st.com>
Link: https://lore.kernel.org/r/20211020150332.10214-2-erwan.leray@foss.st.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc58d0a3
    • Xianting Tian's avatar
      virtio-console: remove unnecessary kmemdup() · 9db81eca
      Xianting Tian authored 
      This revert commit c4baad50 ("virtio-console: avoid DMA from stack")

hvc framework will never pass stack memory to the put_chars() function,
So the calling of kmemdup() is unnecessary, we can remove it.
Signed-off-by: default avatarXianting Tian <xianting.tian@linux.alibaba.com>
Reviewed-by: default avatarShile Zhang <shile.zhang@linux.alibaba.com>
Link: https://lore.kernel.org/r/20211015024658.1353987-4-xianting.tian@linux.alibaba.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9db81eca
    • Xianting Tian's avatar
      tty: hvc: pass DMA capable memory to put_chars() · 0986d7bc
      Xianting Tian authored 
      As well known, hvc backend can register its opertions to hvc backend.
the operations contain put_chars(), get_chars() and so on.

Some hvc backend may do dma in its operations. eg, put_chars() of
virtio-console. But in the code of hvc framework, it may pass DMA
incapable memory to put_chars() under a specific configuration, which
is explained in commit c4baad50(virtio-console: avoid DMA from stack):
1, c[] is on stack,
   hvc_console_print():
        char c[N_OUTBUF] __ALIGNED__;
        cons_ops[index]->put_chars(vtermnos[index], c, i);
2, ch is on stack,
   static void hvc_poll_put_char(,,char ch)
   {
        struct tty_struct *tty = driver->ttys[0];
        struct hvc_struct *hp = tty->driver_data;
        int n;

        do {
                n = hp->ops->put_chars(hp->vtermno, &ch, 1);
        } while (n <= 0);
   }

Commit c4baad50 is just the fix to avoid DMA from stack memory, which
is passed to virtio-console by hvc framework in above code. But I think
the fix is aggressive, it directly uses kmemdup() to alloc new buffer
from kmalloc area and do memcpy no matter the memory is in kmalloc area
or not. But most importantly, it should better be fixed in the hvc
framework, by changing it to never pass stack memory to the put_chars()
function in the first place. Otherwise, we still face the same issue if
a new hvc backend using dma added in the furture.

In this patch, add 'char cons_outbuf[]' as part of 'struct hvc_struct',
so hp->cons_outbuf is no longer the stack memory, we can use it in above
cases safely. We also add lock to protect cons_outbuf instead of using
the global lock of hvc.

Introduce another array(cons_hvcs[]) for hvc pointers next to the
cons_ops[] and vtermnos[] arrays. With the array, we can easily find
hvc's cons_outbuf and its lock.

With the patch, we can revert the fix c4baad50.
Signed-off-by: default avatarXianting Tian <xianting.tian@linux.alibaba.com>
Signed-off-by: default avatarShile Zhang <shile.zhang@linux.alibaba.com>
Link: https://lore.kernel.org/r/20211015024658.1353987-3-xianting.tian@linux.alibaba.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0986d7bc
    • Xianting Tian's avatar
      tty: hvc: use correct dma alignment size · 30480f65
      Xianting Tian authored 
      Use L1_CACHE_BYTES as the dma alignment size, use 'sizeof(long)' as
dma alignment is wrong.
Signed-off-by: default avatarXianting Tian <xianting.tian@linux.alibaba.com>
Signed-off-by: default avatarShile Zhang <shile.zhang@linux.alibaba.com>
Link: https://lore.kernel.org/r/20211015024658.1353987-2-xianting.tian@linux.alibaba.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30480f65
    • Francesco Dolcini's avatar
      serial: imx: disable console clocks on unregister · 9768a37c
      Francesco Dolcini authored 
      During console setup imx_uart_console_setup() enables clocks, but they
are never disabled when the console is unregistered, this leads to
clk_prepare_enable() being called multiple times without a matching
clk_disable_unprepare() in case of console unregister.

Ensure that clock enable/disable are balanced adding
clk_disable_unprepare() in the console exit callback.
Signed-off-by: default avatarFrancesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20211020192643.476895-3-francesco.dolcini@toradex.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9768a37c
    • Stefan Agner's avatar
      serial: imx: fix detach/attach of serial console · 6d0d1b5a
      Stefan Agner authored 
      If the device used as a serial console gets detached/attached at runtime,
register_console() will try to call imx_uart_setup_console(), but this
is not possible since it is marked as __init.

For instance

  # cat /sys/devices/virtual/tty/console/active
  tty1 ttymxc0
  # echo -n N > /sys/devices/virtual/tty/console/subsystem/ttymxc0/console
  # echo -n Y > /sys/devices/virtual/tty/console/subsystem/ttymxc0/console

[   73.166649] 8<--- cut here ---
[   73.167005] Unable to handle kernel paging request at virtual address c154d928
[   73.167601] pgd = 55433e84
[   73.167875] [c154d928] *pgd=8141941e(bad)
[   73.168304] Internal error: Oops: 8000000d [#1] SMP ARM
[   73.168429] Modules linked in:
[   73.168522] CPU: 0 PID: 536 Comm: sh Not tainted 5.15.0-rc6-00056-g3968ddcf #3
[   73.168675] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[   73.168791] PC is at imx_uart_console_setup+0x0/0x238
[   73.168927] LR is at try_enable_new_console+0x98/0x124
[   73.169056] pc : [<c154d928>]    lr : [<c0196f44>]    psr: a0000013
[   73.169178] sp : c2ef5e70  ip : 00000000  fp : 00000000
[   73.169281] r10: 00000000  r9 : c02cf970  r8 : 00000000
[   73.169389] r7 : 00000001  r6 : 00000001  r5 : c1760164  r4 : c1e0fb08
[   73.169512] r3 : c154d928  r2 : 00000000  r1 : efffcbd1  r0 : c1760164
[   73.169641] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   73.169782] Control: 10c5387d  Table: 8345406a  DAC: 00000051
[   73.169895] Register r0 information: non-slab/vmalloc memory
[   73.170032] Register r1 information: non-slab/vmalloc memory
[   73.170158] Register r2 information: NULL pointer
[   73.170273] Register r3 information: non-slab/vmalloc memory
[   73.170397] Register r4 information: non-slab/vmalloc memory
[   73.170521] Register r5 information: non-slab/vmalloc memory
[   73.170647] Register r6 information: non-paged memory
[   73.170771] Register r7 information: non-paged memory
[   73.170892] Register r8 information: NULL pointer
[   73.171009] Register r9 information: non-slab/vmalloc memory
[   73.171142] Register r10 information: NULL pointer
[   73.171259] Register r11 information: NULL pointer
[   73.171375] Register r12 information: NULL pointer
[   73.171494] Process sh (pid: 536, stack limit = 0xcd1ba82f)
[   73.171621] Stack: (0xc2ef5e70 to 0xc2ef6000)
[   73.171731] 5e60:                                     ???????? ???????? ???????? ????????
[   73.171899] 5e80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.172059] 5ea0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.172217] 5ec0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.172377] 5ee0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.172537] 5f00: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.172698] 5f20: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.172856] 5f40: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.173016] 5f60: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.173177] 5f80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.173336] 5fa0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.173496] 5fc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.173654] 5fe0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.173826] [<c0196f44>] (try_enable_new_console) from [<c01984a8>] (register_console+0x10c/0x2ec)
[   73.174053] [<c01984a8>] (register_console) from [<c06e2c90>] (console_store+0x14c/0x168)
[   73.174262] [<c06e2c90>] (console_store) from [<c0383718>] (kernfs_fop_write_iter+0x110/0x1cc)
[   73.174470] [<c0383718>] (kernfs_fop_write_iter) from [<c02cf5f4>] (vfs_write+0x31c/0x548)
[   73.174679] [<c02cf5f4>] (vfs_write) from [<c02cf970>] (ksys_write+0x60/0xec)
[   73.174863] [<c02cf970>] (ksys_write) from [<c0100080>] (ret_fast_syscall+0x0/0x1c)
[   73.175052] Exception stack(0xc2ef5fa8 to 0xc2ef5ff0)
[   73.175167] 5fa0:                   ???????? ???????? ???????? ???????? ???????? ????????
[   73.175327] 5fc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[   73.175486] 5fe0: ???????? ???????? ???????? ????????
[   73.175608] Code: 00000000 00000000 00000000 00000000 (00000000)
[   73.175744] ---[ end trace 9b75121265109bf1 ]---

A similar issue could be triggered by unbinding/binding the serial
console device [*].

Drop __init so that imx_uart_setup_console() can be safely called at
runtime.

[*] https://lore.kernel.org/all/20181114174940.7865-3-stefan@agner.ch/

Fixes: a3cb39d2 ("serial: core: Allow detach and attach serial device for console")
Reviewed-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
Signed-off-by: default avatarFrancesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20211020192643.476895-2-francesco.dolcini@toradex.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d0d1b5a
  3. 18 Oct, 2021 19 commits
  5. 17 Oct, 2021 3 commits
  7. 16 Oct, 2021 10 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7