summaryrefslogtreecommitdiff
path: root/drivers/tty/serial/8250
AgeCommit message (Collapse)AuthorFilesLines
2017-05-18serial: exar: Fix stuck MSIsJan Kiszka1-9/+10
After migrating 8250_exar to MSI in 172c33cb61da, we can get stuck without further interrupts because of the special wake-up event these chips send. They are only cleared by reading INT0. As we fail to do so during startup and shutdown, we can leave the interrupt line asserted, which is fatal with edge-triggered MSIs. Add the required reading of INT0 to startup and shutdown. Also account for the fact that a pending wake-up interrupt means we have to return 1 from exar_handle_irq. Drop the unneeded reading of INT1..3 along with this - those never reset anything. An alternative approach would have been disabling the wake-up interrupt. Unfortunately, this feature (REGB[17] = 1) is not available on the XR17D15X. Fixes: 172c33cb61da ("serial: exar: Enable MSI support") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-18drivers/tty: 8250: only call fintek_8250_probe when doing port I/OArd Biesheuvel1-1/+1
Commit fa01e2ca9f53 ("serial: 8250: Integrate Fintek into 8250_base") modified the probing logic for PNP0501 devices, to remove a collision between the generic 16550A driver and the Fintek driver, which reused the same ACPI _HID. The Fintek device probe is now incorporated into the common 8250 probe path, and gets called for all discovered 16550A compatible devices, including ones that are MMIO mapped rather than IO mapped. However, the Fintek driver assumes the port base is a I/O address, and proceeds to probe some arbitrary offsets above it. This is generally a wrong thing to do, but on ARM systems (having no native port I/O), this may result in faulting accesses of completely unrelated MMIO regions in the PCI I/O space. Given that this is at serial probe time, this results in hard to diagnose crashes at boot. So let's restrict the Fintek probe to devices that we know are using port I/O in the first place. Fixes: fa01e2ca9f53 ("serial: 8250: Integrate Fintek into 8250_base") Suggested-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ricardo Ribalda <ricardo.ribalda@gmail.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-10Merge tag 'hwparam-20170420' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs Pull hw lockdown support from David Howells: "Annotation of module parameters that configure hardware resources including ioports, iomem addresses, irq lines and dma channels. This allows a future patch to prohibit the use of such module parameters to prevent that hardware from being abused to gain access to the running kernel image as part of locking the kernel down under UEFI secure boot conditions. Annotations are made by changing: module_param(n, t, p) module_param_named(n, v, t, p) module_param_array(n, t, m, p) to: module_param_hw(n, t, hwtype, p) module_param_hw_named(n, v, t, hwtype, p) module_param_hw_array(n, t, hwtype, m, p) where the module parameter refers to a hardware setting hwtype specifies the type of the resource being configured. This can be one of: ioport Module parameter configures an I/O port iomem Module parameter configures an I/O mem address ioport_or_iomem Module parameter could be either (runtime set) irq Module parameter configures an I/O port dma Module parameter configures a DMA channel dma_addr Module parameter configures a DMA buffer address other Module parameter configures some other value Note that the hwtype is compile checked, but not currently stored (the lockdown code probably won't require it). It is, however, there for future use. A bonus is that the hwtype can also be used for grepping. The intention is for the kernel to ignore or reject attempts to set annotated module parameters if lockdown is enabled. This applies to options passed on the boot command line, passed to insmod/modprobe or direct twiddling in /sys/module/ parameter files. The module initialisation then needs to handle the parameter not being set, by (1) giving an error, (2) probing for a value or (3) using a reasonable default. What I can't do is just reject a module out of hand because it may take a hardware setting in the module parameters. Some important modules, some ipmi stuff for instance, both probe for hardware and allow hardware to be manually specified; if the driver is aborts with any error, you don't get any ipmi hardware. Further, trying to do this entirely in the module initialisation code doesn't protect against sysfs twiddling. [!] Note that in and of itself, this series of patches should have no effect on the the size of the kernel or code execution - that is left to a patch in the next series to effect. It does mark annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in an already existing field" * tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits) Annotate hardware config module parameters in sound/pci/ Annotate hardware config module parameters in sound/oss/ Annotate hardware config module parameters in sound/isa/ Annotate hardware config module parameters in sound/drivers/ Annotate hardware config module parameters in fs/pstore/ Annotate hardware config module parameters in drivers/watchdog/ Annotate hardware config module parameters in drivers/video/ Annotate hardware config module parameters in drivers/tty/ Annotate hardware config module parameters in drivers/staging/vme/ Annotate hardware config module parameters in drivers/staging/speakup/ Annotate hardware config module parameters in drivers/staging/media/ Annotate hardware config module parameters in drivers/scsi/ Annotate hardware config module parameters in drivers/pcmcia/ Annotate hardware config module parameters in drivers/pci/hotplug/ Annotate hardware config module parameters in drivers/parport/ Annotate hardware config module parameters in drivers/net/wireless/ Annotate hardware config module parameters in drivers/net/wan/ Annotate hardware config module parameters in drivers/net/irda/ Annotate hardware config module parameters in drivers/net/hamradio/ Annotate hardware config module parameters in drivers/net/ethernet/ ...
2017-04-20Annotate hardware config module parameters in drivers/tty/David Howells1-2/+2
When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/tty/. Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: Jiri Slaby <jslaby@suse.com> cc: linux-serial@vger.kernel.org
2017-04-18serial: 8250_early: Add earlycon support for Palmchip UARTMarc Gonzalez2-2/+26
Define an OF early console for Palmchip UART, which can be enabled by passing "earlycon" on the boot command line. Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-03Merge 4.11-rc5 into tty-nextGreg Kroah-Hartman1-2/+6
We want the serial fixes in here as well to handle merge issues. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-31serial: 8250_EXAR: fix duplicate Kconfig text and add missing help textPaul Gortmaker1-2/+6
In commit d0aeaa83f0b0f7a92615bbdd6b1f96812f7dcfd2 ("serial: exar: split out the exar code from 8250_pci") the exar driver got its own Kconfig. However the text for the new option was never changed from the original 8250_PCI text, and hence it appears confusing when you get asked the same question twice: 8250/16550 PCI device support (SERIAL_8250_PCI) [Y/n/m/?] (NEW) 8250/16550 PCI device support (SERIAL_8250_EXAR) [Y/n/m] (NEW) Adding to the confusion, is that there is no help text for this new option to indicate it is specific to a certain family of cards. Fix both issues at the same time, as well as the space vs. tab issues introduced in the same commit. Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci") Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-serial@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-31serial: 8250: 8250_core: Fix irq name for 8250 serial IRQVignesh R1-1/+1
Using dev_name() as IRQ name during request_irq() might be misleading in case of serial over PCI. Therefore identify serial port IRQ using uart_port's name field. This will help mapping IRQs to appropriate ttySN(where N is the serial port index) instances. Signed-off-by: Vignesh R <vigneshr@ti.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-31serial: 8250_lpss: Unconditionally set PCI master for QuarkJan Kiszka1-1/+2
MSI needs it as well. Should have no practical impact, though, as DMA is always available on the Quark. But given the few users of pci_alloc_irq_vectors so far, this incorrect pattern may spread otherwise. Fixes: 3f3a46951e02 ("serial: 8250_lpss: set PCI master only for private DMA") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-29Merge 4.11-rc4 into tty-nextGreg Kroah-Hartman1-2/+7
We want the tty/serial fixes in here to handle bugfixes and merge issues. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-17serial: 8250_dw: simplify optional reset handlingPhilipp Zabel1-8/+5
As of commit bb475230b8e5 ("reset: make optional functions really optional"), the reset framework API calls use NULL pointers to describe optional, non-present reset controls. This allows to return errors from devm_reset_control_get_optional and to call reset_control_(de)assert unconditionally. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-17serial: 8250_fintek: Enable high speed mode on Fintek F81866Lukas Redlinger1-5/+38
Fintek F81866 supports baud rates higher than 115200 but needs to raise it's clock speed from 1.84 to 14.76 MHz. This is eight times faster, so gives 921600 as resulting baud_base. F81866 clock register 0xf2: Bit 7-2 reserved Bit 1-0 00: 1.8432MHz 01: 18.432MHz 10: 24MHz 11: 14.769MHz Signed-off-by: Lukas Redlinger <rel+kernel@agilox.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-14serial: 8250: 8250_core: Use dev_name() during request_irq()Vignesh R1-1/+1
Passing "serial" as name during request_irq() results in all serial port irqs have same name. This does not help much to easily identify which irq belongs to which serial port instance. Therefore pass dev_name() during request_irq() so that better identifiable name is listed for serial ports in cat /proc/interrupts output. Output of cat /proc/interrupts Before this patch: 26: 689 0 GICv2 309 Edge serial After this patch: 26: 696 0 GICv2 309 Edge 2530c00.serial Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-14serial: 8250_exar: Fix spelling of "driver"Andy Shevchenko1-1/+1
Fix typo in "Dricer". Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-14serial: 8250_dw: Fix breakage when HAVE_CLK=nJames Hogan1-0/+2
Commit 6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be used") recently broke the 8250_dw driver on platforms which don't select HAVE_CLK, as dw8250_set_termios() gets confused by the behaviour of the fallback HAVE_CLK=n clock API in linux/clk.h which pretends everything is fine but returns (valid) NULL clocks and 0 HZ clock rates. That 0 rate is written into the uartclk resulting in a crash at boot, e.g. on Cavium Octeon III based UTM-8 we get something like this: 1180000000800.serial: ttyS0 at MMIO 0x1180000000800 (irq = 41, base_baud = 25000000) is a OCTEON ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1 at drivers/tty/serial/serial_core.c:441 uart_get_baud_rate+0xfc/0x1f0 ... Call Trace: ... [<ffffffff8149c2e4>] uart_get_baud_rate+0xfc/0x1f0 [<ffffffff814a5098>] serial8250_do_set_termios+0xb0/0x440 [<ffffffff8149c710>] uart_set_options+0xe8/0x190 [<ffffffff814a6cdc>] serial8250_console_setup+0x84/0x158 [<ffffffff814a11ec>] univ8250_console_setup+0x54/0x70 [<ffffffff811901a0>] register_console+0x1c8/0x418 [<ffffffff8149f004>] uart_add_one_port+0x434/0x4b0 [<ffffffff814a1af8>] serial8250_register_8250_port+0x2d8/0x440 [<ffffffff814aa620>] dw8250_probe+0x388/0x5e8 ... The clock API is defined such that NULL is a valid clock handle so it wouldn't be right to check explicitly for NULL. Instead treat a clk_round_rate() return value of 0 as an error which prevents uartclk being overwritten. Fixes: 6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be used") Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: David Daney <david.daney@cavium.com> Cc: Russell King <linux@armlinux.org.uk> Cc: linux-serial@vger.kernel.org Cc: linux-clk@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: bcm-kernel-feedback-list@broadcom.com Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Jason Uy <jason.uy@broadcom.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-14serial: 8250_dw: Honor clk_round_rate errors in dw8250_set_termiosHeiko Stuebner1-2/+5
clk_round_rate returns a signed long and may possibly return errors in it, for example if there is no possible rate. Till now dw8250_set_termios ignored any error, the signednes and would just use the value as input to clk_set_rate. This of course falls apart if there is an actual error, so check for errors and only try to set a rate if the value is actually valid. This turned up on some Rockchip platforms after commit 6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be used") enabled set_termios callback in all cases, not only ACPI. Fixes: 6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be used") Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10serial: exar: Enable MSI supportJan Kiszka1-1/+7
Use pci_alloc_irq_vectors to enable MSI when available. At least the XR17V352 supports this. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10serial: exar: Move register defines from uapi header to consumer siteJan Kiszka2-0/+19
None of these registers is relevant for the userspace API. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10serial: pci: Remove unused pci_boards entriesJan Kiszka1-22/+0
Became obsolete with the split-out of 8250_exar. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10serial: exar: Move Commtech adapters to 8250_exar as wellJan Kiszka2-143/+79
Those are Exar-based, too. With the required refactoring of the code to fit into 8250_exar, we automatically fix the same issue pci_xr17v35x_setup had before: 8XMODE, FCTL, TXTRG and RXTRG were always only set for port 0. Now they are initialized for the correct target port by using port.membase. Now we can also cleanly fix the blacklist of 8250_pci so that all Commtech devices are rejected and 8250_exar can handle them. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10serial: exar: Fix initialization of EXAR registers for ports > 0Jan Kiszka1-13/+9
So far, pci_xr17v35x_setup always initialized 8XMODE, FCTR & Co. for port 0 because it used the address of that port instead of moving the pointer according to the port number. Fix this and remove the unneeded temporary ioremap by moving default_setup up and reusing the membase it fills into the port structure. Fixes: 14faa8cce88e ("tty/8250 Add support for Commtech's Fastcom Async-335 and Fastcom Async-PCIe cards") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10serial: exar: Fix mapping of port I/O resourcesJan Kiszka1-0/+3
pcim_iomap_table only returns the table of mapping, it does not perform them. For that, we need to call pcim_iomap, but only if that mapping was not done before. Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-10serial: 8250_dw: Avoid "too much work" from bogus rx timeout interruptDouglas Anderson1-0/+23
On a Rockchip rk3399-based board during suspend/resume testing, we found that we could get the console UART into a state where it would print this to the console a lot: serial8250: too much work for irq42 Followed eventually by: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 11s! Upon debugging I found that we're in this state: iir = 0x000000cc lsr = 0x00000060 It appears that somehow we have a RX Timeout interrupt but there is no actual data present to receive. When we're in this state the UART driver claims that it handled the interrupt but it actually doesn't really do anything. This means that we keep getting the interrupt over and over again. Normally we don't actually need to do anything special to handle a RX Timeout interrupt. We'll notice that there is some data ready and we'll read it, which will end up clearing the RX Timeout. In this case we have a problem specifically because we got the RX TImeout without any data. Reading a bogus byte is confirmed to get us out of this state. It's unclear how exactly the UART got into this state, but it is known that the UART lines are essentially undriven and unpowered during suspend, so possibly during resume some garbage / half transmitted bits are seen on the line and put the UART into this state. The UART on the rk3399 is a DesignWare based 8250 UART. From mailing list posts, it appears that other people have run into similar problems with DesignWare based IP. Presumably this problem is unique to that IP, so I have placed the workaround there to avoid possibly of accidentally triggering bad behavior on other IP. Also note the RX Timeout behaves very differently in the DMA case, for for now the workaround is only applied to the non-DMA case. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-09serial: 8250_pci: make pciserial_detach_ports() staticWei Yongjun1-1/+1
Fixes the following sparse warning: drivers/tty/serial/8250/8250_pci.c:3916:6: warning: symbol 'pciserial_detach_ports' was not declared. Should it be static? Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-06serial: 8250_pci: Add MKS Tenta SCOM-0800 and SCOM-0801 cardsIan Abbott1-0/+13
The MKS Instruments SCOM-0800 and SCOM-0801 cards (originally by Tenta Technologies) are 3U CompactPCI serial cards with 4 and 8 serial ports, respectively. The first 4 ports are implemented by an OX16PCI954 chip, and the second 4 ports are implemented by an OX16C954 chip on a local bus, bridged by the second PCI function of the OX16PCI954. The ports are jumper-selectable as RS-232 and RS-422/485, and the UARTs use a non-standard oscillator frequency of 20 MHz (base_baud = 1250000). Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-03serial: 8250_pci: remove exar codeSudip Mukherjee2-333/+4
Remove the Exar specific codes from 8250_pci and blacklist those chips so that the new Exar serial driver binds to the devices. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-03serial: exar: split out the exar code from 8250_pciSudip Mukherjee3-0/+401
Add the serial driver for the Exar chips. And also register the platform device for the GPIO provided by the Exar chips. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-278250: of: remove remnants of generic of_serial driverArnd Bergmann1-69/+24
During build testing, I ran into a warning in a driver that I had written myself at some point: drivers/tty/serial/8250/8250_of.c: In function 'of_platform_serial_probe': drivers/tty/serial/8250/8250_of.c:233:1: error: the frame size of 1200 bytes is larger than 1152 bytes [-Werror=frame-larger-than=] This is harmless by itself, but it shows two other problems in the driver: - It still tries to be generic enough to handle all kinds of serial ports, where in reality the driver has been 8250-only for a while, and every other uart has its own DT support - As a result of that generalization, we keep two copies of 'struct uart_port' on the stack during probe(). This is completely unnessary. Removing the last code dealing with unsupported port_type values solves both problems nicely, and reduces the stack size. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-25serial: 8250_omap: Fix probe and remove for PM runtimeTony Lindgren1-1/+7
Otherwise the interconnect related code implementing PM runtime will produce these errors on a failed probe: omap_uart 48066000.serial: omap_device: omap_device_enable() called from invalid state 1 omap_uart 48066000.serial: use pm_runtime_put_sync_suspend() in driver? Note that we now also need to check for priv in omap8250_runtime_suspend() as it has not yet been registered if probe fails. And we need to use pm_runtime_put_sync() to properly idle the device like we already do in omap8250_remove(). Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-25serial: hp300: mask the warning for people just doing build coveragePaul Gortmaker1-1/+1
Currently this warning is triggered for allmodconfig on m68k. It is well intentioned, in that if you are building the driver but not enabling one of the platforms where the hardware exists, you get a warning. The warning dates back to pre-git days, and now we have COMPILE_TEST so we can use that to mask the warning for people who are obviously just doing build coverage on tree wide changes. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: linux-m68k@lists.linux-m68k.org Cc: linux-serial@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-20serial: 8250_omap: Remove rx_dma_broken flagVignesh R1-5/+0
8250 UART DMA support was marked broken by default as it was not possible to pause ongoing RX DMA transfer. Now that both SDMA and EDMA can support pause operation for RX DMA transactions, don't set rx_dma_broken to true by default. With this patch 8250_omap driver will use DMA by default. Signed-off-by: Vignesh R <vigneshr@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-20serial: 8250_omap: Add OMAP_DMA_TX_KICK quirk for AM437xVignesh R1-6/+3
UART uses as EDMA as dma engine on AM437x SoC and therefore, requires OMAP_DMA_TX_KICK quirk just like AM33xx. So, enable OMAP_DMA_TX_KICK quirk for AM437x platform as well. While at that, drop use of of_machine_is_compatible() and instead pass quirks via device data. Signed-off-by: Vignesh R <vigneshr@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-20serial: 8250_omap: pause DMA only if DMA transfer in progressVignesh R1-4/+7
It is possible that DMA transfer is already complete but, completion handler is yet to be called, when dmaengine_pause() is called in case of error condition(like break/rx timeout). This leads to dmaengine_pause() API to return EINVAL (as descriptor is already NULL) causing rx_dma_broken flag to be set and effectively disabling RX DMA. Fix this by calling dmaengine_pause() only when transfer is in progress. Signed-off-by: Vignesh R <vigneshr@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-19tty: serial: 8250: 8250_gsc:- Handle return NULL error from ioremap_nocacheArvind Yadav1-0/+4
Here, If ioremap_nocache will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-19serial: 8250_mid: set PCI master only for DMA capable deviceAndy Shevchenko1-2/+2
There is no need to set PCI bus mastering when device is not doing any DMA. It includes MSI type of interrupts. Currently only UART on Denverton, which is DMA capable, might have MSI enabled. Taking above into account enable bus mastering for Denverton case only. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-19serial: 8250_mid: enable MSI on DenvertonAndy Shevchenko1-1/+7
Enable MSI type of interrupt if PCI BIOS supports it. 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>
2017-01-19serial: 8250_mid: handle interrupt correctly in DMA caseAndy Shevchenko1-0/+33
Starting from Tangier B0 and continuing on Anniedale the HSU DMA interrupt line is actually shared with UART. Handling them independently is racy and quite often comes with the following traceback. irq 54: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc6-edison64-86244934+ #1 Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 ffff88003f203eb0 ffffffff8130e718 ffff880032627000 ffff88003262709c ffff88003f203ed8 ffffffff810a3960 ffff880032627000 0000000000000000 ffff880032627000 ffff88003f203f10 ffffffff810a3cc7 ffff880032627000 Call Trace: <IRQ> [<ffffffff8130e718>] dump_stack+0x4d/0x65 [<ffffffff810a3960>] __report_bad_irq+0x30/0xc0 [<ffffffff810a3cc7>] note_interrupt+0x227/0x270 [<ffffffff810a1380>] handle_irq_event_percpu+0x40/0x50 [<ffffffff810a13b7>] handle_irq_event+0x27/0x50 [<ffffffff810a42d5>] handle_fasteoi_irq+0x85/0x150 [<ffffffff8101d7fe>] handle_irq+0x6e/0x120 [<ffffffff8105b8bc>] ? _local_bh_enable+0x1c/0x50 [<ffffffff8101d0d6>] do_IRQ+0x46/0xd0 [<ffffffff818cef3f>] common_interrupt+0x7f/0x7f <EOI> [<ffffffff818cdead>] ? mwait_idle+0x7d/0x140 [<ffffffff81024c9a>] arch_cpu_idle+0xa/0x10 [<ffffffff818ce150>] default_idle_call+0x20/0x30 [<ffffffff810908fd>] cpu_startup_entry+0x16d/0x1d0 [<ffffffff818c882d>] rest_init+0x6d/0x70 [<ffffffff81f93e8f>] start_kernel+0x3e2/0x3ef [<ffffffff81f9343d>] x86_64_start_reservations+0x38/0x3a [<ffffffff81f93529>] x86_64_start_kernel+0xea/0xed handlers: [<ffffffff81411670>] serial8250_interrupt Disabling IRQ #54 Fix this by handling interrupt only in one place. The issue is discussed here: https://github.com/andy-shev/linux/issues/5 Moreover this also fixes another bug when Rx DMA returns wrong residue and we can't rely on it. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-19serial: 8250_dw: Allow hardware flow control to be usedJason Uy1-3/+2
In the most common use case, the Synopsys DW UART driver does not set the set_termios callback function. This prevents UPSTAT_AUTOCTS from being set when the UART flag CRTSCTS is set. As a result, the driver will use software flow control as opposed to hardware flow control. To fix the problem, the set_termios callback function is set to the DW specific function. The logic to set UPSTAT_AUTOCTS is moved so that any clock error will not affect setting the hardware flow control. Reviewed-by: Scott Branden <scott.branden@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Jason Uy <jason.uy@broadcom.com> Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-16Merge 4.10-rc4 into tty-nextGreg Kroah-Hartman3-9/+7
We want the serial/tty fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12serial: 8250: Add new port type for TI DA8xx/66AK2xDavid Lechner2-0/+23
This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x. These SoCs have standard 8250 registers plus some extra non-standard registers. The UART will not function unless the non-standard Power and Emulation Management Register (PWREMU_MGMT) is configured correctly. This is currently handled in arch/arm/mach-davinci/serial.c for non-device-tree boards. Making this part of the UART driver will allow UART to work on device-tree boards as well and the mach code can eventually be removed. Signed-off-by: David Lechner <david@lechnology.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12serial: 8250_mid: make option visibleJean Delvare1-1/+1
Hiding tristate options with "if EXPERT" is usually not a good idea. You can decide that the driver should be included by default, but you don't know if the user wants it built-in or as a module. Hiding the option prevents the user from making that decision. This is even more problematic when said option selects other options. You end up with several device drivers forcibly built into the kernel. In this specific case, drivers 8250_mid, virt-dma, hsu_dma and hsu_dma_pci end up being built-in as soon as SERIAL_8250=y. It is very common for distribution kernels to build the subsystem core code into the kernel, because almost everybody will need it, but build all the device drivers as modules. This should be made possible. So drop the "if EXPERT" and make SERIAL_8250_MID visible. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 1fc969c75986 ("serial: 8250_mid: make module available only on X86") Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12serial: 8250_lpss: make option visibleJean Delvare1-1/+1
Hiding tristate options with "if EXPERT" is usually not a good idea. You can decide that the driver should be included by default, but you don't know if the user wants it built-in or as a module. Hiding the option prevents the user from making that decision. This is even more problematic when said option selects other options. You end up with several device drivers forcibly built into the kernel. In this specific case, drivers 8250_lpss, dw_dmac_core and dw_dmac_pci end up being built-in as soon as SERIAL_8250=y. It is very common for distribution kernels to build the subsystem core code into the kernel, because almost everybody will need it, but build all the device drivers as modules. This should be made possible. So drop the "if EXPERT" and make SERIAL_8250_LPSS visible. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: a13e19cf3dc1 ("serial: 8250_lpss: split LPSS driver to separate module") Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12serial: 8250_pci: make option visibleJean Delvare1-1/+1
Hiding tristate options with "if EXPERT" is usually not a good idea. You can decide that the driver should be included by default, but you don't know if the user wants it built-in or as a module. Hiding the option prevents the user from making that decision. In this specific case, driver 8250_pci ends up being built-in as soon as SERIAL_8250=y. It is very common for distribution kernels to build the subsystem core code into the kernel, because almost everybody will need it, but build all the device drivers as modules. This should be made possible. So drop the "if EXPERT" and make SERIAL_8250_PCI visible. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12serial: 8250_port: Remove dangerous pr_debug()Alexey Brodkin1-4/+0
With CONFIG_DYNAMIC_DEBUG if dyndbg enables debug output in 8250_port.c deadlock happens inevitably on UART IRQ handling. That's the problematic execution path: ---------------------------->8------------------------ UART IRQ: serial8250_interrupt() -> serial8250_handle_irq(): lock "port->lock" -> pr_debug() -> serial8250_console_write(): bump in locked "port->lock". OR (if above pr_debug() gets removed): serial8250_tx_chars() -> pr_debug() -> serial8250_console_write(): bump in locked "port->lock". ---------------------------->8------------------------ So let's get rid of those not that much useful debug entries. Discussed problem could be easily reproduced with QEMU for x86_64. As well as this fix could be mimicked with muting of dynamic debug for the problematic lines as simple as: ---------------------------->8------------------------ dyndbg="+p; file 8250_port.c line 1756 -p; file 8250_port.c line 1822 -p" ---------------------------->8------------------------ Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Jiri Slaby <jslaby@suse.com> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Phillip Raffeck <phillip.raffeck@fau.de> Cc: Anton Wuerfel <anton.wuerfel@fau.de> Cc: "Matwey V. Kornilov" <matwey@sai.msu.ru> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Thor Thayer <tthayer@opensource.altera.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12serial: 8250_lpss: avoid potential kernel crash when removeAndy Shevchenko1-2/+2
This is a follow up to the commit a9b01b5823f7 ("serial: 8250_mid fix calltrace when hotplug 8250 serial controller") in which the kernel crash was described for another 8250 based driver. It appears that we have the very same issue in 8250_lpss. Fix it by unregistering serial driver first. Cc: Liwei Song <liwei.song@windriver.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12serial: 8250: moxa: Store num_ports in brdMatwey V. Kornilov1-0/+1
When struct moxa8250_board is allocated, then num_ports should be initialized in order to use it later in moxa8250_remove. Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12serial: 8250_fintek: Add resource check for Fintek F81504/508/512Ji-Ze Hong (Peter Hong)1-4/+9
Add resource type check for Fintek F81504/508/512, BAR3/4/5 must be IORESOURCE_IO. Fintek is trying to make F81504/508/512 works on MMIO interface, but it's still in progress. We found some issue when the experiment IC when the BAR3/4/5 is IORESOURCE_MEM. It'll cause wrong operation with IO resource. So we'll add the resource check for this. Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-11Revert "tty: serial: 8250: add CON_CONSDEV to flags"Herbert Xu1-1/+1
This commit needs to be reverted because it prevents people from using the serial console as a secondary console with input being directed to tty0. IOW, if you boot with console=ttyS0 console=tty0 then all kernels prior to this commit will produce output on both ttyS0 and tty0 but input will only be taken from tty0. With this patch the serial console will always be the primary console instead of tty0, potentially preventing people from getting into their machines in emergency situations. Fixes: d03516df8375 ("tty: serial: 8250: add CON_CONSDEV to flags") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-11Clearing FIFOs in RS485 emulation mode causes subsequent transmits to breakDaniel Jedrychowski1-1/+1
When in RS485 emulation mode, __do_stop_tx_rs485() calls serial8250_clear_fifos(). This not only clears the FIFOs, but also sets all bits in their control register (UART_FCR) to 0. One of the effects of this is the disabling of the FIFOs, which turns them into single-byte holding registers. The rest of the driver doesn't know this, which results in the lions share of characters passed into a write call to be dropped. (I can supply logic analyzer screenshots if necessary) This fix replaces the serial8250_clear_fifos() call to serial8250_clear_and_reinit_fifos() - this prevents the "dropped characters" issue from manifesting again while retaining the requirement of clearing the RX FIFO after transmission if the SER_RS485_RX_DURING_TX flag is disabled. Signed-off-by: Daniel Jedrychowski <avistel@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-118250_pci: Fix potential use-after-free in error pathGabriel Krisman Bertazi1-7/+5
Commit f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during PCI error recovery") introduces a potential use-after-free in case the pciserial_init_ports call in serial8250_io_resume fails, which may happen if a memory allocation fails or if the .init quirk failed for whatever reason). If this happen, further pci_get_drvdata will return a pointer to freed memory. This patch reworks the PCI recovery resume hook to restore the old priv structure in this case, which should be ok, since the ports were already detached. Such error during recovery causes us to give up on the recovery. Fixes: f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during PCI error recovery") Reported-by: Michal Suchanek <msuchanek@suse.com> Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-30 11:40:15 +0000