The check sts & USR1_DTRD was just evaluated to true two lines above.
So this change doesn't have any effect on the semantic of the driver.

Fixes: 27e16501 ("serial: imx: implement DSR irq handling for DTE mode")
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NShawn Guo <shawnguo@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Bit pattern STAT_FRM_ERR is being bit-wise or'd twice; remove the
redundant 2nd STAT_FRM_ERR
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This allows me to login after sending a break when service
serial-getty@ttymxc0.service is running

The "tty_insert_flip_char(port, 0, TTY_BREAK)" in clear_rx_errors
fixes this by allowing the higher layers to see a break.

Also, call uart_handle_break to handle possible
"secure attention key."

FYI: Martin said the ROM sdma firmware works with this patch,
but external sdma firmware still does not send breaks on a
i.mx6UL
Signed-off-by: NTroy Kisky <troy.kisky@boundarydevices.com>
Tested-by: NMartin Hicks <mort@bork.org>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

An issue has been observed on the Marvell Armada 38x serial port.

Writes to UART_LCR can result in characters that are currently held in the
TX FIFO being lost rather than sent, even if the userspace process has
attempted to flush them.

This is most visible when using the "resize" command (tested on Busybox),
where we have observed the escape code for restoring cursor position
becoming mangled.
Signed-off-by: NJoshua Scott <joshua.scott@alliedtelesis.co.nz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

High latencies of classic timers cause performance issues for high-
speed serial transmissions. This patch transforms rx_timer into an
hrtimer to reduce the minimum latency.
Signed-off-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

omap_8250_throttle() is called when tty RX buffer is about to overflow
and can no longer keep up with the rate at which UART is receiving data.
So, the expectation of this callback, is that UART stops RX and asserts
HW flow control to signal the sender to stop sending more data.
omap_8250_throttle() disables RX FIFO interrupts thus FIFO is no longer
serviced, leading to assertion of flow control once RX FIFO is full.
But, this does not work when DMA is enabled as driver keeps queuing new
RX DMA request in completion handler without brothering about throttling
request made by the higher layer.
This patch introduces a flag that can be used to determine whether or
not to queue next RX DMA request based on throttling request.

Without this patch, tty buffer overflows are reported at higher
baudrates.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, data in RX FIFO is read based on UART_LSR register state even
if RDI and RLSI interrupts are disabled in UART_IER register.
This is because when IRQ handler is called due to TX FIFO empty event,
RX FIFO is serviced based on UART_LSR register status instead of
UART_IIR status. This defeats the purpose of disabling UART RX
FIFO interrupts during throttling(see, omap_8250_throttle()) as IRQ
handler continues to drain UART RX FIFO resulting in overflow of buffer
at tty layer.
Fix this by making sure that driver drains UART RX FIFO only when
UART_IIR_RDI is set along with UART_LSR_BI or UART_LSR_DR bits.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some debugging tools (/sys/kernel/debug/gpio, `lsgpio`) use the
gpio_chip's label for displaying an additional context. Right now, the
information duplicates stuff which is already available from the
parent's device. This is how e.g. `lsgpio`'s output looks like:

  GPIO chip: gpiochip2, "spi1.2", 16 GPIO lines

Comparing the output of other GPIO expanders that I have available:

  gpiochip4: GPIOs 464-479, parent: spi/spi1.1, mcp23s17, can sleep:
  gpiochip5: GPIOs 448-463, parent: i2c/0-0020, pca9555, can sleep:
  gpiochip2: GPIOs 496-511, parent: spi/spi1.2, spi1.2, can sleep:

This patch ensures that the type of the real HW device is shown instead
of duplicating the SPI path:

  gpiochip2: GPIOs 496-511, parent: spi/spi1.2, MAX14830, can sleep:
Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The UART can be operated without an irq. In this case a timer is setup
that regularily calls altera_uart_interrupt(). The receiving part
depends on pp->imr having the bit ALTERA_UART_STATUS_RRDY_MSK set,
otherwise altera_uart_rx_chars() is never called. So ensure that the bit
gets set (disguised as ALTERA_UART_CONTROL_RRDY_MSK) by not returning
early from altera_uart_startup() if port->irq is 0.

This doesn't affect the hardware as the ALTERA_UART_CONTROL_RRDY_MSK bit
isn't actually written to the control register.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the irq line of an altera UART device isn't used to report interrupts
for this device the driver better ensures that this device doesn't pull
this line to active state and so disturb the whatever might be connected
to this line.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Most register accesses in the altera driver honor port->regshift by
using altera_uart_writel(). There are a few accesses however that were
missed when the driver was converted to use port->regshift and some
others were added later in commit 4d9d7d89 ("serial: altera_uart:
add earlycon support").

Fixes: 2780ad42 ("tty: serial: altera_uart: Use port->regshift to store bus shift")
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

SPCR is currently only enabled or ARM64 and x86 can use SPCR to setup
an early console.

General fixes include updating Documentation & Kconfig (for x86),
updating comments, and changing parse_spcr() to acpi_parse_spcr(),
and earlycon_init_is_deferred to earlycon_acpi_spcr_enable to be
more descriptive.

On x86, many systems have a valid SPCR table but the table version is
not 2 so the table version check must be a warning.

On ARM64 when the kernel parameter earlycon is used both the early console
and console are enabled.  On x86, only the earlycon should be enabled by
by default.  Modify acpi_parse_spcr() to allow options for initializing
the early console and console separately.
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Reviewed-by: NMark Salter <msalter@redhat.com>
Tested-by: NMark Salter <msalter@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Exar sleep wake-up handling has been done on a per-channel basis by
virtue of INT0 being accessible from each channel's address space. I
believe this was initially done out of necessity, but now that Exar
devices have their own driver, we can do things more efficiently by
registering a dedicated INT0 handler at the PCI device level.

I see this change providing the following benefits:

    1. If more than one port is active, eliminates the redundant bus
       cycles for reading INT0 on every interrupt.
    2. This note associated with hooking in the per-channel handler in
       8250_port.c is resolved:
        /* Fixme: probably not the best place for this */

Cc: Matt Schulte <matts@commtech-fastcom.com>
Signed-off-by: NAaron Sierra <asierra@xes-inc.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Before we go into suspend mode, we enable the imx uart's interrupt for
the awake bit in the UART Status Register 1. If, for some reason, the
awake bit is already set before we enter suspend mode, we get an
interrupt immediately when we enable interrupts for awake. The uart's
clk_ipg is disabled at this point (unless there's an ongoing transfer).
We end up in the interrupt handler, which usually tries to clear the
awake bit. This doesn't work with the clock disabled. Therefore, we
keep getting interrupts forever, resulting in an endless loop.

Clear the awake bit before setting the awaken bit to signal that we want
an imx interrupt when the awake bit will be set. This ensures that we're
not woken up by events that happened before we started going into
suspend mode.

Change the clock handling so that suspend prepares and enables the clock
and suspend_noirq disables it. Revert these operations in resume_noirq and
resume.

With these preparations in place, we can now modify awake and awaken in
the suspend function when the actual imx interrupt is disabled and the
required clk_ipg is active.

Update the thaw and freeze functions to use the new clock handling since
we share the suspend_noirq function between suspend and hibernate.
Signed-off-by: NMartin Kaiser <martin@kaiser.cx>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

setserial changes the IRQ via uart_set_info(). It invokes
uart_shutdown() which free the current used IRQ and clear
TTY_PORT_INITIALIZED. It will then update the IRQ number and invoke
uart_startup() before returning to the caller leaving
TTY_PORT_INITIALIZED cleared.

The next open will crash with
|  list_add double add: new=ffffffff839fcc98, prev=ffffffff839fcc98, next=ffffffff839fcc98.
since the close from the IOCTL won't free the IRQ (and clean the list)
due to the TTY_PORT_INITIALIZED check in uart_shutdown().

There is same pattern in uart_do_autoconfig() and I *think* it also
needs to set TTY_PORT_INITIALIZED there.
Is there a reason why uart_startup() does not set the flag by itself
after the IRQ has been acquired (since it is cleared in uart_shutdown)?
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The documentation was wrong, gpiod_get_direction() returns 0/1 instead
of the GPIOF_* flags. The docs were fixed with commit 94fc7309
("gpio: correct docs about return value of gpiod_get_direction"). Now,
fix this user (until a better, system-wide solution is in place). This
also means we can drop the deprecated use of 'linux/gpio.h'. Yay!
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit

  de9e33bd ("serial: 8250_dw: Improve clock rate setting")

obviously tries to cure symptoms, and not a root cause.

The root cause is the non-flexible rate calculation inside the
corresponding clock driver. What we need is to provide maximum UART
divisor value to the clock driver to allow it do the job transparently
to the caller.

Since from the initial commit message I have got no clue which clock
driver actually needs to be amended, I leave this exercise to the people
who know better the case.

Moreover, it seems [1] the fix introduced a regression. And possible
even one more [2].

Taking above, revert the commit de9e33bd for now.

[1]: https://www.spinics.net/lists/linux-serial/msg28872.html
[2]: https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-357583782

Fixes: de9e33bd ("serial: 8250_dw: Improve clock rate setting")
Cc: stable <stable@vger.kernel.org> # 4.15
Cc: Ed Blake <ed.blake@sondrel.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Lukas Wunner <lukas@wunner.de>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The push-pull vs. open-drain are the only supported output modes. The
inputs are always unconditionally equipped with weak pull-downs. That's
the only mode, so there's probably no point in exporting that. I wonder
if it's worthwhile to provide a custom dbg_show method to indicate the
current status of the outputs, though.

This patch and [1] for i2c-gpio together make it possible to bit-bang an
I2C bus over GPIOs of an UART which is connected via SPI :). Yes, this
is crazy, but it's fast enough (while on a 26Mhz SPI HW bus with a
dual-core 1.6GHz CPU) to drive an I2C bus at 200kHz, according to my
scope.

[1] https://patchwork.ozlabs.org/patch/852591/Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the devicetree, it is possible to specify the baudrate, parity,
bits, flow of the early console, by passing a configuration string like
this:

aliases {
	serial0 = &uart0;
};

chosen {
	stdout-path = "serial0:57600n8";
};

This, for instance, will configure the early console for a baudrate of
57600 bps, no parity, and 8 bits per baud.

This patches implements parsing of this configuration string in the
8250_ingenic driver, which previously just ignored it.
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The JZ4770 SoC's UART is no different from the other JZ SoCs, so this
commit simply adds the ingenic,jz4770-uart compatible string.
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The pointed string is never modified from within uart_parse_options, so
it should be marked as const in the function prototype.
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The error pointer from devm_reset_control_get_optional_shared() is
not propagated.

One of the most common problem scenarios is it returns -EPROBE_DEFER
when the reset controller has not probed yet.  In this case, the
probe of the reset consumer should be deferred.

Fixes: e2860e1f ("serial: 8250_of: Add reset support")
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS
lines, so only allow such wakeup method when the system actually has
RTS/CTS support.

Fixes: bc85734b ("serial: imx: allow waking up on RTSD")
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: NMartin Kaiser <martin@kaiser.cx>
Acked-by: NFugang Duan <fugang.duan@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix to return a negative error code from the port register error
handling case instead of 0, as done elsewhere in this function.

Fixes: 39be40ce ("serial: 8250_uniphier: fix serial port index in private data")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The rs485 flag "SER_RS485_RTS_AFTER_SEND" was wrongly read from the GPIO
flags. This caused the RTS pin to be high during boot.
Signed-off-by: NRafael Gago Castano <rgc@hms.se>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

All calls to neo_copy_data_from_uart_to_queue() are safeguarded
against NULL dereference of its parameter, except the one that
this patch changes.

That said, let's play safe and check for NULL in this case too.
Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After inspection made by Markus using Coccinelle software, he
observed that we could possibly be triggering a NULL pointer
dereference in 2 functions [0].

After discussion in mailing list, it was observed in fact
we have two unnecessary checks for NULL pointer, and they
were leading to Coccinelle warn. So, instead of reworking
the code as proposed by him, we hereby remove the
unnecessary checks, and also some unneeded extra lines in
the code.

These two unnecessary NULL checks were tracked in the call
chain as never NULL, so they can be safely removed.
No functional changes are intended.

[0] https://lkml.org/lkml/2017/11/29/705Suggested-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.

Done with perl script:

$ git grep -w --name-only DEVICE_ATTR | \
  xargs perl -i -e 'local $/; while (<>) { s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S_IWUSR|\s*S_IWUSR\s*\|\s*S_IRUGO\s*|\s*0644\s*)\)?\s*,\s*\1_show\s*,\s*\1_store\s*\)/DEVICE_ATTR_RW(\1)/g; print;}'
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Prior to this patch, the code would happily trigger TX on some ports
before having a chance of reading the RX buffer from the rest of them.
When no flow control was used, this led to RX buffer overruns and
therefore lost data under certain circumstances.

I was able to reproduce this with MAX14830 (that's a quad channel one)
and a simple daisy-chain of RX and TX ports on the eval board:

- TX0 -> RX1
- TX1 -> RX2
- TX2 -> RX3
- TX3 -> RX0

I was testing this by transferring 2MB of data at 115200 baud via each
port. I used a Solidrun Clearfog Base (Armada 388) which was talking to
the UART over an SPI bus clocked at 26MHz (the chip's maximum). Without
this patch, I would always get a "Possible RX FIFO overrun" in dmesg,
and fewer-than-expected amount of bytes received over ttyMAX0. Results
on ttyMAX{1,2,3} tended to be correct all the time, even without the
previous patches in this series and with PIO SPI transfers ("indirect
mode" as the Marvell datasheet calls it), so I assume that heavy
congestion is needed in order to reproduce this.

A drawback of this patch is that the throughput gets reduced "a bit".
Previously, a 115200 baud resulted in about 11.2kBps throughput as
reported by a simple `pv`. With this patch, the throughput of four
parallel streams is roughly 7kBps each, and 9kBps for three streams.
There is no slowdown for one or two parallel streams.

Situation is worse if bytes are being read one-by-one (such as if the
userspace wants to perform parity/framing/break checking) and therefore
without the batched reads.

With just this patch and no other modifications on top of 4.14, I was
only getting roughly 3.6kBps with four parallel streams. The
single-stream performance was the same, and I was seeing about 7.2kBps
with two parallel streams. `perf top` said that a substantial amount of
time was spent in `finish_task_switch`, `_raw_spin_unlock_irqrestore`
and `__timer_delay`.
Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The hardware has a 128 byte RX FIFO buffer for each independent UART.
Previously, the code was always reading that byte-by-byte via
independent SPI transactions and the associated overhead. In practice,
this led to up to eight bytes over SPI for just one byte in the UART's
RX FIFO:

- reading the global IRQ register (two bytes, one for command, the other
for data)
- reading one UART's ISR (again two bytes)
- reading the byte count (two bytes yet again)
- finally, reading one byte of the FIFO via another two-byte transaction

We cannot always use a batched read. If the TTY is set to intercept
break conditions or report framing or parity errors, then it is required
to check the Line Status Register (LSR) for each byte which is read from
the RX FIFO. The documentation does not show a way of doing that in a
single SPI transaction; registers 0x00 and 0x04 are separate.

In my testing, this is no silver bullet. I was feeding 2MB of random
data over four daisy-chaned UARTs of MAX14830, and this is the
distribution that I was getting:

- R <= 1: 7437322
- R <= 2: 162093
- R <= 4: 4093
- R <= 8: 4196
- R <= 16: 645
- R <= 32: 165
- R <= 64: 58
- R <= 128: 0

For a reference, batching the write operations works much better:

- W <= 1: 2664
- W <= 2: 1305
- W <= 4: 627
- W <= 8: 371
- W <= 16: 121
- W <= 32: 68
- W <= 64: 33
- W <= 128: 63139

That's probably because this HW/SW combination (Clearfog Base, Armada
388) is probably "good enough" to react to the chip's IRQ "fast enough"
most of the time. Still, I was getting RX overruns every now and then.
In future, I plan to improve this by letting the RX FIFO be filled a
little more (the chip has support for that and also for a "stale
timeout" to prevent additional starvation).
Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The transmit register supports batched writes. The key is simply to keep
sending additional bytes up to the FIFO size in the same SPI
transaction with the CS pin still being held low.

This duplicates the regmap infrastructure to a certain extent. There are
some provisions for multiple writes in there, but there does not appear
to be any support for those writes which are destined to the *same*
register (and also no standard for SPI bus transfers of these, anyway).

This patch does not solve every case (if the UART xmit circular buffer
wraps around, we're still doing two SPI transactions), but at least
it's not one-byte-per-transaction anymore.

This change does not touch the receive path at this time. Doing that in
the generic case appears to be impossible in the general case, because
the chips' status register contains data about the *current* byte in the
HW's Rx FIFO. We cannot read these two registers in one go,
unfortunately.
Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

According to my chip's datasheet [1], the IRQ output is an open
collector pin which is suitable for sharing with other chips. The chip
also has a register which indicates which UART performed a change and
the driver checks that register already, so we have everything what is
needed to effectively share the IRQ GPIO.

[1] https://datasheets.maximintegrated.com/en/ds/MAX14830.pdfSigned-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As suggested by Russell King, a driver should not really care about bits
such as the interrupt polarity or whether it is edge- or level-
triggered. The reasons for that include:

- an upstream IRQ controller which cannot support edge- or
level-triggered interrupts,
- board design with a built-in inverter

The interrupt type is being already specified by the Device Tree,
anyway. Other drivers (gpio/gpio-tc3589x.c for example) already work in
this way, delegating the proper IRQ line setup to the DT and not
specifying anything by hand.

Also, there's no reason to have the IRQ flags split between two places.
The SPI probing is the only entry point anyway.
Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When compile-testing an allmodconfig kernel for a platform without
sh-sci serial ports, the SERIAL_SH_SCI_NR_UARTS symbol of type "int"
doesn't get assigned a numerical default value, but an empty string,
leading to a build failure:

   .config:3814:warning: symbol value '' invalid for SERIAL_SH_SCI_NR_UARTS
   ...
   make[3]: *** [silentoldconfig] Error 1

Fix this by explicitly providing a default value of 2, like before.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Fixes: f6731485 ("tty: serial: sh-sci: Hide number of ports config question")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The `max310x_spi_probe` function attempted to setup the GPIO bits before
the corresponding structs for each serial port were initialized. If the
DTS file specified a GPIO hog, this led to a crash because the GPIO
stack ended up calling `max310x_gpio_direction_output` which referenced
uninitialized memory:

 [<c04598c0>] (max310x_gpio_direction_output) from [<c03f5a2c>] (_gpiod_direction_output_raw+0x94/0x2d4)
 [<c03f5a2c>] (_gpiod_direction_output_raw) from [<c03f991c>] (gpiod_hog+0x6c/0x154)
 [<c03f991c>] (gpiod_hog) from [<c03fa2d8>] (of_gpiochip_add+0x28c/0x444)
 [<c03fa2d8>] (of_gpiochip_add) from [<c03f6b2c>] (gpiochip_add_data+0x4f8/0x760)
 [<c03f6b2c>] (gpiochip_add_data) from [<c03f6dd4>] (devm_gpiochip_add_data+0x40/0x7c)
 [<c03f6dd4>] (devm_gpiochip_add_data) from [<c0459fec>] (max310x_spi_probe+0x530/0x894)
 [<c0459fec>] (max310x_spi_probe) from [<c0503294>] (spi_drv_probe+0x7c/0xac)
 [<c0503294>] (spi_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8)
 [<c046628c>] (driver_probe_device) from [<c0464890>] (bus_for_each_drv+0x60/0x94)
 [<c0464890>] (bus_for_each_drv) from [<c0465f78>] (__device_attach+0xb0/0x114)
 [<c0465f78>] (__device_attach) from [<c0465548>] (bus_probe_device+0x84/0x8c)
 [<c0465548>] (bus_probe_device) from [<c0463a00>] (device_add+0x3f4/0x580)
 [<c0463a00>] (device_add) from [<c0504164>] (spi_add_device+0x9c/0x134)
 [<c0504164>] (spi_add_device) from [<c0504c18>] (spi_register_controller+0x484/0x910)
 [<c0504c18>] (spi_register_controller) from [<c0506ee0>] (orion_spi_probe+0x2f4/0x3b4)
 [<c0506ee0>] (orion_spi_probe) from [<c0467dac>] (platform_drv_probe+0x50/0xb0)
 [<c0467dac>] (platform_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8)
 [<c046628c>] (driver_probe_device) from [<c04663f8>] (__driver_attach+0xb8/0xbc)
 [<c04663f8>] (__driver_attach) from [<c04647e8>] (bus_for_each_dev+0x68/0x9c)
 [<c04647e8>] (bus_for_each_dev) from [<c046574c>] (bus_add_driver+0x104/0x210)
 [<c046574c>] (bus_add_driver) from [<c0466f14>] (driver_register+0x78/0xf4)
 [<c0466f14>] (driver_register) from [<c0101bdc>] (do_one_initcall+0x44/0x168)
 [<c0101bdc>] (do_one_initcall) from [<c0a00dc0>] (kernel_init_freeable+0x140/0x1cc)
 [<c0a00dc0>] (kernel_init_freeable) from [<c078c590>] (kernel_init+0x8/0x108)
 [<c078c590>] (kernel_init) from [<c0107a50>] (ret_from_fork+0x14/0x24)

This can be easily fixed by moving the corresponding code below. And
because the UARTs are already there by the time we reach this point, the
`goto` needs changing so that more stuff is freed. (I have not tested
this error path.)
Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If uart_add_one_port() fails in mxs_auart_probe, the clks has
to be disabled.Two clks are previously enabled in mxs_get_clks().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NBranislav Radocaj <branislav@radocaj.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixed a spelling error in a comment.
Signed-off-by: NRolf Evers-Fischer <rolf.evers.fischer@aptiv.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If there is no clock rate for uartclk defined, disable the previously
enabled clock again.

Found by Linux Driver Verification project (linuxtesting.org).

Fixes: 23f5b3fd serial: 8250_dw: only get the clock rate in one place
Signed-off-by: NStefan Potyra <Stefan.Potyra@elektrobit.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch replaces stm32 tty name ttyS by ttySTM
to avoid a name conflict when Serial: 8250/16550 driver
is activated.

sysfs: cannot create duplicate filename '/class/tty/ttyS3'
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-12903-gb392521-dirty #1
[<c03118dc>] (unwind_backtrace) from [<c030c950>] (show_stack+0x10/0x14)
[<c030c950>] (show_stack) from [<c0d31e18>] (dump_stack+0x90/0xa4)
[<c0d31e18>] (dump_stack) from [<c03430a0>] (__warn+0xf8/0x110)
[<c03430a0>] (__warn) from [<c03430f0>] (warn_slowpath_fmt+0x38/0x48)
[<c03430f0>] (warn_slowpath_fmt) from [<c04ce574>] (sysfs_warn_dup+0x68/0x78)
[<c04ce574>] (sysfs_warn_dup) from [<c04ce824>] (sysfs_do_create_link_sd+0xb4/0xc4)
[<c04ce824>] (sysfs_do_create_link_sd) from [<c08c60ec>] (device_add+0x204/0x574)
[<c08c60ec>] (device_add) from [<c07a7ddc>] (tty_register_device_attr+0xc8/0x1bc)
[<c07a7ddc>] (tty_register_device_attr) from [<c07c6530>] (uart_add_one_port+0x22c/0x4f4)
Signed-off-by: NLudovic Barre <ludovic.barre@st.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On most Renesas ARM platforms, the SCIF serial ports can be used with
DMA, so most users will want DMA support to be enabled.

On SuperH platforms, SCI(F) serial ports cannot be used with DMA yet
(see also commit 219fb0c1 ("serial: sh-sci: Remove the platform
data dma slave rx/tx channel IDs")), so users will want it disabled to
reduce kernel size.

Hence follow the above rationale to configure the default, unless
CONFIG_EXPERT is enabled.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>