summaryrefslogtreecommitdiffstats
path: root/drivers/tty
AgeCommit message (Collapse)AuthorFilesLines
2019-06-10serial: stm32: fix a recursive locking in stm32_config_rs485Borut Seljak1-3/+0
Remove spin_lock_irqsave in stm32_config_rs485, it cause recursive locking. Already locked in uart_set_rs485_config. Fixes: 1bcda09d291081 ("serial: stm32: add support for RS485 hardware control mode") Signed-off-by: Borut Seljak <borut.seljak@t-2.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-10tty: serial: 8250-of: Do not warn on deferred probeThierry Reding1-2/+3
Deferred probe is an expected return value for clk_get() on many platforms. The driver deals with it properly, so there's no need to output a warning that may potentially confuse users. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-10serial: imx: Use dev_info() instead of pr_info()Fabio Estevam1-1/+1
dev_info() is more appropriate for printing messages inside drivers, so switch to dev_info(). Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-10serial: fsl_lpuart: Use dev_info() instead of printk()Fabio Estevam1-2/+2
dev_info() is more appropriate for printing messages inside drivers, so switch to dev_info(). Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-10uart: mediatek: support Rx in-band wakeupClaire Chang1-0/+24
In order to support Rx in-band wakeup, we need to enable irq wake on an edge sensitive interrupt of Rx pin before suspend and disable it when resuming. This interrupt is used only as wake source to resume the system when suspended. Note that the sent character will be lost as the controller is actually suspended. We use this to support wakeup on bluetooth. Bluetooth will repeatedly send 0xFD to wakeup host. Once host detects Rx falling, an interrupt is triggered, and the system leaves sleep state. Then, the bluetooth driver will send 0xFC to bluetooth and bluetooth can start to send normal HCI packets. Signed-off-by: Claire Chang <tientzu@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-10serial: uartps: Add a timeout to the tx empty waitShubhrajyoti Datta1-4/+10
In case the cable is not connected then the target gets into an infinite wait for tx empty. Add a timeout to the tx empty wait. Reported-by: Jean-Francois Dagenais <jeff.dagenais@gmail.com> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-10serial: uartps: Move the spinlock after the read of the tx emptyShubhrajyoti Datta1-2/+1
Currently we are doing a read of the status register. Move the spinlock after that as the reads need not be spinlock protected. This patch prevents relaxing the cpu with spinlock held. Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-10serial: 8250-mtk: modify uart DMA rxLong Cheng1-29/+20
Modify uart rx and complete for DMA Signed-off-by: Long Cheng <long.cheng@mediatek.com> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-10tty/serial: digicolor: Fix digicolor-usart already registered warningKefeng Wang1-1/+5
When modprobe/rmmod/modprobe module, if platform_driver_register() fails, the kernel complained, proc_dir_entry 'driver/digicolor-usart' already registered WARNING: CPU: 1 PID: 5636 at fs/proc/generic.c:360 proc_register+0x19d/0x270 Fix this by adding uart_unregister_driver() when platform_driver_register() fails. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Acked-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-10serial: stm32: Make stm32_get_databits staticYueHaibing1-1/+1
Fix sparse warning: drivers/tty/serial/stm32-usart.c:603:14: warning: symbol 'stm32_get_databits' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-10serial: stm32: select pinctrl state in each suspend/resume functionBich Hemon1-0/+4
Select either pinctrl sleep state in suspend function or default state in resume function. Signed-off-by: Bich Hemon <bich.hemon@st.com> Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-04Revert "consolemap: Fix a memory leaking bug in drivers/tty/vt/consolemap.c"Ben Hutchings1-5/+1
This reverts commit 84ecc2f6eb1cb12e6d44818f94fa49b50f06e6ac. con_insert_unipair() is working with a sparse 3-dimensional array: - p->uni_pgdir[] is the top layer - p1 points to a middle layer - p2 points to a bottom layer If it needs to allocate a new middle layer, and then fails to allocate a new bottom layer, it would previously free only p2, and now it frees both p1 and p2. But since the new middle layer was already registered in the top layer, it was not leaked. However, if it looks up an *existing* middle layer and then fails to allocate a bottom layer, it now frees both p1 and p2 but does *not* free any other bottom layers under p1. So it *introduces* a memory leak. The error path also cleared the wrong index in p->uni_pgdir[], introducing a use-after-free. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Fixes: 84ecc2f6eb1c ("consolemap: Fix a memory leaking bug in drivers/tty/vt/consolemap.c") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-04serial: sa1100: add note about modem control signalsRussell King1-0/+4
As suggested by Uwe, add a note indicating that the modem control signals do not support interrupts, which precludes the driver from using mctrl_gpio_init(). Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-06-04serial: sa1100: add support for mctrl gpiosRussell King2-4/+39
Add support for the generic mctrl gpio helper. This will allow us to convert several board files to use the gpiod tables to assign GPIOs to serial ports, rather than needing to have private function callbacks. If the generic mctrl gpio helper fails, ignore the mctrl gpios rather than preventing the (possibly console) serial port from being created. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-06-03Merge 5.2-rc3 into tty-nextGreg Kroah-Hartman4-3/+12
We want the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24vt/fbcon: deinitialize resources in visual_init() after failed memory allocationGrzegorz Halat1-2/+9
After memory allocation failure vc_allocate() doesn't clean up data which has been initialized in visual_init(). In case of fbcon this leads to divide-by-0 in fbcon_init() on next open of the same tty. memory allocation in vc_allocate() may fail here: 1097: vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_KERNEL); on next open() fbcon_init() skips vc_font.data initialization: 1088: if (!p->fontdata) { division by zero in fbcon_init() happens here: 1149: new_cols /= vc->vc_font.width; Additional check is needed in fbcon_deinit() to prevent usage of uninitialized vc_screenbuf: 1251: if (vc->vc_hi_font_mask && vc->vc_screenbuf) 1252: set_vc_hi_font(vc, false); Crash: #6 [ffffc90001eafa60] divide_error at ffffffff81a00be4 [exception RIP: fbcon_init+463] RIP: ffffffff814b860f RSP: ffffc90001eafb18 RFLAGS: 00010246 ... #7 [ffffc90001eafb60] visual_init at ffffffff8154c36e #8 [ffffc90001eafb80] vc_allocate at ffffffff8154f53c #9 [ffffc90001eafbc8] con_install at ffffffff8154f624 ... Signed-off-by: Grzegorz Halat <ghalat@redhat.com> Reviewed-by: Oleksandr Natalenko <oleksandr@redhat.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24tty: cpm_uart: drop unused iflag macroJohan Hovold1-2/+0
Drop the RELEVANT_IFLAG() macro which hasn't been used at least since the dawn of git. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24tty: tty_io: fix driver refcount imbalance on error pathLin Yi1-1/+3
tty_lookup_driver take a reference to the struct tty_driver, but forget to release it on the error path, lead to a memory leak. add a tty_driver_kref_put before error return. Signed-off-by: Lin Yi <teroincn@163.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24vt/fbcon: deinitialize resources in visual_init() after failed memory allocationGrzegorz Halat1-2/+9
After memory allocation failure vc_allocate() doesn't clean up data which has been initialized in visual_init(). In case of fbcon this leads to divide-by-0 in fbcon_init() on next open of the same tty. memory allocation in vc_allocate() may fail here: 1097: vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_KERNEL); on next open() fbcon_init() skips vc_font.data initialization: 1088: if (!p->fontdata) { division by zero in fbcon_init() happens here: 1149: new_cols /= vc->vc_font.width; Additional check is needed in fbcon_deinit() to prevent usage of uninitialized vc_screenbuf: 1251: if (vc->vc_hi_font_mask && vc->vc_screenbuf) 1252: set_vc_hi_font(vc, false); Crash: #6 [ffffc90001eafa60] divide_error at ffffffff81a00be4 [exception RIP: fbcon_init+463] RIP: ffffffff814b860f RSP: ffffc90001eafb18 RFLAGS: 00010246 ... #7 [ffffc90001eafb60] visual_init at ffffffff8154c36e #8 [ffffc90001eafb80] vc_allocate at ffffffff8154f53c #9 [ffffc90001eafbc8] con_install at ffffffff8154f624 ... Signed-off-by: Grzegorz Halat <ghalat@redhat.com> Reviewed-by: Oleksandr Natalenko <oleksandr@redhat.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24consolemap: Fix a memory leaking bug in drivers/tty/vt/consolemap.cGen Zhang1-1/+5
In function con_insert_unipair(), when allocation for p2 and p1[n] fails, ENOMEM is returned, but previously allocated p1 is not freed, remains as leaking memory. Thus we should free p1 as well when this allocation fails. Signed-off-by: Gen Zhang <blackgod016574@gmail.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24tty: serial: cpm_uart - fix init when SMC is relocatedChristophe Leroy1-6/+11
SMC relocation can also be activated earlier by the bootloader, so the driver's behaviour cannot rely on selected kernel config. When the SMC is relocated, CPM_CR_INIT_TRX cannot be used. But the only thing CPM_CR_INIT_TRX does is to clear the rstate and tstate registers, so this can be done manually, even when SMC is not relocated. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Fixes: 9ab921201444 ("cpm_uart: fix non-console port startup bug") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24serial: stm32: fix the get_irq error caseErwan Le Ray1-8/+26
Checks the returned values of platform_get_irq() for both required "event" and optional "wakeup" IRQs during probe. This allows the driver probe to be deferred if needed. Removes redundant checks for 'cfg.has_wakeup'. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24serial: stm32: fix wakeup source initializationErwan Le Ray1-13/+15
Fixes dedicated_irq_wakeup issue and deactivated uart as wakeup source by default. Fixes: 270e5a74fe4c ("serial: stm32: add wakeup mechanism") Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24serial: stm32: Add support of TC bit status checkErwan Le Ray1-17/+15
Adds a check on the Transmission Complete bit status before closing the com port. Prevents the port closure before the end of the transmission. TC poll loop is moved from stm32_tx_dma_complete to stm32_shutdown routine, in order to check TC before shutdown in both dma and PIO tx modes. TC clear is added in stm32_transmit_char routine, in order to be cleared before transmitting in both dma and PIO tx modes. Fixes: 3489187204eb ("serial: stm32: adding dma support") Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24serial: stm32: fix transmit_chars when tx is stoppedErwan Le Ray1-8/+3
Disables the tx irq when the transmission is ended and updates stop_tx conditions for code cleanup. Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24serial: stm32: fix rx data length when parity enabledErwan Le Ray2-4/+9
- Fixes a rx data error when data length < 8 bits and parity is enabled. RDR register MSB is used for parity bit reception. - Adds a mask to ignore MSB when data is get from RDR. Fixes: 3489187204eb ("serial: stm32: adding dma support") Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24serial: stm32: fix rx error handlingErwan Le Ray2-27/+37
- Fixes parity and framing error bit by clearing parity and framing error flag. The current implementation doesn't clear the error bits when an error is detected. - Fixes the incorrect name of framing error clearing flag in header file. - Fixes misalignement between data frame and errors status. The status read for "n" frame was the status of "n+1" frame". - Fixes break detection was not triggered by the expected register. Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24serial: stm32: fix word length configurationErwan Le Ray2-9/+50
STM32 supports either: - 8 and 9 bits word length (including parity bit) for stm32f4 compatible devices - 7, 8 and 9 bits word length (including parity bit) for stm32f7 and stm32h7 compatible devices. As a consequence STM32 supports the following termios configurations: - CS7 with parity bit, and CS8 (with or without parity bit) for stm32f4 compatible devices. - CS6 with parity bit, CS7 and CS8 (with or without parity bit) for stm32f7 and stm32h7 compatible devices. This patch is fixing word length by configuring correctly the SoC with supported configurations. Fixes: ada8618ff3bf ("serial: stm32: adding support for stm32f7") Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Fix external crystal register setupJoe Burmeister1-1/+1
The datasheet states: Bit 4: ClockEnSet the ClockEn bit high to enable an external clocking (crystal or clock generator at XIN). Set the ClockEn bit to 0 to disable clocking Bit 1: CrystalEnSet the CrystalEn bit high to enable the crystal oscillator. When using an external clock source at XIN, CrystalEn must be set low. The bit 4, MAX310X_CLKSRC_EXTCLK_BIT, should be set and was not. This was required to make the MAX3107 with an external crystal on our board able to send or receive data. Signed-off-by: Joe Burmeister <joe.burmeister@devtank.co.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21serial: sh-sci: disable DMA for uart_consoleGeorge G. Davis1-0/+7
As noted in commit 84b40e3b57ee ("serial: 8250: omap: Disable DMA for console UART"), UART console lines use low-level PIO only access functions which will conflict with use of the line when DMA is enabled, e.g. when the console line is also used for systemd messages. So disable DMA support for UART console lines. Reported-by: Michael Rodin <mrodin@de.adit-jv.com> Link: https://patchwork.kernel.org/patch/10929511/ Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: stable@vger.kernel.org Signed-off-by: George G. Davis <george_davis@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21serial: imx: remove log spamming error messageSascha Hauer1-1/+0
Each time the DMA engine signals a transaction error the driver prints a message at error level. Getting transaction errors is pretty much expected on baudrate mismatches and the correspoding error counters are increased in this case properly. Remove the error message which is possibly repeated at a very high rate which can lock up the whole system. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: serial: msm_serial: Fix XON/XOFFJorge Ramirez-Ortiz1-1/+4
When the tty layer requests the uart to throttle, the current code executing in msm_serial will trigger "Bad mode in Error Handler" and generate an invalid stack frame in pstore before rebooting (that is if pstore is indeed configured: otherwise the user shall just notice a reboot with no further information dumped to the console). This patch replaces the PIO byte accessor with the word accessor already used in PIO mode. Fixes: 68252424a7c7 ("tty: serial: msm: Support big-endian CPUs") Cc: stable@vger.kernel.org Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Split uart characters insertion loopSerge Semin1-4/+10
Batch read mode doesn't check any conditions or flags except the Rx overflow one. But it may only happen after the last character is pushed into the RHR register. In this case we shouldn't push all the read characters with overrun flag set, but only the last one caused the FIFO overflow. This commit splits the characters retrieval loop into two parts. First one is ordinary intsert-chars procedure without taking the overrun status into account. Second part inserts the last character checking whether the overrun happened and pushing a '\0' character with TTY_OVERRUN flag to a flip-buffer. If we left the loop the way it was the '\0' character would be inserted after each character retrieved at the overrun occasion. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Optionally enable rs485 on startupSerge Semin1-0/+16
UART port might be pre-configured with rs485 enabled flag at the time of the port starting up process. In this case we need to have the hardware rs485-related registers initialized in accordance with the rs485 flags and settings provided by the configs descriptor. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Add rx-during-tx rs485 flag supportSerge Semin1-15/+14
The driver currently sets the echo suppression bit by default when rs485 is enabled. Naturally it disables any data retrieval in rs485 mode while RTSn is pushed up. The receiver gate (RX_) can be enabled just by clearing (or not setting) the EchoSuprs bit of mode2 register. So by setting or clearing the bit we implement the SER_RS485_RX_DURING_TX rs485 flag support. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Fix invalid baudrate divisors calculatorSerge Semin1-20/+31
Current calculator doesn't do it' job quite correct. First of all the max310x baud-rates generator supports the divisor being less than 16. In this case the x2/x4 modes can be used to double or quadruple the reference frequency. But the current baud-rate setter function just filters all these modes out by the first condition and setups these modes only if there is a clocks-baud division remainder. The former doesn't seem right at all, since enabling the x2/x4 modes causes the line noise tolerance reduction and should be only used as a last resort to enable a requested too high baud-rate. Finally the fraction is supposed to be calculated from D = Fref/(c*baud) formulae, but not from D % 16, which causes the precision loss. So to speak the current baud-rate calculator code works well only if the baud perfectly fits to the uart reference input frequency. Lets fix the calculator by implementing the algo fully compliant with the fractional baud-rate generator described in the datasheet: D = Fref / (c*baud), where c={16,8,4} is the x1/x2/x4 rate mode respectively, Fref - reference input frequency. The divisor fraction is calculated from the same formulae, but making sure it is found with a resolution of 0.0625 (four bits). Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Don't pass stacked buffers to SPISerge Semin1-9/+18
SPI transfer tx/rx buffers must be DMA-safe and the structure documentation clearly states this. Data declared on the system stack isn't DMA-safe [1]. Instead at least kernel memory should be used for the buffers. In order to fix this here we can create the buffers at the device probing stage and use them without any synchronization, since batch read/write methods are called from non-reentrant contexts - either from rx-event IRQ threaded handler or from the tx workqueue item. [1] Documentation/DMA-API-HOWTO.txt Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Introduce max310x_one port macro-wrapperSerge Semin1-3/+5
uart_port structure instance is embedded into the max310x_one super-structure, which is accessed by some of the uart-port callback methods. In order to improve the callback's code readability lets define the to_max310x_port() wrapper which just translates the passed uart_port pointer to the max310x_one one. It is also going to be handy in future commits. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Simplify tx-work item codeSerge Semin1-13/+3
Since cmwq introduction in the kernel, workqueues've been turned into non-reentrant execution contexts [1]. It means any work item is guaranteed to be executed by at most one worker system-wide at any given time. Since tx-handler max310x_handle_tx() is called by a single work item we don't need it to be self-protected by the mutex. We also don't need to check the tx work item pending state before scheduling it (which in the first place was racy btw), since cmwq will make sure to reschedule the item if it wasn't pending at the moment of schedule_work() call. [1] Documentation/core-api/workqueue.rst Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: amba-pl011: allow shared interruptDoug Berger1-1/+1
The PL011 register space includes all necessary status bits to determine whether a device instance requires handling in response to an interrupt. Therefore, multiple instances of the device could be serviced by a single shared interrupt, which is the case on BCM7211. Signed-off-by: Doug Berger <opendmb@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: serial: 8250: Fix type field in format stringHao Lee1-2/+2
The dev_dbg statement should print the value of uart.port.mapbase instead of its address. Besides that, uart.port.irq and uart.port.iotype are all unsigned types, so using %u is more appropriate. Signed-off-by: Hao Lee <haolee.swjtu@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21serial: 8250_of: Use of_device_get_match_data()Andy Shevchenko1-6/+3
Use of_device_get_match_data() to simplify the code a bit. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: John Garry <john.garry@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-19Merge tag 'riscv-for-linus-5.2-mw2' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux Pull RISC-V updates from Palmer Dabbelt: "This contains an assortment of RISC-V related patches that I'd like to target for the 5.2 merge window. Most of the patches are cleanups, but there are a handful of user-visible changes: - The nosmp and nr_cpus command-line arguments are now supported, which work like normal. - The SBI console no longer installs itself as a preferred console, we rely on standard mechanisms (/chosen, command-line, hueristics) instead. - sfence_remove_sfence_vma{,_asid} now pass their arguments along to the SBI call. - Modules now support BUG(). - A missing sfence.vma during boot has been added. This bug only manifests during boot. - The arch/riscv support for SiFive's L2 cache controller has been merged, which should un-block the EDAC framework work. I've only tested this on QEMU again, as I didn't have time to get things running on the Unleashed. The latest master from this morning merges in cleanly and passes the tests as well" * tag 'riscv-for-linus-5.2-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux: (31 commits) riscv: fix locking violation in page fault handler RISC-V: sifive_l2_cache: Add L2 cache controller driver for SiFive SoCs RISC-V: Add DT documentation for SiFive L2 Cache Controller RISC-V: Avoid using invalid intermediate translations riscv: Support BUG() in kernel module riscv: Add the support for c.ebreak check in is_valid_bugaddr() riscv: support trap-based WARN() riscv: fix sbi_remote_sfence_vma{,_asid}. riscv: move switch_mm to its own file riscv: move flush_icache_{all,mm} to cacheflush.c tty: Don't force RISCV SBI console as preferred console RISC-V: Access CSRs using CSR numbers RISC-V: Add interrupt related SCAUSE defines in asm/csr.h RISC-V: Use tabs to align macro values in asm/csr.h RISC-V: Fix minor checkpatch issues. RISC-V: Support nr_cpus command line option. RISC-V: Implement nosmp commandline option. RISC-V: Add RISC-V specific arch_match_cpu_phys_id riscv: vdso: drop unnecessary cc-ldoption riscv: call pm_power_off from machine_halt / machine_power_off ...
2019-05-16tty: Don't force RISCV SBI console as preferred consoleAnup Patel1-1/+0
The Linux kernel will auto-disables all boot consoles whenever it gets a preferred real console. Currently on RISC-V systems, if we have a real console which is not RISCV SBI console then boot consoles (such as earlycon=sbi) are not auto-disabled when a real console (ttyS0 or ttySIF0) is available. This results in duplicate prints at boot-time after kernel starts using real console (i.e. ttyS0 or ttySIF0) if "earlycon=" kernel parameter was passed by bootloader. The reason for above issue is that RISCV SBI console always adds itself as preferred console which is causing other real consoles to be not used as preferred console. Ideally "console=" kernel parameter passed by bootloaders should be the one selecting a preferred real console. This patch fixes above issue by not forcing RISCV SBI console as preferred console. Fixes: afa6b1ccfad5 ("tty: New RISC-V SBI console driver") Cc: stable@vger.kernel.org Signed-off-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-05-14panic: avoid the extra noise dmesgFeng Tang1-0/+6
When kernel panic happens, it will first print the panic call stack, then the ending msg like: [ 35.743249] ---[ end Kernel panic - not syncing: Fatal exception [ 35.749975] ------------[ cut here ]------------ The above message are very useful for debugging. But if system is configured to not reboot on panic, say the "panic_timeout" parameter equals 0, it will likely print out many noisy message like WARN() call stack for each and every CPU except the panic one, messages like below: WARNING: CPU: 1 PID: 280 at kernel/sched/core.c:1198 set_task_cpu+0x183/0x190 Call Trace: <IRQ> try_to_wake_up default_wake_function autoremove_wake_function __wake_up_common __wake_up_common_lock __wake_up wake_up_klogd_work_func irq_work_run_list irq_work_tick update_process_times tick_sched_timer __hrtimer_run_queues hrtimer_interrupt smp_apic_timer_interrupt apic_timer_interrupt For people working in console mode, the screen will first show the panic call stack, but immediately overridden by these noisy extra messages, which makes debugging much more difficult, as the original context gets lost on screen. Also these noisy messages will confuse some users, as I have seen many bug reporters posted the noisy message into bugzilla, instead of the real panic call stack and context. Adding a flag "suppress_printk" which gets set in panic() to avoid those noisy messages, without changing current kernel behavior that both panic blinking and sysrq magic key can work as is, suggested by Petr Mladek. To verify this, make sure kernel is not configured to reboot on panic and in console # echo c > /proc/sysrq-trigger to see if console only prints out the panic call stack. Link: http://lkml.kernel.org/r/1551430186-24169-1-git-send-email-feng.tang@intel.com Signed-off-by: Feng Tang <feng.tang@intel.com> Suggested-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kees Cook <keescook@chromium.org> Cc: Borislav Petkov <bp@suse.de> Cc: Andi Kleen <ak@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-09Merge tag 'dmaengine-5.2-rc1' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds1-2/+2
Pull dmaengine updates from Vinod Koul: - Updates to stm32 dma residue calculations - Interleave dma capability to axi-dmac and support for ZynqMP arch - Rework of channel assignment for rcar dma - Debugfs for pl330 driver - Support for Tegra186/Tegra194, refactoring for new chips and support for pause/resume - Updates to axi-dmac, bcm2835, fsl-edma, idma64, imx-sdma, rcar-dmac, stm32-dma etc - dev_get_drvdata() updates on few drivers * tag 'dmaengine-5.2-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (34 commits) dmaengine: tegra210-adma: restore channel status dmaengine: tegra210-dma: free dma controller in remove() dmaengine: tegra210-adma: add pause/resume support dmaengine: tegra210-adma: add support for Tegra186/Tegra194 Documentation: DT: Add compatibility binding for Tegra186 dmaengine: tegra210-adma: prepare for supporting newer Tegra chips dmaengine: at_xdmac: remove a stray bottom half unlock dmaengine: fsl-edma: Adjust indentation dmaengine: fsl-edma: Fix typo in Vybrid name dmaengine: stm32-dma: fix residue calculation in stm32-dma dmaengine: nbpfaxi: Use dev_get_drvdata() dmaengine: bcm-sba-raid: Use dev_get_drvdata() dmaengine: stm32-dma: Fix unsigned variable compared with zero dmaengine: stm32-dma: use platform_get_irq() dmaengine: rcar-dmac: Update copyright information dmaengine: imx-sdma: Only check ratio on parts that support 1:1 dmaengine: xgene-dma: fix spelling mistake "descripto" -> "descriptor" dmaengine: idma64: Move driver name to the header dmaengine: bcm2835: Drop duplicate capability setting. dmaengine: pl330: _stop: clear interrupt status ...
2019-05-08Merge tag 'tty-5.2-rc1' of ↵Linus Torvalds41-119/+2604
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial updates from Greg KH: "Here is the "big" set of tty/serial driver patches for 5.2-rc1. It's really pretty small, not much happening in this portion of the kernel at the moment. When the "highlight" is the movement of the documentation from .txt to .rst files, it's a good merge window. There's a number of small fixes and updates over the various serial drivers, and a new "tty null" driver for those embedded systems that like to make things even smaller and not break things. All of these have been in linux-next for a while with no reported issues" * tag 'tty-5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (45 commits) tty: serial: add driver for the SiFive UART dt-bindings: serial: add documentation for the SiFive UART driver serial: uartps: Add support for cts-override dt-bindings: xilinx-uartps: Add support for cts-override serial: milbeaut_usio: Fix error handling in probe and remove tty: rocket: deprecate the rp_ioctl tty: rocket: Remove RCPK_GET_STRUCT ioctl tty: update obsolete termios comment tty: serial_core: fix error code returned by uart_register_driver() serial: 8250-mtk: modify baudrate setting serial: 8250-mtk: add follow control docs: serial: convert docs to ReST and rename to *.rst serial: 8250_exar: Adjust IOT2000 matching TTY: serial_core, add ->install serial: Fix using plain integer instead of Null pointer tty:serial_core: Spelling mistake tty: Add NULL TTY driver tty: vt: keyboard: Allow Unicode compose base char Revert "tty: fix NULL pointer issue when tty_port ops is not set" serial: Add Milbeaut serial control ...
2019-05-07Merge tag 'staging-5.2-rc1' of ↵Linus Torvalds2-19/+34
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging / IIO driver updates from Greg KH: "Here is the big staging and iio driver update for 5.2-rc1. Lots of tiny fixes all over the staging and IIO driver trees here, along with some new IIO drivers. The "counter" subsystem was added in here as well, as it is needed by the IIO drivers and subsystem. Also we ended up deleting two drivers, making this pull request remove a few hundred thousand lines of code, always a nice thing to see. Both of the drivers removed have been replaced with "real" drivers in their various subsystem directories, and they will be coming to you from those locations during this merge window. There are some core vt/selection changes in here, that was due to some cleanups needed for the speakup fixes. Those have all been acked by the various subsystem maintainers (i.e. me), so those are ok. We also added a few new drivers, for some odd hardware, giving new developers plenty to work on with basic coding style cleanups to come in the near future. Other than that, nothing unusual here. All of these have been in linux-next for a while with no reported issues, other than an odd gcc warning for one of the new drivers that should be fixed up soon" [ I fixed up the warning myself - Linus ] * tag 'staging-5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (663 commits) staging: kpc2000: kpc_spi: Fix build error for {read,write}q Staging: rtl8192e: Remove extra space before break statement Staging: rtl8192u: ieee80211: Fix if-else indentation warning Staging: rtl8192u: ieee80211: Fix indentation errors by removing extra spaces staging: most: cdev: fix chrdev_region leak in mod_exit staging: wlan-ng: Fix improper SPDX comment style staging: rtl8192u: ieee80211: Resolve ERROR reported by checkpatch staging: vc04_services: bcm2835-camera: Compress two lines into one line staging: rtl8723bs: core: Use !x in place of NULL comparison. staging: rtl8723bs: core: Prefer using the BIT Macro. staging: fieldbus: anybus-s: fix wait_for_completion_timeout return handling staging: kpc2000: fix up build problems with readq() staging: rtlwifi: move remaining phydm .h files staging: rtlwifi: strip down phydm .h files staging: rtlwifi: delete the staging driver staging: fieldbus: anybus-s: rename bus id field to avoid confusion staging: fieldbus: anybus-s: keep device bus id in bus endianness Staging: sm750fb: Change *array into *const array staging: rtl8192u: ieee80211: Fix spelling mistake staging: rtl8192u: ieee80211: Replace bit shifting with BIT macro ...
2019-05-06Merge tag 'arm64-mmiowb' of ↵Linus Torvalds2-2/+0
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull mmiowb removal from Will Deacon: "Remove Mysterious Macro Intended to Obscure Weird Behaviours (mmiowb()) Remove mmiowb() from the kernel memory barrier API and instead, for architectures that need it, hide the barrier inside spin_unlock() when MMIO has been performed inside the critical section. The only relatively recent changes have been addressing review comments on the documentation, which is in a much better shape thanks to the efforts of Ben and Ingo. I was initially planning to split this into two pull requests so that you could run the coccinelle script yourself, however it's been plain sailing in linux-next so I've just included the whole lot here to keep things simple" * tag 'arm64-mmiowb' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (23 commits) docs/memory-barriers.txt: Update I/O section to be clearer about CPU vs thread docs/memory-barriers.txt: Fix style, spacing and grammar in I/O section arch: Remove dummy mmiowb() definitions from arch code net/ethernet/silan/sc92031: Remove stale comment about mmiowb() i40iw: Redefine i40iw_mmiowb() to do nothing scsi/qla1280: Remove stale comment about mmiowb() drivers: Remove explicit invocations of mmiowb() drivers: Remove useless trailing comments from mmiowb() invocations Documentation: Kill all references to mmiowb() riscv/mmiowb: Hook up mmwiob() implementation to asm-generic code powerpc/mmiowb: Hook up mmwiob() implementation to asm-generic code ia64/mmiowb: Add unconditional mmiowb() to arch_spin_unlock() mips/mmiowb: Add unconditional mmiowb() to arch_spin_unlock() sh/mmiowb: Add unconditional mmiowb() to arch_spin_unlock() m68k/io: Remove useless definition of mmiowb() nds32/io: Remove useless definition of mmiowb() x86/io: Remove useless definition of mmiowb() arm64/io: Remove useless definition of mmiowb() ARM/io: Remove useless definition of mmiowb() mmiowb: Hook up mmiowb helpers to spinlocks and generic I/O accessors ...
2019-05-06tty: rocket: fix incorrect forward declaration of 'rp_init()'Linus Torvalds1-1/+1
Make the forward declaration actually match the real function definition, something that previous versions of gcc had just ignored. This is another patch to fix new warnings from gcc-9 before I start the merge window pulls. I don't want to miss legitimate new warnings just because my system update brought a new compiler with new warnings. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>