Kevin Cernekee [Tue, 21 Oct 2014 22:22:58 +0000 (15:22 -0700)]
tty: serial: bcm63xx: Add support for unnamed clock outputs from DT
The original non-DT bcm63xx clk code ignores the struct device argument
and looks up a global clock name. DT platforms, by contrast, often just
use a phandle to reference a clock node with no "clock-output-names"
property. Modify the UART driver to support both schemes.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kevin Cernekee [Tue, 21 Oct 2014 22:22:57 +0000 (15:22 -0700)]
tty: serial: bcm63xx: Allow bcm63xx_uart to be built on other platforms
This device was originally supported on bcm63xx only, but it shows up on
a wide variety of MIPS and ARM chipsets spanning multiple product lines.
Now that the driver has eliminated dependencies on bcm63xx-specific
header files, we can build it on any non-bcm63xx kernel.
Compile-tested on x86, both statically and as a module. Tested for
functionality on bcm3384 (a new MIPS platform under active development).
Daniel Thompson [Tue, 28 Oct 2014 08:28:07 +0000 (09:28 +0100)]
serial: imx: clean up imx_poll_put_char()
imx_put_poll_char() has been simplified to remove the code to disable
interrupts. The present code can corrupt register state when re-entered
from FIQ handler.
Switch to _relaxed() MMIO functions (which are safe for polled I/O and
needed to avoid taking spin locks).
Stephen Boyd [Thu, 23 Oct 2014 00:33:01 +0000 (17:33 -0700)]
tty: serial: msm_serial: Use DT aliases
We rely on probe order of this driver to determine the line number for
the uart port. This makes it impossible to know the line number
when these devices are populated via DT. Use the DT alias
mechanism to assign the line based on the aliases node.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Boyd [Thu, 30 Oct 2014 01:47:01 +0000 (18:47 -0700)]
tty: serial: msm: Reset uartdm after baud rate change
We need to issue a reset if we ever change the value of the IPR
register on DM hardware. If we don't reset the hardware the RX
stale interrupt never triggers and the only way to trigger an RX
handling event is by filling up the fifo. This causes things like
getty to not work so well considering it might change the baud
rate a few times. Fix this by moving the reset on startup and any
reprogramming required after the reset to be after we change the
baud rate.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Boyd [Wed, 29 Oct 2014 18:14:38 +0000 (11:14 -0700)]
tty: serial: msm: Support sysrq on uartDM devices
To properly support sysrq on uartDM hardware we need to properly
handle break characters. With the DM hardware the fifo can pack 4
characters at a time, where a break is indicated by an all zero
byte. Unfortunately, we can't differentiate between an all zero
byte for a break and an all zero byte of data, so try and do as
best we can. First unmask the RX break start interrupt and record
the interrupt when it arrives. Then while processing the fifo,
detect the break by searching for an all zero character as long
as we recently received an RX break start interrupt. This should
make sysrq work fairly well.
Cc: Frank Rowand <frank.rowand@sonymobile.com> Cc: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Boyd [Wed, 29 Oct 2014 18:14:37 +0000 (11:14 -0700)]
tty: serial: msm: Fix sysrq spinlock recursion on non-DM
The handle_rx() path calls uart_handle_sysrq_char() with the port
lock held. This causes a spinlock recursion. Release and
reacquire the lock here to avoid this.
Janusz Uzycki [Fri, 10 Oct 2014 16:53:24 +0000 (18:53 +0200)]
serial: mxs-auart: clean get_mctrl and set_mctrl
Russell King:
The only thing which the .get_mctrl method is supposed to do is
to return the state of the /input/ lines, which are CTS, DCD, DSR, RI.
The output line state is stored in port->mctrl, and is added to
the returned value by serial_core when it's required.
RTS output state should not be returned from the .get_mctrl method.
This patch removes ctrl variable from mxs_auart_port
and removes useless reading back RTS line.
The ctrl variable in mxs_auart_port duplicated mctrl,
member of uart_port structure in serial_core.h.
The removed code from mxs_auart_set_mctrl() and mxs_auart_get_mctrl
duplicated uart_update_mctrl() and uart_tiocmget()
in serial_core.c.
Signed-off-by: Janusz Uzycki <j.uzycki@elproma.com.pl> Reviewed-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cyrille Pitchen [Mon, 20 Oct 2014 17:12:20 +0000 (19:12 +0200)]
tty/serial: at91: fix rx ring buffer management
This patch swaps the use "tail" and "head" to fit the semantic of the linux
circular buffer documentation:
- head: the point at which the producer (the DMA controller) inserts items.
- tail: the point at which the consumer (the serial framework) finds the next
item.
Besides the former code of the rx ring buffer didn't manage the case where
head < tail, which might lead to loss of data. To fix this bug the data are now
sent from the DMA buffer to the serial framework in two steps:
1 - First, we test if head < tail. If so, we copy the data from tail to the end
of the DMA buffer then reset tail to zero.
2 - Finally, we copy data from tail to head then set tail to head.
In addition, since tty_insert_flip_string() may now be called twice,
atmel_flip_buffer_rx_dma() becomes less efficient than moving the calls
dma_sync_sg_for_cpu(), dma_sync_sg_for_device(), tty_insert_flip_string() and
tty_flip_buffer_push() directly into atmel_rx_from_dma().
John Crispin [Thu, 16 Oct 2014 19:48:21 +0000 (21:48 +0200)]
serial: of: add a PORT_RT2880 definition
The Ralink RT2880 SoC and its successors have an internal 8250 core. This core
needs the same quirks applied as the AMD AU1xxx uart. In addition to these
quirks, the ports memory region is only 0x100 unlike the AU1xxx which has a
size of 0x1000.
Signed-off-by: John Crispin <blogic@openwrt.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nishanth Menon [Wed, 22 Oct 2014 12:46:50 +0000 (07:46 -0500)]
tty: serial: omap: Increase max consoles and add check to prevent crash
Increase the maximum number of consoles possible to 10 since DRA7 now
has the maximum number of consoles possible. without doing this, for
example, enabling DRA7 UART10 results in internal data structures and
console cannot match up and we endup with a crash as follows:
The final solution is to transition off to use 8250 driver and no
dependency on console structures and move away from omap-serial
driver, hence no major cleanups are done for this driver, so add a
simple check to prevent future crashes in a similar manner in case of
platform with additional ports.
Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Thu, 6 Nov 2014 14:06:12 +0000 (09:06 -0500)]
serial: pl011: Fix build breakage with !CONFIG_DMA_ENGINE
Commit 479e9b94fdce7bc4 ("serial: Refactor uart_flush_buffer() from
uart_close") refactored the uart_flush_buffer() in uart_close() into
those drivers that define a flush_buffer() method. However, in the
amba-pl011 driver configured without CONFIG_DMA_ENGINE, flush_buffer()
is a NULL method, so the direct call fails to compile.
Check and call the flush_buffer() method through the ops table instead.
Reported-by: Fengguang Wu <fengguang.wu@intel.com> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:26:31 +0000 (12:26 -0500)]
vt: Remove vt_get_kmsg_redirect() from uapi header
vt_get_kmsg_redirect() only has meaning to the console driver as
an alias for calling vt_kmsg_redirect(). Move the macro definition
to the only source file which uses it; remove from uapi/linux/vt.h
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:26:30 +0000 (12:26 -0500)]
tty: Document defunct ASYNC_SPLIT_TERMIOS flag in uapi header
The last vestige of ASYNC_SPLIT_TERMIOS was removed by commit
'cris: Remove obsolete ASYNC_SPLIT_TERMIOS behavior'. Mark the flag
as defunct in the uapi header.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial_console_init() is not defined by the tty core; remove
declaration.
Note that the powerpc arch boot code contains a serial_console_init()
declaration in arch/powerpc/boot/ops.h which is restricted to
the powerpc arch boot.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
,which misses printing the associated device address.
In order to fix this, register all the irqs inside the probe function via
devm_request_irq(), which will correctly report the serial interrupts associated
with their correspondent serial device and also helps simplyfing the code by
avoiding the calls to free_irq().
Commit e676253b19b2 ("serial/8250: Add support for RS485 IOCTLs") added
references to TIOC[SG]RS48 on 8250_core.c. This change triggered the
need to define them in all the arches that uses tty/serial.
Commit e676253b19b2 ("serial/8250: Add support for RS485 IOCTLs") added
references to TIOC[SG]RS48 on 8250_core.c. This change triggered the
need to define them in all the arches that uses tty/serial.
Ray Jui [Wed, 8 Oct 2014 00:35:47 +0000 (17:35 -0700)]
serial: 8250_dw: Add DMA support for non-ACPI platforms
The dma pointer under struct uart_8250_port is currently left
unassigned for non-ACPI platforms. It should be pointing to the dma
member in struct dw8250_data like how it was done for ACPI, so the core
8250 code will try to request for DMA when registering the port
If DMA is not enabled in device tree, request DMA will fail and the
driver will fall back to PIO
Signed-off-by: Ray Jui <rjui@broadcom.com> Reviewed-by: JD (Jiandong) Zheng <jdzheng@broadcom.com> Reviewed-by: Scott Branden <sbranden@broadcom.com> Tested-by: Scott Branden <sbranden@broadcom.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
max310x: max3109_detect should use indirect addressing in SPI mode for REVID register
This patch allows to read the REV_ID register in SPI mode and consequently
to properly detect the max3109. Indeed in SPI mode, this register is only
accessible by using indirect addressing.
Paul Bolle [Mon, 6 Oct 2014 10:07:23 +0000 (12:07 +0200)]
serial: samsung: Remove checks for CONFIG_SAMSUNG_CLOCK
Commit 32726d2d5502 ("ARM: SAMSUNG: Remove legacy clock code") removed
the Kconfig symbol SAMSUNG_CLOCK. Remove the last checks for its macro,
and the dead code they hide, too.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: use container_of to resolve uart_sunzilog_port from uart_port
Use container_of instead of casting first structure member.
Signed-off-by: Fabian Frederick <fabf@skynet.be> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: sunsab: use container_of to resolve uart_sunsu_port from uart_port
Use container_of instead of casting first structure member.
Signed-off-by: Fabian Frederick <fabf@skynet.be> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: sunsu: use container_of to resolve uart_sunsu_port from uart_port
Use container_of instead of casting first structure member.
Signed-off-by: Fabian Frederick <fabf@skynet.be> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds the required pieces to 8250-OMAP UART driver for DMA
support. The TX burst size is set to 1 so we can send an arbitrary
amount of bytes.
The RX burst is currently set to 48 which means we receive an DMA
interrupt every 48 bytes and have to reprogram everything. Less bytes in
the RX-FIFO mean that no DMA transfer will happen and the UART will send a
RX-timeout _or_ RDI event at which point the FIFO will be manually purged.
There is a workaround for TX-DMA on AM33xx where we put the first byte
into the FIFO to kick start the DMA process. Haven't seen this problem on
OMAP36xx (beagle board xm) or DRA7xx.
On AM375x there is "Usage Note 2.7: UART: Cannot Acknowledge Idle
Requests in Smartidle Mode When Configured for DMA Operations" in the
errata document. This problem persists even after disabling DMA in the
UART and will be addressed in the HWMOD.
v10:
- delay update_registers() from set_termios() until TX-DMA is
done. It has been reported / proved that invoking
update_registers() while TX-DMA is in progress may stall the
DMA operation and it won't finish.
- use the new omap DMA-TX-RX hooks and DMA only interrupt
routine.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We have (or will have) custom DMA callbacks in the omap driver due to
the different behaviour in the RX and TX case. To make this work
we need a few changes in the IRQ handler to invoke the rx_handler again
after the "manual" mode or retry the tx_handler again before falling
back to the manual mode.
Heikki didn't want to see the extra hacks in the generic / default irq
handler and Peter wasn't too happy about an OMAP-only IRQ handler. The
way I planned it is to use this extra IRQ routine only in DMA case. If
Peter dislike this approach then I hope Heikki doesn't block changes in
the default IRQ handler :)
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The omap needs a DMA request pending right away. If it is
enqueued once the bytes are in the FIFO then nothing will happen
and the FIFO will be later purged via RX-timeout interrupt.
This patch enqueues RX-DMA request on completion but not if it
was aborted on error. The first enqueue will happen in the driver
in startup.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch provides mostly a copy of serial8250_tx_dma() +
__dma_tx_complete() with the following extensions:
- DMA bug
At least on AM335x the following problem exists: Even if the TX FIFO is
empty and a TX transfer is programmed (and started) the UART does not
trigger the DMA transfer.
After $TRESHOLD number of bytes have been written to the FIFO manually the
UART reevaluates the whole situation and decides that now there is enough
room in the FIFO and so the transfer begins.
This problem has not been seen on DRA7 or beagle board xm (OMAP3). I am not
sure if this is UART-IP core specific or DMA engine.
The workaround is to use a threshold of one byte, program the DMA
transfer minus one byte and then to put the first byte into the FIFO to
kick start the transfer.
- support for runtime PM
RPM is enabled on start_tx(). We can't disable RPM on DMA complete callback
because there is still data in the FIFO which is being sent. We have to wait
until the FIFO is empty before we disable it.
For this to happen we fake a TX sent error and enable THRI. Once the
FIFO is empty we receive an interrupt and since the TTY-buffer is still
empty we "put RPM" via __stop_tx(). Should it been filed then in the
start_tx() path we should program the DMA transfer and remove the error
flag and the THRI bit.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty: serial: 8250: allow to use custom DMA implementation
The OMAP has a few corner cases where it needs a share of kindness of
affection to do the right thing. Heikki Krogerus suggested that instead
adding the quirks into the default DMA implementation, OMAP could get
its own copy of the function. And Alan suggested the same thing so here
we go.
This patch provides callbacks for custom TX/RX DMA implementation. If
there are not setup / used, then the default (current) implementation is
used.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty: serial: 8250_dma: keep own book keeping about RX transfers
After dmaengine_terminate_all() has been invoked then both DMA drivers
(edma and omap-dma) do not invoke dma_cookie_complete() to mark the
transfer as complete. This dma_cookie_complete() is performed by the
Synopsys DesignWare driver which is probably the only one that is used
by omap8250-dma and hence don't see following problem…
…which is that once a RX transfer has been terminated then following
query of channel status reports DMA_IN_PROGRESS (again: the actual
transfer has been canceled, there is nothing going on anymore).
This means that serial8250_rx_dma() never enqueues another DMA transfer
because it (wrongly) assumes that there is a transer already pending.
Vinod Koul refuses to accept a patch which adds this
dma_cookie_complete() to both drivers and so dmaengine_tx_status() would
report DMA_COMPLETE instead (and behave like the Synopsys DesignWare
driver already does). He argues that I am not allowed to use the cookie
to query the status and that the driver already cleaned everything up after
the invokation of dmaengine_terminate_all().
To end this I add a bookkeeping whether or not a RX-transfer has been
started to the 8250-dma code. It has already been done for the TX side.
*Now* we learn about the RX status based on our bookkeeping and don't
need dmaengine_tx_status() for this anymore.
Cc: vinod.koul@intel.com Reviewed-by: Tony Lindgren <tony@atomide.com> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Right now it is possible that serial8250_tx_dma() fails and returns
-EBUSY. The caller (serial8250_start_tx()) will then enable
UART_IER_THRI which will generate an interrupt once the TX FIFO is
empty.
In serial8250_handle_irq() nothing will happen because up->dma is set
and so serial8250_tx_chars() won't be invoked. We end up with plenty of
interrupts and some "too much work for irq" output.
This patch introduces dma_tx_err in struct uart_8250_port to signal that
the last invocation of serial8250_tx_dma() failed so we can fill the TX
FIFO manually. Should the next invocation of serial8250_start_tx()
succeed then the dma_tx_err flag along with the THRI bit is removed and
DMA only usage may continue.
Reviewed-by: Tony Lindgren <tony@atomide.com> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch provides a 8250-core based UART driver for the internal OMAP
UART. The long term goal is to provide the same functionality as the
current OMAP uart driver and DMA support.
I tried to merge omap-serial code together with the 8250-core code.
There should should be hardly a noticable difference. The trigger levels
are different compared to omap-serial:
- omap serial
TX: Interrupt comes after TX FIFO has room for 16 bytes.
TX of 4096 bytes in one go results in 256 interrupts
RX: Interrupt comes after there is on byte in the FIFO.
RX of 4096 bytes results in 4096 interrupts.
- this driver
TX: Interrupt comes once the TX FIFO is empty.
TX of 4096 bytes results in 65 interrupts. That means there will
be gaps on the line while the driver reloads the FIFO.
RX: Interrupt comes once there are 48 bytes in the FIFO or less over
"longer" time frame. We have
1 / 11520 * 10^3 * 16 => 1.38… ms
1.38ms to react and purge the FIFO on 115200,8N1. Since the other
driver fired after each byte it had ~5.47ms time to react. This
_may_ cause problems if one relies on no missing bytes and has no
flow control. On the other hand we get only 85 interrupts for the
same amount of data.
It has been only tested as console UART on am335x-evm, dra7-evm and
beagle bone. I also did some longer raw-transfers to meassure the load.
The device name is ttyS based instead of ttyO. If a ttyO based node name
is required please ask udev for it. If both driver are activated (this
and omap-serial) then this serial driver will take control over the
device due to the link order
v9…v10:
- Tony noticed that omap3 won't show anything after waking up
from core off. In v9 I reworked the register restore and set
IER to 0 by accident. This went unnoticed because start_tx
usually sets ier (either due to DMA bug or due to TX-complete
IRQ).
- dropped EFR and SLEEP from capabilities. We do have both but
nobody should touch it. We already handle SLEEP ourself.
- make the private copy of the registers (like EFR) u8 instead
u32
- drop MDR1 & DL[ML] reset in restore registers. Does not look
required it is set to the required value later.
- update MDR1 & SCR only if changed.
- set MDR1 as the last thing. The errata says that we should
setup everything before MDR1 set.
- avoid div by 0 in omap_8250_get_divisor() if baud rate gets
very large (Frans Klaver fixed the same thing omap-serial)
- drop "is in early stage" from Kconfig.
v8…v9:
- less on a file seems to hang the am335x after a while. I
believe I introduce this bug a while ago since I can reproduce
this prior to v8. Fixed by redoing the omap8250_restore_regs()
v7…v8:
- redo the register write. There is now one function for that
which is used from set_termios() and runtime-resume.
- drop PORT_OMAP_16750 and move the setup to the omap file. We
have our own set termios function anyway (Heikki Krogerus)
- use MEM instead of MEM32. TRM of AM/DM37x says that 32bit
access on THR might result in data abort. We only need 32bit
access in the errata function which is before we use 8250's
read function so it doesn't matter.
v4…v7:
- change trigger levels after some tests with raw transfers.
v3…v4:
- drop RS485 support
- wire up ->throttle / ->unthrottle
v2…v3:
- wire up startup & shutdown for wakeup-irq handling.
- RS485 handling (well the core does).
v1…v2:
- added runtime PM. Could somebody could please double check
this?
- added omap_8250_set_termios()
Reviewed-by: Tony Lindgren <tony@atomide.com> Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Frans Klaver <frans.klaver@xsens.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty: serial: 8250: make serial8250_console_setup() non _init
if I boot with console=ttyS0 and the omap driver is module I end up with
| console [ttyS0] disabled
| omap8250 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 88, base_baud = 3000000) is a 8250
| Unable to handle kernel paging request at virtual address c07a9de0
| Modules linked in: 8250_omap(+)
| CPU: 0 PID: 908 Comm: modprobe Not tainted 3.17.0-rc5+ #1593
| PC is at serial8250_console_setup+0x0/0xc8
| LR is at register_console+0x13c/0x3a4
| [<c0078788>] (register_console) from [<c02d0340>] (uart_add_one_port+0x3cc/0x420)
| [<c02d0340>] (uart_add_one_port) from [<c02d38a4>] (serial8250_register_8250_port+0x298/0x39c)
| [<c02d38a4>] (serial8250_register_8250_port) from [<bf006274>] (omap8250_probe+0x218/0x3dc [8250_omap])
| [<bf006274>] (omap8250_probe [8250_omap]) from [<c02e3424>] (platform_drv_probe+0x2c/0x5c)
| [<c02e3424>] (platform_drv_probe) from [<c02e1eac>] (driver_probe_device+0x104/0x228)
…
| [<c009fa48>] (SyS_init_module) from [<c000e6e0>] (ret_fast_syscall+0x0/0x30)
| Code: 7823603bf8314620051b3013491ed416 (44792204)
because serial8250_console_setup() is already gone.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty: serial: 8250: Fix wording in runtime-PM comments
Frans reworded the two comments with better English for better
understanding. His review hit the mailing list after the patch got
applied so here is an incremental update.
Reported-by: Frans Klaver <frans.klaver@xsens.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Janusz Uzycki [Fri, 10 Oct 2014 11:13:28 +0000 (13:13 +0200)]
serial: mxs-auart: add sysrq support
When using mxs-auart based console, sometime we need the sysrq function
to help debugging kernel. The sysrq code is basically there,
this patch just simply enable it.
Markus Pargmann [Wed, 5 Nov 2014 12:20:50 +0000 (13:20 +0100)]
tty: serial: omap: Remove probe error message
This error message is not necessary. The driver core code will print all
probe error messages. It also resolves some error codes to proper error
messages. For example -EPROBE_DEFER will only be printed as an info message.
This patch removes the error message as the core prints the same
information.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Thu, 16 Oct 2014 20:54:27 +0000 (16:54 -0400)]
serial: core: Fix port count when uart_open() errors
A port count mismatch occurs if mutex_lock_interruptible()
exits uart_open() and the port has already been opened. This may
prematurely close a port on an open tty. Since uart_close() is _always_
called if uart_open() fails, the port count must be corrected if errors
occur.
Always increment the port count in uart_open(), regardless of errors;
always decrement the port count in uart_close(). Note that
tty_port_close_start() decrements the port count when uart_open()
was successful.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Thu, 16 Oct 2014 20:54:26 +0000 (16:54 -0400)]
serial: core: Remove extra locking in uart_write()
uart_start() only claims the port->lock to call __uart_start(),
which does the actual processing. Eliminate the extra acquire/release
in uart_write(); call __uart_start() directly with port->lock already
held.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Thu, 16 Oct 2014 20:54:25 +0000 (16:54 -0400)]
serial: core: Colocate crucial structure linkage
The key function of uart_add_one_port() is to cross-reference the
UART driver's port structure with the serial core's state table;
keep the assignments together and document this crucial association.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Thu, 16 Oct 2014 20:54:22 +0000 (16:54 -0400)]
tty: Document defunct ASYNC_* bits in uapi header
Note the serial_struct flags for which the kernel ignores and performs
no action. The flags cannot be removed since they form part of the
userspace interface via the TIOCSSERIAL/TIOCGSERIAL ioctls.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Thu, 16 Oct 2014 20:54:21 +0000 (16:54 -0400)]
tty,serial: Unify UPF_* and ASYNC_* flag definitions
The userspace-defined ASYNC_* flags in include/uapi/linux/tty_flags.h
are the authoritative bit definitions for the serial_struct flags,
and thus for any derivative values or fields.
Although the serial core provides the TIOCSSERIAL and TIOCGSERIAL
ioctls to set and retrieve these flags from userspace, it defines these
bits independently, as UPF_* macros.
Define the UPF_* macros which are userspace-modifiable directly from
the ASYNC_* symbolic constants. Add compile-time test to ensure the
bits changeable by TIOCSSERIAL match the defined range in the uapi
header.
Add ASYNCB_MAGIC_MULTIPLIER to the uapi header since this bit is
programmable by userspace.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Thu, 16 Oct 2014 20:54:20 +0000 (16:54 -0400)]
serial: Fix locking for uart driver set_termios() method
The low-level uart driver may modify termios settings to override
settings that are not compatible with the uart, such as CRTSCTS.
Thus, callers of the low-level uart driver's set_termios() method must
hold termios_rwsem write lock to prevent concurrent access to termios,
in case such override occurs.
The termios_rwsem lock requirement does not extend to console setup
(ie., uart_set_options), as console setup cannot race with tty
operations. Nor does this lock requirement extend to functions which
cannot be concurrent with tty ioctls (ie., uart_port_startup() and
uart_resume_port()).
Further, always claim the port mutex to protect hardware
re-reprogramming in the set_termios() uart driver method. Note this
is unnecessary for console initialization in uart_set_options()
which cannot be concurrent with other uart operations.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Thu, 16 Oct 2014 20:54:19 +0000 (16:54 -0400)]
serial: core: Flush ldisc after dropping port mutex in uart_close()
The tty buffers (and any line discipline buffers) must be flushed after
the UART hardware has shutdown; otherwise, a racing open on the same
tty may receive data from the previous session, which is a security
hazard. However, holding the port mutex while flushing the line
discipline buffers creates a lock inversion if the set_termios()
handler takes the port mutex (as it does in the followup patch,
'serial: Fix locking for uart driver set_termios method'.
Flush the ldisc buffers after dropping the port mutex; the tty lock
is still held which prevents a concurrent open() from advancing while
flushing. Since no new rx data is possible after uart_shutdown() until
a new open reinitializes the port, the later flush has no impact on
what data is being discarded.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Thu, 16 Oct 2014 20:54:18 +0000 (16:54 -0400)]
serial: Refactor uart_flush_buffer() from uart_close()
In the context of the final tty & port close, flushing the tx
ring buffer after the hardware has already been shutdown and
the ring buffer freed is neither required nor desirable.
uart_flush_buffer() performs 3 operations:
1. Resets tx ring buffer indices, but the tx ring buffer has
already been freed and the indices are reset if the port is
re-opened.
2. Calls uart driver's flush_buffer() method
5 in-tree uart drivers define flush_buffer() methods:
amba-pl011, atmel-serial, imx, serial-tegra, timbuart
These have been refactored into the shutdown() method, if
required.
3. Kicks the ldisc for more writing, but this is undesirable.
The file handle is being released; any waiting writer will
will be kicked out by tty_release() with a warning. Further,
the N_TTY ldisc may generate SIGIO for a file handle which
is no longer valid.
Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:13:09 +0000 (12:13 -0500)]
tty: Flush ldisc buffer atomically with tty flip buffers
tty_ldisc_flush() first clears the line discipline input buffer,
then clears the tty flip buffers. However, this allows for existing
data in the tty flip buffers to be added after the ldisc input
buffer has been cleared, but before the flip buffers have been cleared.
Add an optional ldisc parameter to tty_buffer_flush() to allow
tty_ldisc_flush() to pass the ldisc to clear.
NB: Initially, the plan was to do this automatically in
tty_buffer_flush(). However, an audit of the behavior of existing
line disciplines showed that performing a ldisc buffer flush on
ioctl(TCFLSH) was not always the outcome. For example, some line
disciplines have flush_buffer() methods but not ioctl() methods,
so a ->flush_buffer() command would be unexpected.
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:13:08 +0000 (12:13 -0500)]
tty: Fix timeout on pty set ldisc
When changing the ldisc on one end of a pty pair, there may be
waiting readers/writers on the other end which may not exit from
the ldisc i/o loop, preventing tty_ldisc_lock_pair_timeout() from
acquiring the other side's ldisc lock.
Only acquire this side's ldisc lock; although this will no longer
prevent the other side from writing new input, that input will not
be processed until after the ldisc change completes. This has no
effect on normal ttys; new input from the driver was never disabled.
Remove tty_ldisc_enable_pair().
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:13:07 +0000 (12:13 -0500)]
tty: Fix hung task on pty hangup
When hanging up one end of a pty pair, there may be waiting
readers/writers on the other end which may not exit, preventing
tty_ldisc_lock_pair() from acquiring the other side's ldisc lock.
Only acquire this side's ldisc lock; although this will no longer
prevent the other side from writing new input, that input will not
be processing until after the ldisc hangup is complete.
Reported-by: Sasha Levin <sasha.levin@oracle.com> Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty_ldisc_lock(), tty_ldisc_unlock(), and tty_ldisc_lock_nested()
are low-level aliases for the underlying lock mechanism. Rename
with double underscore to allow for new, higher level functions
with those names.
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:13:05 +0000 (12:13 -0500)]
pty, n_tty: Simplify input processing on final close
When releasing one end of a pty pair, that end may just have written
to the other, which the input processing worker, flush_to_ldisc(), is
still working on but has not completed the copy to the other end's
read buffer. So input may not appear to be available to a waiting
reader but yet TTY_OTHER_CLOSED is now observed. The n_tty line
discipline has worked around this by waiting for input processing
to complete and then re-checking if input is available before
exiting with -EIO.
Since the tty/ldisc lock reordering, the wait for input processing
to complete can now occur during final close before setting
TTY_OTHER_CLOSED. In this way, a waiting reader is guaranteed to
see input available (if any) before observing TTY_OTHER_CLOSED.
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:13:02 +0000 (12:13 -0500)]
tty: Preset lock subclass for nested tty locks
Eliminate the requirement of specifying the tty lock nesting at
lock time; instead, set the lock subclass for slave ptys at pty
install (normal ttys and master ptys use subclass 0).
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:13:01 +0000 (12:13 -0500)]
tty: Change tty lock order to master->slave
When releasing the master pty, the slave pty also needs to be locked
to prevent concurrent tty count changes for the slave pty and to
ensure that only one parallel master and slave release observe the
final close, and proceed to destruct the pty pair. Conversely, when
releasing the slave pty, locking the master pty is not necessary
(since the master's state can be inferred by the slave tty count).
Introduce tty_lock_slave()/tty_unlock_slave() which acquires/releases
the tty lock of the slave pty. Remove tty_lock_pair()/tty_unlock_pair().
Dropping the tty_lock is no longer required to re-establish a stable
lock order.
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:12:56 +0000 (12:12 -0500)]
tty: Simplify pty pair teardown logic
When the slave side closes and its tty count is 0, the pty
pair can be destroyed; the master side must have already
closed for the slave side tty count to be 0. Thus, only the
pty master close must check if the slave side has closed by
checking the slave tty count.
Remove the pre-computed closing flags and check the actual count(s).
Regular ttys are unaffected by this change.
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:12:55 +0000 (12:12 -0500)]
tty: Document check_tty_count() requires tty_lock held
Holding the tty_lock() is necessary to prevent concurrent changes
to the tty count that may cause it to differ from the open file
list count. The tty_lock() is already held at all call sites.
NB: Note that the check for the pty master tty count is safe because
the slave's tty_lock() is held while decrementing the pty master
tty count.
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:12:54 +0000 (12:12 -0500)]
tty: Don't release tty locks for wait queue sanity check
Releasing the tty locks while waiting for the tty wait queues to
be empty is no longer necessary nor desirable. Prior to
"tty: Don't take tty_mutex for tty count changes", dropping the
tty locks was necessary to reestablish the correct lock order between
tty_mutex and the tty locks. Dropping the global tty_mutex was necessary;
otherwise new ttys could not have been opened while waiting.
However, without needing the global tty_mutex held, the tty locks for
the releasing tty can now be held through the sleep. The sanity check
is for abnormal conditions caused by kernel bugs, not for recoverable
errors caused by misbehaving userspace; dropping the tty locks only
allows the tty state to get more sideways.
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:12:53 +0000 (12:12 -0500)]
tty: Don't take tty_mutex for tty count changes
Holding tty_mutex is no longer required to serialize changes to
the tty_count or to prevent concurrent opens of closing ttys;
tty_lock() is sufficient.
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:12:51 +0000 (12:12 -0500)]
tty: Drop tty_mutex before tty reopen
Holding tty_mutex for a tty re-open is no longer necessary since
"tty: Clarify re-open behavior of master ptys". Because the
slave tty count is no longer accessed by tty_reopen(), holding
tty_mutex to prevent concurrent final tty_release() of the slave
pty is not required.
As with "tty: Re-open /dev/tty without tty_mutex", holding a
tty kref until the tty_lock is acquired is sufficient to ensure
the tty has not been freed, which, in turn, is sufficient to
ensure the tty_lock can be safely acquired and the tty count
can be safely retrieved. A non-zero tty count with the tty lock
held guarantees that release_tty() has not run and cannot
run concurrently with tty_reopen().
Change tty_driver_lookup_tty() to acquire the tty kref, which
allows the tty_mutex to be dropped before acquiring the tty lock.
Dropping the tty_mutex before attempting the tty_lock allows
other ttys to be opened and released, without needing this
tty_reopen() to complete.
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:12:50 +0000 (12:12 -0500)]
tty: Re-open /dev/tty without tty_mutex
Opening /dev/tty (ie., the controlling tty for the current task)
is always a re-open of the underlying tty. Because holding the
tty_lock is sufficient for safely re-opening a tty, and because
having a tty kref is sufficient for safely acquiring the tty_lock [1],
tty_open_current_tty() does not require holding tty_mutex.
Repurpose tty_open_current_tty() to perform the re-open itself and
refactor tty_open().
[1] Analysis of safely re-opening the current tty w/o tty_mutex
get_current_tty() gets a tty kref from the already kref'ed tty value of
current->signal->tty while holding the sighand lock for the current
task. This guarantees that the tty pointer returned from
get_current_tty() points to a tty which remains referenceable
while holding the kref.
Although release_tty() may run concurrently, and thus the driver
reference may be removed, release_one_tty() cannot have run, and
won't while holding the tty kref.
This, in turn, guarantees the tty_lock() can safely be acquired
(since tty->magic and tty->legacy_mutex are still a valid dereferences).
The tty_lock() also gets a tty kref to prevent the tty_unlock() from
dereferencing a released tty. Thus, the kref returned from
get_current_tty() can be released.
Lastly, the first operation of tty_reopen() is to check the tty count.
If non-zero, this ensures release_tty() is not running concurrently,
and the driver references have not been removed.
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:12:49 +0000 (12:12 -0500)]
pty: Always return -EIO if slave BSD pty opened first
Opening the slave BSD pty first already returns -EIO from the slave
pty_open(), which in turn causes the newly installed tty pair to be
released before returning from tty_open(). However, this can also
cause a parallel master BSD pty open to fail because the pty pair
destruction may already been taking place in tty_release().
Failing at driver->install() if the slave pty is opened first ensures
that a pty master open cannot fail, because the driver tables will
not have been updated so tty_driver_lookup_tty() won't find the
master pty (and attempt to "re-open" it).
In turn, this guarantees that any tty with a tty->count == 0 is
in final close (rather than never opened).
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:12:48 +0000 (12:12 -0500)]
tty: Check tty->count instead of TTY_CLOSING in tty_reopen()
Although perhaps not obvious, the TTY_CLOSING bit is set when the
tty count has been decremented to 0 (which occurs while holding
tty_lock). The only other case when tty count is 0 during a re-open
is when a legacy BSD pty master has been opened in parallel but
after the pty slave, which is unsupported and returns an error.
Thus !tty->count contains the complete set of degenerate conditions
under which a tty open fails.
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Wed, 5 Nov 2014 17:12:47 +0000 (12:12 -0500)]
tty: Clarify re-open behavior of master ptys
Re-opening master ptys is not allowed. Once opened and for the remaining
lifetime of the master pty, its tty count is 1. If its tty count has
dropped to 0, then the master pty was closed and TTY_CLOSING was set,
and destruction may begin imminently.
Besides the normal case of a legacy BSD pty master being re-opened
(which always returns -EIO), this code is only reachable in 2 degenerate
cases:
1. The pty master is the controlling terminal (this is possible through
the TIOCSCTTY ioctl). pty masters are not designed to be controlling
terminals and it's an oversight that tiocsctty() ever let that happen.
The attempted open of /dev/tty will always fail. No known program does
this.
2. The legacy BSD pty slave was opened first. The slave open will fail
in pty_open() and tty_release() will commence. But before tty_release()
claims the tty_mutex, there is a very small window where a parallel
master open might succeed. In a test of racing legacy BSD slave and
master parallel opens, where:
slave open attempts: 10000 success:4527 failure:5473
master open attempts: 11728 success:5789 failure:5939
only 8 master open attempts would have succeeded reaching this code and
successfully opened the master pty. This case is not possible with
SysV ptys.
Always return -EIO if a master pty is re-opened or the slave is opened
first and the master opened in parallel (for legacy BSD ptys).
Furthermore, now that changing the slave's count is not required,
the tty_lock is sufficient for preventing concurrent changes to the
tty being re-opened (or failing re-opening).
Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / linux-beck.git / log