kernel/linux.git/drivers/tty/serial, branch v5.4.50

serial: amba-pl011: Make sure we initialize the port.lock spinlock

2020-06-24T15:50:24+00:00

[ Upstream commit 8508f4cba308f785b2fd4b8c38849c117b407297 ] Valentine reported seeing: [ 3.626638] INFO: trying to register non-static key. [ 3.626639] the code is fine but needs lockdep annotation. [ 3.626640] turning off the locking correctness validator. [ 3.626644] CPU: 7 PID: 51 Comm: kworker/7:1 Not tainted 5.7.0-rc2-00115-g8c2e9790f196 #116 [ 3.626646] Hardware name: HiKey960 (DT) [ 3.626656] Workqueue: events deferred_probe_work_func [ 3.632476] sd 0:0:0:0: [sda] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes) [ 3.640220] Call trace: [ 3.640225] dump_backtrace+0x0/0x1b8 [ 3.640227] show_stack+0x20/0x30 [ 3.640230] dump_stack+0xec/0x158 [ 3.640234] register_lock_class+0x598/0x5c0 [ 3.640235] __lock_acquire+0x80/0x16c0 [ 3.640236] lock_acquire+0xf4/0x4a0 [ 3.640241] _raw_spin_lock_irqsave+0x70/0xa8 [ 3.640245] uart_add_one_port+0x388/0x4b8 [ 3.640248] pl011_register_port+0x70/0xf0 [ 3.640250] pl011_probe+0x184/0x1b8 [ 3.640254] amba_probe+0xdc/0x180 [ 3.640256] really_probe+0xe0/0x338 [ 3.640257] driver_probe_device+0x60/0xf8 [ 3.640259] __device_attach_driver+0x8c/0xd0 [ 3.640260] bus_for_each_drv+0x84/0xd8 [ 3.640261] __device_attach+0xe4/0x140 [ 3.640263] device_initial_probe+0x1c/0x28 [ 3.640265] bus_probe_device+0xa4/0xb0 [ 3.640266] deferred_probe_work_func+0x7c/0xb8 [ 3.640269] process_one_work+0x2c0/0x768 [ 3.640271] worker_thread+0x4c/0x498 [ 3.640272] kthread+0x14c/0x158 [ 3.640275] ret_from_fork+0x10/0x1c Which seems to be due to the fact that after allocating the uap structure, nothing initializes the spinlock. Its a little confusing, as uart_port_spin_lock_init() is one place where the lock is supposed to be initialized, but it has an exception for the case where the port is a console. This makes it seem like a deeper fix is needed to properly register the console, but I'm not sure what that entails, and Andy suggested that this approach is less invasive. Thus, this patch resolves the issue by initializing the spinlock in the driver, and resolves the resulting warning. Cc: Andy Shevchenko Cc: Russell King Cc: Jiri Slaby Cc: linux-serial@vger.kernel.org Reported-by: Valentin Schneider Reviewed-by: Andy Shevchenko Signed-off-by: John Stultz Reviewed-and-tested-by: Valentin Schneider Link: https://lore.kernel.org/r/20200428184050.6501-1-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250: Fix max baud limit in generic 8250 port

2020-06-24T15:50:13+00:00

[ Upstream commit 7b668c064ec33f3d687c3a413d05e355172e6c92 ] Standard 8250 UART ports are designed in a way so they can communicate with baud rates up to 1/16 of a reference frequency. It's expected from most of the currently supported UART controllers. That's why the former version of serial8250_get_baud_rate() method called uart_get_baud_rate() with min and max baud rates passed as (port->uartclk / 16 / UART_DIV_MAX) and ((port->uartclk + tolerance) / 16) respectively. Doing otherwise, like it was suggested in commit ("serial: 8250_mtk: support big baud rate."), caused acceptance of bauds, which was higher than the normal UART controllers actually supported. As a result if some user-space program requested to set a baud greater than (uartclk / 16) it would have been permitted without truncation, but then serial8250_get_divisor(baud) (which calls uart_get_divisor() to get the reference clock divisor) would have returned a zero divisor. Setting zero divisor will cause an unpredictable effect varying from chip to chip. In case of DW APB UART the communications just stop. Lets fix this problem by getting back the limitation of (uartclk + tolerance) / 16 maximum baud supported by the generic 8250 port. Mediatek 8250 UART ports driver developer shouldn't have touched it in the first place notably seeing he already provided a custom version of set_termios() callback in that glue-driver which took into account the extended baud rate values and accordingly updated the standard and vendor-specific divisor latch registers anyway. Fixes: 81bb549fdf14 ("serial: 8250_mtk: support big baud rate.") Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Arnd Bergmann Cc: Long Cheng Cc: Andy Shevchenko Cc: Maxime Ripard Cc: Catalin Marinas Cc: Will Deacon Cc: Russell King Cc: linux-mips@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: https://lore.kernel.org/r/20200506233136.11842-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250: Avoid error message on reprobe

2020-06-22T07:31:18+00:00

commit e0a851fe6b9b619527bd928aa93caaddd003f70c upstream. If the call to uart_add_one_port() in serial8250_register_8250_port() fails, a half-initialized entry in the serial_8250ports[] array is left behind. A subsequent reprobe of the same serial port causes that entry to be reused. Because uart->port.dev is set, uart_remove_one_port() is called for the half-initialized entry and bails out with an error message: bcm2835-aux-uart 3f215040.serial: Removing wrong port: (null) != (ptrval) The same happens on failure of mctrl_gpio_init() since commit 4a96895f74c9 ("tty/serial/8250: use mctrl_gpio helpers"). Fix by zeroing the uart->port.dev pointer in the probe error path. The bug was introduced in v2.6.10 by historical commit befff6f5bf5f ("[SERIAL] Add new port registration/unregistration functions."): https://git.kernel.org/tglx/history/c/befff6f5bf5f The commit added an unconditional call to uart_remove_one_port() in serial8250_register_port(). In v3.7, commit 835d844d1a28 ("8250_pnp: do pnp probe before legacy probe") made that call conditional on uart->port.dev which allows me to fix the issue by zeroing that pointer in the error path. Thus, the present commit will fix the problem as far back as v3.7 whereas still older versions need to also cherry-pick 835d844d1a28. Fixes: 835d844d1a28 ("8250_pnp: do pnp probe before legacy probe") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v2.6.10 Cc: stable@vger.kernel.org # v2.6.10: 835d844d1a28: 8250_pnp: do pnp probe before legacy Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/b4a072013ee1a1d13ee06b4325afb19bda57ca1b.1589285873.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: Move Pericom IDs to pci_ids.h

2020-06-22T07:31:17+00:00

[ Upstream commit 62a7f3009a460001eb46984395280dd900bc4ef4 ] Move the IDs to pci_ids.h so it can be used by next patch. Link: https://lore.kernel.org/r/20200508065343.32751-1-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Acked-by: Greg Kroah-Hartman Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

kgdboc: Use a platform device to handle tty drivers showing up late

2020-06-22T07:31:06+00:00

[ Upstream commit 68e55f61c13842baf825958129698c5371db432c ] If you build CONFIG_KGDB_SERIAL_CONSOLE into the kernel then you should be able to have KGDB init itself at bootup by specifying the "kgdboc=..." kernel command line parameter. This has worked OK for me for many years, but on a new device I switched to it stopped working. The problem is that on this new device the serial driver gets its probe deferred. Now when kgdb initializes it can't find the tty driver and when it gives up it never tries again. We could try to find ways to move up the initialization of the serial driver and such a thing might be worthwhile, but it's nice to be robust against serial drivers that load late. We could move kgdb to init itself later but that penalizes our ability to debug early boot code on systems where the driver inits early. We could roll our own system of detecting when new tty drivers get loaded and then use that to figure out when kgdb can init, but that's ugly. Instead, let's jump on the -EPROBE_DEFER bandwagon. We'll create a singleton instance of a "kgdboc" platform device. If we can't find our tty device when the singleton "kgdboc" probes we'll return -EPROBE_DEFER which means that the system will call us back later to try again when the tty device might be there. We won't fully transition all of the kgdboc to a platform device because early kgdb initialization (via the "ekgdboc" kernel command line parameter) still runs before the platform device has been created. The kgdb platform device is merely used as a convenient way to hook into the system's normal probe deferral mechanisms. As part of this, we'll ever-so-slightly change how the "kgdboc=..." kernel command line parameter works. Previously if you booted up and kgdb couldn't find the tty driver then later reading '/sys/module/kgdboc/parameters/kgdboc' would return a blank string. Now kgdb will keep track of the string that came as part of the command line and give it back to you. It's expected that this should be an OK change. Signed-off-by: Douglas Anderson Reviewed-by: Greg Kroah-Hartman Reviewed-by: Daniel Thompson Link: https://lore.kernel.org/r/20200507130644.v4.3.I4a493cfb0f9f740ce8fd2ab58e62dc92d18fed30@changeid [daniel.thompson@linaro.org: Make config_mutex static] Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin

tty: serial: add missing spin_lock_init for SiFive serial console

2020-05-27T15:46:46+00:00

commit 17b4efdf4e4867079012a48ca10d965fe9d68822 upstream. An uninitialised spin lock for sifive serial console raises a bad magic spin_lock error as reported and discussed here [1]. Initialising the spin lock resolves the issue. The fix is tested on HiFive Unleashed A00 board with Linux 5.7-rc4 and OpenSBI v0.7 [1] https://lore.kernel.org/linux-riscv/b9fe49483a903f404e7acc15a6efbef756db28ae.camel@wdc.com Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART") Reported-by: Atish Patra Signed-off-by: Sagar Shrikant Kadam Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt Cc: stable Link: https://lore.kernel.org/r/1589019852-21505-2-git-send-email-sagar.kadam@sifive.com Signed-off-by: Greg Kroah-Hartman

tty: xilinx_uartps: Fix missing id assignment to the console

2020-05-14T05:58:19+00:00

[ Upstream commit 2ae11c46d5fdc46cb396e35911c713d271056d35 ] When serial console has been assigned to ttyPS1 (which is serial1 alias) console index is not updated property and pointing to index -1 (statically initialized) which ends up in situation where nothing has been printed on the port. The commit 18cc7ac8a28e ("Revert "serial: uartps: Register own uart console and driver structures"") didn't contain this line which was removed by accident. Fixes: 18cc7ac8a28e ("Revert "serial: uartps: Register own uart console and driver structures"") Signed-off-by: Shubhrajyoti Datta Cc: stable Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/ed3111533ef5bd342ee5ec504812240b870f0853.1588602446.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

Revert "serial: uartps: Register own uart console and driver structures"

2020-04-29T14:33:24+00:00

commit 18cc7ac8a28e28cd005c2475f52576cfe10cabfb upstream. This reverts commit 024ca329bfb9a948f76eaff3243e21b7e70182f2. As Johan says, this driver needs a lot more work and these changes are only going in the wrong direction: https://lkml.kernel.org/r/20190523091839.GC568@localhost Reported-by: Johan Hovold Signed-off-by: Michal Simek Cc: stable Link: https://lore.kernel.org/r/1ee35667e36a8efddee381df5fe495ad65f4d15c.1585905873.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman

Revert "serial: uartps: Move Port ID to device data structure"

2020-04-29T14:33:24+00:00

commit 492cc08bc16c44e2e587362ada3f6269dee2be22 upstream. This reverts commit bed25ac0e2b6ab8f9aed2d20bc9c3a2037311800. As Johan says, this driver needs a lot more work and these changes are only going in the wrong direction: https://lkml.kernel.org/r/20190523091839.GC568@localhost Reported-by: Johan Hovold Signed-off-by: Michal Simek Cc: stable Link: https://lore.kernel.org/r/eb0ec98fecdca9b79c1a3ac0c30c668b6973b193.1585905873.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman

Revert "serial: uartps: Change uart ID port allocation"

2020-04-29T14:33:24+00:00

commit 72d68197281e2ad313960504d10b0c41ff87fd55 upstream. This reverts commit ae1cca3fa3478be92948dbbcd722390272032ade. With setting up NR_PORTS to 16 to be able to use serial2 and higher aliases and don't loose functionality which was intended by these changes. As Johan says, this driver needs a lot more work and these changes are only going in the wrong direction: https://lkml.kernel.org/r/20190523091839.GC568@localhost Reported-by: Johan Hovold Signed-off-by: Michal Simek Cc: stable Link: https://lore.kernel.org/r/a94931b65ce0089f76fb1fe6b446a08731bff754.1585905873.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman