aboutsummaryrefslogtreecommitdiff
path: root/drivers/tty
AgeCommit message (Collapse)AuthorFilesLines
2018-01-25tty: serial: exar: Relocate sleep wake-up handlingAaron Sierra2-30/+30
Exar sleep wake-up handling has been done on a per-channel basis by virtue of INT0 being accessible from each channel's address space. I believe this was initially done out of necessity, but now that Exar devices have their own driver, we can do things more efficiently by registering a dedicated INT0 handler at the PCI device level. I see this change providing the following benefits: 1. If more than one port is active, eliminates the redundant bus cycles for reading INT0 on every interrupt. 2. This note associated with hooking in the per-channel handler in 8250_port.c is resolved: /* Fixme: probably not the best place for this */ Cc: Matt Schulte <[email protected]> Signed-off-by: Aaron Sierra <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-23serdev: add method to set parityUlrich Hecht2-0/+36
Adds serdev_device_set_parity() and an implementation for ttyport. The interface uses an enum with the values SERIAL_PARITY_NONE, SERIAL_PARITY_EVEN and SERIAL_PARITY_ODD. Signed-off-by: Ulrich Hecht <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-01-23tty: fix data race between tty_init_dev and flush of bufGaurav Kohli2-3/+9
There can be a race, if receive_buf call comes before tty initialization completes in n_tty_open and tty->disc_data may be NULL. CPU0 CPU1 ---- ---- 000|n_tty_receive_buf_common() n_tty_open() -001|n_tty_receive_buf2() tty_ldisc_open.isra.3() -002|tty_ldisc_receive_buf(inline) tty_ldisc_setup() Using ldisc semaphore lock in tty_init_dev till disc_data initializes completely. Signed-off-by: Gaurav Kohli <[email protected]> Reviewed-by: Alan Cox <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-22serial: imx: fix endless loop during suspendMartin Kaiser1-17/+15
Before we go into suspend mode, we enable the imx uart's interrupt for the awake bit in the UART Status Register 1. If, for some reason, the awake bit is already set before we enter suspend mode, we get an interrupt immediately when we enable interrupts for awake. The uart's clk_ipg is disabled at this point (unless there's an ongoing transfer). We end up in the interrupt handler, which usually tries to clear the awake bit. This doesn't work with the clock disabled. Therefore, we keep getting interrupts forever, resulting in an endless loop. Clear the awake bit before setting the awaken bit to signal that we want an imx interrupt when the awake bit will be set. This ensures that we're not woken up by events that happened before we started going into suspend mode. Change the clock handling so that suspend prepares and enables the clock and suspend_noirq disables it. Revert these operations in resume_noirq and resume. With these preparations in place, we can now modify awake and awaken in the suspend function when the actual imx interrupt is disabled and the required clk_ipg is active. Update the thaw and freeze functions to use the new clock handling since we share the suspend_noirq function between suspend and hibernate. Signed-off-by: Martin Kaiser <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-22serial: core: mark port as initialized after successful IRQ changeSebastian Andrzej Siewior1-0/+2
setserial changes the IRQ via uart_set_info(). It invokes uart_shutdown() which free the current used IRQ and clear TTY_PORT_INITIALIZED. It will then update the IRQ number and invoke uart_startup() before returning to the caller leaving TTY_PORT_INITIALIZED cleared. The next open will crash with | list_add double add: new=ffffffff839fcc98, prev=ffffffff839fcc98, next=ffffffff839fcc98. since the close from the IOCTL won't free the IRQ (and clean the list) due to the TTY_PORT_INITIALIZED check in uart_shutdown(). There is same pattern in uart_do_autoconfig() and I *think* it also needs to set TTY_PORT_INITIALIZED there. Is there a reason why uart_startup() does not set the flag by itself after the IRQ has been acquired (since it is cleared in uart_shutdown)? Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-22serdev: only match serdev devicesJohan Hovold1-0/+8
Only serdev devices (a.k.a. clients or slaves) are bound to drivers so bail out early from match() in case the device is not a serdev device (i.e. if it's a serdev controller). Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-22serdev: do not generate modaliases for controllersJohan Hovold1-38/+34
Serdev controllers are not bound to any drivers and it therefore makes no sense to generate modaliases for them. This has already been fixed separately for ACPI controllers for which uevent errors were also being logged during probe due to the missing ACPI companions (from which ACPI modaliases are generated). This patch moves the modalias handling from the bus type to the client device type. Specifically, this means that only serdev devices (a.k.a. clients or slaves) will have have MODALIAS fields in their uevent environments and corresponding modalias sysfs attributes. Also add the missing static keyword for the modalias device attribute when moving the definition. Reported-by: Hans de Goede <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-22serial: mxs-auart: don't use GPIOF_* with gpiod_get_directionWolfram Sang1-2/+1
The documentation was wrong, gpiod_get_direction() returns 0/1 instead of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 ("gpio: correct docs about return value of gpiod_get_direction"). Now, fix this user (until a better, system-wide solution is in place). This also means we can drop the deprecated use of 'linux/gpio.h'. Yay! Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-22serial: 8250_dw: Revert "Improve clock rate setting"Andy Shevchenko1-18/+12
The commit de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting") obviously tries to cure symptoms, and not a root cause. The root cause is the non-flexible rate calculation inside the corresponding clock driver. What we need is to provide maximum UART divisor value to the clock driver to allow it do the job transparently to the caller. Since from the initial commit message I have got no clue which clock driver actually needs to be amended, I leave this exercise to the people who know better the case. Moreover, it seems [1] the fix introduced a regression. And possible even one more [2]. Taking above, revert the commit de9e33bdfa22 for now. [1]: https://www.spinics.net/lists/linux-serial/msg28872.html [2]: https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-357583782 Fixes: de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting") Cc: stable <[email protected]> # 4.15 Cc: Ed Blake <[email protected]> Cc: Heikki Krogerus <[email protected]> Cc: Lukas Wunner <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09gpio: serial: max310x: Support open-drain configuration for GPIOsJan Kundrát1-0/+22
The push-pull vs. open-drain are the only supported output modes. The inputs are always unconditionally equipped with weak pull-downs. That's the only mode, so there's probably no point in exporting that. I wonder if it's worthwhile to provide a custom dbg_show method to indicate the current status of the outputs, though. This patch and [1] for i2c-gpio together make it possible to bit-bang an I2C bus over GPIOs of an UART which is connected via SPI :). Yes, this is crazy, but it's fast enough (while on a 26Mhz SPI HW bus with a dual-core 1.6GHz CPU) to drive an I2C bus at 200kHz, according to my scope. [1] https://patchwork.ozlabs.org/patch/852591/ Signed-off-by: Jan Kundrát <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09serdev: Fix serdev_uevent failure on ACPI enumerated serdev-controllersHans de Goede1-0/+5
ACPI enumerated serdev-controllers do not have an ACPI companion, the ACPI companion belongs to the serdev-device child of the serdev-controller, not to the controller itself. This was causing serdev_uevent to always return -ENODEV when called on a serdev-controller leading to errors like these: kernel: serial serial0: uevent: failed to send synthetic uevent being logged. This commit modifies serdev_uevent to directly return 0 when called on an ACPI enumerated serdev-controller fixing this. Note: I do not think that setting a modalias on a devicetree enumerated serdev-controller makes sense either. So perhaps the !dev->of_node part of the check can be dropped too, but I'm not entirely sure that doing this on devicetree too is correct. Signed-off-by: Hans de Goede <[email protected]> Acked-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09serial: 8250_ingenic: Parse earlycon optionsPaul Cercueil1-2/+10
In the devicetree, it is possible to specify the baudrate, parity, bits, flow of the early console, by passing a configuration string like this: aliases { serial0 = &uart0; }; chosen { stdout-path = "serial0:57600n8"; }; This, for instance, will configure the early console for a baudrate of 57600 bps, no parity, and 8 bits per baud. This patches implements parsing of this configuration string in the 8250_ingenic driver, which previously just ignored it. Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09serial: 8250_ingenic: Add support for the JZ4770 SoCPaul Cercueil1-0/+5
The JZ4770 SoC's UART is no different from the other JZ SoCs, so this commit simply adds the ingenic,jz4770-uart compatible string. Signed-off-by: Paul Cercueil <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09serial: core: Make uart_parse_options take const char* argumentPaul Cercueil1-2/+3
The pointed string is never modified from within uart_parse_options, so it should be marked as const in the function prototype. Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09serial: 8250_of: fix return code when probe function fails to get resetMasahiro Yamada1-1/+4
The error pointer from devm_reset_control_get_optional_shared() is not propagated. One of the most common problem scenarios is it returns -EPROBE_DEFER when the reset controller has not probed yet. In this case, the probe of the reset consumer should be deferred. Fixes: e2860e1f62f2 ("serial: 8250_of: Add reset support") Cc: [email protected] # v4.13+ Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTSFabio Estevam1-6/+8
The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS lines, so only allow such wakeup method when the system actually has RTS/CTS support. Fixes: bc85734b126f ("serial: imx: allow waking up on RTSD") Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Martin Kaiser <[email protected]> Acked-by: Fugang Duan <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09serial: 8250_uniphier: fix error return code in uniphier_uart_probe()Wei Yongjun1-2/+3
Fix to return a negative error code from the port register error handling case instead of 0, as done elsewhere in this function. Fixes: 39be40ce066d ("serial: 8250_uniphier: fix serial port index in private data") Signed-off-by: Wei Yongjun <[email protected]> Acked-by: Masahiro Yamada <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09tty: n_gsm: Allow ADM response in addition to UA for control dlciTony Lindgren1-3/+14
Some devices have the control dlci stay in ADM mode instead of the UA mode. This can seen at least on droid 4 when trying to open the ts 27.010 mux port. Enabling n_gsm debug mode shows the control dlci always respond with DM to SABM instead of UA: # modprobe n_gsm debug=0xff # ldattach -d GSM0710 /dev/ttyS0 & gsmld_output: 00000000: f9 03 3f 01 1c f9 --> 0) C: SABM(P) gsmld_receive: 00000000: f9 03 1f 01 36 f9 <-- 0) C: DM(P) ... $ minicom -D /dev/gsmtty1 minicom: cannot open /dev/gsmtty1: No error information $ strace minicom -D /dev/gsmtty1 ... open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT Note that this is different issue from other n_gsm -EL2HLT issues such as timeouts when the control dlci does not respond at all. The ADM mode seems to be a quite common according to "RF Wireless World" article "GSM Issue-UE sends SABM and gets a DM response instead of UA response": This issue is most commonly observed in GSM networks where in UE sends SABM and expects network to send UA response but it ends up receiving DM response from the network. SABM stands for Set asynchronous balanced mode, UA stands for Unnumbered Acknowledge and DA stands for Disconnected Mode. An RLP entity can be in one of two modes: - Asynchronous Balanced Mode (ABM) - Asynchronous Disconnected Mode (ADM) Currently Linux kernel closes the control dlci after several retries in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce error code -EL2HLT when trying to open them as the closing of control dlci has already set gsm->dead. Let's fix the issue by allowing control dlci stay in ADM mode after the retries so the /dev/gsmtty ports can be opened and used. It seems that it might take several attempts to get any response from the control dlci, so it's best to allow ADM mode only after the SABM retries are done. Note that for droid 4 additional patches are needed to mux the ttyS0 pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also needed to use n_gsm. And the mdm6600 modem needs to be powered on. Cc: [email protected] Cc: Alan Cox <[email protected]> Cc: Jiri Prchal <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: Marcel Partap <[email protected]> Cc: Michael Scott <[email protected]> Cc: Peter Hurley <[email protected]> Cc: Russ Gorby <[email protected]> Cc: Sascha Hauer <[email protected]> Cc: Sebastian Reichel <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09tty: omap-serial: Fix initial on-boot RTS GPIO levelRafael Gago1-4/+3
The rs485 flag "SER_RS485_RTS_AFTER_SEND" was wrongly read from the GPIO flags. This caused the RTS pin to be high during boot. Signed-off-by: Rafael Gago Castano <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09tty: serial: jsm: Add one check against NULL pointer dereferenceGuilherme G. Piccoli1-0/+3
All calls to neo_copy_data_from_uart_to_queue() are safeguarded against NULL dereference of its parameter, except the one that this patch changes. That said, let's play safe and check for NULL in this case too. Signed-off-by: Guilherme G. Piccoli <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09tty: serial: jsm: Remove unnecessary NULL checksGuilherme G. Piccoli2-9/+0
After inspection made by Markus using Coccinelle software, he observed that we could possibly be triggering a NULL pointer dereference in 2 functions [0]. After discussion in mailing list, it was observed in fact we have two unnecessary checks for NULL pointer, and they were leading to Coccinelle warn. So, instead of reworking the code as proposed by him, we hereby remove the unnecessary checks, and also some unneeded extra lines in the code. These two unnecessary NULL checks were tracked in the call chain as never NULL, so they can be safely removed. No functional changes are intended. [0] https://lkml.org/lkml/2017/11/29/705 Suggested-by: Markus Elfring <[email protected]> Signed-off-by: Guilherme G. Piccoli <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-09treewide: Use DEVICE_ATTR_RWJoe Perches1-1/+1
Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible. Done with perl script: $ git grep -w --name-only DEVICE_ATTR | \ xargs perl -i -e 'local $/; while (<>) { s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S_IWUSR|\s*S_IWUSR\s*\|\s*S_IRUGO\s*|\s*0644\s*)\)?\s*,\s*\1_show\s*,\s*\1_store\s*\)/DEVICE_ATTR_RW(\1)/g; print;}' Signed-off-by: Joe Perches <[email protected]> Acked-by: Felipe Balbi <[email protected]> Acked-by: Andy Shevchenko <[email protected]> Acked-by: Bartlomiej Zolnierkiewicz <[email protected]> Acked-by: Zhang Rui <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-01-08serdev: Introduce devm_serdev_device_open()Andrey Smirnov1-0/+27
Add code implementing managed version of serdev_device_open() for serdev device drivers that "open" the device during driver's lifecycle only once (e.g. opened in .probe() and closed in .remove()). Acked-by: Philippe Ombredanne <[email protected]> Acked-by: Pavel Machek <[email protected]> Acked-by: Rob Herring <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Andrey Smirnov <[email protected]> Signed-off-by: Lee Jones <[email protected]>
2018-01-08serdev: Make .remove in struct serdev_device_driver optionalAndrey Smirnov1-2/+2
Using devres infrastructure it is possible to write a serdev driver that doesn't have any code that needs to be called as a part of .remove. Add code to make .remove optional. Acked-by: Philippe Ombredanne <[email protected]> Acked-by: Pavel Machek <[email protected]> Acked-by: Rob Herring <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Andrey Smirnov <[email protected]> Signed-off-by: Lee Jones <[email protected]>
2018-01-02Merge 4.15-rc6 into tty-nextGreg Kroah-Hartman1-2/+2
We want the ldisc fix here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-21n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)Linus Torvalds1-2/+2
We added support for EXTPROC back in 2010 in commit 26df6d13406d ("tty: Add EXTPROC support for LINEMODE") and the intent was to allow it to override some (all?) ICANON behavior. Quoting from that original commit message: There is a new bit in the termios local flag word, EXTPROC. When this bit is set, several aspects of the terminal driver are disabled. Input line editing, character echo, and mapping of signals are all disabled. This allows the telnetd to turn off these functions when in linemode, but still keep track of what state the user wants the terminal to be in. but the problem turns out that "several aspects of the terminal driver are disabled" is a bit ambiguous, and you can really confuse the n_tty layer by setting EXTPROC and then causing some of the ICANON invariants to no longer be maintained. This fixes at least one such case (TIOCINQ) becoming unhappy because of the confusion over whether ICANON really means ICANON when EXTPROC is set. This basically makes TIOCINQ match the case of read: if EXTPROC is set, we ignore ICANON. Also, make sure to reset the ICANON state ie EXTPROC changes, not just if ICANON changes. Fixes: 26df6d13406d ("tty: Add EXTPROC support for LINEMODE") Reported-by: Tetsuo Handa <[email protected]> Reported-by: syzkaller <[email protected]> Cc: Jiri Slaby <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-19pty: cancel pty slave port buf's work in tty_releaseSahara1-0/+2
In case that CONFIG_SLUB_DEBUG is on and pty is used, races between release_one_tty and flush_to_ldisc work threads may happen and lead to use-after-free condition on tty->link->port. Because SLUB_DEBUG is turned on, freed tty->link->port is filled with POISON_FREE value. So far without SLUB_DEBUG, port was filled with zero and flush_to_ldisc could return without a problem by checking if tty is NULL. CPU 0 CPU 1 ----- ----- release_tty pty_write cancel_work_sync(tty) to = tty->link tty_kref_put(tty->link) tty_schedule_flip(to->port) << workqueue >> ... release_one_tty ... pty_cleanup ... kfree(tty->link->port) << workqueue >> flush_to_ldisc tty = READ_ONCE(port->itty) tty is 0x6b6b6b6b6b6b6b6b !!PANIC!! access tty->ldisc Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b93 pgd = ffffffc0eb1c3000 [6b6b6b6b6b6b6b93] *pgd=0000000000000000, *pud=0000000000000000 ------------[ cut here ]------------ Kernel BUG at ffffff800851154c [verbose debug info unavailable] Internal error: Oops - BUG: 96000004 [#1] PREEMPT SMP CPU: 3 PID: 265 Comm: kworker/u8:9 Tainted: G W 3.18.31-g0a58eeb #1 Hardware name: Qualcomm Technologies, Inc. MSM 8996pro v1.1 + PMI8996 Carbide (DT) Workqueue: events_unbound flush_to_ldisc task: ffffffc0ed610ec0 ti: ffffffc0ed624000 task.ti: ffffffc0ed624000 PC is at ldsem_down_read_trylock+0x0/0x4c LR is at tty_ldisc_ref+0x24/0x4c pc : [<ffffff800851154c>] lr : [<ffffff800850f6c0>] pstate: 80400145 sp : ffffffc0ed627cd0 x29: ffffffc0ed627cd0 x28: 0000000000000000 x27: ffffff8009e05000 x26: ffffffc0d382cfa0 x25: 0000000000000000 x24: ffffff800a012f08 x23: 0000000000000000 x22: ffffffc0703fbc88 x21: 6b6b6b6b6b6b6b6b x20: 6b6b6b6b6b6b6b93 x19: 0000000000000000 x18: 0000000000000001 x17: 00e80000f80d6f53 x16: 0000000000000001 x15: 0000007f7d826fff x14: 00000000000000a0 x13: 0000000000000000 x12: 0000000000000109 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffc0ed624000 x8 : ffffffc0ed611580 x7 : 0000000000000000 x6 : ffffff800a42e000 x5 : 00000000000003fc x4 : 0000000003bd1201 x3 : 0000000000000001 x2 : 0000000000000001 x1 : ffffff800851004c x0 : 6b6b6b6b6b6b6b93 Signed-off-by: Sahara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-19serial: max310x: Reduce RX work starvationJan Kundrát1-13/+10
Prior to this patch, the code would happily trigger TX on some ports before having a chance of reading the RX buffer from the rest of them. When no flow control was used, this led to RX buffer overruns and therefore lost data under certain circumstances. I was able to reproduce this with MAX14830 (that's a quad channel one) and a simple daisy-chain of RX and TX ports on the eval board: - TX0 -> RX1 - TX1 -> RX2 - TX2 -> RX3 - TX3 -> RX0 I was testing this by transferring 2MB of data at 115200 baud via each port. I used a Solidrun Clearfog Base (Armada 388) which was talking to the UART over an SPI bus clocked at 26MHz (the chip's maximum). Without this patch, I would always get a "Possible RX FIFO overrun" in dmesg, and fewer-than-expected amount of bytes received over ttyMAX0. Results on ttyMAX{1,2,3} tended to be correct all the time, even without the previous patches in this series and with PIO SPI transfers ("indirect mode" as the Marvell datasheet calls it), so I assume that heavy congestion is needed in order to reproduce this. A drawback of this patch is that the throughput gets reduced "a bit". Previously, a 115200 baud resulted in about 11.2kBps throughput as reported by a simple `pv`. With this patch, the throughput of four parallel streams is roughly 7kBps each, and 9kBps for three streams. There is no slowdown for one or two parallel streams. Situation is worse if bytes are being read one-by-one (such as if the userspace wants to perform parity/framing/break checking) and therefore without the batched reads. With just this patch and no other modifications on top of 4.14, I was only getting roughly 3.6kBps with four parallel streams. The single-stream performance was the same, and I was seeing about 7.2kBps with two parallel streams. `perf top` said that a substantial amount of time was spent in `finish_task_switch`, `_raw_spin_unlock_irqrestore` and `__timer_delay`. Signed-off-by: Jan Kundrát <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-19serial: max310x: Use batched reads when reasonably safeJan Kundrát1-40/+86
The hardware has a 128 byte RX FIFO buffer for each independent UART. Previously, the code was always reading that byte-by-byte via independent SPI transactions and the associated overhead. In practice, this led to up to eight bytes over SPI for just one byte in the UART's RX FIFO: - reading the global IRQ register (two bytes, one for command, the other for data) - reading one UART's ISR (again two bytes) - reading the byte count (two bytes yet again) - finally, reading one byte of the FIFO via another two-byte transaction We cannot always use a batched read. If the TTY is set to intercept break conditions or report framing or parity errors, then it is required to check the Line Status Register (LSR) for each byte which is read from the RX FIFO. The documentation does not show a way of doing that in a single SPI transaction; registers 0x00 and 0x04 are separate. In my testing, this is no silver bullet. I was feeding 2MB of random data over four daisy-chaned UARTs of MAX14830, and this is the distribution that I was getting: - R <= 1: 7437322 - R <= 2: 162093 - R <= 4: 4093 - R <= 8: 4196 - R <= 16: 645 - R <= 32: 165 - R <= 64: 58 - R <= 128: 0 For a reference, batching the write operations works much better: - W <= 1: 2664 - W <= 2: 1305 - W <= 4: 627 - W <= 8: 371 - W <= 16: 121 - W <= 32: 68 - W <= 64: 33 - W <= 128: 63139 That's probably because this HW/SW combination (Clearfog Base, Armada 388) is probably "good enough" to react to the chip's IRQ "fast enough" most of the time. Still, I was getting RX overruns every now and then. In future, I plan to improve this by letting the RX FIFO be filled a little more (the chip has support for that and also for a "stale timeout" to prevent additional starvation). Signed-off-by: Jan Kundrát <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-19serial: max310x: use a batch write op for UART transmitJan Kundrát1-7/+29
The transmit register supports batched writes. The key is simply to keep sending additional bytes up to the FIFO size in the same SPI transaction with the CS pin still being held low. This duplicates the regmap infrastructure to a certain extent. There are some provisions for multiple writes in there, but there does not appear to be any support for those writes which are destined to the *same* register (and also no standard for SPI bus transfers of these, anyway). This patch does not solve every case (if the UART xmit circular buffer wraps around, we're still doing two SPI transactions), but at least it's not one-byte-per-transaction anymore. This change does not touch the receive path at this time. Doing that in the generic case appears to be impossible in the general case, because the chips' status register contains data about the *current* byte in the HW's Rx FIFO. We cannot read these two registers in one go, unfortunately. Signed-off-by: Jan Kundrát <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-19serial: max310x: Support IRQ sharing with other devicesJan Kundrát1-6/+14
According to my chip's datasheet [1], the IRQ output is an open collector pin which is suitable for sharing with other chips. The chip also has a register which indicates which UART performed a change and the driver checks that register already, so we have everything what is needed to effectively share the IRQ GPIO. [1] https://datasheets.maximintegrated.com/en/ds/MAX14830.pdf Signed-off-by: Jan Kundrát <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-19serial: max310x: Do not hard-code the IRQ typeJan Kundrát1-5/+3
As suggested by Russell King, a driver should not really care about bits such as the interrupt polarity or whether it is edge- or level- triggered. The reasons for that include: - an upstream IRQ controller which cannot support edge- or level-triggered interrupts, - board design with a built-in inverter The interrupt type is being already specified by the Device Tree, anyway. Other drivers (gpio/gpio-tc3589x.c for example) already work in this way, delegating the proper IRQ line setup to the DT and not specifying anything by hand. Also, there's no reason to have the IRQ flags split between two places. The SPI probing is the only entry point anyway. Signed-off-by: Jan Kundrát <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-18serdev: ttyport: do not used keyed wakeup in write_wakeupJohan Hovold1-1/+2
Serdev does not use the file abstraction and specifically there will never be anyone polling a file descriptor for POLLOUT events. Just use plain wake_up_interruptible() in the write_wakeup callback and document why it's there. Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-18tty: serial: sh-sci: Add default for number of ports for compile-testingGeert Uytterhoeven1-0/+1
When compile-testing an allmodconfig kernel for a platform without sh-sci serial ports, the SERIAL_SH_SCI_NR_UARTS symbol of type "int" doesn't get assigned a numerical default value, but an empty string, leading to a build failure: .config:3814:warning: symbol value '' invalid for SERIAL_SH_SCI_NR_UARTS ... make[3]: *** [silentoldconfig] Error 1 Fix this by explicitly providing a default value of 2, like before. Reported-by: kbuild test robot <[email protected]> Fixes: f6731485a51978ca ("tty: serial: sh-sci: Hide number of ports config question") Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15serial: max310x: Fix invalid memory access during GPIO initJan Kundrát1-17/+17
The `max310x_spi_probe` function attempted to setup the GPIO bits before the corresponding structs for each serial port were initialized. If the DTS file specified a GPIO hog, this led to a crash because the GPIO stack ended up calling `max310x_gpio_direction_output` which referenced uninitialized memory: [<c04598c0>] (max310x_gpio_direction_output) from [<c03f5a2c>] (_gpiod_direction_output_raw+0x94/0x2d4) [<c03f5a2c>] (_gpiod_direction_output_raw) from [<c03f991c>] (gpiod_hog+0x6c/0x154) [<c03f991c>] (gpiod_hog) from [<c03fa2d8>] (of_gpiochip_add+0x28c/0x444) [<c03fa2d8>] (of_gpiochip_add) from [<c03f6b2c>] (gpiochip_add_data+0x4f8/0x760) [<c03f6b2c>] (gpiochip_add_data) from [<c03f6dd4>] (devm_gpiochip_add_data+0x40/0x7c) [<c03f6dd4>] (devm_gpiochip_add_data) from [<c0459fec>] (max310x_spi_probe+0x530/0x894) [<c0459fec>] (max310x_spi_probe) from [<c0503294>] (spi_drv_probe+0x7c/0xac) [<c0503294>] (spi_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8) [<c046628c>] (driver_probe_device) from [<c0464890>] (bus_for_each_drv+0x60/0x94) [<c0464890>] (bus_for_each_drv) from [<c0465f78>] (__device_attach+0xb0/0x114) [<c0465f78>] (__device_attach) from [<c0465548>] (bus_probe_device+0x84/0x8c) [<c0465548>] (bus_probe_device) from [<c0463a00>] (device_add+0x3f4/0x580) [<c0463a00>] (device_add) from [<c0504164>] (spi_add_device+0x9c/0x134) [<c0504164>] (spi_add_device) from [<c0504c18>] (spi_register_controller+0x484/0x910) [<c0504c18>] (spi_register_controller) from [<c0506ee0>] (orion_spi_probe+0x2f4/0x3b4) [<c0506ee0>] (orion_spi_probe) from [<c0467dac>] (platform_drv_probe+0x50/0xb0) [<c0467dac>] (platform_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8) [<c046628c>] (driver_probe_device) from [<c04663f8>] (__driver_attach+0xb8/0xbc) [<c04663f8>] (__driver_attach) from [<c04647e8>] (bus_for_each_dev+0x68/0x9c) [<c04647e8>] (bus_for_each_dev) from [<c046574c>] (bus_add_driver+0x104/0x210) [<c046574c>] (bus_add_driver) from [<c0466f14>] (driver_register+0x78/0xf4) [<c0466f14>] (driver_register) from [<c0101bdc>] (do_one_initcall+0x44/0x168) [<c0101bdc>] (do_one_initcall) from [<c0a00dc0>] (kernel_init_freeable+0x140/0x1cc) [<c0a00dc0>] (kernel_init_freeable) from [<c078c590>] (kernel_init+0x8/0x108) [<c078c590>] (kernel_init) from [<c0107a50>] (ret_from_fork+0x14/0x24) This can be easily fixed by moving the corresponding code below. And because the UARTs are already there by the time we reach this point, the `goto` needs changing so that more stuff is freed. (I have not tested this error path.) Signed-off-by: Jan Kundrát <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15tty: serial: mxs-auart: fix error handling in mxs_auart_probeBranislav Radocaj1-2/+6
If uart_add_one_port() fails in mxs_auart_probe, the clks has to be disabled.Two clks are previously enabled in mxs_get_clks(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Branislav Radocaj <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15tty: goldfish: Enable 'earlycon' only if built-inSebastian Andrzej Siewior2-1/+7
Commit 3840ed9548f7 ("tty: goldfish: Implement support for kernel 'earlycon' parameter") breaks an allmodconfig config on x86: | LD vmlinux.o | MODPOST vmlinux.o |drivers/tty/serial/earlycon.o: In function `parse_options': |drivers/tty/serial/earlycon.c:97: undefined reference to `uart_parse_earlycon' |Makefile:1005: recipe for target 'vmlinux' failed earlycon.c::parse_options() invokes uart_parse_earlycon() from serial_core.c which is compiled=m because GOLDFISH_TTY itself (and most others) are =m. To avoid that, I'm adding the _CONSOLE config option which is selected if the GOLDFISH module itself is =y since it doesn't need the early bits for the =m case (other drivers do the same dance). The alternative would be to move uart_parse_earlycon() from serial_core.c to earlycon.c (we don't have that many users of that function). Fixes: 3840ed9548f7 ("tty: goldfish: Implement support for kernel 'earlycon' parameter") Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Reviewed-by: Miodrag Dinic <[email protected]> Acked-by: Miodrag Dinic <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15serial: 8250: 8250_omap: Fix spelling error.Rolf Evers-Fischer1-1/+1
Fixed a spelling error in a comment. Signed-off-by: Rolf Evers-Fischer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15serial: 8250_dw: Disable clock on errorStefan Potyra1-1/+2
If there is no clock rate for uartclk defined, disable the previously enabled clock again. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 23f5b3fdd04e serial: 8250_dw: only get the clock rate in one place Signed-off-by: Stefan Potyra <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15serial: stm32: fix name conflict with 8250Ludovic Barre1-1/+1
This patch replaces stm32 tty name ttyS by ttySTM to avoid a name conflict when Serial: 8250/16550 driver is activated. sysfs: cannot create duplicate filename '/class/tty/ttyS3' Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-12903-gb392521-dirty #1 [<c03118dc>] (unwind_backtrace) from [<c030c950>] (show_stack+0x10/0x14) [<c030c950>] (show_stack) from [<c0d31e18>] (dump_stack+0x90/0xa4) [<c0d31e18>] (dump_stack) from [<c03430a0>] (__warn+0xf8/0x110) [<c03430a0>] (__warn) from [<c03430f0>] (warn_slowpath_fmt+0x38/0x48) [<c03430f0>] (warn_slowpath_fmt) from [<c04ce574>] (sysfs_warn_dup+0x68/0x78) [<c04ce574>] (sysfs_warn_dup) from [<c04ce824>] (sysfs_do_create_link_sd+0xb4/0xc4) [<c04ce824>] (sysfs_do_create_link_sd) from [<c08c60ec>] (device_add+0x204/0x574) [<c08c60ec>] (device_add) from [<c07a7ddc>] (tty_register_device_attr+0xc8/0x1bc) [<c07a7ddc>] (tty_register_device_attr) from [<c07c6530>] (uart_add_one_port+0x22c/0x4f4) Signed-off-by: Ludovic Barre <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15tty/isicom: Fix a possible sleep-in-atomic bug in WaitTillCardIsFreeJia-Ju Bai1-5/+1
The driver may sleep under a spinlock. The function call paths are: isicom_activate (acquire the spinlock) isicom_setup_board drop_dtr_rts WaitTillCardIsFree msleep --> may sleep isicom_set_termios isicom_config_port drop_dtr WaitTillCardIsFree msleep --> may sleep isicom_tiocmset drop_dtr WaitTillCardIsFree msleep --> may sleep Though "in_atomic" is used to check atomic context, but it is not recommended to use in driver code (see include/linux/preempt.h). To fix it, only using mdelay instead. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15tty: serial: sh-sci: Hide DMA config questionGeert Uytterhoeven1-1/+2
On most Renesas ARM platforms, the SCIF serial ports can be used with DMA, so most users will want DMA support to be enabled. On SuperH platforms, SCI(F) serial ports cannot be used with DMA yet (see also commit 219fb0c1436e4893 ("serial: sh-sci: Remove the platform data dma slave rx/tx channel IDs")), so users will want it disabled to reduce kernel size. Hence follow the above rationale to configure the default, unless CONFIG_EXPERT is enabled. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15tty: serial: sh-sci: Hide earlycon config questionGeert Uytterhoeven1-1/+2
Renesas H8/300 and ARM platforms use DT and support earlycon, so most users want earlycon support to be enabled. On SuperH platforms, earlycon is not yet supported. Hence follow the above rationale to configure the default, unless CONFIG_EXPERT is enabled. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15tty: serial: sh-sci: Hide serial console config questionGeert Uytterhoeven1-1/+2
Most users will want to use a serial console. Hence make that the default, unless CONFIG_EXPERT is enabled. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15tty: serial: sh-sci: Hide number of ports config questionGeert Uytterhoeven1-2/+4
Auto-configure the maximum number of serial ports based on how many can be present on the architecture: - 3 on H8/300, - 10 on SuperH, - 18 on Reneas ARM. The default can still be overridden if CONFIG_EXPERT is enabled. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-15serial: forbid 8250 on s390Christian Borntraeger1-0/+1
Using "make kvmconfig" results in a potentially unusable linux image on s390. The reason is that both the (default on s390) sclp consoles as well as the 8250 console register a ttyS<x> as console. Since there will be no 8250 on s390 let's fence 8250. This will ensure that there is always a working sclp console. Reported-by: Alice Frosi <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Reviewed-by: Hendrik Brueckner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-12-11Merge 4.15-rc3 into tty-nextGreg Kroah-Hartman3-9/+34
We want the serial/tty fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-11-28the rest of drivers/*: annotate ->poll() instancesAl Viro6-15/+15
Signed-off-by: Al Viro <[email protected]>
2017-11-28serial: imx: Support common rs485 binding for RTS polarityLukas Wunner1-0/+6
Invoke the ->rs485_config callback on probe to adjust the initial RTS polarity based on the UART's device properties. This implicitly fixes a bug: If RTS control is not available, rs485 should be disabled even if it was enabled through a device property. Log an error when that occurs. Cc: Sascha Hauer <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-11-28serial: fsl_lpuart: Support common rs485 binding for RTS polarityLukas Wunner1-10/+3
Invoke the ->rs485_config callback on probe to set UARTMODEM_TXRTSPOL appropriately based on the UART's device properties. This implicitly sets UARTMODEM_TXRTSE if rs485 was enabled in the device properties, so drop the identical code from lpuart_probe(). It also fixes a bug: If an unsupported rs485 property was specified (rs485-rx-during-tx or rs485-rts-delay), the driver returns -ENOSYS without performing any cleanup, in particular without calling uart_remove_one_port() or clk_disable_unprepare(), thus leaking the uart_port. But with the invocation of ->rs485_config, the unsupported properties are now cleared in struct serial_rs485 and thus ignored. It therefore seems sufficient to just log an error instead of bailing out. Cc: Sascha Hauer <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.