Fix the following Calltrace:
[ 77.768221] WARNING: CPU: 5 PID: 645 at drivers/dma/dmaengine.c:1069 dma_async_device_unregister+0xe2/0xf0
[ 77.775058] dma_async_device_unregister called while 1 clients hold a reference
[ 77.825048] CPU: 5 PID: 645 Comm: sh Not tainted 4.8.8-WR9.0.0.0_standard+ #3
[ 77.832550] Hardware name: Intel Corp. Aspen Cove/Server, BIOS HAVLCRB1.X64.0012.D58.1604140405 04/14/2016
[ 77.840396] 0000000000000000 ffffc90008adbc80 ffffffff81403456 ffffc90008adbcd0
[ 77.848245] 0000000000000000 ffffc90008adbcc0 ffffffff8105e2e1 0000042d08adbf20
[ 77.855934] ffff88046a861c18 ffff88046a85c420 ffffffff820d4200 ffff88046ae92318
[ 77.863601] Call Trace:
[ 77.871113] [<ffffffff81403456>] dump_stack+0x4f/0x69
[ 77.878655] [<ffffffff8105e2e1>] __warn+0xd1/0xf0
[ 77.886102] [<ffffffff8105e34f>] warn_slowpath_fmt+0x4f/0x60
[ 77.893508] [<ffffffff814187a9>] ? find_next_bit+0x19/0x20
[ 77.900730] [<ffffffff814bf83e>] ? dma_channel_rebalance+0x23e/0x270
[ 77.907814] [<ffffffff814bfee2>] dma_async_device_unregister+0xe2/0xf0
[ 77.914992] [<ffffffff814c53aa>] hsu_dma_remove+0x1a/0x60
[ 77.921977] [<ffffffff814ee14c>] dnv_exit+0x1c/0x20
[ 77.928752] [<ffffffff814edff6>] mid8250_remove+0x26/0x40
[ 77.935607] [<ffffffff8144f1b9>] pci_device_remove+0x39/0xc0
[ 77.942292] [<ffffffff8160cfea>] __device_release_driver+0x9a/0x140
[ 77.948836] [<ffffffff8160d0b3>] device_release_driver+0x23/0x30
[ 77.955364] [<ffffffff81447dcc>] pci_stop_bus_device+0x8c/0xa0
[ 77.961769] [<ffffffff81447f0a>] pci_stop_and_remove_bus_device_locked+0x1a/0x30
[ 77.968113] [<ffffffff81450d4e>] remove_store+0x5e/0x70
[ 77.974267] [<ffffffff81607ed8>] dev_attr_store+0x18/0x30
[ 77.980243] [<ffffffff8123006a>] sysfs_kf_write+0x3a/0x50
[ 77.986180] [<ffffffff8122f5ab>] kernfs_fop_write+0x10b/0x190
[ 77.992118] [<ffffffff811bf1c8>] __vfs_write+0x18/0x40
[ 77.998032] [<ffffffff811bfdee>] vfs_write+0xae/0x190
[ 78.003747] [<ffffffff811c1016>] SyS_write+0x46/0xb0
[ 78.009234] [<ffffffff81a4c31b>] entry_SYSCALL_64_fastpath+0x13/0x8f
[ 78.014809] ---[ end trace 0c36dd73b7408eb2 ]---
This happens when the 8250 serial controller is hotplugged as follows:
echo 1 > /sys/bus/pci/devices/0000:00:1a.0/remove
This trace happens due to the serial port still holding a reference when
the dma device is unregistered.
The dma unregister routine will check if there is still a reference exist,
if so it will give the WARNING(here serial port still was not unregister).
To fix this, We need to unregister the serial port first, then do DMA
device unregister to make sure there is no reference when to DMA routine.
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
During a PCI error recovery, like the ones provoked by EEH in the ppc64
platform, all IO to the device must be blocked while the recovery is
completed. Current 8250_pci implementation only suspends the port
instead of detaching it, which doesn't prevent incoming accesses like
TIOCMGET and TIOCMSET calls from reaching the device. Those end up
racing with the EEH recovery, crashing it. Similar races were also
observed when opening the device and when shutting it down during
recovery.
This patch implements a more robust IO blockage for the 8250_pci
recovery by unregistering the port at the beginning of the procedure and
re-adding it afterwards. Since the port is detached from the uart
layer, we can be sure that no request will make through to the device
during recovery. This is similar to the solution used by the JSM serial
driver.
I thank Peter Hurley <peter@hurleysoftware.com> for valuable input on
this one over one year ago.
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no need to check port for NULL in uart_port_deref() since we call it
only when port is defined.
There are few places that violate this. Fix them here as well.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The mxs-auart driver does not count FIFO overrun errors. These errors never
appear in /proc/tty/driver/ttyAPP. This is because the OERR status bit is
masked by read_status_mask in the rx interrupt function, but the
AUART_STAT_OERR bit is never set in read_status_mask. The patch enables the
counting of overrun errors.
Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a set_ldisc function to enable/disable IrDA SIR mode according to
the new line discipline, if IrDA SIR mode is supported by the hardware
configuration.
Signed-off-by: Ed Blake <ed.blake@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Expose set_ldisc() function so that it can be overridden with a
platform specific implementation.
Signed-off-by: Ed Blake <ed.blake@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add an IrDA UART capability flag and change the type of
uart_8250_port.capabilities to be u32 rather than unsigned short to
accommodate the additional flag.
Signed-off-by: Ed Blake <ed.blake@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When any 8250 based driver sets up DMA and has UART_CAP_RPM capability enabled
the device is left powered on after transfer is done. We need to schedule a
device suspend operation when DMA completes the transfer.
The patch is based on the work done by the reporter.
Reported-by: Huiquan Zhong <huiquan.zhong@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The following fix of runtime PM use in DMA mode requires at least
serial8250_rpm_put_tx() to be available. Export both calls.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When su_probe() fails it doesn't free *up and we may have a memory
leak. Fix this by freeing *up before return.
Signed-off-by: Souptick joarder <jrdr.linux@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In each call to hv_remove(), con_read_page and con_write_page is not
getting freed and lead to memory leakage. Fix this by freeing both
pointers in hv_remove().
Signed-off-by: Souptick joarder <jrdr.linux@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Declare an OF early console for SBSA UART so that the early console device
can be specified via the "stdout-path" property in device-tree.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The STM32 serial port is SoC specific so no point enabling it
without the architecture enabled.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When spi_setup() fails it doesn't free ifx_dev and we have a memory
leak. Fix this by freeing ifx_dev before the return.
Signed-off-by: Souptick joarder <jrdr.linux@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Inside ioc4_attach_local() 4 memory was allocated using kzalloc and
assign it to ports[] within loop. When kzalloc fails inside loop,
it returns error without freeing previously allocated memory and we
may have memory leak. Fix this by freeing ports[] before return.
Signed-off-by: Souptick joarder <jrdr.linux@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The fresh new serial driver for pxa produces warnings when
CONFIG_PM_SLEEP is disabled:
drivers/tty/serial/8250/8250_pxa.c:50:12: error: 'serial_pxa_resume' defined but not used [-Werror=unused-function]
drivers/tty/serial/8250/8250_pxa.c:41:12: error: 'serial_pxa_suspend' defined but not used [-Werror=unused-function]
This removes the #ifdef around the two functions and instead marks both
as __maybe_unused, which is more robust and avoids the warning.
Fixes: ab28f51c77 ("serial: rewrite pxa2xx-uart to use 8250_core")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
An otherwise very nice cleanup of the pxa2xx uart support marked the
init function of this driver as __deprecated:
drivers/tty/serial/pxa.c:944:1: error: 'serial_pxa_init' is deprecated [-Werror=deprecated-declarations]
This seems unhelpful to me, as we now warn for every allmodconfig build,
which is otherwise free of warnings on most architectures. Let's
remove the annotation again.
Fixes: ab28f51c77 ("serial: rewrite pxa2xx-uart to use 8250_core")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drop invalid user-pointer check from TIOCGSERIAL handler.
A NULL-pointer can be valid in user space and copy_to_user() takes care
of sanity checking.
Cc: Mikael Starvik <starvik@axis.com>
Cc: linux-cris-kernel@axis.com
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi,
below patch to fix Fourth port offset of Percom PI7C9X7954 boards.
I had a problem using Fourth port on a pci express serial board based on Pericom
PI7C9X7954. Reading datasheet I notice a "special" offset assign to this port
when used in I/O mode.
Offset 0x0 -> UART 0
Offset 0x8 -> UART 1
Offset 0x10 -> UART 2
Offset 0x38 -> UART 3 <<---- This don't follow a logical sequence
This patch add a different init to last port, to have right offset.
I check also Pericom 7952 and 7958 but that devices follow logical sequence,
so they are ok.
Regards,
Angelo
Signed-off-by: Angelo Butti <buttiangelo@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
While spin is already locked, serial output request causes the deadlock,
because serial output process also tries to lock the spin.
This patch removes serial output with spin locked.
Signed-off-by: Takatoshi Akiyama <takatoshi.akiyama.kj@ps.hitachi-solutions.com>
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Kconfig currently controlling compilation of this code is:
arch/cris/arch-v10/drivers/Kconfig:config ETRAX_SERIAL
arch/cris/arch-v10/drivers/Kconfig: bool "Serial-port support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
We don't replace module.h with init.h since the file already has that.
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-cris-kernel@axis.com
Cc: linux-serial@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The newly added pxa glue driver for 8250 supports console output, but
fails to build if the 8250 console is disabled:
drivers/tty/serial/8250/8250_pxa.o: In function `early_serial_pxa_setup':
8250_pxa.c:(.init.text+0x50): undefined reference to `early_serial8250_setup'
This adds an #ifdef like the other glue drivers have it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The hardware book says, the FCR is combined with a register called
CHAR (it will trigger interrupt when a specific character is
received). At first, I used lock/read/modify/write/unlock dance for
the FCR to not affect the upper bits, but the CHAR is actually never
used. It should not hurt to always clear the CHAR and to handle the
FCR as a normal case. It can save the costly locking.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Denys Vlasenko <dvlasenk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For this driver, uart_port::regshift is always 2. Hardcode the
shift value instead of reading ->regshift to get an already known
value. (pointed out by Denys Vlasenko)
Furthermore, I am using register macros that are already shifted,
which will save code a bit.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The port->console flag is always false, as uart_console() is called
before the serial console has been registered.
Hence for a serial port used as the console, uart_tty_port_shutdown()
will still be called when userspace closes the port, powering it down.
This may lead to a system lock up when the serial console driver writes
to the serial port's registers.
To fix this, move the setting of port->console after the call to
uart_configure_port(), which registers the serial console.
Fixes: 761ed4a945 ("tty: serial_core: convert uart_close to use tty_port_close")
Reported-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[robh: rebased on tty-linus]
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commit 1cf6e8fc83 ("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 1cf6e8fc83 ("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 1cf6e8fc83 ("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
Cc: <stable@vger.kernel.org> #4.4+ (beware, missing atmel_port variable)
Fixes: 1cf6e8fc83 ("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>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2a41bc2a2b ("tty: serial: fsl_lpuart: add polled console
functions") caused a build warning about an unused variable, so fix it.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Nicolae Rosia <nicolae_rosia@mentor.com>
Cc: Stefan Golinschi <stefan.golinschi@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The regmap_update first reads the IOState register and then triggers
a write if needed. However, GPIOS might be configured as an input so
the read to IOState on this GPIO is the current state which might
be random.
Signed-off-by: Francois Berder <Francois.Berder@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NXP SC16C2552 requires that we always write a reset to the RX FIFO and
TX FIFO whenever we enable the FIFOs
Cc: xe-kernel@external.cisco.com
Signed-off-by: Steve Shih <sshih@cisco.com>
Signed-off-by: David Singleton <davsingl@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the case where head == 0 on the circular buffer, there should be one
DMA buffer, not two. The second zero-length buffer would break the
lpuart driver, transfer would never complete.
Signed-off-by: Aaron Brice <aaron.brice@datasoft.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Tested-by: Stefan Agner <stefan@agner.ch>
Tested-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fintek F81865 is a LPC to 6 UARTs SuperIO. It has less functional UARTs
likes F81866. It's also need check the IRQ mode with system assigned,
but the configuration is not the same with F81216 series.
F81865 IRQ Mode setting:
0xf0
Bit1: IRQ_MODE0
Bit0: Share mode (always on)
Level/Low: IRQ_MODE0:0
Edge/High: IRQ_MODE0:1
The following list is brief descriptions of F81865:
F81865 (0704)
9Bit(not implements with mainline)
RS485(implemented)
Suggested-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fintek F81866 is a LPC to 6 UARTs SuperIO. It has fully functional UARTs
likes F81216H. It's also need check the IRQ mode with system assigned,
but the configuration is not the same with F81216 series.
F81866 IRQ Mode setting:
0xf0
Bit1: IRQ_MODE0
Bit0: Share mode (always on)
0xf6
Bit3: IRQ_MODE1
Level/Low: IRQ_MODE0:0, IRQ_MODE1:0
Edge/High: IRQ_MODE0:1, IRQ_MODE1:0
The following list is brief descriptions of F81866:
F81866 (1010)
9Bit/High baud rate(not implements with mainline)
RS485, 128Bytes FIFO (implemented)
Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fintek F81216 is a LPC to 4 UARTs device. It's the F81216 series but
support less functional than F81216AD/F81216H
The following list is brief descriptions of F81216 series:
F81216H (0105)
9Bit/High baud rate(not implements with mainline)
RS485, 128Bytes FIFO (implemented)
F81216AD (0216)
9Bit(not implements with mainline)
RS485(implemented)
F81216 (0208)
basically 16550A
Suggested-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Fintek F81216H had maximum 128Bytes FIFO, but some BIOS configurated
as normal 16Bytes FIFO. This patch will set 128Bytes FIFO and trigger
level multiplier as 4x when F81216H detected.
Default 16550A trigger level is 8Bytes. When this patch applied, the
trigger level will change to 8Byte x 4 = 32Byte. It can be reduce the RX
incoming interrupts.
Suggested-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Set IRQ Mode when port probed in probe_setup_port()
It should hold the IO port premission via fintek_8250_enter_key() and
release via fintek_8250_exit_key() when we configure the SuperIO.
This patch will move all SuperIO configure operations to
probe_setup_port() to reduce fintek_8250_enter_key() and
fintek_8250_exit_key() usage.
Suggested-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If we need to access SuperIO registers, It should write register offset
to base_addr and read/write value to base_addr + 1 to perform read/write.
We can make it more simply with write/read functions.
This patch add sio_read_reg()/sio_write_reg()/sio_write_mask_reg() to
reduce SuperIO register operation with lot of outb()/inb().
Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Transfer the device-tree pxa uart handling from 8250_of to the new
8250_pxa. As a corollary, add the early console definition into
8250_pxa.
This enables to have the same uart node for the early console and the
normal uart.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Instead of a direct assignment use pci_irq_vector() call as it's done for the
other case.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The use of IRQF_ONESHOT when registering an interrupt handler with
request_irq() is non-sensical.
Not only that, it also prevents the handler from being threaded when it
otherwise should be w/ IRQ_FORCED_THREADING is enabled. This causes the
following deadlock observed by Sean Nyekjaer on -rt:
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[..]
rt_spin_lock_slowlock from queue_kthread_work
queue_kthread_work from sc16is7xx_irq
sc16is7xx_irq [sc16is7xx] from handle_irq_event_percpu
handle_irq_event_percpu from handle_irq_event
handle_irq_event from handle_level_irq
handle_level_irq from generic_handle_irq
generic_handle_irq from mxc_gpio_irq_handler
mxc_gpio_irq_handler from mx3_gpio_irq_handler
mx3_gpio_irq_handler from generic_handle_irq
generic_handle_irq from __handle_domain_irq
__handle_domain_irq from gic_handle_irq
gic_handle_irq from __irq_svc
__irq_svc from rt_spin_unlock
rt_spin_unlock from kthread_worker_fn
kthread_worker_fn from kthread
kthread from ret_from_fork
Fixes: 9e6f4ca3e5 ("sc16is7xx: use kthread_worker for tx_work and irq")
Reported-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: Josh Cartwright <joshc@ni.com>
Cc: linux-rt-users@vger.kernel.org
Cc: Jakub Kicinski <moorray3@wp.pl>
Cc: stable@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Julia Cartwright <julia@ni.com>
Acked-by: Jakub Kicinski <kubakici@wp.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enable MWI mechanism if PCI bus master supports it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no need to set PCI bus mastering when device is not doing any DMA.
Though on Intel Quark DMA is a part of UART IP and thus shares same device in
Linux kernel.
Enable bus mastering only for Quark case.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fsl_lpuart cannot be used with kgdb because the kgdb
initcall is called before the driver's init.
Move kgdb to be initialized after all serial drivers
have been inited.
Signed-off-by: Nicolae Rosia <nicolae_rosia@mentor.com>
Signed-off-by: Stefan Golinschi <stefan.golinschi@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds polling functions as used by kgdb.
Signed-off-by: Nicolae Rosia <nicolae_rosia@mentor.com>
Signed-off-by: Stefan Golinschi <stefan.golinschi@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds function pl011_console_match() that implements
method match of struct console. It allows to match consoles against
data specified in a string, for example taken from command line or
compiled by ACPI SPCR table handler.
This patch was merged to tty-next but then reverted because of
conflict with
commit 46e36683f4 ("serial: earlycon: Extend earlycon command line option to support 64-bit addresses")
Now it is fixed.
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit 4fe0d15488 ("PCI: Use positive flags in pci_alloc_irq_vectors()")
replaces flags from negative to positive values which makes mandatory to have
the last argument in pci_alloc_irq_vectors() non-zero (if we want to be no-op).
This basically drops MSI enabling in 8250_lpss driver.
Restore desired behaviour in 8250_lpss by passing PCI_IRQ_ALL_TYPES instead of
0 to pci_alloc_irq_vectors().
Fixes: 60a9244a5d ("serial: 8250_lpss: enable MSI for Intel Quark")
Cc: Christoph Hellwig <hch@lst.de>
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>
pxa2xx-uart was a separate uart platform driver. It was declaring
the same device names and numbers as 8250 driver. As a result,
it was impossible to use 8250 driver on PXA SoCs.
Upon closer examination pxa2xx-uart turned out to be a clone of
8250_core driver.
Workaround for Erratum #19 according to Marvel(R) PXA270M Processor
Specification Update (April 19, 2010) is dropped. 8250_core reads
from FIFO immediately after checking DR bit in LSR.
The patch leaves the original SERIAL_PXA driver around. The original
driver is just marked DEPRECATED in Kconfig and C source. When
the original driver is considered safe to remove, no changes
to SERIAL_8250 will be necessary.
Compiling SERIAL_8250_CONSOLE and SERIAL_PXA_CONSOLE even without
SERIAL_8250_PXA breaks console for SERIAL_PXA. For this reasons, the new
and the original drivers are made mutually exclusive.
Signed-off-by: Sergei Ianovich <ynvich@gmail.com>
CC: Heikki Krogerus <heikki.krogerus@linux.intel.com>
CC: James Cameron <quozl@laptop.org>
CC: Robert Jarzmik <robert.jarzmik@free.fr>
CC: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
[rebased on v4.8]
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 761ed4a945 ('tty: serial_core: convert uart_close to use
tty_port_close') started setting the ttyport console flag for serial
drivers. This is causing crashes, hangs, or garbage output on several
platforms because the serial shutdown is skipped and IRQs are left
enabled.
Partially revert commit 761ed4a945 and drop reporting UART tty_ports
as a console leaving the console handling to the serial_core as it was
before.
Fixes: 761ed4a945 ("tty: serial_core: convert uart_close to use tty_port_close")
Reported-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reported-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Reported-by: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
At this point, 'value' is always a byte, then this code is clearing
bit 15, which is already clear. I meant to clear bit 7.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: Denys Vlasenko <dvlasenk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liwei Song