summaryrefslogtreecommitdiff
path: root/drivers/tty
AgeCommit message (Collapse)AuthorFilesLines
2020-10-05serial: mcf: add sysrq capabilityAngelo Dureghello1-0/+1
After some unsuccessful attempts to use sysrq over console, figured out that port->has_sysrq should likely be enabled, as per other architectures, this when CONFIG_SERIAL_MCF_CONSOLE is also enabled. Tested some magic sysrq commands (h, p, t, b), they works now properly. Commands works inside 5 secs after BREAK is sent, as expected. Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com> Link: https://lore.kernel.org/r/20201002140545.477481-1-angelo.dureghello@timesys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-05serial: fsl_lpuart: add sysrq support when using dmaAngelo Dureghello1-0/+57
Add handling of magic sysrq keys when using dma/edma. Tested by sending BREAK followed by a sysrq command inside a 5 secs time window, by: echo 1 > /proc/sys/kernel/sysrq BREAK + h, t, e, b, c Tested also sending a command after 5 secs after BREAK, that's properly ignored. Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com> Link: https://lore.kernel.org/r/20201004161144.1307174-1-angelo.dureghello@timesys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-02tty/sysrq: Extend the sysrq_key_table to cover capital lettersAndrzej Pietrasiewicz1-2/+47
All slots in sysrq_key_table[] are either used, reserved or at least commented with their intended use. This patch adds capital letter versions available, which means adding 26 more entries. For already existing SysRq operations the user presses Alt-SysRq-<key>, and for the newly added ones Alt-Shift-SysRq-<key>. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20200818112825.6445-2-andrzej.p@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-01serial: max310x: rework RX interrupt handlingThomas Petazzoni1-5/+24
Currently, the RX interrupt logic uses the RXEMPTY interrupt, with the RXEMPTYINV bit set, which means we get an RX interrupt as soon as the RX FIFO is non-empty. However, with the MAX310X having a FIFO of 128 bytes, this makes very poor use of the FIFO: we trigger an interrupt as soon as the RX FIFO has one byte, which means a lot of interrupts, each only collecting a few bytes from the FIFO, causing a significant CPU load. Instead this commit relies on two other RX interrupt events: - MAX310X_IRQ_RXFIFO_BIT, which triggers when the RX FIFO has reached a certain threshold, which we define to be half of the FIFO size. This ensure we get an interrupt before the RX FIFO fills up. - MAX310X_LSR_RXTO_BIT, which triggers when the RX FIFO has received some bytes, and then no more bytes are received for a certain time. Arbitrarily, this time is defined to the time is takes to receive 4 characters. On a Microchip SAMA5D3 platform that is receiving 20 bytes every 16ms over one MAX310X UART, this patch has allowed to reduce the CPU consumption of the interrupt handler thread from ~25% to 6-7%. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Link: https://lore.kernel.org/r/20201001074415.349739-1-thomas.petazzoni@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-30serial: 8250_dw: Fix clk-notifier/port suspend deadlockSerge Semin1-35/+19
It has been discovered that there is a potential deadlock between the clock-change-notifier thread and the UART port suspending one: CPU0 (suspend CPU/UART) CPU1 (update clock) ---- ---- lock(&port->mutex); lock((work_completion)(&data->clk_work)); lock(&port->mutex); lock((work_completion)(&data->clk_work)); *** DEADLOCK *** The best way to fix this is to eliminate the CPU0 port->mutex/work-completion scenario. So we suggest to register and unregister the clock-notifier during the DW APB UART port probe/remove procedures, instead of doing that at the points of the port startup/shutdown. Link: https://lore.kernel.org/linux-serial/f1cd5c75-9cda-6896-a4e2-42c5bfc3f5c3@redhat.com Fixes: cc816969d7b5 ("serial: 8250_dw: Fix common clocks usage race condition") Reported-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200923161950.6237-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-30serial: 8250: Skip uninitialized TTY port baud rate updateSerge Semin1-0/+4
It is erroneous to update the TTY port baud rate if it hasn't been initialized yet, because in that case the TTY struct isn't set. So there is no termios structure to get and re-calculate the baud if the current baud can't be reached. Let's skip the baud rate update then until the port is fully initialized. Note the update UART clock method still sets the uartclk member with a new ref clock value even if the port is turned off. The new UART ref clock rate will be used later on the port starting up procedure. Fixes: 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method") Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200923161950.6237-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-30serial: 8250: Discard RTS/DTS setting from clock update methodSerge Semin1-1/+0
It has been a mistake to add the MCR register RTS/DTS fields setting in the generic method of the UART reference clock update. There is no point in asserting these lines at that procedure. Just discard the serial8250_out_MCR() mathod invocation from there then. Fixes: 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method") Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200923161950.6237-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-30tty: serial: imx: disable TXDC IRQ in imx_uart_shutdown() to avoid IRQ stormMatthias Schiffer1-5/+6
The IPG clock is disabled at the end of imx_uart_shutdown(); we really don't want to run any IRQ handlers after this point. At least on i.MX8MN, the UART will happily continue to generate interrupts even with its clocks disabled, but in this state, all register writes are ignored (which will cause the shadow registers to differ from the actual register values, resulting in all kinds of weirdness). In a transfer without DMA, this could lead to the following sequence of events: - The UART finishes its transmission while imx_uart_shutdown() is run, triggering the TXDC interrupt (we can trigger this fairly reliably by writing a single byte to the TTY and closing it right away) - imx_uart_shutdown() finishes, disabling the UART clocks - imx_uart_int() -> imx_uart_transmit_buffer() -> imx_uart_stop_tx() imx_uart_stop_tx() should now clear UCR4_TCEN to disable the TXDC interrupt, but this register write is ineffective. This results in an interrupt storm. To disable all interrupts in the same place, and to avoid setting UCR4 twice, clearing UCR4_OREN is moved below del_timer_sync() as well; this should be harmless. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/20200925082412.12960-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-30serial: 8250_fsl: Fix TX interrupt handling conditionAndrij Abyzov1-1/+1
This is the port of the commit db1b5bc047b3 ("serial: 8250: Fix TX interrupt handling condition") to the 8250_fsl irq handling logic. Interrupt handler checked THRE bit (transmitter holding register empty) in LSR to detect if TX fifo is empty. In case when there is only receive interrupts the TX handling got called because THRE bit in LSR is set when there is no transmission (FIFO empty). TX handling caused TX stop, which in RS-485 half-duplex mode actually resets receiver FIFO. This is not desired during reception because of possible data loss. The fix is to check if THRI is set in IER in addition of the TX fifo status. THRI in IER is set when TX is started and cleared when TX is stopped. This ensures that TX handling is only called when there is really transmission on going and an interrupt for THRE and not when there are only RX interrupts. Signed-off-by: Andrij Abyzov <aabyzov@slb.com> Link: https://lore.kernel.org/r/20200928144127.87156-1-aabyzov@slb.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-30serial: pl011: Fix lockdep splat when handling magic-sysrq interruptPeter Zijlstra1-4/+7
Issuing a magic-sysrq via the PL011 causes the following lockdep splat, which is easily reproducible under QEMU: | sysrq: Changing Loglevel | sysrq: Loglevel set to 9 | | ====================================================== | WARNING: possible circular locking dependency detected | 5.9.0-rc7 #1 Not tainted | ------------------------------------------------------ | systemd-journal/138 is trying to acquire lock: | ffffab133ad950c0 (console_owner){-.-.}-{0:0}, at: console_lock_spinning_enable+0x34/0x70 | | but task is already holding lock: | ffff0001fd47b098 (&port_lock_key){-.-.}-{2:2}, at: pl011_int+0x40/0x488 | | which lock already depends on the new lock. [...] | Possible unsafe locking scenario: | | CPU0 CPU1 | ---- ---- | lock(&port_lock_key); | lock(console_owner); | lock(&port_lock_key); | lock(console_owner); | | *** DEADLOCK *** The issue being that CPU0 takes 'port_lock' on the irq path in pl011_int() before taking 'console_owner' on the printk() path, whereas CPU1 takes the two locks in the opposite order on the printk() path due to setting the "console_owner" prior to calling into into the actual console driver. Fix this in the same way as the msm-serial driver by dropping 'port_lock' before handling the sysrq. Cc: <stable@vger.kernel.org> # 4.19+ Cc: Russell King <linux@armlinux.org.uk> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20200811101313.GA6970@willie-the-truck Signed-off-by: Peter Zijlstra <peterz@infradead.org> Tested-by: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20200930120432.16551-1-will@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-30tty: serial: fsl_lpuart: fix lpuart32_poll_get_charPeng Fan1-1/+1
The watermark is set to 1, so we need to input two chars to trigger RDRF using the original logic. With the new logic, we could always get the char when there is data in FIFO. Suggested-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20200929095509.21680-1-peng.fan@nxp.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-30tty: serial: lpuart: fix lpuart32_write usagePeng Fan1-8/+6
The 2nd and 3rd parameter were wrongly used, and cause kernel abort when doing kgdb debug. Fixes: 1da17d7cf8e2 ("tty: serial: fsl_lpuart: Use appropriate lpuart32_* I/O funcs") Cc: stable <stable@vger.kernel.org> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20200929091920.22612-1-peng.fan@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-30serial: qcom_geni_serial: To correct QUP Version detection logicParas Sharma1-1/+1
For QUP IP versions 2.5 and above the oversampling rate is halved from 32 to 16. Commit ce734600545f ("tty: serial: qcom_geni_serial: Update the oversampling rate") is pushed to handle this scenario. But the existing logic is failing to classify QUP Version 3.0 into the correct group ( 2.5 and above). As result Serial Engine clocks are not configured properly for baud rate and garbage data is sampled to FIFOs from the line. So, fix the logic to detect QUP with versions 2.5 and above. Fixes: ce734600545f ("tty: serial: qcom_geni_serial: Update the oversampling rate") Cc: stable <stable@vger.kernel.org> Signed-off-by: Paras Sharma <parashar@codeaurora.org> Reviewed-by: Akash Asthana <akashast@codeaurora.org> Link: https://lore.kernel.org/r/1601445926-23673-1-git-send-email-parashar@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-29serial: mvebu-uart: fix unused variable warningQinglang Miao1-1/+1
There's a warning shows that 'ret' becomes an unused variable after simplify the return expression of mvebu_uart_probe(). So remove it. Fixes: b63537020db3 ("serial: mvebu-uart: simplify the return expression of mvebu_uart_probe()") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/20200929085651.158283-1-miaoqinglang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-27vt_ioctl: make VT_RESIZEX behave like VT_RESIZETetsuo Handa1-47/+10
syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data. VT_RESIZEX was introduced in Linux 1.3.3, but it is unclear that what comes to the "+ more" part, and I couldn't find a user of VT_RESIZEX. #define VT_RESIZE 0x5609 /* set kernel's idea of screensize */ #define VT_RESIZEX 0x560A /* set kernel's idea of screensize + more */ So far we are not aware of syzbot reports caused by setting non-zero value to v_vlin parameter. But given that it is possible that nobody is using VT_RESIZEX, we can try removing support for v_clin and v_vlin parameters. Therefore, this patch effectively makes VT_RESIZEX behave like VT_RESIZE, with emitting a message if somebody is still using v_clin and/or v_vlin parameters. [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Reported-by: syzbot <syzbot+b308f5fd049fbbc6e74f@syzkaller.appspotmail.com> Reported-by: syzbot <syzbot+16469b5e8e5a72e9131e@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/4933b81b-9b1a-355b-df0e-9b31e8280ab9@i-love.sakura.ne.jp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-27serial: mvebu-uart: simplify the return expression of mvebu_uart_probe()Qinglang Miao1-4/+1
Simplify the return expression. Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/20200921131105.93177-1-miaoqinglang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-27tty: serial: imx: fix link error with CONFIG_SERIAL_CORE_CONSOLE=nYang Yingliang1-0/+1
aarch64-linux-gnu-ld: drivers/tty/serial/imx_earlycon.o: in function `imx_uart_console_early_write': imx_earlycon.c:(.text+0x84): undefined reference to `uart_console_write' The driver uses the uart_console_write(), but SERIAL_CORE_CONSOLE is not selected, so uart_console_write is not defined, then we get the error. Fix this by selecting SERIAL_CORE_CONSOLE. Fixes: 699cc4dfd140 ("tty: serial: imx: add imx earlycon driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20200919063240.2754965-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-27tty: hvc: fix link error with CONFIG_SERIAL_CORE_CONSOLE=nYang Yingliang1-0/+1
aarch64-linux-gnu-ld: drivers/tty/hvc/hvc_dcc.o: in function `dcc_early_write': hvc_dcc.c:(.text+0x164): undefined reference to `uart_console_write' The driver uses the uart_console_write(), but SERIAL_CORE_CONSOLE is not selected, so uart_console_write is not defined, then we get the error. Fix this by selecting SERIAL_CORE_CONSOLE. Fixes: d1a1af2cdf19 ("hvc: dcc: Add earlycon support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20200919063535.2809707-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-27pch_uart: drop double zeroingJulia Lawall1-1/+1
sg_init_table zeroes its first argument, so the allocation of that argument doesn't have to. the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x,n,flags; @@ x = - kcalloc + kmalloc_array (n,sizeof(struct scatterlist),flags) ... sg_init_table(x,n) // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/1600601186-7420-2-git-send-email-Julia.Lawall@inria.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-21Merge 5.9.0-rc6 into tty-nextGreg Kroah-Hartman2-24/+30
We need the tty/serial fixes in here and this resolves a merge issue in the 8250 driver. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16tty: serial: qcom_geni_serial: Fix the UART wakeup issuesatya priya1-1/+1
As a part of system suspend uart_port_suspend is called from the Serial driver, which calls set_mctrl passing mctrl as 0. This makes RFR high(NOT_READY) during suspend. Due to this BT SoC is not able to send wakeup bytes to UART during suspend. Include if check for non-suspend case to keep RFR low during suspend. Signed-off-by: satya priya <skakit@codeaurora.org> Reviewed-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1599742438-16811-5-git-send-email-skakit@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: 8250_pci: Add Realtek 816a and 816bTobias Diedrich1-0/+11
These serial ports are exposed by the OOB-management-engine on RealManage-enabled network cards (e.g. AMD DASH enabled systems using Realtek cards). Because these have 3 BARs, they fail the "num_iomem <= 1" check in serial_pci_guess_board. I've manually checked the two IOMEM regions and BAR 2 doesn't seem to respond to reads, but BAR 4 seems to be an MMIO version of the IO ports (untested). With this change, the ports are detected: 0000:02:00.1: ttyS0 at I/O 0x2200 (irq = 82, base_baud = 115200) is a 16550A 0000:02:00.2: ttyS1 at I/O 0x2100 (irq = 55, base_baud = 115200) is a 16550A lspci output: 02:00.1 0700: 10ec:816a (rev 0e) (prog-if 02 [16550]) Subsystem: 17aa:5082 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin B routed to IRQ 82 IOMMU group: 11 Region 0: I/O ports at 2200 [size=256] Region 2: Memory at fd715000 (64-bit, non-prefetchable) [size=4K] Region 4: Memory at fd704000 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [70] Express (v2) Endpoint, MSI 01 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp- 10BitTagReq- OBFF Via message/WAKE#, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Vector table: BAR=4 offset=00000000 PBA: BAR=4 offset=00000800 Capabilities: [d0] Vital Product Data Not readable Capabilities: [100 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [170 v1] Latency Tolerance Reporting Max snoop latency: 0ns Max no snoop latency: 0ns Capabilities: [178 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=150us PortTPowerOnTime=150us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=0ns L1SubCtl2: T_PwrOn=10us 02:00.2 0700: 10ec:816b (rev 0e) [...same...] Signed-off-by: Tobias Diedrich <tobiasdiedrich@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200914173628.GA22508@yamamaya.is-a-geek.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: core: fix console port-lock regressionJohan Hovold1-17/+15
Fix the port-lock initialisation regression introduced by commit a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") by making sure that the lock is again initialised during console setup. The console may be registered before the serial controller has been probed in which case the port lock needs to be initialised during console setup by a call to uart_set_options(). The console-detach changes introduced a regression in several drivers by effectively removing that initialisation by not initialising the lock when the port is used as a console (which is always the case during console setup). Add back the early lock initialisation and instead use a new console-reinit flag to handle the case where a console is being re-attached through sysfs. The question whether the console-detach interface should have been added in the first place is left for another discussion. Note that the console-enabled check in uart_set_options() is not redundant because of kgdboc, which can end up reinitialising an already enabled console (see commit 42b6a1baa3ec ("serial_core: Don't re-initialize a previously initialized spinlock.")). Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") Cc: stable <stable@vger.kernel.org> # 5.7 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200909143101.15389-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: core: fix port-lock initialisationJohan Hovold1-8/+6
Commit f743061a85f5 ("serial: core: Initialise spin lock before use in uart_configure_port()") tried to work around a breakage introduced by commit a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") by adding a second initialisation of the port lock when registering the port. As reported by the build robots [1], this doesn't really solve the regression introduced by the console-detach changes and also adds a second redundant initialisation of the lock for normal ports. Start cleaning up this mess by removing the redundant initialisation and making sure that the port lock is again initialised once-only for ports that aren't already in use as a console. [1] https://lore.kernel.org/r/20200802054852.GR23458@shao2-debian Fixes: f743061a85f5 ("serial: core: Initialise spin lock before use in uart_configure_port()") Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") Cc: stable <stable@vger.kernel.org> # 5.7 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200909143101.15389-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16tty: serial: qcom_geni_serial: 115.2 is a better console default than 9600Douglas Anderson1-1/+1
Commit c5cbc78acf69 ("tty: serial: qcom_geni_serial: Initialize baud in qcom_geni_console_setup") fixed a bug by initting a variable that was used in some cases without initialization. However, the "default" baud rate picked by that CL was probably not the best choice. The chances that anyone out there is trying to run a system with kernel messages piped out over a 9600 baud serial port is just about nil. Console messages are printed in a blocking manner. At 9600 baud we print about 1 character per millisecond which means that printing a 40-byte message to the console will take ~40 ms. While it would probably work, it's going to make boot _very_ slow and probably cause the occasional timeout here and there in drivers (heck, even at 115200 console delays can wreck havoc). This has already bit at least two people that I'm aware of that tried to enable serial console by just adding "console=ttyMSM0" (instead of "console=ttyMSM0,115200n8") to the command line, so it seems like it'd be nice to fix. Let's switch the default to 115200. Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200911080054.1.I4c00b921c2f17b6988688046fa7be0f729f8d591@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: pmac_zilog: use for_each_child_of_node() macroQinglang Miao1-1/+1
Use for_each_child_of_node() macro instead of open coding it. Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/20200916062138.191188-1-miaoqinglang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16tty: serial: 8250_mtk: set regshift for mmio32Hsin-Yi Wang1-0/+1
To use mmio32, we also need to set regshift. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Acked-by: Eddie Huang <eddie.huang@mediatek.com> Link: https://lore.kernel.org/r/20200915054825.3289105-2-hsinyi@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16tty: serial: print earlycon info after match->setupHsin-Yi Wang1-1/+8
8250 devices may modify iotype in their own earlycon setup. For example: 8250_mtk and 8250_uniphier force iotype to be MMIO32. Print earlycon info after match->setup to reflect actual earlycon info. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Link: https://lore.kernel.org/r/20200915054825.3289105-1-hsinyi@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: ucc_uart: make qe_uart_set_mctrl() staticJason Yan1-1/+1
This eliminates the following sparse warning: drivers/tty/serial/ucc_uart.c:286:6: warning: symbol 'qe_uart_set_mctrl' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200912033834.143166-1-yanaijie@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: 8250_pci: Remove unused function get_pci_irq()YueHaibing1-9/+0
It is not used since commit 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200909135103.17768-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04pty: do tty_flip_buffer_push without port->lock in pty_writeArtem Savkov1-1/+1
b6da31b2c07c "tty: Fix data race in tty_insert_flip_string_fixed_flag" puts tty_flip_buffer_push under port->lock introducing the following possible circular locking dependency: [30129.876566] ====================================================== [30129.876566] WARNING: possible circular locking dependency detected [30129.876567] 5.9.0-rc2+ #3 Tainted: G S W [30129.876568] ------------------------------------------------------ [30129.876568] sysrq.sh/1222 is trying to acquire lock: [30129.876569] ffffffff92c39480 (console_owner){....}-{0:0}, at: console_unlock+0x3fe/0xa90 [30129.876572] but task is already holding lock: [30129.876572] ffff888107cb9018 (&pool->lock/1){-.-.}-{2:2}, at: show_workqueue_state.cold.55+0x15b/0x6ca [30129.876576] which lock already depends on the new lock. [30129.876577] the existing dependency chain (in reverse order) is: [30129.876578] -> #3 (&pool->lock/1){-.-.}-{2:2}: [30129.876581] _raw_spin_lock+0x30/0x70 [30129.876581] __queue_work+0x1a3/0x10f0 [30129.876582] queue_work_on+0x78/0x80 [30129.876582] pty_write+0x165/0x1e0 [30129.876583] n_tty_write+0x47f/0xf00 [30129.876583] tty_write+0x3d6/0x8d0 [30129.876584] vfs_write+0x1a8/0x650 [30129.876588] -> #2 (&port->lock#2){-.-.}-{2:2}: [30129.876590] _raw_spin_lock_irqsave+0x3b/0x80 [30129.876591] tty_port_tty_get+0x1d/0xb0 [30129.876592] tty_port_default_wakeup+0xb/0x30 [30129.876592] serial8250_tx_chars+0x3d6/0x970 [30129.876593] serial8250_handle_irq.part.12+0x216/0x380 [30129.876593] serial8250_default_handle_irq+0x82/0xe0 [30129.876594] serial8250_interrupt+0xdd/0x1b0 [30129.876595] __handle_irq_event_percpu+0xfc/0x850 [30129.876602] -> #1 (&port->lock){-.-.}-{2:2}: [30129.876605] _raw_spin_lock_irqsave+0x3b/0x80 [30129.876605] serial8250_console_write+0x12d/0x900 [30129.876606] console_unlock+0x679/0xa90 [30129.876606] register_console+0x371/0x6e0 [30129.876607] univ8250_console_init+0x24/0x27 [30129.876607] console_init+0x2f9/0x45e [30129.876609] -> #0 (console_owner){....}-{0:0}: [30129.876611] __lock_acquire+0x2f70/0x4e90 [30129.876612] lock_acquire+0x1ac/0xad0 [30129.876612] console_unlock+0x460/0xa90 [30129.876613] vprintk_emit+0x130/0x420 [30129.876613] printk+0x9f/0xc5 [30129.876614] show_pwq+0x154/0x618 [30129.876615] show_workqueue_state.cold.55+0x193/0x6ca [30129.876615] __handle_sysrq+0x244/0x460 [30129.876616] write_sysrq_trigger+0x48/0x4a [30129.876616] proc_reg_write+0x1a6/0x240 [30129.876617] vfs_write+0x1a8/0x650 [30129.876619] other info that might help us debug this: [30129.876620] Chain exists of: [30129.876621] console_owner --> &port->lock#2 --> &pool->lock/1 [30129.876625] Possible unsafe locking scenario: [30129.876626] CPU0 CPU1 [30129.876626] ---- ---- [30129.876627] lock(&pool->lock/1); [30129.876628] lock(&port->lock#2); [30129.876630] lock(&pool->lock/1); [30129.876631] lock(console_owner); [30129.876633] *** DEADLOCK *** [30129.876634] 5 locks held by sysrq.sh/1222: [30129.876634] #0: ffff8881d3ce0470 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x359/0x650 [30129.876637] #1: ffffffff92c612c0 (rcu_read_lock){....}-{1:2}, at: __handle_sysrq+0x4d/0x460 [30129.876640] #2: ffffffff92c612c0 (rcu_read_lock){....}-{1:2}, at: show_workqueue_state+0x5/0xf0 [30129.876642] #3: ffff888107cb9018 (&pool->lock/1){-.-.}-{2:2}, at: show_workqueue_state.cold.55+0x15b/0x6ca [30129.876645] #4: ffffffff92c39980 (console_lock){+.+.}-{0:0}, at: vprintk_emit+0x123/0x420 [30129.876648] stack backtrace: [30129.876649] CPU: 3 PID: 1222 Comm: sysrq.sh Tainted: G S W 5.9.0-rc2+ #3 [30129.876649] Hardware name: Intel Corporation 2012 Client Platform/Emerald Lake 2, BIOS ACRVMBY1.86C.0078.P00.1201161002 01/16/2012 [30129.876650] Call Trace: [30129.876650] dump_stack+0x9d/0xe0 [30129.876651] check_noncircular+0x34f/0x410 [30129.876653] __lock_acquire+0x2f70/0x4e90 [30129.876656] lock_acquire+0x1ac/0xad0 [30129.876658] console_unlock+0x460/0xa90 [30129.876660] vprintk_emit+0x130/0x420 [30129.876660] printk+0x9f/0xc5 [30129.876661] show_pwq+0x154/0x618 [30129.876662] show_workqueue_state.cold.55+0x193/0x6ca [30129.876664] __handle_sysrq+0x244/0x460 [30129.876665] write_sysrq_trigger+0x48/0x4a [30129.876665] proc_reg_write+0x1a6/0x240 [30129.876666] vfs_write+0x1a8/0x650 It looks like the commit was aimed to protect tty_insert_flip_string and there is no need for tty_flip_buffer_push to be under this lock. Fixes: b6da31b2c07c ("tty: Fix data race in tty_insert_flip_string_fixed_flag") Signed-off-by: Artem Savkov <asavkov@redhat.com> Acked-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20200902120045.3693075-1-asavkov@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04tty: hvcs: Don't NULL tty->driver_data until hvcs_cleanup()Tyrel Datwyler1-7/+7
The code currently NULLs tty->driver_data in hvcs_close() with the intent of informing the next call to hvcs_open() that device needs to be reconfigured. However, when hvcs_cleanup() is called we copy hvcsd from tty->driver_data which was previoulsy NULLed by hvcs_close() and our call to tty_port_put(&hvcsd->port) doesn't actually do anything since &hvcsd->port ends up translating to NULL by chance. This has the side effect that when hvcs_remove() is called we have one too many port references preventing hvcs_destuct_port() from ever being called. This also prevents us from reusing the /dev/hvcsX node in a future hvcs_probe() and we can eventually run out of /dev/hvcsX devices. Fix this by waiting to NULL tty->driver_data in hvcs_cleanup(). Fixes: 27bf7c43a19c ("TTY: hvcs, add tty install") Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com> Link: https://lore.kernel.org/r/20200820234643.70412-1-tyreld@linux.ibm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04tty: ipwireless: fix error handlingTong Zhang2-3/+3
ipwireless_send_packet() can only return 0 on success and -ENOMEM on error, the caller should check non zero for error condition Signed-off-by: Tong Zhang <ztong0001@gmail.com> Acked-by: David Sterba <dsterba@suse.com> Link: https://lore.kernel.org/r/20200821161942.36589-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04tty: synclink_gt: switch from 'pci_' to 'dma_' APIChristophe JAILLET1-5/+9
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'alloc_desc()' and 'alloc_bufs()', GFP_KERNEL can be used because it is only called from a probe function and no lock is acquired. The call chain is: init_one (the probe function) --> device_init --> alloc_dma_bufs --> alloc_desc --> alloc_bufs @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20200806054404.728854-1-christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04tty: serial: icom: switch from 'pci_' to 'dma_' APIChristophe JAILLET1-14/+18
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'get_port_memory()', GFP_KERNEL can be used because it is only called from a probe function and no lock is acquired. The call chain is: icom_probe (the probe function) --> icom_load_ports --> get_port_memory When memory is allocated in 'load_code()', GFP_KERNEL can be used because it is only called from a .startup function. icom_open (the .startup function of struct uart_ops) --> startup --> load_code .startup functions are protected using a semaphore and no spinlock is taken. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/20200806060507.730142-1-christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04serial: 8250_fsl: Add ACPI supportkuldip dwivedi1-7/+101
This adds support for ACPI enumerated FSL 16550 UARTs. For supporting ACPI, I added a wrapper so that this driver can be used if firmware has exposed the HID "NXP0018" in DSDT table. This will be built as object file if config "SERIAL_8250_FSL" is enabled which depends on config "SERIAL_8250_CONSOLE". Signed-off-by: kuldip dwivedi <kuldip.dwivedi@puresoftware.com> Link: https://lore.kernel.org/r/20200903113402.12371-1-kuldip.dwivedi@puresoftware.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04serial: stm32: Add RS485 RTS GPIO control againMarek Vasut1-8/+25
While the STM32 does support RS485 drive-enable control within the UART IP itself, some systems have the drive-enable line connected to a pin which cannot be pinmuxed as RTS. Add support for toggling the RTS GPIO line using the modem control GPIOs to provide at least some sort of emulation. Fixes: 7df5081cbf5e ("serial: stm32: Add RS485 RTS GPIO control") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Fabrice Gasnier <fabrice.gasnier@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com Link: https://lore.kernel.org/r/20200831171045.205691-1-marex@denx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04tty: serial: earlycon dependencyTong Zhang1-0/+1
parse_options() in drivers/tty/serial/earlycon.c calls uart_parse_earlycon in drivers/tty/serial/serial_core.c therefore selecting SERIAL_EARLYCON should automatically select SERIAL_CORE, otherwise will result in symbol not found error during linking if SERIAL_CORE is not configured as builtin Fixes: 9aac5887595b ("tty/serial: add generic serial earlycon") Signed-off-by: Tong Zhang <ztong0001@gmail.com> Link: https://lore.kernel.org/r/20200828123949.2642-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04sc16is7xx: Set iobase to device indexDaniel Mack1-0/+1
Some derivates of sc16is7xx devices expose more than one tty device to userspace. If multiple such devices exist in a system, userspace currently has no clean way to infer which tty maps to which physical line. Set the .iobase value to the relative index within the device to allow infering the order through sysfs. Signed-off-by: Daniel Mack <daniel@zonque.org> Link: https://lore.kernel.org/r/20200901120329.4176302-1-daniel@zonque.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04serial: core: Simplify with dev_err_probe()Krzysztof Kozlowski1-3/+1
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and the error value gets printed. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/20200901153100.18827-2-krzk@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04serial: 8250: Simplify with dev_err_probe()Krzysztof Kozlowski2-23/+9
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and the error value gets printed. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/20200901153100.18827-1-krzk@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-04serial: imx: Delete duplicated argument to '|' in imx_uart_probeYe Bin1-2/+1
When calculate "ucr1" UCR1_TRDYEN is duplicate. Signed-off-by: Ye Bin <yebin10@huawei.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20200903062401.692442-1-yebin10@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-31Merge 5.9-rc3 into tty-nextGreg Kroah-Hartman28-49/+89
We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-28serial: 8250_pci: Add WCH384_8S 8 port serial deviceDu Huanpeng1-0/+56
Add PCI id for WCH384_8S 8 port PCI-E serial card. because this card has so many ports, you may have to check these two options before use it: CONFIG_SERIAL_8250_RUNTIME_UARTS CONFIG_SERIAL_8250_NR_UARTS Signed-off-by: Du Huanpeng <u74147@gmail.com> Link: https://lore.kernel.org/r/1598060848-27807-1-git-send-email-u74147@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-28tty: serial: qcom_geni_serial: Unconditionally call dev_pm_opp_of_remove_table()Viresh Kumar1-8/+5
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to find the OPP table with error -ENODEV (i.e. OPP table not present for the device). And we can call dev_pm_opp_of_remove_table() unconditionally here. While at it, create a new label to put clkname on errors. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/583003f385a103b4c089ce8144a215c58cfb117a.1598594714.git.viresh.kumar@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-28serial: core: don't use snprintf() for formatting sysfs attrsAlex Dewar1-13/+13
As per the documentation (Documentation/filesystems/sysfs.rst), snprintf() should not be used for formatting values returned by sysfs. For all of the instances in serial_core.c, we know that the string will be <PAGE_SIZE in length, so just use sprintf(). Issue identified by Coccinelle. Signed-off-by: Alex Dewar <alex.dewar90@gmail.com> Link: https://lore.kernel.org/r/20200824223932.27709-1-alex.dewar90@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-28serial: fsl_lpuart: Fix typo in "transfer"Fabio Estevam1-2/+2
Fix two occurrences where "transfer" is spelled incorrectly. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20200818224457.16507-1-festevam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-26Merge tag 'tty-5.9-rc3' of ↵Linus Torvalds10-23/+66
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are a few small TTY/Serial/vt fixes for 5.9-rc3 Included in here are: - qcom serial fixes - vt ioctl and core bugfixes - pl011 serial driver fixes - 8250 serial driver fixes - other misc serial driver fixes and for good measure: - fbcon fix for syzbot found problem. All of these have been in linux-next for a while with no reported issues" * tag 'tty-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: tty: serial: imx: add dependence and build for earlycon serial: samsung: Removes the IRQ not found warning serial: 8250: change lock order in serial8250_do_startup() serial: stm32: avoid kernel warning on absence of optional IRQ serial: pl011: Fix oops on -EPROBE_DEFER serial: pl011: Don't leak amba_ports entry on driver register error serial: 8250_exar: Fix number of ports for Commtech PCIe cards tty: serial: qcom_geni_serial: Drop __init from qcom_geni_console_setup serial: qcom_geni_serial: Fix recent kdb hang vt_ioctl: change VT_RESIZEX ioctl to check for error return from vc_resize() fbcon: prevent user font height or width change from causing potential out-of-bounds access vt: defer kfree() of vc_screenbuf in vc_do_resize()
2020-08-24Revert "vc_screen: extract vcs_read_buf_header"Jiri Slaby1-18/+13
This reverts commit b1c32fcfadf5593ab7a63261cc8a5747c36e627e, because Syzkaller reports a use-after-free, a write in vcs_read: BUG: KASAN: use-after-free in vcs_read_buf drivers/tty/vt/vc_screen.c:357 [inline] BUG: KASAN: use-after-free in vcs_read+0xaa7/0xb40 drivers/tty/vt/vc_screen.c:449 Write of size 2 at addr ffff8880a8014000 by task syz-executor.5/16936 CPU: 1 PID: 16936 Comm: syz-executor.5 Not tainted 5.9.0-rc1-next-20200820-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: ... kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 vcs_read_buf drivers/tty/vt/vc_screen.c:357 [inline] vcs_read+0xaa7/0xb40 drivers/tty/vt/vc_screen.c:449 There are two issues with the patch: 1) vcs_read rounds the 'count' *up* to an even number. So if we read odd bytes from the header (3 bytes in the reproducer), the second byte of a (2-byte/ushort) write to temporary con_buf won't fit. It is because with the patch applied, we only subtract the real number read (3 bytes) and not the whole header (4 bytes). 2) in this scenario, we perform unaligned accesses now: there are 2-byte/ushort writes to odd addresses. Due to the same reason as above. Revert this for now, re-think and retry later. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Reported-by: syzbot+ad1f53726c3bd11180cb@syzkaller.appspotmail.com Fixes: b1c32fcfadf5 ("vc_screen: extract vcs_read_buf_header") Cc: akpm@linux-foundation.org Cc: nico@fluxnic.net Link: https://lore.kernel.org/r/20200824095425.4376-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-24treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva20-26/+23
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-18 11:49:32 +0300