Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 4月, 2021 1 次提交
  3. 06 11月, 2020 1 次提交
  5. 24 8月, 2020 1 次提交
  7. 22 7月, 2020 1 次提交
    • H
      tty: xilinx_uartps: Really fix id assignment · 22a82fa7
      由 Helmut Grohne 提交于 
      The problems started with the revert (18cc7ac8). The
cdns_uart_console.index is statically assigned -1. When the port is
registered, Linux assigns consecutive numbers to it. It turned out that
when using ttyPS1 as console, the index is not updated as we are reusing
the same cdns_uart_console instance for multiple ports. When registering
ttyPS0, it gets updated from -1 to 0, but when registering ttyPS1, it
already is 0 and not updated.

That led to 2ae11c46. It assigns the index prior to registering
the uart_driver once. Unfortunately, that ended up breaking the
situation where the probe order does not match the id order. When using
the same device tree for both uboot and linux, it is important that the
serial0 alias points to the console. So some boards reverse those
aliases. This was reported by Jan Kiszka. The proposed fix was reverting
the index assignment and going back to the previous iteration.

However such a reversed assignement (serial0 -> uart1, serial1 -> uart0)
was already partially broken by the revert (18cc7ac8). While the
ttyPS device works, the kmsg connection is already broken and kernel
messages go missing. Reverting the id assignment does not fix this.

>From the xilinx_uartps driver pov (after reverting the refactoring
commits), there can be only one console. This manifests in static
variables console_pprt and cdns_uart_console. These variables are not
properly linked and can go out of sync. The cdns_uart_console.index is
important for uart_add_one_port. We call that function for each port -
one of which hopefully is the console. If it isn't, the CON_ENABLED flag
is not set and console_port is cleared. The next cdns_uart_probe call
then tries to register the next port using that same cdns_uart_console.

It is important that console_port and cdns_uart_console (and its index
in particular) stay in sync. The index assignment implemented by
Shubhrajyoti Datta is correct in principle. It just may have to happen a
second time if the first cdns_uart_probe call didn't encounter the
console device. And we shouldn't change the index once the console uart
is registered.
Reported-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Reported-by: NJan Kiszka <jan.kiszka@web.de>
Link: https://lore.kernel.org/linux-serial/f4092727-d8f5-5f91-2c9f-76643aace993@siemens.com/
Fixes: 18cc7ac8 ("Revert "serial: uartps: Register own uart console and driver structures"")
Fixes: 2ae11c46 ("tty: xilinx_uartps: Fix missing id assignment to the console")
Fixes: 76ed2e10 ("Revert "tty: xilinx_uartps: Fix missing id assignment to the console"")
Signed-off-by: NHelmut Grohne <helmut.grohne@intenta.de>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200713073227.GA3805@laureti-devSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22a82fa7
  9. 27 6月, 2020 1 次提交
  11. 05 5月, 2020 1 次提交
  13. 16 4月, 2020 9 次提交
  15. 24 3月, 2020 2 次提交
  17. 14 1月, 2020 3 次提交
  19. 18 12月, 2019 1 次提交
  21. 04 10月, 2019 1 次提交
  23. 04 9月, 2019 1 次提交
    • S
      xilinx_uartps.c: suppress "may be used uninitialised" warning · 2bf593f1
      由 Stephen Rothwell 提交于 
      A powerpc allyesconfig build produces this warning:

In file included from include/linux/radix-tree.h:16,
                 from include/linux/idr.h:15,
                 from include/linux/kernfs.h:13,
                 from include/linux/sysfs.h:16,
                 from include/linux/kobject.h:20,
                 from include/linux/device.h:16,
                 from include/linux/platform_device.h:13,
                 from drivers/tty/serial/xilinx_uartps.c:16:
drivers/tty/serial/xilinx_uartps.c: In function 'cdns_uart_console_write':
include/linux/spinlock.h:288:3: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
   _raw_spin_unlock_irqrestore(lock, flags); \
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/tty/serial/xilinx_uartps.c:1197:16: note: 'flags' was declared here
  unsigned long flags;
                ^~~~~

It looks like gcc just can't track the relationship between "locked"
and "flags", and it is obvious that "flags" won't be used when "locked"
is zero, so the simplest thing is to initialise flags.

Cc: Jiri Slaby <jslaby@suse.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20190731160557.6a09c3e1@canb.auug.org.auSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2bf593f1
  25. 18 6月, 2019 6 次提交
  27. 11 6月, 2019 2 次提交
  29. 29 4月, 2019 1 次提交
  31. 02 3月, 2019 1 次提交
  33. 19 2月, 2019 1 次提交
    • A
      serial: uartps: Fix stuck ISR if RX disabled with non-empty FIFO · 7abab160
      由 Anssi Hannula 提交于 
      If RX is disabled while there are still unprocessed bytes in RX FIFO,
cdns_uart_handle_rx() called from interrupt handler will get stuck in
the receive loop as read bytes will not get removed from the RX FIFO
and CDNS_UART_SR_RXEMPTY bit will never get set.

Avoid the stuck handler by checking first if RX is disabled. port->lock
protects against race with RX-disabling functions.

This HW behavior was mentioned by Nathan Rossi in 43e98facc4a3 ("tty:
xuartps: Fix RX hang, and TX corruption in termios call") which fixed a
similar issue in cdns_uart_set_termios().
The behavior can also be easily verified by e.g. setting
CDNS_UART_CR_RX_DIS at the beginning of cdns_uart_handle_rx() - the
following loop will then get stuck.

Resetting the FIFO using RXRST would not set RXEMPTY either so simply
issuing a reset after RX-disable would not work.

I observe this frequently on a ZynqMP board during heavy RX load at 1M
baudrate when the reader process exits and thus RX gets disabled.

Fixes: 61ec9016 ("tty/serial: add support for Xilinx PS UART")
Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
Cc: stable@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7abab160
  35. 19 12月, 2018 4 次提交
  37. 06 12月, 2018 1 次提交
  39. 05 12月, 2018 1 次提交