summaryrefslogtreecommitdiff
path: root/drivers/tty
AgeCommit message (Collapse)AuthorFilesLines
2016-11-21Merge tag 'v4.4.33' into dev-4.4openbmc-4.4-20161121-1dev-4.4Joel Stanley3-6/+30
This is the 4.4.33 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2016-11-18tty/serial: at91: fix hardware handshake on Atmel platformsRichard Genoud1-4/+23
commit 9bcffe7575b721d7b6d9b3090fe18809d9806e78 upstream. After commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled"), the hardware handshake wasn't functional anymore on Atmel platforms (beside SAMA5D2). To understand why, one has to understand the flag ATMEL_US_USMODE_HWHS first: Before commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled"), this flag was never set. Thus, the CTS/RTS where only handled by serial_core (and everything worked just fine). This commit introduced the use of the ATMEL_US_USMODE_HWHS flag, enabling it for all boards when the user space enables flow control. When the ATMEL_US_USMODE_HWHS is set, the Atmel USART controller handles a part of the flow control job: - disable the transmitter when the CTS pin gets high. - drive the RTS pin high when the DMA buffer transfer is completed or PDC RX buffer full or RX FIFO is beyond threshold. (depending on the controller version). NB: This feature is *not* mandatory for the flow control to work. (Nevertheless, it's very useful if low latencies are needed.) Now, the specifics of the ATMEL_US_USMODE_HWHS flag: - For platforms with DMAC and no FIFOs (sam9x25, sam9x35, sama5D3, sama5D4, sam9g15, sam9g25, sam9g35)* this feature simply doesn't work. ( source: https://lkml.org/lkml/2016/9/7/598 ) Tested it on sam9g35, the RTS pins always stays up, even when RXEN=1 or a new DMA transfer descriptor is set. => ATMEL_US_USMODE_HWHS must not be used for those platforms - For platforms with a PDC (sam926{0,1,3}, sam9g10, sam9g20, sam9g45, sam9g46)*, there's another kind of problem. Once the flag ATMEL_US_USMODE_HWHS is set, the RTS pin can't be driven anymore via RTSEN/RTSDIS in USART Control Register. The RTS pin can only be driven by enabling/disabling the receiver or setting RCR=RNCR=0 in the PDC (Receive (Next) Counter Register). => Doing this is beyond the scope of this patch and could add other bugs, so the original (and working) behaviour should be set for those platforms (meaning ATMEL_US_USMODE_HWHS flag should be unset). - For platforms with a FIFO (sama5d2)*, the RTS pin is driven according to the RX FIFO thresholds, and can be also driven by RTSEN/RTSDIS in USART Control Register. No problem here. (This was the use case of commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")) NB: If the CTS pin declared as a GPIO in the DTS, (for instance cts-gpios = <&pioA PIN_PB31 GPIO_ACTIVE_LOW>), the transmitter will be disabled. => ATMEL_US_USMODE_HWHS flag can be set for this platform ONLY IF the CTS pin is not a GPIO. So, the only case when ATMEL_US_USMODE_HWHS can be enabled is when (atmel_use_fifo(port) && !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) Tested on all Atmel USART controller flavours: AT91SAM9G35-CM (DMAC flavour), AT91SAM9G20-EK (PDC flavour), SAMA5D2xplained (FIFO flavour). * the list may not be exhaustive Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled") Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [nicolas.ferre@atmel.com: adapt to 4.4.x kernel for stable by adding the atmel_port variable declaration which was missing] Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-10tty: vt, fix bogus division in csi_JJiri Slaby1-1/+1
commit 42acfc6615f47e465731c263bee0c799edb098f2 upstream. In csi_J(3), the third parameter of scr_memsetw (vc_screenbuf_size) is divided by 2 inappropriatelly. But scr_memsetw expects size, not count, because it divides the size by 2 on its own before doing actual memset-by-words. So remove the bogus division. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Petr Písař <ppisar@redhat.com> Fixes: f8df13e0a9 (tty: Clean console safely) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-10tty: limit terminal size to 4M charsDmitry Vyukov1-0/+2
commit 32b2921e6a7461fe63b71217067a6cf4bddb132f upstream. Size of kmalloc() in vc_do_resize() is controlled by user. Too large kmalloc() size triggers WARNING message on console. Put a reasonable upper bound on terminal size to prevent WARNINGs. Signed-off-by: Dmitry Vyukov <dvyukov@google.com> CC: David Rientjes <rientjes@google.com> Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: linux-kernel@vger.kernel.org Cc: syzkaller@googlegroups.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-10vt: clear selection before resizingScot Doyle1-0/+3
commit 009e39ae44f4191188aeb6dfbf661b771dbbe515 upstream. When resizing a vt its selection may exceed the new size, resulting in an invalid memory access [1]. Clear the selection before resizing. [1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Scot Doyle <lkml14@scotdoyle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-22serial: 8250_dw: Check the data->pclk when get apb_pclkKefeng Wang1-1/+1
commit e16b46f190a22587898b331f9d58583b0b166c9a upstream. It should check the data->pclk, not data->clk when get apb_pclk. Fixes: c8ed99d4f6a8("serial: 8250_dw: Add support for deferred probing") Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-21Merge tag 'v4.4.26' into dev-4.4Joel Stanley5-12/+164
This is the 4.4.26 stable release
2016-09-24serial: 8250: added acces i/o products quad and octal serial cardsJimi Damon1-0/+139
commit c8d192428f52f244130b84650ad616df09f2b1e1 upstream. Added devices ids for acces i/o products quad and octal serial cards that make use of existing Pericom PI7C9X7954 and PI7C9X7958 configurations . Signed-off-by: Jimi Damon <jdamon@accesio.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-24serial: 8250_mid: fix divide error bug if baud rate is 0Andy Shevchenko1-0/+3
commit 47b34d2ef266e2c283b514d65c8963c2ccd42474 upstream. Since the commit c1a67b48f6a5 ("serial: 8250_pci: replace switch-case by formula for Intel MID"), the 8250 driver crashes in the byt_set_termios() function with a divide error. This is caused by the fact that a baud rate of 0 (B0) is not handled properly. Fix it by falling back to B9600 in this case. Reported-by: "Mendez Salinas, Fernando" <fernando.mendez.salinas@intel.com> Fixes: c1a67b48f6a5 ("serial: 8250_pci: replace switch-case by formula for Intel MID") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-20tty/serial: atmel: fix RS485 half duplex with DMAAlexandre Belloni1-6/+8
commit 0058f0871efe7b01c6f2b3046c68196ab73e96da upstream. When using DMA, half duplex doesn't work properly because rx is not stopped before starting tx. Ensure we call atmel_stop_rx() in the DMA case. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-20serial: samsung: Fix ERR pointer dereference on deferred probeKrzysztof Kozlowski1-5/+13
commit e51e4d8a185de90424b03f30181b35f29c46a25a upstream. When the clk_get() of "uart" clock returns EPROBE_DEFER, the next re-probe finishes with success but uses invalid (ERR_PTR) values. This leads to dereferencing of ERR_PTR stored under ourport->clk: 12c30000.serial: Controller clock not found (...) 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 61, base_baud = 0) is a S3C6400/10 Unable to handle kernel paging request at virtual address fffffdfb (clk_prepare) from [<c039f7d0>] (s3c24xx_serial_pm+0x20/0x128) (s3c24xx_serial_pm) from [<c0395414>] (uart_change_pm+0x38/0x40) (uart_change_pm) from [<c039689c>] (uart_add_one_port+0x31c/0x44c) (uart_add_one_port) from [<c03a035c>] (s3c24xx_serial_probe+0x2a8/0x418) (s3c24xx_serial_probe) from [<c03ee110>] (platform_drv_probe+0x50/0xb0) (platform_drv_probe) from [<c03ecb44>] (driver_probe_device+0x1f4/0x2b0) (driver_probe_device) from [<c03eb0c0>] (bus_for_each_drv+0x44/0x8c) (bus_for_each_drv) from [<c03ec8c8>] (__device_attach+0x9c/0x100) (__device_attach) from [<c03ebf54>] (bus_probe_device+0x84/0x8c) (bus_probe_device) from [<c03ec388>] (deferred_probe_work_func+0x60/0x8c) (deferred_probe_work_func) from [<c012fee4>] (process_one_work+0x120/0x328) (process_one_work) from [<c0130150>] (worker_thread+0x2c/0x4ac) (worker_thread) from [<c0135320>] (kthread+0xd8/0xf4) (kthread) from [<c0107978>] (ret_from_fork+0x14/0x3c) The first unsuccessful clk_get() causes s3c24xx_serial_init_port() to exit with failure but the s3c24xx_uart_port is left half-configured (e.g. port->mapbase is set, clk contains ERR_PTR). On next re-probe, the function s3c24xx_serial_init_port() will exit early with success because of configured port->mapbase and driver will use old values, including the ERR_PTR as clock. Fix this by cleaning the port->mapbase on error path so each re-probe will initialize all of the port settings. Fixes: 60e93575476f ("serial: samsung: enable clock before clearing pending interrupts during init") Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-20tty: serial: msm: Don't read off end of tx fifoBjorn Andersson1-1/+1
commit 30acf549ca1e81859a67590ab9ecfce3d1050a0b upstream. For dm uarts in pio mode tx data is transferred to the fifo register 4 bytes at a time, but care is not taken when these 4 bytes spans the end of the xmit buffer so the loop might read up to 3 bytes past the buffer and then skip the actual data at the beginning of the buffer. Fix this by, analogous to the DMA case, make sure the chunk doesn't wrap the xmit buffer. Fixes: 3a878c430fd6 ("tty: serial: msm: Add TX DMA support") Cc: Ivan Ivanov <iivanov.xz@gmail.com> Reported-by: Frank Rowand <frowand.list@gmail.com> Reported-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Andy Gross <andy.gross@linaro.org> Tested-by: Frank Rowand <frank.rowand@am.sony.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-19Merge tag 'v4.4.18' into dev-4.4openbmc-4.4-20160819-1Joel Stanley1-33/+30
This is the 4.4.18 stable release Signed-off-by: Joel Stanley <joel@jms.du.au>
2016-08-16devpts: clean up interface to pty driversLinus Torvalds1-33/+30
commit 67245ff332064c01b760afa7a384ccda024bfd24 upstream. This gets rid of the horrible notion of having that struct inode *ptmx_inode be the linchpin of the interface between the pty code and devpts. By de-emphasizing the ptmx inode, a lot of things actually get cleaner, and we will have a much saner way forward. In particular, this will allow us to associate with any particular devpts instance at open-time, and not be artificially tied to one particular ptmx inode. The patch itself is actually fairly straightforward, and apart from some locking and return path cleanups it's pretty mechanical: - the interfaces that devpts exposes all take "struct pts_fs_info *" instead of "struct inode *ptmx_inode" now. NOTE! The "struct pts_fs_info" thing is a completely opaque structure as far as the pty driver is concerned: it's still declared entirely internally to devpts. So the pty code can't actually access it in any way, just pass it as a "cookie" to the devpts code. - the "look up the pts fs info" is now a single clear operation, that also does the reference count increment on the pts superblock. So "devpts_add/del_ref()" is gone, and replaced by a "lookup and get ref" operation (devpts_get_ref(inode)), along with a "put ref" op (devpts_put_ref()). - the pty master "tty->driver_data" field now contains the pts_fs_info, not the ptmx inode. - because we don't care about the ptmx inode any more as some kind of base index, the ref counting can now drop the inode games - it just gets the ref on the superblock. - the pts_fs_info now has a back-pointer to the super_block. That's so that we can easily look up the information we actually need. Although quite often, the pts fs info was actually all we wanted, and not having to look it up based on some magical inode makes things more straightforward. In particular, now that "devpts_get_ref(inode)" operation should really be the *only* place we need to look up what devpts instance we're associated with, and we do it exactly once, at ptmx_open() time. The other side of this is that one ptmx node could now be associated with multiple different devpts instances - you could have a single /dev/ptmx node, and then have multiple mount namespaces with their own instances of devpts mounted on /dev/pts/. And that's all perfectly sane in a model where we just look up the pts instance at open time. This will eventually allow us to get rid of our odd single-vs-multiple pts instance model, but this patch in itself changes no semantics, only an internal binding model. Cc: Eric Biederman <ebiederm@xmission.com> Cc: Peter Anvin <hpa@zytor.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Cc: Jann Horn <jann@thejh.net> Cc: Greg KH <greg@kroah.com> Cc: Jiri Slaby <jslaby@suse.com> Cc: Florian Weimer <fw@deneb.enyo.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Francesco Ruggeri <fruggeri@arista.com> Cc: "Herton R. Krzesinski" <herton@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-04Merge tag 'v4.4.16' into dev-4.4openbmc-4.4-20160804-1Joel Stanley2-21/+10
This is the 4.4.16 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2016-07-27tty/vt/keyboard: fix OOB access in do_compute_shiftstate()Dmitry Torokhov1-21/+9
commit 510cccb5b0c8868a2b302a0ab524da7912da648b upstream. The size of individual keymap in drivers/tty/vt/keyboard.c is NR_KEYS, which is currently 256, whereas number of keys/buttons in input device (and therefor in key_down) is much larger - KEY_CNT - 768, and that can cause out-of-bound access when we do sym = U(key_maps[0][k]); with large 'k'. To fix it we should not attempt iterating beyond smaller of NR_KEYS and KEY_CNT. Also while at it let's switch to for_each_set_bit() instead of open-coding it. Reported-by: Sasha Levin <sasha.levin@oracle.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-07-27tty: vt: Fix soft lockup in fbcon cursor blink timer.David Daney1-0/+1
commit 1b45996d2ebf9680ccd0db875fc668aa025f40fd upstream. We are getting somewhat random soft lockups with this signature: [ 86.992215] [<fffffc00080935e0>] el1_irq+0xa0/0x10c [ 86.997082] [<fffffc000841822c>] cursor_timer_handler+0x30/0x54 [ 87.002991] [<fffffc000810ec44>] call_timer_fn+0x54/0x1a8 [ 87.008378] [<fffffc000810ef88>] run_timer_softirq+0x1c4/0x2bc [ 87.014200] [<fffffc000809077c>] __do_softirq+0x114/0x344 [ 87.019590] [<fffffc00080af45c>] irq_exit+0x74/0x98 [ 87.024458] [<fffffc00080fac20>] __handle_domain_irq+0x98/0xfc [ 87.030278] [<fffffc000809056c>] gic_handle_irq+0x94/0x190 This is caused by the vt visual_init() function calling into fbcon_init() with a vc_cur_blink_ms value of zero. This is a transient condition, as it is later set to a non-zero value. But, if the timer happens to expire while the blink rate is zero, it goes into an endless loop, and we get soft lockup. The fix is to initialize vc_cur_blink_ms before calling the con_init() function. Signed-off-by: David Daney <david.daney@cavium.com> Acked-by: Pavel Machek <pavel@ucw.cz> Tested-by: Ming Lei <ming.lei@canonical.com> Acked-by: Scot Doyle <lkml14@scotdoyle.com> Tested-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-07-22Merge tag 'v4.4.15' into dev-4.4Joel Stanley1-0/+3
This is the 4.4.15 stable release
2016-06-08QE-UART: add "fsl,t1040-ucc-uart" to of_device_idZhao Qiang1-0/+3
commit 11ca2b7ab432eb90906168c327733575e68d388f upstream. New bindings use "fsl,t1040-ucc-uart" as the compatible for qe-uart. So add it. Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-03Merge tag 'v4.4.12' into dev-4.4Joel Stanley10-89/+88
This is the 4.4.12 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2016-06-01serial: samsung: Reorder the sequence of clock control when call ↵Chanwoo Choi1-2/+2
s3c24xx_serial_set_termios() commit b8995f527aac143e83d3900ff39357651ea4e0f6 upstream. This patch fixes the broken serial log when changing the clock source of uart device. Before disabling the original clock source, this patch enables the new clock source to protect the clock off state for a split second. Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
2016-06-01serial: 8250_mid: recognize interrupt source in handlerAndy Shevchenko1-10/+11
commit c42850f1ae7e70056f852e67bb9dddf927853b47 upstream. There is a special register that shows interrupt status by source. In particular case the source can be a combination of DMA Tx, DMA Rx, and UART. Read the register and call the handlers only for sources that request an interrupt. Fixes: 6ede6dcd87aa ("serial: 8250_mid: add support for DMA engine handling from UART MMIO") Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-01serial: 8250_mid: use proper bar for DNV platformAndy Shevchenko1-3/+11
commit 107e15fc1f8d6ef69eac5f175971252f76e82f0d upstream. Unlike Intel Medfield and Tangier platforms DNV uses PCI BAR0 for IO compatible resources and BAR1 for MMIO. We need latter in a way to support DMA. Introduce an additional field in the internal structure and pass PCI BAR based on device ID. Reported-by: "Lai, Poey Seng" <poey.seng.lai@intel.com> Fixes: 6ede6dcd87aa ("serial: 8250_mid: add support for DMA engine handling from UART MMIO") Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-01serial: 8250_pci: fix divide error bug if baud rate is 0David Müller1-0/+3
commit 6f210c18c1c0f016772c8cd51ae12a02bfb9e7ef upstream. Since commit 21947ba654a6 ("serial: 8250_pci: replace switch-case by formula"), the 8250 driver crashes in the byt_set_termios() function with a divide error. This is caused by the fact that a baud rate of 0 (B0) is not handled properly. Fix it by falling back to B9600 in this case. Signed-off-by: David Müller <d.mueller@elsoft.ch> Fixes: 21947ba654a6 ("serial: 8250_pci: replace switch-case by formula") Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-01Fix OpenSSH pty regression on closeBrian Bloniarz4-70/+42
commit 0f40fbbcc34e093255a2b2d70b6b0fb48c3f39aa upstream. OpenSSH expects the (non-blocking) read() of pty master to return EAGAIN only if it has received all of the slave-side output after it has received SIGCHLD. This used to work on pre-3.12 kernels. This fix effectively forces non-blocking read() and poll() to block for parallel i/o to complete for all ttys. It also unwinds these changes: 1) f8747d4a466ab2cafe56112c51b3379f9fdb7a12 tty: Fix pty master read() after slave closes 2) 52bce7f8d4fc633c9a9d0646eef58ba6ae9a3b73 pty, n_tty: Simplify input processing on final close 3) 1a48632ffed61352a7810ce089dc5a8bcd505a60 pty: Fix input race when closing Inspired by analysis and patch from Marc Aurele La France <tsi@tuyoix.net> Reported-by: Volth <openssh@volth.com> Reported-by: Marc Aurele La France <tsi@tuyoix.net> BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=52 BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=2492 Signed-off-by: Brian Bloniarz <brian.bloniarz@gmail.com> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-01tty/serial: atmel: fix hardware handshake selectionAlexandre Belloni1-1/+13
commit 5be605ac9af979265d7b64c160ad9928088a78be upstream. Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled") actually allowed to enable hardware handshaking. Before, the CRTSCTS flags was silently ignored. As the DMA controller can't drive RTS (as explain in the commit message). Ensure that hardware flow control stays disabled when DMA is used and FIFOs are not available. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-01TTY: n_gsm, fix false positive WARN_ONJiri Slaby1-1/+3
commit d175feca89a1c162f60f4e3560ca7bc9437c65eb upstream. Dmitry reported, that the current cleanup code in n_gsm can trigger a warning: WARNING: CPU: 2 PID: 24238 at drivers/tty/n_gsm.c:2048 gsm_cleanup_mux+0x166/0x6b0() ... Call Trace: ... [<ffffffff81247ab9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:490 [<ffffffff828d0456>] gsm_cleanup_mux+0x166/0x6b0 drivers/tty/n_gsm.c:2048 [<ffffffff828d4d87>] gsmld_open+0x5b7/0x7a0 drivers/tty/n_gsm.c:2386 [<ffffffff828b9078>] tty_ldisc_open.isra.2+0x78/0xd0 drivers/tty/tty_ldisc.c:447 [<ffffffff828b973a>] tty_set_ldisc+0x1ca/0xa70 drivers/tty/tty_ldisc.c:567 [< inline >] tiocsetd drivers/tty/tty_io.c:2650 [<ffffffff828a14ea>] tty_ioctl+0xb2a/0x2140 drivers/tty/tty_io.c:2883 ... But this is a legal path when open fails to find a space in the gsm_mux array and tries to clean up. So make it a standard test instead of a warning. Reported-by: "Dmitry Vyukov" <dvyukov@google.com> Cc: Alan Cox <alan@linux.intel.com> Link: http://lkml.kernel.org/r/CACT4Y+bHQbAB68VFi7Romcs-Z9ZW3kQRvcq+BvHH1oa5NcAdLA@mail.gmail.com Fixes: 5a640967 ("tty/n_gsm.c: fix a memory leak in gsmld_open()") Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-01tty: vt, return error when con_startup failsJiri Slaby1-2/+3
commit 6798df4c5fe0a7e6d2065cf79649a794e5ba7114 upstream. When csw->con_startup() fails in do_register_con_driver, we return no error (i.e. 0). This was changed back in 2006 by commit 3e795de763. Before that we used to return -ENODEV. So fix the return value to be -ENODEV in that case again. Fixes: 3e795de763 ("VT binding: Add binding/unbinding support for the VT console") Signed-off-by: Jiri Slaby <jslaby@suse.cz> Reported-by: "Dan Carpenter" <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-05-05Merge tag 'v4.4.9' into dev-4.4Joel Stanley2-51/+6
This is the 4.4.9 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2016-05-05serial: sh-sci: Remove cpufreq notifier to fix crash/deadlockGeert Uytterhoeven1-39/+0
commit ff1cab374ad98f4b9f408525ca9c08992b4ed784 upstream. The BSP team noticed that there is spin/mutex lock issue on sh-sci when CPUFREQ is used. The issue is that the notifier function may call mutex_lock() while the spinlock is held, which can lead to a BUG(). This may happen if CPUFREQ is changed while another CPU calls clk_get_rate(). Taking the spinlock was added to the notifier function in commit e552de2413edad1a ("sh-sci: add platform device private data"), to protect the list of serial ports against modification during traversal. At that time the Common Clock Framework didn't exist yet, and clk_get_rate() just returned clk->rate without taking a mutex. Note that since commit d535a2305facf9b4 ("serial: sh-sci: Require a device per port mapping."), there's no longer a list of serial ports to traverse, and taking the spinlock became superfluous. To fix the issue, just remove the cpufreq notifier: 1. The notifier doesn't work correctly: all it does is update stored clock rates; it does not update the divider in the hardware. The divider will only be updated when calling sci_set_termios(). I believe this was broken back in 2004, when the old drivers/char/sh-sci.c driver (where the notifier did update the divider) was replaced by drivers/serial/sh-sci.c (where the notifier just updated port->uartclk). Cfr. full-history-linux commits 6f8deaef2e9675d9 ("[PATCH] sh: port sh-sci driver to the new API") and 3f73fe878dc9210a ("[PATCH] Remove old sh-sci driver"). 2. On modern SoCs, the sh-sci parent clock rate is no longer related to the CPU clock rate anyway, so using a cpufreq notifier is futile. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-128250: use callbacks to access UART_DLL/UART_DLMSebastian Frias1-12/+6
commit 0b41ce991052022c030fd868e03877700220b090 upstream. Some UART HW has a single register combining UART_DLL/UART_DLM (this was probably forgotten in the change that introduced the callbacks, commit b32b19b8ffc05cbd3bf91c65e205f6a912ca15d9) Fixes: b32b19b8ffc0 ("[SERIAL] 8250: set divisor register correctly ...") Signed-off-by: Sebastian Frias <sf84@laposte.net> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-21drivers/serial: Add driver for Aspeed virtual UARTJeremy Kerr3-0/+344
This change adds a driver for the 16550-based Aspeed virtual UART device. We use a similar process to the of_serial driver for device probe, but expose some VUART-specific functions through sysfs too. If host TX discard mode is enabled, we don't see the LSR[RBR} bit getting set on new characters written on the host side. This makes the VUART a little useless. OpenPOWER firmware doesn't like it when the host-side of the VUART's FIFO is not drained. This change only disables host TX discard mode when the port is in use. We set the VUART enabled bit when we bind to the device, and clear it on unbind. We don't want to do this on open/release, as the host may be using this bit to configure serial output modes, which is independent of whether the devices has been opened by BMC userspace. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Joel Stanley <joel@jms.id.au>
2016-02-25serial: omap: Prevent DoS using unprivileged ioctl(TIOCSRS485)Peter Hurley1-2/+6
commit 308bbc9ab838d0ace0298268c7970ba9513e2c65 upstream. The omap-serial driver emulates RS485 delays using software timers, but neglects to clamp the input values from the unprivileged ioctl(TIOCSRS485). Because the software implementation busy-waits, malicious userspace could stall the cpu for ~49 days. Clamp the input values to < 100ms. Fixes: 4a0ac0f55b18 ("OMAP: add RS485 support") Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25serial: 8250_pci: Add Intel Broadwell portsMika Westerberg1-0/+29
commit 6c55d9b98335f7f6bd5f061866ff1633401f3a44 upstream. Some recent (early 2015) macbooks have Intel Broadwell where LPSS UARTs are PCI enumerated instead of ACPI. The LPSS UART block is pretty much same as used on Intel Baytrail so we can reuse the existing Baytrail setup code. Add both Broadwell LPSS UART ports to the list of supported devices. Signed-off-by: Leif Liddy <leif.liddy@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25tty: Add support for PCIe WCH382 2S multi-IO cardJeremy McNicoll1-0/+21
commit 7dde55787b43a8f2b4021916db38d90c03a2ec64 upstream. WCH382 2S board is a PCIe card with 2 DB9 COM ports detected as Serial controller: Device 1c00:3253 (rev 10) (prog-if 05 [16850]) Signed-off-by: Jeremy McNicoll <jmcnicol@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25pty: make sure super_block is still valid in final /dev/tty closeHerton R. Krzesinski1-3/+6
commit 1f55c718c290616889c04946864a13ef30f64929 upstream. Considering current pty code and multiple devpts instances, it's possible to umount a devpts file system while a program still has /dev/tty opened pointing to a previosuly closed pty pair in that instance. In the case all ptmx and pts/N files are closed, umount can be done. If the program closes /dev/tty after umount is done, devpts_kill_index will use now an invalid super_block, which was already destroyed in the umount operation after running ->kill_sb. This is another "use after free" type of issue, but now related to the allocated super_block instance. To avoid the problem (warning at ida_remove and potential crashes) for this specific case, I added two functions in devpts which grabs additional references to the super_block, which pty code now uses so it makes sure the super block structure is still valid until pty shutdown is done. I also moved the additional inode references to the same functions, which also covered similar case with inode being freed before /dev/tty final close/shutdown. Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25pty: fix possible use after free of tty->driver_dataHerton R. Krzesinski1-1/+17
commit 2831c89f42dcde440cfdccb9fee9f42d54bbc1ef upstream. This change fixes a bug for a corner case where we have the the last release from a pty master/slave coming from a previously opened /dev/tty file. When this happens, the tty->driver_data can be stale, due to all ptmx or pts/N files having already been closed before (and thus the inode related to these files, which tty->driver_data points to, being already freed/destroyed). The fix here is to keep a reference on the opened master ptmx inode. We maintain the inode referenced until the final pty_unix98_shutdown, and only pass this inode to devpts_kill_index. Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-17tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)Peter Hurley1-1/+23
commit 5c17c861a357e9458001f021a7afa7aab9937439 upstream. ioctl(TIOCGETD) retrieves the line discipline id directly from the ldisc because the line discipline id (c_line) in termios is untrustworthy; userspace may have set termios via ioctl(TCSETS*) without actually changing the line discipline via ioctl(TIOCSETD). However, directly accessing the current ldisc via tty->ldisc is unsafe; the ldisc ptr dereferenced may be stale if the line discipline is changing via ioctl(TIOCSETD) or hangup. Wait for the line discipline reference (just like read() or write()) to retrieve the "current" line discipline id. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-17tty: Retry failed reopen if tty teardown in-progressPeter Hurley1-4/+8
commit 7f22f6c935cda600660e623a411fe380015d28d9 upstream. A small window exists where a tty reopen will observe the tty just prior to imminent teardown (tty->count == 0); in this case, open() returns EIO to userspace. Instead, retry the open after checking for signals and yielding; this interruptible retry loop allows teardown to commence and initialize a new tty on retry. Never retry the BSD master pty reopen; there is no guarantee the pty pair teardown is imminent since the slave file descriptors may remain open indefinitely. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-17tty: Wait interruptibly for tty lock on reopenPeter Hurley2-1/+15
commit 0bfd464d3fdd5bb322f9cace4cc47f1796545cf7 upstream. Allow a signal to interrupt the wait for a tty reopen; eg., if the tty has starting final close and is waiting for the device to drain. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-17n_tty: Fix unsafe reference to "other" ldiscPeter Hurley1-5/+2
commit 6d27a63caad3f13e96cf065d2d96828c2006be6b upstream. Although n_tty_check_unthrottle() has a valid ldisc reference (since the tty core gets the ldisc ref in tty_read() before calling the line discipline read() method), it does not have a valid ldisc reference to the "other" pty of a pty pair. Since getting an ldisc reference for tty->link essentially open-codes tty_wakeup(), just replace with the equivalent tty_wakeup(). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds1-5/+7
Pull sparc fixes from David Miller: 1) Finally make perf stack backtraces stable on sparc, several problems (mostly due to the context in which the user copies from the stack are done) contributed to this. From Rob Gardner. 2) Export ADI capability if the cpu supports it. 3) Hook up userfaultfd system call. 4) When faults happen during user copies we really have to clean up and restore the FPU state fully. Also from Rob Gardner * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: tty/serial: Skip 'NULL' char after console break when sysrq enabled sparc64: fix FP corruption in user copy functions sparc64: Perf should save/restore fault info sparc64: Ensure perf can access user stacks sparc64: Don't set %pil in rtrap_nmi too early sparc64: Add ADI capability to cpu capabilities tty: serial: constify sunhv_ops structs sparc: Hook up userfaultfd system call
2015-12-24tty/serial: Skip 'NULL' char after console break when sysrq enabledVijay Kumar1-2/+4
When sysrq is triggered from console, serial driver for SUN hypervisor console receives a console break and enables the sysrq. It expects a valid sysrq char following with break. Meanwhile if driver receives 'NULL' ASCII char then it disables sysrq and sysrq handler will never be invoked. This fix skips calling uart sysrq handler when 'NULL' is received while sysrq is enabled. Signed-off-by: Vijay Kumar <vijay.ac.kumar@oracle.com> Acked-by: Karl Volz <karl.volz@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-24tty: serial: constify sunhv_ops structsAya Mahfouz1-3/+3
Constifies sunhv_ops structures in tty's serial driver since they are not modified after their initialization. Detected and found using Coccinelle. Suggested-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Aya Mahfouz <mahfouz.saif.elyazal@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-13tty: Fix GPF in flush_to_ldisc()Peter Hurley1-1/+1
A line discipline which does not define a receive_buf() method can can cause a GPF if data is ever received [1]. Oddly, this was known to the author of n_tracesink in 2011, but never fixed. [1] GPF report BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) PGD 3752d067 PUD 37a7b067 PMD 0 Oops: 0010 [#1] SMP KASAN Modules linked in: CPU: 2 PID: 148 Comm: kworker/u10:2 Not tainted 4.4.0-rc2+ #51 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: events_unbound flush_to_ldisc task: ffff88006da94440 ti: ffff88006db60000 task.ti: ffff88006db60000 RIP: 0010:[<0000000000000000>] [< (null)>] (null) RSP: 0018:ffff88006db67b50 EFLAGS: 00010246 RAX: 0000000000000102 RBX: ffff88003ab32f88 RCX: 0000000000000102 RDX: 0000000000000000 RSI: ffff88003ab330a6 RDI: ffff88003aabd388 RBP: ffff88006db67c48 R08: ffff88003ab32f9c R09: ffff88003ab31fb0 R10: ffff88003ab32fa8 R11: 0000000000000000 R12: dffffc0000000000 R13: ffff88006db67c20 R14: ffffffff863df820 R15: ffff88003ab31fb8 FS: 0000000000000000(0000) GS:ffff88006dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000037938000 CR4: 00000000000006e0 Stack: ffffffff829f46f1 ffff88006da94bf8 ffff88006da94bf8 0000000000000000 ffff88003ab31fb0 ffff88003aabd438 ffff88003ab31ff8 ffff88006430fd90 ffff88003ab32f9c ffffed0007557a87 1ffff1000db6cf78 ffff88003ab32078 Call Trace: [<ffffffff8127cf91>] process_one_work+0x8f1/0x17a0 kernel/workqueue.c:2030 [<ffffffff8127df14>] worker_thread+0xd4/0x1180 kernel/workqueue.c:2162 [<ffffffff8128faaf>] kthread+0x1cf/0x270 drivers/block/aoe/aoecmd.c:1302 [<ffffffff852a7c2f>] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:468 Code: Bad RIP value. RIP [< (null)>] (null) RSP <ffff88006db67b50> CR2: 0000000000000000 ---[ end trace a587f8947e54d6ea ]--- Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-13serial: earlycon: Add missing spinlock initializationGeert Uytterhoeven1-0/+2
If an earlycon console driver needs to acquire the uart_port.lock spinlock for serial console output, and CONFIG_DEBUG_SPINLOCK=y: BUG: spinlock bad magic on CPU#0, swapper/0 lock: sci_ports+0x0/0x3480, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-rc2-koelsch-g62ea5edf143bb1d0-dirty #2083 Hardware name: Generic R8A7791 (Flattened Device Tree) [<c00173a0>] (unwind_backtrace) from [<c0013094>] (show_stack+0x10/0x14) [<c0013094>] (show_stack) from [<c01f2338>] (dump_stack+0x70/0x8c) [<c01f2338>] (dump_stack) from [<c00702d8>] (do_raw_spin_lock+0x20/0x190) [<c00702d8>] (do_raw_spin_lock) from [<c0267590>] (serial_console_write+0x4c/0x130) [<c0267590>] (serial_console_write) from [<c00734c4>] (call_console_drivers.constprop.13+0xc8/0xec) [<c00734c4>] (call_console_drivers.constprop.13) from [<c0074ef0>] (console_unlock+0x354/0x440) [<c0074ef0>] (console_unlock) from [<c0075bb4>] (register_console+0x2a0/0x394) [<c0075bb4>] (register_console) from [<c06cb750>] (of_setup_earlycon+0x90/0xa4) [<c06cb750>] (of_setup_earlycon) from [<c06cfb60>] (setup_of_earlycon+0x118/0x13c) [<c06cfb60>] (setup_of_earlycon) from [<c06b34ac>] (do_early_param+0x64/0xb4) [<c06b34ac>] (do_early_param) from [<c00472c0>] (parse_args+0x254/0x350) [<c00472c0>] (parse_args) from [<c06b3860>] (parse_early_options+0x2c/0x3c) [<c06b3860>] (parse_early_options) from [<c06b389c>] (parse_early_param+0x2c/0x40) [<c06b389c>] (parse_early_param) from [<c06b5b08>] (setup_arch+0x520/0xaf0) [<c06b5b08>] (setup_arch) from [<c06b3948>] (start_kernel+0x94/0x370) [<c06b3948>] (start_kernel) from [<40008090>] (0x40008090) Initialize the spinlock in of_setup_earlycon() and register_earlycon(), to fix this for both DT-based and legacy earlycon. If the driver would reinitialize the spinlock again, this is harmless, as it's allowed to reinitialize an unlocked spinlock. Alternatives are: - Drivers having an early_serial_console_write() that only performs the core functionality of serial_console_write(), without acquiring the lock (which may be unsafe, depending on the hardware), - Drivers initializing the spinlock in their private earlycon setup functions. As uart_port is owned by generic serial_core, and uart_port.lock is initialized by uart_add_one_port() for the normal case, this can better be handled in the earlycon core. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Reported-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-13serial: sh-sci: Fix length of scatterlistYoshihiro Shimoda1-1/+1
This patch fixes an issue that the "length" of scatterlist should be set using sg_dma_len(). Otherwise, a dmaengine driver cannot work correctly if CONFIG_NEED_SG_DMA_LENGTH=y. Fixes: 7b39d90184 (serial: sh-sci: Fix NULL pointer dereference if HIGHMEM is enabled) Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-13n_tty: Fix poll() after buffer-limited eof push readPeter Hurley1-13/+9
commit 40d5e0905a03 ("n_tty: Fix EOF push handling") fixed EOF push for reads. However, that approach still allows a condition mismatch between poll() and read(), where poll() returns POLLIN but read() blocks. This state can happen when a previous read() returned because the user buffer was full and the next character was an EOF not at the beginning of the line. While the next read() will properly identify the condition and advance the read buffer tail without improperly indicating an EOF file condition (ie., read() will not mistakenly return 0), poll() will mistakenly indicate POLLIN. Although a possible solution would be to peek at the input buffer in n_tty_poll(), the better solution in this patch is to eat the EOF during the previous read() (ie., fix the problem by eliminating the condition). The current canon line buffer copy limits the scan for next end-of-line to the smaller of either, a. the remaining user buffer size b. completed lines in the input buffer When the remaining user buffer size is exactly one less than the end-of-line marked by EOF push, the EOF is not scanned nor skipped but left for subsequent reads. In the example below, the scan index 'eol' has stopped at the EOF because it is past the scan limit of 5 (not because it has found the next set bit in read_flags) user buffer [*nr = 5] _ _ _ _ _ read_flags 0 0 0 0 0 1 input buffer h e l l o [EOF] ^ ^ / / tail eol result: found = 0, tail += 5, *nr += 5 Instead, allow the scan to peek ahead 1 byte (while still limiting the scan to completed lines in the input buffer). For the example above, result: found = 1, tail += 6, *nr += 5 Because the scan limit is now bumped +1 byte, when the scan is completed, the tail advance and the user buffer copy limit is re-clamped to *nr when EOF is _not_ found. Fixes: 40d5e0905a03 ("n_tty: Fix EOF push handling") Cc: <stable@vger.kernel.org> # 3.12+ Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-13serial: 8250_uniphier: fix dl_read and dl_write functionsMasahiro Yamada1-2/+6
The register offset must be shifted by regshift, otherwise the baudrate is not set. I missed the issue probably because the divisor register was already set by the boot loader. Fixes: 1a8d2903cb6a ("serial: 8250_uniphier: add UniPhier serial driver") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-21serial: export fsl8250_handle_irqArnd Bergmann1-0/+1
fsl8250_handle_irq is now used by the of_serial driver, and that fails if it is a loadable module: ERROR: "fsl8250_handle_irq" [drivers/tty/serial/of_serial.ko] undefined! This exports the symbol to avoid randconfig errors. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: d43b54d269d2 ("serial: Enable Freescale 16550 workaround on arm") Cc: Scott Wood <scottwood@freescale.com> Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-22 05:20:41 +0300