Fix two occurrences where "transfer" is spelled incorrectly.
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20200818224457.16507-1-festevam@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use platform_get_resource() to fetch the memory resource
instead of open-coded variant.

While here, fail the probe if no resource found or no port is added.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200804134807.11589-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

As in the previous patches, fix kernel-doc in serial drivers.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200818085655.12071-8-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: NRomain Perier <romain.perier@gmail.com>
Signed-off-by: NAllen Pais <allen.lkml@gmail.com>
Link: https://lore.kernel.org/r/20200817085921.26033-5-allen.cryptic@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: NRomain Perier <romain.perier@gmail.com>
Signed-off-by: NAllen Pais <allen.lkml@gmail.com>
Link: https://lore.kernel.org/r/20200817085921.26033-4-allen.cryptic@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: NRomain Perier <romain.perier@gmail.com>
Signed-off-by: NAllen Pais <allen.lkml@gmail.com>
Link: https://lore.kernel.org/r/20200817085921.26033-3-allen.cryptic@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 679193b7.

It appears that in QEmu the lock has been initialised differently
(it wasn't obvious on real hardware during testing). Let's
revert the change until the better approach will be developed.
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200802111612.36189-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since the serial core handles spin lock initialisation,
let the driver rely on it.

Depends-on: f743061a ("serial: core: Initialise spin lock before use in uart_configure_port()")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200731123733.22754-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

While the STM32 does support RS485 drive-enable control within the
UART IP itself, some systems have the drive-enable line connected
to a pin which cannot be pinmuxed as RTS. Add support for toggling
the RTS GPIO line using the modem control GPIOs to provide at least
some sort of emulation.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-stm32@st-md-mailman.stormreply.com
Link: https://lore.kernel.org/r/20200725144947.537007-1-marex@denx.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The race condition may happen if the UART reference clock is shared with
some other device (on Baikal-T1 SoC it's another DW UART port). In this
case if that device changes the clock rate while serial console is using
it the DW 8250 UART port might not only end up with an invalid uartclk
value saved, but may also experience a distorted output data since
baud-clock could have been changed. In order to fix this lets at least
try to adjust the 8250 port setting like UART clock rate in case if the
reference clock rate change is discovered. The driver will call the new
method to update 8250 UART port clock rate settings. It's done by means of
the clock event notifier registered at the port startup and unregistered
in the shutdown callback method.

Note 1. In order to avoid deadlocks we had to execute the UART port update
method in a dedicated deferred work. This is due to (in my opinion
redundant) the clock update implemented in the dw8250_set_termios()
method.
Note 2. Before the ref clock is manually changed by the custom
set_termios() function we swap the port uartclk value with new rate
adjusted to be suitable for the requested baud. It is necessary in
order to effectively disable a functionality of the ref clock events
handler for the current UART port, since uartclk update will be done
a bit further in the generic serial8250_do_set_termios() function.
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>

Link: https://lore.kernel.org/r/20200723003357.26897-5-Sergey.Semin@baikalelectronics.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Indeed according to the clk API if clk_round_rate() has successfully
accepted a rate, then in order setup the clock with value returned by the
clk_round_rate() the clk_set_rate() method must be called with the
original rate value.
Suggested-by: NRussell King <linux@armlinux.org.uk>
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>

Link: https://lore.kernel.org/r/20200723003357.26897-4-Sergey.Semin@baikalelectronics.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Really instead of twice checking the clk_round_rate() return value
we could do it once, and if it isn't error the clock rate can be changed.
By doing so we decrease a number of ret-value tests and remove a weird
goto-based construction implemented in the dw8250_set_termios() method.
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>

Link: https://lore.kernel.org/r/20200723003357.26897-3-Sergey.Semin@baikalelectronics.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some platforms can be designed in a way so the UART port reference clock
might be asynchronously changed at some point. In Baikal-T1 SoC this may
happen due to the reference clock being shared between two UART ports, on
the Allwinner SoC the reference clock is derived from the CPU clock, so
any CPU frequency change should get to be known/reflected by/in the UART
controller as well. But it's not enough to just update the
uart_port->uartclk field of the corresponding UART port, the 8250
controller reference clock divisor should be altered so to preserve
current baud rate setting. All of these things is done in a coherent
way by calling the serial8250_update_uartclk() method provided in this
patch. Though note that it isn't supposed to be called from within the
UART port callbacks because the locks using to the protect the UART port
data are already taken in there.
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>

Link: https://lore.kernel.org/r/20200723003357.26897-2-Sergey.Semin@baikalelectronics.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Split imx earlycon driver from imx serial driver "imx.c" as
separated driver. imx serial driver can be built as module,
but earlycon driver only support build in.
Signed-off-by: NFugang Duan <fugang.duan@nxp.com>
Link: https://lore.kernel.org/r/20200724070815.11445-3-fugang.duan@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for building i.MX serial driver as module.

The changes of the patch:
- imx console driver can be built as module.
- move out earlycon code to separated driver like imx_earlycon.c,
  and imx earlycon driver only support build-in.
Signed-off-by: NFugang Duan <fugang.duan@nxp.com>
Link: https://lore.kernel.org/r/20200724070815.11445-2-fugang.duan@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Sealevel XR17V35X based devices are inoperable on kernel versions
4.11 and above due to a change in the GPIO preconfiguration introduced in
commit
7dea8165. This patch fixes this by preconfiguring the GPIO on Sealevel
cards to the value (0x00) used prior to commit 7dea8165

With GPIOs preconfigured as per commit 7dea8165 all ports on
Sealevel XR17V35X based devices become stuck in high impedance
mode, regardless of dip-switch or software configuration. This
causes the device to become effectively unusable. This patch (in
various forms) has been distributed to our customers and no issues
related to it have been reported.

Fixes: 7dea8165 ("serial: exar: Preconfigure xr17v35x MPIOs as output")
Signed-off-by: NMatthew Howell <matthew.howell@sealevel.com>
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2007221605270.13247@tstest-VirtualBoxSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add sparse context annotation to the receive handlers, which release and
reacquire the port lock, to silence sparse warnings:

	drivers/tty/serial/msm_serial.c:748:25: warning: context imbalance in 'msm_handle_rx_dm' - unexpected unlock
	drivers/tty/serial/msm_serial.c:814:28: warning: context imbalance in 'msm_handle_rx' - unexpected unlock
Signed-off-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200723123327.5843-3-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add sparse context annotation to the receive handler, which releases and
reacquires the port lock, to silence a sparse warning:

	drivers/tty/serial/pmac_zilog.c:255:36: sparse: sparse: context imbalance in 'pmz_receive_chars' - unexpected unlock
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200723123327.5843-2-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 7b668c06 ("serial: 8250: Fix max baud limit in generic 8250
port") fixed limits of a baud rate setting for a generic 8250 port.
In other words since that commit the baud rate has been permitted to be
within [uartclk / 16 / UART_DIV_MAX; uartclk / 16], which is absolutely
normal for a standard 8250 UART port. But there are custom 8250 ports,
which provide extended baud rate limits. In particular the Mediatek 8250
port can work with baud rates up to "uartclk" speed.

Normally that and any other peculiarity is supposed to be handled in a
custom set_termios() callback implemented in the vendor-specific
8250-port glue-driver. Currently that is how it's done for the most of
the vendor-specific 8250 ports, but for some reason for Mediatek a
solution has been spread out to both the glue-driver and to the generic
8250-port code. Due to that a bug has been introduced, which permitted the
extended baud rate limit for all even for standard 8250-ports. The bug
has been fixed by the commit 7b668c06 ("serial: 8250: Fix max baud
limit in generic 8250 port") by narrowing the baud rates limit back down to
the normal bounds. Unfortunately by doing so we also broke the
Mediatek-specific extended bauds feature.

A fix of the problem described above is twofold. First since we can't get
back the extended baud rate limits feature to the generic set_termios()
function and that method supports only a standard baud rates range, the
requested baud rate must be locally stored before calling it and then
restored back to the new termios structure after the generic set_termios()
finished its magic business. By doing so we still use the
serial8250_do_set_termios() method to set the LCR/MCR/FCR/etc. registers,
while the extended baud rate setting procedure will be performed later in
the custom Mediatek-specific set_termios() callback. Second since a true
baud rate is now fully calculated in the custom set_termios() method we
need to locally update the port timeout by calling the
uart_update_timeout() function. After the fixes described above are
implemented in the 8250_mtk.c driver, the Mediatek 8250-port should
get back to normally working with extended baud rates.

Link: https://lore.kernel.org/linux-serial/20200701211337.3027448-1-danielwinkler@google.com

Fixes: 7b668c06 ("serial: 8250: Fix max baud limit in generic 8250 port")
Reported-by: NDaniel Winkler <danielwinkler@google.com>
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: stable <stable@vger.kernel.org>
Tested-by: NClaire Chang <tientzu@chromium.org>
Link: https://lore.kernel.org/r/20200714124113.20918-1-Sergey.Semin@baikalelectronics.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

I got null-ptr-deref in serial8250_start_tx():

[   78.114630] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[   78.123778] Mem abort info:
[   78.126560]   ESR = 0x86000007
[   78.129603]   EC = 0x21: IABT (current EL), IL = 32 bits
[   78.134891]   SET = 0, FnV = 0
[   78.137933]   EA = 0, S1PTW = 0
[   78.141064] user pgtable: 64k pages, 48-bit VAs, pgdp=00000027d41a8600
[   78.147562] [0000000000000000] pgd=00000027893f0003, p4d=00000027893f0003, pud=00000027893f0003, pmd=00000027c9a20003, pte=0000000000000000
[   78.160029] Internal error: Oops: 86000007 [#1] SMP
[   78.164886] Modules linked in: sunrpc vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce ses enclosure sg sbsa_gwdt ipmi_ssif spi_dw_mmio sch_fq_codel vhost_net tun vhost vhost_iotlb tap ip_tables ext4 mbcache jbd2 ahci hisi_sas_v3_hw libahci hisi_sas_main libsas hns3 scsi_transport_sas hclge libata megaraid_sas ipmi_si hnae3 ipmi_devintf ipmi_msghandler br_netfilter bridge stp llc nvme nvme_core xt_sctp sctp libcrc32c dm_mod nbd
[   78.207383] CPU: 11 PID: 23258 Comm: null-ptr Not tainted 5.8.0-rc6+ #48
[   78.214056] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B210.01 03/12/2020
[   78.222888] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--)
[   78.228435] pc : 0x0
[   78.230618] lr : serial8250_start_tx+0x160/0x260
[   78.235215] sp : ffff800062eefb80
[   78.238517] x29: ffff800062eefb80 x28: 0000000000000fff
[   78.243807] x27: ffff800062eefd80 x26: ffff202fd83b3000
[   78.249098] x25: ffff800062eefd80 x24: ffff202fd83b3000
[   78.254388] x23: ffff002fc5e50be8 x22: 0000000000000002
[   78.259679] x21: 0000000000000001 x20: 0000000000000000
[   78.264969] x19: ffffa688827eecc8 x18: 0000000000000000
[   78.270259] x17: 0000000000000000 x16: 0000000000000000
[   78.275550] x15: ffffa68881bc67a8 x14: 00000000000002e6
[   78.280841] x13: ffffa68881bc67a8 x12: 000000000000c539
[   78.286131] x11: d37a6f4de9bd37a7 x10: ffffa68881cccff0
[   78.291421] x9 : ffffa68881bc6000 x8 : ffffa688819daa88
[   78.296711] x7 : ffffa688822a0f20 x6 : ffffa688819e0000
[   78.302002] x5 : ffff800062eef9d0 x4 : ffffa68881e707a8
[   78.307292] x3 : 0000000000000000 x2 : 0000000000000002
[   78.312582] x1 : 0000000000000001 x0 : ffffa688827eecc8
[   78.317873] Call trace:
[   78.320312]  0x0
[   78.322147]  __uart_start.isra.9+0x64/0x78
[   78.326229]  uart_start+0xb8/0x1c8
[   78.329620]  uart_flush_chars+0x24/0x30
[   78.333442]  n_tty_receive_buf_common+0x7b0/0xc30
[   78.338128]  n_tty_receive_buf+0x44/0x2c8
[   78.342122]  tty_ioctl+0x348/0x11f8
[   78.345599]  ksys_ioctl+0xd8/0xf8
[   78.348903]  __arm64_sys_ioctl+0x2c/0xc8
[   78.352812]  el0_svc_common.constprop.2+0x88/0x1b0
[   78.357583]  do_el0_svc+0x44/0xd0
[   78.360887]  el0_sync_handler+0x14c/0x1d0
[   78.364880]  el0_sync+0x140/0x180
[   78.368185] Code: bad PC value

SERIAL_PORT_DFNS is not defined on each arch, if it's not defined,
serial8250_set_defaults() won't be called in serial8250_isa_init_ports(),
so the p->serial_in pointer won't be initialized, and it leads a null-ptr-deref.
Fix this problem by calling serial8250_set_defaults() after init uart port.
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200721143852.4058352-1-yangyingliang@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch imitates 6e0a5de2 ("serial: 8250: Use hrtimers for
rs485 delays") in replacing the previously used classic timers
with hrtimers. The old way provided a too coarse resolution on
systems with configs of less than 1000 HZ.

Use of hrtimers addresses this and can be easily extended to
support microsecond resolution in future when support
for this arrives upstream.
Signed-off-by: NAhmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.kernel.org/r/20200714093012.21621-3-uwe@kleine-koenig.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This adds support for delays between assertion of RTS (which is supposed
to enable the rs485 transmitter) and sending as well as between the last
send char and deassertionof RTS.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20200714093012.21621-2-uwe@kleine-koenig.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The struct tty_port is part of the uart state and will never be NULL in
the receive helpers. Drop the bogus NULL checks and rename the
pointer-variables "port" to differentiate them from struct tty_struct
pointers (which can be NULL).

Fixes: 962963e4 ("serial: tegra: Switch to using struct tty_port")
Signed-off-by: NJohan Hovold <johan@kernel.org>
Acked-by: NThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200710135947.2737-3-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 33ae787b ("serial: tegra: add support to ignore read") added
support for dropping input in case CREAD isn't set, but for PIO the
ignore_status_mask wasn't checked until after the character had been
put in the receive buffer.

Note that the NULL tty-port test is bogus and will be removed by a
follow-on patch.

Fixes: 33ae787b ("serial: tegra: add support to ignore read")
Cc: stable <stable@vger.kernel.org>     # 5.4
Cc: Shardar Shariff Md <smohammed@nvidia.com>
Cc: Krishna Yarlagadda <kyarlagadda@nvidia.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Acked-by: NThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200710135947.2737-2-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Drivers using legacy PM have to manage PCI states and device's PM states
themselves. They also need to take care of configuration registers.

With improved and powerful support of generic PM, PCI Core takes care of
above mentioned, device-independent, jobs.

This driver makes use of PCI helper functions like
pci_save/restore_state(), pci_enable_device() and pci_set_power_state()
to do required operations. In generic mode, they are no longer needed.

Change function parameter in both .suspend() and .resume() to
"struct device*" type. Use dev_get_drvdata() to get drv data.

Compile-tested only.
Signed-off-by: NVaibhav Gupta <vaibhavgupta40@gmail.com>
Link: https://lore.kernel.org/r/20200720120414.399961-1-vaibhavgupta40@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.
Signed-off-by: NAlexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: NTobias Klauser <tklauser@distanz.ch>
Link: https://lore.kernel.org/r/20200718103018.3164-1-grandmaster@al2klimov.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes the following checkpatch error and warning:
  1. space required after ','
  2. Missing a blank line after declarations
Signed-off-by: NTamseel Shams <m.shams@samsung.com>
Link: https://lore.kernel.org/r/20200716115438.9967-1-m.shams@samsung.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.
Signed-off-by: NAlexander A. Klimov <grandmaster@al2klimov.de>
Link: https://lore.kernel.org/r/20200718100807.983-1-grandmaster@al2klimov.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.
Signed-off-by: NAlexander A. Klimov <grandmaster@al2klimov.de>
Link: https://lore.kernel.org/r/20200718123840.19957-1-grandmaster@al2klimov.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit f38278e9.

There has been a quick fix against uninitialised lock revealed by
the commit f743061a ("serial: core: Initialise spin lock before use
in uart_configure_port()"). Since we have now better fix in serial core,
this may be safely reverted.

Fixes: f38278e9 ("serial: sh-sci: Initialize spinlock for uart console")
Depends-on: f743061a ("serial: core: Initialise spin lock before use in uart_configure_port()")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200711135346.71171-5-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 8f065ace.

There has been a quick fix against uninitialised lock revealed by
the commit f743061a ("serial: core: Initialise spin lock before use
in uart_configure_port()"). Since we have now better fix in serial core,
this may be safely reverted.

Fixes: 8f065ace ("serial: imx: Initialize lock for non-registered console")
Depends-on: f743061a ("serial: core: Initialise spin lock before use in uart_configure_port()")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200711135346.71171-4-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 17b4efdf.

There has been a quick fix against uninitialised lock revealed by
the commit f743061a ("serial: core: Initialise spin lock before use
in uart_configure_port()"). Since we have now better fix in serial core,
this may be safely reverted.

Fixes: 17b4efdf ("tty: serial: add missing spin_lock_init for SiFive serial console")
Depends-on: f743061a ("serial: core: Initialise spin lock before use in uart_configure_port()")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200711135346.71171-3-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 8508f4cb.

There has been a quick fix against uninitialised lock revealed by
the commit f743061a ("serial: core: Initialise spin lock before use
in uart_configure_port()"). Since we have now better fix in serial core,
this may be safely reverted.

Fixes: 8508f4cb ("serial: amba-pl011: Make sure we initialize the port.lock spinlock")
Depends-on: f743061a ("serial: core: Initialise spin lock before use in uart_configure_port()")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200711135346.71171-2-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 0f87aa66.

There has been a quick fix against uninitialised lock revealed by
the commit f743061a ("serial: core: Initialise spin lock before use
in uart_configure_port()"). Since we have now better fix in serial core,
this may be safely reverted.

Fixes: 0f87aa66 ("serial: sunhv: Initialize lock for non-registered console")
Depends-on: f743061a ("serial: core: Initialise spin lock before use in uart_configure_port()")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200711135346.71171-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The problems started with the revert (18cc7ac8). The
cdns_uart_console.index is statically assigned -1. When the port is
registered, Linux assigns consecutive numbers to it. It turned out that
when using ttyPS1 as console, the index is not updated as we are reusing
the same cdns_uart_console instance for multiple ports. When registering
ttyPS0, it gets updated from -1 to 0, but when registering ttyPS1, it
already is 0 and not updated.

That led to 2ae11c46. It assigns the index prior to registering
the uart_driver once. Unfortunately, that ended up breaking the
situation where the probe order does not match the id order. When using
the same device tree for both uboot and linux, it is important that the
serial0 alias points to the console. So some boards reverse those
aliases. This was reported by Jan Kiszka. The proposed fix was reverting
the index assignment and going back to the previous iteration.

However such a reversed assignement (serial0 -> uart1, serial1 -> uart0)
was already partially broken by the revert (18cc7ac8). While the
ttyPS device works, the kmsg connection is already broken and kernel
messages go missing. Reverting the id assignment does not fix this.

>From the xilinx_uartps driver pov (after reverting the refactoring
commits), there can be only one console. This manifests in static
variables console_pprt and cdns_uart_console. These variables are not
properly linked and can go out of sync. The cdns_uart_console.index is
important for uart_add_one_port. We call that function for each port -
one of which hopefully is the console. If it isn't, the CON_ENABLED flag
is not set and console_port is cleared. The next cdns_uart_probe call
then tries to register the next port using that same cdns_uart_console.

It is important that console_port and cdns_uart_console (and its index
in particular) stay in sync. The index assignment implemented by
Shubhrajyoti Datta is correct in principle. It just may have to happen a
second time if the first cdns_uart_probe call didn't encounter the
console device. And we shouldn't change the index once the console uart
is registered.
Reported-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Reported-by: NJan Kiszka <jan.kiszka@web.de>
Link: https://lore.kernel.org/linux-serial/f4092727-d8f5-5f91-2c9f-76643aace993@siemens.com/
Fixes: 18cc7ac8 ("Revert "serial: uartps: Register own uart console and driver structures"")
Fixes: 2ae11c46 ("tty: xilinx_uartps: Fix missing id assignment to the console")
Fixes: 76ed2e10 ("Revert "tty: xilinx_uartps: Fix missing id assignment to the console"")
Signed-off-by: NHelmut Grohne <helmut.grohne@intenta.de>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200713073227.GA3805@laureti-devSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When using the geni-serial as console, its important to be
able to hit the lowest possible power state in suspend,
even with no_console_suspend.
The only thing that prevents it today on platforms like the sc7180
is the interconnect BW votes, which we certainly don't need when
the system is in suspend. So in the suspend handler mark them as
ACTIVE_ONLY (0x3) and on resume switch them back to the ALWAYS tag (0x7)
Signed-off-by: NRajendra Nayak <rnayak@codeaurora.org>
Reviewed-by: NAkash Asthana <akashast@codeaurora.org>
Tested-by: NMatthias Kaehlcke <mka@chromium.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1594704709-26072-1-git-send-email-rnayak@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The geni serial driver had a rule that we'd only use 1 byte per FIFO
word for the TX FIFO if we were being used for the serial console.
This is ugly and a bit of a pain.  It's not too hard to fix, so fix
it.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NEvan Green <evgreen@chromium.org>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200626125844.2.Iabd56347670b9e4e916422773aba5b27943d19ee@changeidSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The geni serial driver had the rather sketchy hack in it where it
would adjust the number of bytes per RX FIFO word from 4 down to 1 if
it detected that CONFIG_CONSOLE_POLL was enabled (for kgdb) and this
was a console port (defined by the kernel directing output to this
port via the "console=" command line argument).

The problem with that sketchy hack is that it's possible to run kgdb
over a serial port even if it isn't used for console.

Let's avoid the hack by simply handling the 4-bytes-per-FIFO word case
for kdb.  We'll have to have a (very small) cache but that should be
fine.

A nice side effect of this patch is that an agetty (or similar)
running on this port is less likely to drop characters.  We'll
have roughly 4 times the RX FIFO depth than we used to now.

NOTE: the character cache here isn't shared between the polling API
and the non-polling API.  That means that, technically, the polling
API could eat a few extra bytes.  This doesn't seem to pose a huge
problem in reality because we'll only get several characters per FIFO
word if those characters are all received at nearly the same time and
we don't really expect non-kgdb characters to be sent to the same port
as kgdb at the exact same time we're exiting kgdb.

ALSO NOTE: we still have the sketchy hack for setting the number of
bytes per TX FIFO word in place, but that one is less bad.  kgdb
doesn't have any problem with this because it always just sends 1 byte
at a time and waits for it to finish.  The TX FIFO hack is only really
needed for console output.  In any case, a future patch will remove
that hack, too.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NEvan Green <evgreen@chromium.org>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeidSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The comment near to uart_port_spin_lock_init() says:

  Ensure that the serial console lock is initialised early.
  If this port is a console, then the spinlock is already initialised.

and there is nothing about enabled or disabled consoles. The commit
a3cb39d2 ("serial: core: Allow detach and attach serial device
for console") made a change, which follows the comment, and also to
prevent reinitialisation of the lock in use, when user detaches and
attaches back the same console device. But this change discovers
another issue, that uart_add_one_port() tries to access a spin lock
that now may be uninitialised. This happens when a driver expects
the serial core to register a console on its behalf. In this case
we must initialise a spin lock before use.

Fixes: a3cb39d2 ("serial: core: Allow detach and attach serial device for console")
Reported-by: NMarc Zyngier <maz@kernel.org>
Reported-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Reported-by: NAnatoly Pugachev <matorola@gmail.com>
Acked-by: NMarc Zyngier <maz@kernel.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20200706214903.56148-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This driver calls ioremap() in probe, but it misses calling iounmap() in
probe's error handler and remove.
Add the missed calls to fix it.

Fixes: 47d37d6f ("serial: Add auart driver for i.MX23/28")
Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200709135608.68290-1-hslester96@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>