- 04 Oct, 2015 39 commits
-
-
Yoshihiro Shimoda authored
This patch fixes an issue that this driver causes a NULL pointer dereference in the following conditions: - CONFIG_HIGHMEM and CONFIG_SERIAL_SH_SCI_DMA are enabled - This driver runs on the sci_dma_rx_push() This issue was caused by virt_to_page(buf) in the sci_request_dma() because this driver didn't check if the "buf" was valid or not. So, this patch uses the "buf" from dma_alloc_coherent() as is, not page. This patch also fixes a WARNING issue in sci_rx_dma_release(): WARNING: CPU: 0 PID: 1328 at lib/dma-debug.c:1125 check_unmap+0x444/0x848() rcar-dmac e6700000.dma-controller: DMA-API: device driver frees DMA memory with different CPU address [device address=0x000000006dd89000] [size=64 bytes] [cpu alloc address=0x000000016189c000] [cpu free address=0x0000000080000000] WARNING: CPU: 1 PID: 1 at drivers/base/dma-mapping.c:334 dma_common_free_remap+0x48/0x6c() trying to free invalid coherent area: (null) Signed-off-by:Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> [geert] Rebased [geert] Reworded [geert] Dropped .rx_chunk, as it's always identical to .rx_buf[0] Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Geert Uytterhoeven authored
There's no need to keep all buffer and DMA pointers on the stack. Signed-off-by:
-
Geert Uytterhoeven authored
Switch from using tty_buffer_request_room() and looping over tty_insert_flip_char() to tty_insert_flip_string(). Keep track of buffer overruns in the icount structure, like serial_core.c does. Signed-off-by:
-
Geert Uytterhoeven authored
Currently sci_dma_rx_push() has to find the active scatterlist itself, but in some cases the caller already knows. Hence let the caller pass the scatterlist, and introduce a helper to find the active DMA request while we're at it. Signed-off-by:
-
Geert Uytterhoeven authored
During serial port shutdown, the DMA receive worker function may still be called after the receive DMA cleanup function has been called. Fix this race condition between work_fn_rx() and sci_rx_dma_release() by acquiring the port's spinlock in sci_rx_dma_release(). This requires releasing the spinlock in work_fn_rx() before calling (any function that may call) sci_rx_dma_release(). Terminate all active receive DMA descriptors to release them, and to make sure no more completions come in. Do the same in sci_tx_dma_release() for symmetry, although the serial upper layer will no longer submit more data at this point of time. Signed-off-by:
-
Kazuya Mizuguchi authored
There is a problem when the sci_dma_rx_complete() is processed before cancel process of work_fn_rx() completes by rx_timer_fn(). This patch locks work_fn_rx(). Signed-off-by:
Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by:
Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by:
-
Geert Uytterhoeven authored
Resubmission of DMA descriptors is explicitly forbidden by the DMA engine API. Hence pass DMA_CTRL_ACK to dmaengine_prep_slave_sg(), and prepare a new DMA descriptor instead of reusing the old one. Remove sci_port.desc_rx[], as there's no longer a need to access the active descriptor. Signed-off-by:
-
Geert Uytterhoeven authored
Simplify the error handling in sci_submit_rx() by - Moving it to the end of the function, - Just calling dmaengine_terminate_all() instead of calling async_tx_ack() for all already submitted descriptors. Signed-off-by: -
Geert Uytterhoeven authored
As dmaengine_prep_slave_sg() is called with the DMA_CTRL_ACK flag set for DMA transmit requests, there's no need to explicitly acknowledge DMA transmit requests in the DMA transmit completion callback. Hence remove the call to async_tx_ack(), and remove the now unused dma_async_tx_descriptor pointer in the sci_port structure. Signed-off-by:
-
Geert Uytterhoeven authored
Convert the SCI driver from the SHDMAE-specific partial DMA transfer handling to the generic dmaengine residual data framework. Signed-off-by:
-
Geert Uytterhoeven authored
Replace open-coded - calls to dma_async_tx_descriptor.tx_submit() by calls to the dmaengine_submit() helper, - dma_cookie_t comparisons by calls to dma_submit_error(). Signed-off-by: -
Geert Uytterhoeven authored
The mapped transmit buffer is never unmapped. This leaks quite some mappings, as the mapping is done in uart_ops.startup(), i.e. every time the device is opened. Unmap the buffer on device close. Signed-off-by:
-
Geert Uytterhoeven authored
Simplify the DMA transmit code by using dma_map_single() instead of constantly modifying the single-entry scatterlist to match what's currently being transmitted. Signed-off-by:
-
Geert Uytterhoeven authored
When comparing differently sized types, it's better to use min_t()/max_t() than adding casts. Also use "unsigned int" instead of "int", as that's the right type for the length of an SG entry. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Geert Uytterhoeven authored
To function correctly in the presence of an IOMMU, the DMA buffers must be managed using the DMA channel's device instead of the platform device's device. Make sure to free the DMA memory before releasing the channel, not after. Signed-off-by:
-
Geert Uytterhoeven authored
Let sci_request_dma() handle failures to initialize DMA itself. This way sci_tx_dma_release() and sci_rx_dma_release() don't have to consider partial initialization, and thus don't need to reset DMA addresses to DMA_ERROR_CODE, which is not 100% portable access architectures. Signed-off-by:
-
Geert Uytterhoeven authored
Reformat, grammar improvements, use "ms" instead of "msec". Signed-off-by:
-
Geert Uytterhoeven authored
Make the life of the driver developer/debugger easier: - Add __func__ prefix to identical messages, - Add DMA directions to messages, - Add TX failure messages, - Always use "cookie %d" for DMA cookies, - "#%d" is reserved for the DMA cookie/descriptor index. Signed-off-by:
-
Yoshihiro Shimoda authored
This patch fix an issue that the driver may cause "nobody cared" IRQ when this driver detects the overrun flag only. Signed-off-by:
-
Geert Uytterhoeven authored
Commit 8b6ff84c ("serial: sh-sci: Fix R-Car SCIF and HSCIF overrun handling") added overrun handling for (H)SCIF using the SCLSR register, but also accidentally added a bogus call to sci_handle_fifo_overrun() in the receive interrupt path. Remove it again. Signed-off-by:
-
Geert Uytterhoeven authored
Printing an error on memory allocation failures is unnecessary. Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
Reorder sampling_rate assignment for consistency in all cases of the switch statement. Avoid using the ternary conditional operator to make it more clear that the value is overridden by platform data. Signed-off-by:
-
Geert Uytterhoeven authored
serial_core.c was moved from drivers/serial/ to drivers/tty/serial/ a while ago. Remove the path to make it move-proof. Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Geert Uytterhoeven authored
SCIF_ERROR_CLEAR includes SCIFA_ORER, which exists only on SCIFA/SCIFB and SCIF on sh7705/sh7720/sh7721. To fix this: 1. Remove SCIFA_ORER from the definition of SCIF_ERROR_CLEAR, 2. During initialization, store the error clear mask to use, incorporating the overrun bit only if it applies to the SCxSR register. Signed-off-by: -
Geert Uytterhoeven authored
Expressions involving "BIT(...)" create values of type "long", which is 64-bit on 64-bit. Hence "~BIT(...)" no longer fits in 32-bit, which will cause future compiler warnings when assigning to 32-bit variables: drivers/tty/serial/sh-sci.c: In function 'sci_init_single': drivers/tty/serial/sh-sci.h:58:25: warning: large integer implicitly truncated to unsigned type [-Woverflow] #define SCI_ERROR_CLEAR ~(SCI_RESERVED | SCI_PER | SCI_FER | SCI_ORER) ^ drivers/tty/serial/sh-sci.c:2325:27: note: in expansion of macro 'SCI_ERROR_CLEAR' sci_port->error_clear = SCI_ERROR_CLEAR; As these values are (at most) 32-bit register values anyway, cast them to "u32" at the definition level to prevent such compiler warnings. Reported-by:kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Geert Uytterhoeven authored
The #ifdef logic to clear SCxSR bits using RMW on SCIFA/SCIFB and SCIF variants with some SCIFA features (sh7705/SH7720/sh7721) has several drawbacks: - It wasn't updated for newer R-Mobile variants (APE6), - It doesn't correctly handle SoCs with both SCIF and SCIFA/B (e.g. R-Car Gen2, but also legacy sh7723/sh7724), - It doesn't play well with ARM multi-platform kernels: on R-Car Gen2, SCIF/SCIFA/SCIFB/HSCIF were handled differently, depending on whether r8a7740 or sh73a0 support was enabled or not, Replace the #ifdef logic by runtime logic to fix this. SCIFA/SCIFB and SCIF on sh7705/sh7720/sh7721 use RMW to clear error bits, other variants use plain stores, as before. Note that this changes behavior for SCIFA on sh7723/sh7724 (these SoCs have both SCIF and SCIFA), which didn't use RMW before. Signed-off-by: -
Taichi Kageyama authored
The following race conditions can happen when a serial port is used as console. Case1: CPU_B is used to detect an interrupt from a serial port, but it can have interrupts disabled during the waiting time. Case2: CPU_B clears UART_IER just after CPU_A sets UART_IER and then a serial port may not make an interrupt. Case3: CPU_A sets UART_IER just after CPU_B clears UART_IER. This is an unexpected behavior for serial8250_console_write(). CPU_A [autoconfig_irq] | CPU_B [serial8250_console_write] ----------------------------|--------------------------------------- | probe_irq_on() | spin_lock_irqsave(&port->lock,) serial_outp(,UART_IER,0x0f) | serial_out(,UART_IER,0) udelay(20); | uart_console_write() probe_irq_off() | | spin_unlock_irqrestore(&port->lock,) Case1 and 2 can make autoconfig_irq() failed. In these cases, the console doesn't work in interrupt mode and "input overrun" (which can make operation mistakes) can happen on some systems. Especially in the Case1, It is known that the problem happens with high rate every boot once it occurs because the boot sequence is always almost same. port mutex makes sure that the autoconfig operation is exclusive of any other concurrent HW access except by the console operation. console lock is required in autoconfig_irq(). Signed-off-by:Taichi Kageyama <t-kageyama@cp.jp.nec.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Reviewed-by:
Peter Hurley <peter@hurleysoftware.com> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Uwe Kleine-König authored
This fixes receiving broken characters on the console from an MPC5125 system when systemd comes up which repeatedly opens and shuts down the console device. Trial and error with the needed interval showed that 500 us are good enough most of the time when using 38400 Bd, so I think 1 ms is a good compromise between fixing the issue and not penalize faster setups too much. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: 8250/Kconfig:config SERIAL_8250_LPC18XX 8250/Kconfig: bool "NXP LPC18xx/43xx serial port support" ...meaning that it currently is not being built as a module by anyone. When targetting orphaned modular code in non-modular drivers, this came up. Joachim indicated that the driver was actually meant to be tristate but ended up bool by accident. So here we make it tristate instead of removing the modular code that was essentially orphaned. Suggested-by:
Joachim Eastwood <manabian@gmail.com> Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by:
-
Paul Gortmaker authored
The Kconfig for this driver is currently: config SERIAL_MPSC bool "Marvell MPSC serial port support" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We leave some tags like MODULE_AUTHOR for documentation purposes. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-serial@vger.kernel.org Signed-off-by: -
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: drivers/tty/hvc/Kconfig:config HVC_DRIVER drivers/tty/hvc/Kconfig: bool ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only, even though someone bothered to comment that the code was not used. Unlike other changes, this driver binds in w/o using module_init, so we dont have init ordering concerns with this commit. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
-
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: config.debug:config MAGIC_SYSRQ bool "Magic SysRq key" ...meaning that it currently is not being built as a module by anyone. Lets remove the traces of modularity we can so that when reading the driver there is less doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We don't delete the module.h include since other parts of the file are using content from there. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by: -
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: drivers/tty/Kconfig:config LEGACY_PTYS drivers/tty/Kconfig: bool "Legacy (BSD) PTY support" ...and: drivers/tty/Kconfig:config UNIX98_PTYS drivers/tty/Kconfig: bool "Unix98 PTY support" if EXPERT combined with this: obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o ...meaning that it currently is not being built as a module by anyone. Lets remove the traces of modularity we can so that when reading the driver there is less doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We don't delete the module.h include since other parts of the file are using content from there. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by:
-
Maciej S. Szmigiero authored
CIR type serial ports aren't real serial ports. This is just a way to prevent legacy 8250 serial driver from probing and eventually binding some resources. Since in current state such ports aren't providing any real functionality and it is not possible to change their type via setserial/ioctl(TIOCSSERIAL) (due to UPF_FIXED_PORT flag set on them) it is simpler and cleaner to not register them at all with serial core. Print a short message in this case so it is known to user what has happened. This way checks for PORT_8250_CIR in serial port callbacks can be removed too, since they won't ever be called. Signed-off-by:
Maciej Szmigiero <mail@maciej.szmigiero.name> Signed-off-by:
-
Sebastian Andrzej Siewior authored
The function tty_insert_flip_string() returns an int and as such it might fail. So the result is that I kindly asked to insert 48 bytes and the function only insterted 32. I have no idea what to do with the remaining 16 so I think dropping them is the only option. I also increase the buf_overrun counter so userpace has a clue that we lost bytes. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
- 27 Sep, 2015 1 commit
-
-
Linus Torvalds authored
-
