Commit 5f5c9ae5
"serial_core: Unregister console in uart_remove_one_port()"
fixed a crash where a serial port was removed but
not deregistered as a console.

There is a side effect of that commit for platforms having serial consoles
and of_serial configured (CONFIG_SERIAL_OF_PLATFORM). The serial console
is disabled midway through the boot process.

This cessation of the serial console affects PowerPC computers
such as the MVME5100 and SAM440EP.

The sequence is:

	bootconsole [udbg0] enabled
	....
	serial8250/16550 driver initialises and registers its UARTS,
	one of these is the serial console.
	console [ttyS0] enabled
	....
	of_serial probes "platform" devices, registering them as it goes.
	One of these is the serial console.
	console [ttyS0] disabled.

The disabling of the serial console is due to:

	a.  unregister_console in printk not clearing the
	    CONS_ENABLED bit in the console flags,
	    even though it has announced that the console is disabled; and

	b.  of_platform_serial_probe in of_serial not setting the port type
	    before it registers with serial8250_register_8250_port.

This patch ensures that the serial console is re-enabled when of_serial
registers a serial port that corresponds to the designated console.
Signed-off-by: NStephen Chivers <schivers@csc.com>
Tested-by: NStephen Chivers <schivers@csc.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [unregister_console]
Cc: stable <stable@vger.kernel.org> # 3.15

===
The above failure was identified in Linux-3.15-rc2.

Tested using MVME5100 and SAM440EP PowerPC computers with
kernels built from Linux-3.15-rc5 and tty-next.

The continued operation of the serial console is vital for computers
such as the MVME5100 as that Single Board Computer does not
have any grapical/display hardware.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Using dma_mapping_error() to make sure the mapping did not
fail.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

8250 uart driver currently supports only software assisted hw flow
control. The software assisted hw flow control maintains a hw_stopped
flag in the tty structure to stop and start transmission and use modem
status interrupt for the event to drive the handshake signals. This is
not needed if hw has flow control capabilities. This patch adds a
DT attribute for enabling hw flow control for a uart port. Also skip
stop and start if this flag is present in flag field of the port
structure.
Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
CC: Rob Herring <robh+dt@kernel.org>
CC: Pawel Moll <pawel.moll@arm.com>
CC: Mark Rutland <mark.rutland@arm.com>
CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
CC: Kumar Gala <galak@codeaurora.org>
CC: Randy Dunlap <rdunlap@infradead.org>
CC: Jiri Slaby <jslaby@suse.cz>
CC: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Handle CTS/DSR/RI/DCD GPIO interrupts in atmel_serial.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On sam9x5, dedicated CTS (and RTS) pins are unusable together with the
LCDC, the EMAC, or the MMC because they share the same line.

Moreover, the USART controller doesn't handle DTR/DSR/DCD/RI signals,
so we have to control them via GPIO.

This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI
signals.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch add some helpers to control modem lines (CTS/RTS/DSR...) via
GPIO.
This will be useful for many boards which have a serial controller that
only handle CTS/RTS pins (or even just RX/TX).
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: NYegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is needed for gpiod_get_direction().
Otherwise, it returns -EINVAL.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

RTS pin is an active low pin.
For now, this doesn't change anything as the ACTIVE_LOW flag is not
handled in atmel_serial, but it will be in 3.16.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch add IGNPAR flag handling for the driver.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

sccnxp_timer() is triggered only by timer, so there are no need to
check for timer_pending().
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch disables the receiver ready interrupt for imx_stop_rx.
It reduces the interrupt numbers when the uart is going to close
or suspend.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The DMA wait queue makes the code very complicated:
  For RX, the @->stop_rx hook does not really stop the RX;
  For TX, the @->stop_tx hook does not really stop the TX.

The above make the imx_shutdown has to wait the RX/TX DMA to be finished.

In order to make code more simple, this patch removes the DMA wait queue.
By calling the dmaengine_terminate_all, this patch makes the RX stops
immediately after we call the @->stop_rx hook, so does the TX.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the imx_startup(), we will reset the uart port which will reset all
the FIFOs, including the URXD.

So the code to clear the RX FIFO is redundant. Just remove it.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Current code resets the uart port only when it supports the irda mode.
In actually, we also need to reset the uart port in the non-irda mode.
A hang was caught in the following case:

    UART A transmits data to the other end. But the transmission maybe
    terminated. In some corner case, the TX FIFO maybe not empty.

The kernel will hang at the imx_set_termios():
	............................................................
	while (!(readl(sport->port.membase + USR2) & USR2_TXDC))
		barrier();
	............................................................

This patch resets the uart port all the time in the imx_startup().
And fix the hang.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for Advantech PCM-3614I/PCM-3618I serial expansion cards

Advantech makes a variety of serial port expansion cards, including the
PCM-3614 and PCM-3618
(http://www.advantech.com/products/1-2JKLU5/PCM-3618/mod_5DF8DE5A-6B49-4429-BB2F-CB35FE1D168D.aspx).
They have a driver available which was forked from the kernel driver
ages ago and has not been maintained in quite some time, available at
http://support.advantech.com.tw/Support/DownloadSRDetail_New.aspx?SR_ID=1-1W8FZ5&Doc_Source=Download
Their driver added several features to aid in communications at higher
baud rates, but at normal serial port speeds, the standard 8250_pci
driver functions just fine. This patch adds the necessary PCI IDs to
recognize this card.

See bug 75681 (https://bugzilla.kernel.org/show_bug.cgi?id=75681)
Signed-off-by: NThomee Wright <TWright@TMCDesign.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Bit 7 of UCR3 is described in the i.MX reference manuals (with the exception
of i.MX1) as follows:

ADNIMP: Autobaud Detection Not Improved-. Disables new features of
	autobaud detection (See Baud Rate Automatic Detection
	Protocol, for more details).

	0 Autobaud detection new features selected
	1 Keep old autobaud detection mechanism

The "new features" mechanism occasionally cause the receiver to get out of sync
and continuously produce received characters of '\xff'.

In order to reproduce the problem:

$ stty -F /dev/ttymxc0 19200

- Change the terminal baudrate to 19200

- Type in the console and it should look good

- Change the terminal baudrate back to 115200

- Type 'b' in the console, then a stream of garbage characters is seen.

Also rename the bit definition as per the reference manual.

Tested on mx6q, mx6dl, mx6solo and mx53.

Based on a patch from Eric Nelson for U-boot.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Tested-by: NEric Nelson <eric.nelson@boundarydevices.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Simply document a new compat string.
There appears to be no need for a driver updates.
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This Multi-IO card has one serial 16550-like and one parallel port connector.
Here's the lspci output, after this commit is applied:

03:07.0 Serial controller: Device 4348:5053 (rev 10) (prog-if 02 [16550])
	Subsystem: Device 4348:5053
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 21
	Region 0: I/O ports at cf00 [size=8]
	Region 1: I/O ports at ce00 [size=8]
	Kernel driver in use: parport_serial
	Kernel modules: 8250_pci, parport_serial

This commit adds an entry with the device ID to the blacklist declared in
8250_pci to prevent the driver from taking ownership. Also, and as was done
for the 2S/1P variant, add a quirk to skip autodetection and set the correct
type to 16550A clone.

Proper entries are added to parport_serial, to support the device parallel
and serial ports.

Cc: Gianluca Anzolin <gianluca@sottospazio.it>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add missing specification of efm32_uart_exit as module_exit.

This fixes the following compilation warning:

  drivers/tty/serial/efm32-uart.c:840:123: warning: ‘efm32_uart_exit’ defined but not used [-Wunused-function]
Signed-off-by: NVincent Stehlé <vincent.stehle@laposte.net>
Cc: Jiri Slaby <jslaby@suse.cz>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add format and argument checking and fix misuses in the dbg macro.

Add __printf
Use %pR for resource
Add #include guard to samsung.h
Move static functions from .h to .c
Use vscnprintf instead of length unguarded vsprintf
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Don't activate the TX Space available IRQ on startup, or a simple
$ cat /dev/ttyHSU0
will cause an endless amount of IRQs, as there is always space in
the TX FIFO available if no data is going to be sent.

Also correct comments for IRQ names (RX and TX swapped).
Signed-off-by: NJohannes Thumshirn <johannes.thumshirn@men.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On my test platform (B2020/STiH416) the serial port issues bad characters
during the initial message avalanche as the console comes up. The problem
also occurs when dense(ish) I/O is done using the polled I/O interface.

The problem is fixed for me by using the FIFO half-empty bit rather than
FIFO full bit. Note that using the half-empty bit causes the FIFO to be
managed in a similar way to interrupt based I/O (i.e. where the hardware
gets best test coverage).

Running the FIFO half full will have no impact (good or bad) on console
performance. The UART will still remain fully saturated and the busy-wait
until the FIFO is empty in asc_console_write() will complete at the same
time.
Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Acked-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Xilinx MDM (Microblaze Debug Module) also contains
uart interface via JTAG which is compatible with
uartlite driver. This interface is really slow
that's why timeout is setup to 1s.

Make this time delay not to be cpu speed dependent.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Acked-by: NPeter Korsgaard <peter@korsgaard.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If NO_DMA=y:

drivers/built-in.o: In function `lpuart_dma_rx_free':
fsl_lpuart.c:(.text+0x7da28): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `lpuart_dma_tx_free':
fsl_lpuart.c:(.text+0x7da60): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `lpuart_dma_rx':
fsl_lpuart.c:(.text+0x7dab8): undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `lpuart_dma_tx':
fsl_lpuart.c:(.text+0x7db7e): undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `lpuart_copy_rx_to_tty':
fsl_lpuart.c:(.text+0x7dcd4): undefined reference to `dma_sync_single_for_cpu'
make[3]: *** [vmlinux] Error 1
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb78b811 provide a workaround for
kernel panic, but bring potential deadlock risk. that is in
sirfsoc_rx_tmo_process_tl while enter into sirfsoc_uart_pio_rx_chars
cpu hold uart_port->lock, if uart interrupt comes cpu enter into
sirfsoc_uart_isr and deadlock occurs in getting uart_port->lock.

the patch replace spin_lock version to spin_lock_irq* version to avoid
spinlock dead lock issue. let function tty_flip_buffer_push in tasklet
outof spin_lock_irq* protect area to avoid add the pair of spin_lock and
spin_unlock for tty_flip_buffer_push.
BTW drop self defined unused spinlock protect of tx_lock/rx_lock.

56274.220464] BUG: spinlock lockup suspected on CPU#0, swapper/0/0
[56274.223648]  lock: 0xc05d9db0, .magic: dead4ead, .owner: swapper/0/0,
	.owner_cpu: 0
	[56274.231278] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G
	O 3.10.35 #1
	[56274.238241] [<c0015530>] (unwind_backtrace+0x0/0xf4) from
	[<c00120d8>] (show_stack+0x10/0x14)
	[56274.246742] [<c00120d8>] (show_stack+0x10/0x14) from
	[<c01b11b0>] (do_raw_spin_lock+0x110/0x184)
	[56274.255501] [<c01b11b0>] (do_raw_spin_lock+0x110/0x184) from
	[<c02124c8>] (sirfsoc_uart_isr+0x20/0x42c)
	[56274.264874] [<c02124c8>] (sirfsoc_uart_isr+0x20/0x42c) from
	[<c0075790>] (handle_irq_event_percpu+0x54/0x17c)
	[56274.274758] [<c0075790>] (handle_irq_event_percpu+0x54/0x17c)
	from [<c00758f4>] (handle_irq_event+0x3c/0x5c)
	[56274.284561] [<c00758f4>] (handle_irq_event+0x3c/0x5c) from
	[<c0077fa0>] (handle_level_irq+0x98/0xfc)
	[56274.293670] [<c0077fa0>] (handle_level_irq+0x98/0xfc) from
	[<c0074f44>] (generic_handle_irq+0x2c/0x3c)
	[56274.302952] [<c0074f44>] (generic_handle_irq+0x2c/0x3c) from
	[<c000ef80>] (handle_IRQ+0x40/0x90)
	[56274.311706] [<c000ef80>] (handle_IRQ+0x40/0x90) from
	[<c000dc80>] (__irq_svc+0x40/0x70)
	[56274.319697] [<c000dc80>] (__irq_svc+0x40/0x70) from
	[<c038113c>] (_raw_spin_unlock_irqrestore+0x10/0x48)
	[56274.329158] [<c038113c>]
	(_raw_spin_unlock_irqrestore+0x10/0x48) from [<c0200034>]
	(tty_port_tty_get+0x58/0x90)
	[56274.339213] [<c0200034>] (tty_port_tty_get+0x58/0x90) from
	[<c0212008>] (sirfsoc_uart_pio_rx_chars+0x1c/0xc8)
	[56274.349097] [<c0212008>]
	(sirfsoc_uart_pio_rx_chars+0x1c/0xc8) from [<c0212ef8>]
	(sirfsoc_rx_tmo_process_tl+0xe4/0x1fc)
	[56274.359853] [<c0212ef8>]
	(sirfsoc_rx_tmo_process_tl+0xe4/0x1fc) from [<c0027c04>]
	(tasklet_action+0x84/0x114)
	[56274.369739] [<c0027c04>] (tasklet_action+0x84/0x114) from
	[<c0027db4>] (__do_softirq+0x120/0x200)
	[56274.378585] [<c0027db4>] (__do_softirq+0x120/0x200) from
	[<c0027f44>] (do_softirq+0x54/0x5c)
	[56274.386998] [<c0027f44>] (do_softirq+0x54/0x5c) from
	[<c00281ec>] (irq_exit+0x9c/0xd0)
	[56274.394899] [<c00281ec>] (irq_exit+0x9c/0xd0) from
	[<c000ef84>] (handle_IRQ+0x44/0x90)
	[56274.402790] [<c000ef84>] (handle_IRQ+0x44/0x90) from
	[<c000dc80>] (__irq_svc+0x40/0x70)
	[56274.410774] [<c000dc80>] (__irq_svc+0x40/0x70) from
	[<c0288af4>] (cpuidle_enter_state+0x50/0xe0)
	[56274.419532] [<c0288af4>] (cpuidle_enter_state+0x50/0xe0) from
	[<c0288c34>] (cpuidle_idle_call+0xb0/0x148)
	[56274.429080] [<c0288c34>] (cpuidle_idle_call+0xb0/0x148) from
	[<c000f3ac>] (arch_cpu_idle+0x8/0x38)
	[56274.438016] [<c000f3ac>] (arch_cpu_idle+0x8/0x38) from
	[<c0059344>] (cpu_startup_entry+0xfc/0x140)
	[56274.446956] [<c0059344>] (cpu_startup_entry+0xfc/0x140) from
	[<c04a3a54>] (start_kernel+0x2d8/0x2e4)
Signed-off-by: NQipan Li <Qipan.Li@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

All SiRFSoC UART registers are in 32-bits. If we use writeb for
TXFIFO, actually all of 32-bits are still written, for TXTIFO,
only low 8-bits are valid, so in prima2&atlas6, this causes no
problem.
But in the new atlas7, using writeb to write UART registers will
cause an imprecise data abort as HW does check the "wrong" writeb.
So move to writel and this also makes the code consistent with
sirfsoc_uart_pio_tx_chars() in which we use writel.
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Two new drivers have been added since 3.14, the MEN 16z135 uart, and
the ARM semihosting console. Both are missing an explicit 'select
SERIAL_CORE', which can leads build errors when no other driver
selects the core, as found during ARM randconfig testing.
In case of the ARM semihosting console, we also have to select
SERIAL_CORE_CONSOLE.

This adds the missing 'select' statements.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This fixes the warnings:

   drivers/tty/serial/sc16is7xx.c: In function 'sc16is7xx_handle_rx':
>> drivers/tty/serial/sc16is7xx.c:548:1: warning: 'sc16is7xx_handle_rx' uses dynamic stack allocation [enabled by default]
   drivers/tty/serial/sc16is7xx.c: In function 'sc16is7xx_handle_tx':
>> drivers/tty/serial/sc16is7xx.c:589:1: warning: 'sc16is7xx_handle_tx' uses dynamic stack allocation [enabled by default]
Signed-off-by: NJon Ringle <jringle@gridpoint.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

drivers/tty/serial/sc16is7xx.c:1060:12: warning: 'sc16is7xx_probe' defined but not used [-Wunused-function]
 static int sc16is7xx_probe(struct device *dev,
            ^
drivers/tty/serial/sc16is7xx.c:1176:12: warning: 'sc16is7xx_remove' defined but not used [-Wunused-function]
 static int sc16is7xx_remove(struct device *dev)
            ^
drivers/tty/serial/sc16is7xx.c:1215:29: warning: 'regcfg' defined but not used [-Wunused-variable]
 static struct regmap_config regcfg = {
                             ^

Fixed these warnings by removing the `#ifdef CONFIG_REGMAP_I2C' around their
calls as this driver selects REGMAP_I2C in Kconfig. This part of driver just
didn't compile at all when REGMAP_I2C configured as module (CONFIG_REGMAP_I2C
is not defined, just CONFIG_REGMAP_I2C_MODULE).
Signed-off-by: NJan Moskyto Matejka <mq@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On initialization failure, an error message is already printed with
level KERN_ERR, no need to print another one with level KERN_INFO.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The pch_uart driver is for a companion chip to the Intel Atom E600
series processors. These are 32-bit x86 processors so the driver is
only needed on X86_32. Add COMPILE_TEST as an alternative, so that the
driver can still be build-tested elsewhere.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 9aac5887 (tty/serial: add generic serial earlycon) moved
console option parsing from 8250_early.c and converted to kstrto*
functions from simple_strtoul along the way. However, kstrto* functions
are not equivalent in that they do not allow non-convertible characters
at the end such as "115200n8". Fix this by changing back to
simple_strtoul and ignore what checkpatch.pl says.
Reported-by: NYinghai Lu <yinghai@kernel.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: linux-serial@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit d2fd6810 (tty/serial: convert 8250 to generic earlycon)
removed setup_early_serial8250_console, but there are still 2 callers
in:

arch/mips/mti-malta/malta-init.c
drivers/firmware/pcdp.c

Add back the function implemented as a wrapper to setup_earlycon.
Reported-by: NYinghai Lu <yinghai@kernel.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: linux-serial@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The asm-generic, big-endian version of zero_bytemask creates a mask of
bytes preceding the first zero-byte by left shifting ~0ul based on the
position of the first zero byte.

Unfortunately, if the first (top) byte is zero, the output of
prep_zero_mask has only the top bit set, resulting in undefined C
behaviour as we shift left by an amount equal to the width of the type.
As it happens, GCC doesn't manage to spot this through the call to fls(),
but the issue remains if architectures choose to implement their shift
instructions differently.

An example would be arch/arm/ (AArch32), where LSL Rd, Rn, #32 results
in Rd == 0x0, whilst on arch/arm64 (AArch64) LSL Xd, Xn, #64 results in
Xd == Xn.

Rather than check explicitly for the problematic shift, this patch adds
an extra shift by 1, replacing fls with __fls. Since zero_bytemask is
never called with a zero argument (has_zero() is used to check the data
first), we don't need to worry about calling __fls(0), which is
undefined.

Cc: <stable@vger.kernel.org>
Cc: Victor Kamensky <victor.kamensky@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This merges the patch to fix possible loss of dirty bit on munmap() or
madvice(DONTNEED).  If there are concurrent writers on other CPU's that
have the unmapped/unneeded page in their TLBs, their writes to the page
could possibly get lost if a third CPU raced with the TLB flush and did
a page_mkclean() before the page was fully written.

Admittedly, if you unmap() or madvice(DONTNEED) an area _while_ another
thread is still busy writing to it, you deserve all the lost writes you
could get.  But we kernel people hold ourselves to higher quality
standards than "crazy people deserve to lose", because, well, we've seen
people do all kinds of crazy things.

So let's get it right, just because we can, and we don't have to worry
about it.

* safe-dirty-tlb-flush:
  mm: split 'tlb_flush_mmu()' into tlb flushing and memory freeing parts

Pull btrfs fixes from Chris Mason.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: limit the path size in send to PATH_MAX
  Btrfs: correctly set profile flags on seqlock retry
  Btrfs: use correct key when repeating search for extent item
  Btrfs: fix inode caching vs tree log
  Btrfs: fix possible memory leaks in open_ctree()
  Btrfs: avoid triggering bug_on() when we fail to start inode caching task
  Btrfs: move btrfs_{set,clear}_and_info() to ctree.h
  btrfs: replace error code from btrfs_drop_extents
  btrfs: Change the hole range to a more accurate value.
  btrfs: fix use-after-free in mount_subvol()

Pull arm fixes from Russell King:
 "A number of fixes for the PJ4/iwmmxt changes which arm-soc forced me
  to take during the merge window.  This stuff should have been better
  tested and sorted out *before* the merge window"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 8042/1: iwmmxt: allow to build iWMMXt on Marvell PJ4B
  ARM: 8041/1: pj4: fix cpu_is_pj4 check
  ARM: 8040/1: pj4: properly detect existence of iWMMXt coprocessor
  ARM: 8039/1: pj4: enable iWMMXt only if CONFIG_IWMMXT is set
  ARM: 8038/1: iwmmxt: explicitly check for supported architectures

Pull arm64 fixes from Catalin Marinas:
 - compat renameat2 syscall wiring and __NR_compat_syscalls fix
 - TLB fix for transparent huge pages following switch to generic
   mmu_gather
 - spinlock initialisation for init_mm's context
 - move of_clk_init() earlier
 - Kconfig duplicate entry fix

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: init: Move of_clk_init to time_init
  arm64: initialize spinlock for init_mm's context
  arm64: debug: remove noisy, pointless warning
  arm64: mm: Add THP TLB entries to general mmu_gather
  arm64: add renameat2 compat syscall
  ARM64: Remove duplicated Kconfig entry for "kernel/power/Kconfig"
  arm64: __NR_compat_syscalls fix