linux-stable/drivers/tty/serial/qcom_geni_serial.c

1849 lines
49 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017-2018, The Linux foundation. All rights reserved.
/* Disable MMIO tracing to prevent excessive logging of unwanted MMIO traces */
#define __DISABLE_TRACE_MMIO__
#include <linux/clk.h>
#include <linux/console.h>
#include <linux/io.h>
#include <linux/iopoll.h>
#include <linux/irq.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/pm_opp.h>
#include <linux/platform_device.h>
tty: serial: qcom_geni_serial: Wakeup IRQ cleanup This patch is the continuation of below mentioned commits which adds wakeup feature over the UART RX line. 1)commit 3e4aaea7a039 ("tty: serial: qcom_geni_serial: IRQ cleanup")[v2] 2)commit 8b7103f31950 ("tty: serial: qcom_geni_serial: Wakeup over UART RX")[v2] The following cleanup is done based on upstream comment received on subsequent versions of the above-mentioned commits to simplifying the code. - Use devm_kasprintf API in place of scnprintf. - Use dev_pm_set_dedicated_wake_irq API that will take care of requesting and attaching wakeup irqs for devices. Also, it sets wakeirq status to WAKE_IRQ_DEDICATED_ALLOCATED as a result enabling/disabling of wake irq will be managed by suspend/resume framework. We can remove the code for enabling and disabling of wake irq from the this driver. - Use platform_get_irq_optional API to get optional wakeup IRQ for device. - Move ISR registration later in probe after uart port gets register with serial core. Patch link: - https://patchwork.kernel.org/patch/11189717/ (v3) - https://patchwork.kernel.org/patch/11227435/ (v4) - https://patchwork.kernel.org/patch/11241669/ (v5) - https://patchwork.kernel.org/patch/11258045/ (v6) Signed-off-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1578321905-25843-2-git-send-email-akashast@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-06 14:45:04 +00:00
#include <linux/pm_runtime.h>
#include <linux/pm_wakeirq.h>
#include <linux/soc/qcom/geni-se.h>
#include <linux/serial.h>
#include <linux/serial_core.h>
#include <linux/slab.h>
#include <linux/tty.h>
#include <linux/tty_flip.h>
#include <dt-bindings/interconnect/qcom,icc.h>
/* UART specific GENI registers */
#define SE_UART_LOOPBACK_CFG 0x22c
#define SE_UART_IO_MACRO_CTRL 0x240
#define SE_UART_TX_TRANS_CFG 0x25c
#define SE_UART_TX_WORD_LEN 0x268
#define SE_UART_TX_STOP_BIT_LEN 0x26c
#define SE_UART_TX_TRANS_LEN 0x270
#define SE_UART_RX_TRANS_CFG 0x280
#define SE_UART_RX_WORD_LEN 0x28c
#define SE_UART_RX_STALE_CNT 0x294
#define SE_UART_TX_PARITY_CFG 0x2a4
#define SE_UART_RX_PARITY_CFG 0x2a8
#define SE_UART_MANUAL_RFR 0x2ac
/* SE_UART_TRANS_CFG */
#define UART_TX_PAR_EN BIT(0)
#define UART_CTS_MASK BIT(1)
/* SE_UART_TX_STOP_BIT_LEN */
#define TX_STOP_BIT_LEN_1 0
#define TX_STOP_BIT_LEN_2 2
/* SE_UART_RX_TRANS_CFG */
#define UART_RX_PAR_EN BIT(3)
/* SE_UART_RX_WORD_LEN */
#define RX_WORD_LEN_MASK GENMASK(9, 0)
/* SE_UART_RX_STALE_CNT */
#define RX_STALE_CNT GENMASK(23, 0)
/* SE_UART_TX_PARITY_CFG/RX_PARITY_CFG */
#define PAR_CALC_EN BIT(0)
#define PAR_EVEN 0x00
#define PAR_ODD 0x01
#define PAR_SPACE 0x10
/* SE_UART_MANUAL_RFR register fields */
#define UART_MANUAL_RFR_EN BIT(31)
#define UART_RFR_NOT_READY BIT(1)
#define UART_RFR_READY BIT(0)
/* UART M_CMD OP codes */
#define UART_START_TX 0x1
/* UART S_CMD OP codes */
#define UART_START_READ 0x1
#define UART_PARAM 0x1
#define UART_PARAM_RFR_OPEN BIT(7)
#define UART_OVERSAMPLING 32
#define STALE_TIMEOUT 16
#define DEFAULT_BITS_PER_CHAR 10
#define GENI_UART_CONS_PORTS 1
#define GENI_UART_PORTS 3
#define DEF_FIFO_DEPTH_WORDS 16
#define DEF_TX_WM 2
#define DEF_FIFO_WIDTH_BITS 32
#define UART_RX_WM 2
/* SE_UART_LOOPBACK_CFG */
#define RX_TX_SORTED BIT(0)
#define CTS_RTS_SORTED BIT(1)
#define RX_TX_CTS_RTS_SORTED (RX_TX_SORTED | CTS_RTS_SORTED)
/* UART pin swap value */
#define DEFAULT_IO_MACRO_IO0_IO1_MASK GENMASK(3, 0)
#define IO_MACRO_IO0_SEL 0x3
#define DEFAULT_IO_MACRO_IO2_IO3_MASK GENMASK(15, 4)
#define IO_MACRO_IO2_IO3_SWAP 0x4640
/* We always configure 4 bytes per FIFO word */
#define BYTES_PER_FIFO_WORD 4U
#define DMA_RX_BUF_SIZE 2048
struct qcom_geni_device_data {
bool console;
enum geni_se_xfer_mode mode;
};
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
struct qcom_geni_private_data {
/* NOTE: earlycon port will have NULL here */
struct uart_driver *drv;
u32 poll_cached_bytes;
unsigned int poll_cached_bytes_cnt;
u32 write_cached_bytes;
unsigned int write_cached_bytes_cnt;
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
};
struct qcom_geni_serial_port {
struct uart_port uport;
struct geni_se se;
tty: serial: qcom_geni_serial: Wakeup IRQ cleanup This patch is the continuation of below mentioned commits which adds wakeup feature over the UART RX line. 1)commit 3e4aaea7a039 ("tty: serial: qcom_geni_serial: IRQ cleanup")[v2] 2)commit 8b7103f31950 ("tty: serial: qcom_geni_serial: Wakeup over UART RX")[v2] The following cleanup is done based on upstream comment received on subsequent versions of the above-mentioned commits to simplifying the code. - Use devm_kasprintf API in place of scnprintf. - Use dev_pm_set_dedicated_wake_irq API that will take care of requesting and attaching wakeup irqs for devices. Also, it sets wakeirq status to WAKE_IRQ_DEDICATED_ALLOCATED as a result enabling/disabling of wake irq will be managed by suspend/resume framework. We can remove the code for enabling and disabling of wake irq from the this driver. - Use platform_get_irq_optional API to get optional wakeup IRQ for device. - Move ISR registration later in probe after uart port gets register with serial core. Patch link: - https://patchwork.kernel.org/patch/11189717/ (v3) - https://patchwork.kernel.org/patch/11227435/ (v4) - https://patchwork.kernel.org/patch/11241669/ (v5) - https://patchwork.kernel.org/patch/11258045/ (v6) Signed-off-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1578321905-25843-2-git-send-email-akashast@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-06 14:45:04 +00:00
const char *name;
u32 tx_fifo_depth;
u32 tx_fifo_width;
u32 rx_fifo_depth;
dma_addr_t tx_dma_addr;
dma_addr_t rx_dma_addr;
bool setup;
unsigned int baud;
unsigned long clk_rate;
void *rx_buf;
u32 loopback;
bool brk;
unsigned int tx_remaining;
int wakeup_irq;
bool rx_tx_swap;
bool cts_rts_swap;
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
struct qcom_geni_private_data private_data;
const struct qcom_geni_device_data *dev_data;
};
static const struct uart_ops qcom_geni_console_pops;
static const struct uart_ops qcom_geni_uart_pops;
static struct uart_driver qcom_geni_console_driver;
static struct uart_driver qcom_geni_uart_driver;
static inline struct qcom_geni_serial_port *to_dev_port(struct uart_port *uport)
{
return container_of(uport, struct qcom_geni_serial_port, uport);
}
static struct qcom_geni_serial_port qcom_geni_uart_ports[GENI_UART_PORTS] = {
[0] = {
.uport = {
.iotype = UPIO_MEM,
.ops = &qcom_geni_uart_pops,
.flags = UPF_BOOT_AUTOCONF,
.line = 0,
},
},
[1] = {
.uport = {
.iotype = UPIO_MEM,
.ops = &qcom_geni_uart_pops,
.flags = UPF_BOOT_AUTOCONF,
.line = 1,
},
},
[2] = {
.uport = {
.iotype = UPIO_MEM,
.ops = &qcom_geni_uart_pops,
.flags = UPF_BOOT_AUTOCONF,
.line = 2,
},
},
};
static struct qcom_geni_serial_port qcom_geni_console_port = {
.uport = {
.iotype = UPIO_MEM,
.ops = &qcom_geni_console_pops,
.flags = UPF_BOOT_AUTOCONF,
.line = 0,
},
};
static int qcom_geni_serial_request_port(struct uart_port *uport)
{
struct platform_device *pdev = to_platform_device(uport->dev);
struct qcom_geni_serial_port *port = to_dev_port(uport);
uport->membase = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(uport->membase))
return PTR_ERR(uport->membase);
port->se.base = uport->membase;
return 0;
}
static void qcom_geni_serial_config_port(struct uart_port *uport, int cfg_flags)
{
if (cfg_flags & UART_CONFIG_TYPE) {
uport->type = PORT_MSM;
qcom_geni_serial_request_port(uport);
}
}
static unsigned int qcom_geni_serial_get_mctrl(struct uart_port *uport)
{
unsigned int mctrl = TIOCM_DSR | TIOCM_CAR;
u32 geni_ios;
if (uart_console(uport)) {
mctrl |= TIOCM_CTS;
} else {
geni_ios = readl(uport->membase + SE_GENI_IOS);
if (!(geni_ios & IO2_DATA_IN))
mctrl |= TIOCM_CTS;
}
return mctrl;
}
static void qcom_geni_serial_set_mctrl(struct uart_port *uport,
unsigned int mctrl)
{
u32 uart_manual_rfr = 0;
struct qcom_geni_serial_port *port = to_dev_port(uport);
if (uart_console(uport))
return;
if (mctrl & TIOCM_LOOP)
port->loopback = RX_TX_CTS_RTS_SORTED;
if (!(mctrl & TIOCM_RTS) && !uport->suspended)
uart_manual_rfr = UART_MANUAL_RFR_EN | UART_RFR_NOT_READY;
writel(uart_manual_rfr, uport->membase + SE_UART_MANUAL_RFR);
}
static const char *qcom_geni_serial_get_type(struct uart_port *uport)
{
return "MSM";
}
static struct qcom_geni_serial_port *get_port_from_line(int line, bool console)
{
struct qcom_geni_serial_port *port;
int nr_ports = console ? GENI_UART_CONS_PORTS : GENI_UART_PORTS;
if (line < 0 || line >= nr_ports)
return ERR_PTR(-ENXIO);
port = console ? &qcom_geni_console_port : &qcom_geni_uart_ports[line];
return port;
}
static bool qcom_geni_serial_main_active(struct uart_port *uport)
{
return readl(uport->membase + SE_GENI_STATUS) & M_GENI_CMD_ACTIVE;
}
static bool qcom_geni_serial_secondary_active(struct uart_port *uport)
{
return readl(uport->membase + SE_GENI_STATUS) & S_GENI_CMD_ACTIVE;
}
static bool qcom_geni_serial_poll_bit(struct uart_port *uport,
int offset, int field, bool set)
{
u32 reg;
struct qcom_geni_serial_port *port;
unsigned int baud;
unsigned int fifo_bits;
unsigned long timeout_us = 20000;
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
struct qcom_geni_private_data *private_data = uport->private_data;
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
if (private_data->drv) {
port = to_dev_port(uport);
baud = port->baud;
if (!baud)
baud = 115200;
fifo_bits = port->tx_fifo_depth * port->tx_fifo_width;
/*
* Total polling iterations based on FIFO worth of bytes to be
* sent at current baud. Add a little fluff to the wait.
*/
timeout_us = ((fifo_bits * USEC_PER_SEC) / baud) + 500;
}
/*
* Use custom implementation instead of readl_poll_atomic since ktimer
* is not ready at the time of early console.
*/
timeout_us = DIV_ROUND_UP(timeout_us, 10) * 10;
while (timeout_us) {
reg = readl(uport->membase + offset);
if ((bool)(reg & field) == set)
return true;
udelay(10);
timeout_us -= 10;
}
return false;
}
static void qcom_geni_serial_setup_tx(struct uart_port *uport, u32 xmit_size)
{
u32 m_cmd;
writel(xmit_size, uport->membase + SE_UART_TX_TRANS_LEN);
m_cmd = UART_START_TX << M_OPCODE_SHFT;
writel(m_cmd, uport->membase + SE_GENI_M_CMD0);
}
static void qcom_geni_serial_poll_tx_done(struct uart_port *uport)
{
int done;
u32 irq_clear = M_CMD_DONE_EN;
done = qcom_geni_serial_poll_bit(uport, SE_GENI_M_IRQ_STATUS,
M_CMD_DONE_EN, true);
if (!done) {
writel(M_GENI_CMD_ABORT, uport->membase +
SE_GENI_M_CMD_CTRL_REG);
irq_clear |= M_CMD_ABORT_EN;
qcom_geni_serial_poll_bit(uport, SE_GENI_M_IRQ_STATUS,
M_CMD_ABORT_EN, true);
}
writel(irq_clear, uport->membase + SE_GENI_M_IRQ_CLEAR);
}
static void qcom_geni_serial_abort_rx(struct uart_port *uport)
{
u32 irq_clear = S_CMD_DONE_EN | S_CMD_ABORT_EN;
writel(S_GENI_CMD_ABORT, uport->membase + SE_GENI_S_CMD_CTRL_REG);
qcom_geni_serial_poll_bit(uport, SE_GENI_S_CMD_CTRL_REG,
S_GENI_CMD_ABORT, false);
writel(irq_clear, uport->membase + SE_GENI_S_IRQ_CLEAR);
writel(FORCE_DEFAULT, uport->membase + GENI_FORCE_DEFAULT_REG);
}
#ifdef CONFIG_CONSOLE_POLL
static int qcom_geni_serial_get_char(struct uart_port *uport)
{
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
struct qcom_geni_private_data *private_data = uport->private_data;
u32 status;
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
u32 word_cnt;
int ret;
if (!private_data->poll_cached_bytes_cnt) {
status = readl(uport->membase + SE_GENI_M_IRQ_STATUS);
writel(status, uport->membase + SE_GENI_M_IRQ_CLEAR);
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
status = readl(uport->membase + SE_GENI_S_IRQ_STATUS);
writel(status, uport->membase + SE_GENI_S_IRQ_CLEAR);
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
status = readl(uport->membase + SE_GENI_RX_FIFO_STATUS);
word_cnt = status & RX_FIFO_WC_MSK;
if (!word_cnt)
return NO_POLL_CHAR;
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
if (word_cnt == 1 && (status & RX_LAST))
/*
* NOTE: If RX_LAST_BYTE_VALID is 0 it needs to be
* treated as if it was BYTES_PER_FIFO_WORD.
*/
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
private_data->poll_cached_bytes_cnt =
(status & RX_LAST_BYTE_VALID_MSK) >>
RX_LAST_BYTE_VALID_SHFT;
if (private_data->poll_cached_bytes_cnt == 0)
private_data->poll_cached_bytes_cnt = BYTES_PER_FIFO_WORD;
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
private_data->poll_cached_bytes =
readl(uport->membase + SE_GENI_RX_FIFOn);
}
private_data->poll_cached_bytes_cnt--;
ret = private_data->poll_cached_bytes & 0xff;
private_data->poll_cached_bytes >>= 8;
return ret;
}
static void qcom_geni_serial_poll_put_char(struct uart_port *uport,
unsigned char c)
{
writel(DEF_TX_WM, uport->membase + SE_GENI_TX_WATERMARK_REG);
qcom_geni_serial_setup_tx(uport, 1);
WARN_ON(!qcom_geni_serial_poll_bit(uport, SE_GENI_M_IRQ_STATUS,
M_TX_FIFO_WATERMARK_EN, true));
writel(c, uport->membase + SE_GENI_TX_FIFOn);
writel(M_TX_FIFO_WATERMARK_EN, uport->membase + SE_GENI_M_IRQ_CLEAR);
qcom_geni_serial_poll_tx_done(uport);
}
#endif
#ifdef CONFIG_SERIAL_QCOM_GENI_CONSOLE
serial: make uart_console_write->putchar()'s character an unsigned char Currently, uart_console_write->putchar's second parameter (the character) is of type int. It makes little sense, provided uart_console_write() accepts the input string as "const char *s" and passes its content -- the characters -- to putchar(). So switch the character's type to unsigned char. We don't use char as that is signed on some platforms. That would cause troubles for drivers which (implicitly) cast the char to u16 when writing to the device. Sign extension would happen in that case and the value written would be completely different to the provided char. DZ is an example of such a driver -- on MIPS, it uses u16 for dz_out in dz_console_putchar(). Note we do the char -> uchar conversion implicitly in uart_console_write(). Provided we do not change size of the data type, sign extension does not happen there, so the problem is void. This makes the types consistent and unified with the rest of the uart layer, which uses unsigned char in most places already. One exception is xmit_buf, but that is going to be converted later. Cc: Paul Cercueil <paul@crapouillou.net> Cc: Tobias Klauser <tklauser@distanz.ch> Cc: Russell King <linux@armlinux.org.uk> Cc: Vineet Gupta <vgupta@kernel.org> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: Alexander Shiyan <shc_work@mail.ru> Cc: Baruch Siach <baruch@tkos.co.il> Cc: "Maciej W. Rozycki" <macro@orcam.me.uk> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Karol Gugala <kgugala@antmicro.com> Cc: Mateusz Holenko <mholenko@antmicro.com> Cc: Vladimir Zapolskiy <vz@mleia.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Taichi Sugaya <sugaya.taichi@socionext.com> Cc: Takao Orito <orito.takao@socionext.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: "Andreas Färber" <afaerber@suse.de> Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Baolin Wang <baolin.wang7@gmail.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Michal Simek <michal.simek@xilinx.com> Acked-by: Richard Genoud <richard.genoud@gmail.com> [atmel_serial] Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Paul Cercueil <paul@crapouillou.net> Acked-by: Neil Armstrong <narmstrong@baylibre.com> # meson_serial Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220303080831.21783-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-03 08:08:31 +00:00
static void qcom_geni_serial_wr_char(struct uart_port *uport, unsigned char ch)
{
struct qcom_geni_private_data *private_data = uport->private_data;
private_data->write_cached_bytes =
(private_data->write_cached_bytes >> 8) | (ch << 24);
private_data->write_cached_bytes_cnt++;
if (private_data->write_cached_bytes_cnt == BYTES_PER_FIFO_WORD) {
writel(private_data->write_cached_bytes,
uport->membase + SE_GENI_TX_FIFOn);
private_data->write_cached_bytes_cnt = 0;
}
}
static void
__qcom_geni_serial_console_write(struct uart_port *uport, const char *s,
unsigned int count)
{
struct qcom_geni_private_data *private_data = uport->private_data;
int i;
u32 bytes_to_send = count;
for (i = 0; i < count; i++) {
/*
* uart_console_write() adds a carriage return for each newline.
* Account for additional bytes to be written.
*/
if (s[i] == '\n')
bytes_to_send++;
}
writel(DEF_TX_WM, uport->membase + SE_GENI_TX_WATERMARK_REG);
qcom_geni_serial_setup_tx(uport, bytes_to_send);
for (i = 0; i < count; ) {
size_t chars_to_write = 0;
size_t avail = DEF_FIFO_DEPTH_WORDS - DEF_TX_WM;
/*
* If the WM bit never set, then the Tx state machine is not
* in a valid state, so break, cancel/abort any existing
* command. Unfortunately the current data being written is
* lost.
*/
if (!qcom_geni_serial_poll_bit(uport, SE_GENI_M_IRQ_STATUS,
M_TX_FIFO_WATERMARK_EN, true))
break;
chars_to_write = min_t(size_t, count - i, avail / 2);
uart_console_write(uport, s + i, chars_to_write,
qcom_geni_serial_wr_char);
writel(M_TX_FIFO_WATERMARK_EN, uport->membase +
SE_GENI_M_IRQ_CLEAR);
i += chars_to_write;
}
if (private_data->write_cached_bytes_cnt) {
private_data->write_cached_bytes >>= BITS_PER_BYTE *
(BYTES_PER_FIFO_WORD - private_data->write_cached_bytes_cnt);
writel(private_data->write_cached_bytes,
uport->membase + SE_GENI_TX_FIFOn);
private_data->write_cached_bytes_cnt = 0;
}
qcom_geni_serial_poll_tx_done(uport);
}
static void qcom_geni_serial_console_write(struct console *co, const char *s,
unsigned int count)
{
struct uart_port *uport;
struct qcom_geni_serial_port *port;
bool locked = true;
unsigned long flags;
u32 geni_status;
u32 irq_en;
WARN_ON(co->index < 0 || co->index >= GENI_UART_CONS_PORTS);
port = get_port_from_line(co->index, true);
if (IS_ERR(port))
return;
uport = &port->uport;
if (oops_in_progress)
serial: qcom-geni: Use port lock wrappers When a serial port is used for kernel console output, then all modifications to the UART registers which are done from other contexts, e.g. getty, termios, are interference points for the kernel console. So far this has been ignored and the printk output is based on the principle of hope. The rework of the console infrastructure which aims to support threaded and atomic consoles, requires to mark sections which modify the UART registers as unsafe. This allows the atomic write function to make informed decisions and eventually to restore operational state. It also allows to prevent the regular UART code from modifying UART registers while printk output is in progress. All modifications of UART registers are guarded by the UART port lock, which provides an obvious synchronization point with the console infrastructure. To avoid adding this functionality to all UART drivers, wrap the spin_[un]lock*() invocations for uart_port::lock into helper functions which just contain the spin_[un]lock*() invocations for now. In a subsequent step these helpers will gain the console synchronization mechanisms. Converted with coccinelle. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://lore.kernel.org/r/20230914183831.587273-50-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-14 18:38:06 +00:00
locked = uart_port_trylock_irqsave(uport, &flags);
else
serial: qcom-geni: Use port lock wrappers When a serial port is used for kernel console output, then all modifications to the UART registers which are done from other contexts, e.g. getty, termios, are interference points for the kernel console. So far this has been ignored and the printk output is based on the principle of hope. The rework of the console infrastructure which aims to support threaded and atomic consoles, requires to mark sections which modify the UART registers as unsafe. This allows the atomic write function to make informed decisions and eventually to restore operational state. It also allows to prevent the regular UART code from modifying UART registers while printk output is in progress. All modifications of UART registers are guarded by the UART port lock, which provides an obvious synchronization point with the console infrastructure. To avoid adding this functionality to all UART drivers, wrap the spin_[un]lock*() invocations for uart_port::lock into helper functions which just contain the spin_[un]lock*() invocations for now. In a subsequent step these helpers will gain the console synchronization mechanisms. Converted with coccinelle. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://lore.kernel.org/r/20230914183831.587273-50-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-14 18:38:06 +00:00
uart_port_lock_irqsave(uport, &flags);
geni_status = readl(uport->membase + SE_GENI_STATUS);
if (!locked) {
serial: qcom-geni: Don't cancel/abort if we can't get the port lock As of commit d7402513c935 ("arm64: smp: IPI_CPU_STOP and IPI_CPU_CRASH_STOP should try for NMI"), if we've got pseudo-NMI enabled then we'll use it to stop CPUs at panic time. This is nice, but it does mean that there's a pretty good chance that we'll end up stopping a CPU while it holds the port lock for the console UART. Specifically, I see a CPU get stopped while holding the port lock nearly 100% of the time on my sc7180-trogdor based Chromebook by enabling the "buddy" hardlockup detector and then doing: sysctl -w kernel.hardlockup_all_cpu_backtrace=1 sysctl -w kernel.hardlockup_panic=1 echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT UART drivers are _supposed_ to handle this case OK and this is why UART drivers check "oops_in_progress" and only do a "trylock" in that case. However, before we enabled pseudo-NMI to stop CPUs it wasn't a very well-tested situation. Now that we're testing the situation a lot, it can be seen that the Qualcomm GENI UART driver is pretty broken. Specifically, when I run my test case and look at the console output I just see a bunch of garbled output like: [ 201.069084] NMI backtrace[ 201.069084] NM[ 201.069087] CPU: 6 PID: 10296 Comm: dnsproxyd Not tainted 6.7.0-06265-gb13e8c0ede12 #1 01112b9f14923cbd0b[ 201.069090] Hardware name: Google Lazor ([ 201.069092] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DI[ 201.069095] pc : smp_call_function_man[ 201.069099] That's obviously not so great. This happens because each call to the console driver exits after the data has been written to the FIFO but before it's actually been flushed out of the serial port. When we have multiple calls into the console one after the other then (if we can't get the lock) each call tells the UART to throw away any data in the FIFO that hadn't been transferred yet. I've posted up a patch to change the arm64 core to avoid this situation most of the time [1] much like x86 seems to do, but even if that patch lands the GENI driver should still be fixed. >From testing, it appears that we can just delete the cancel/abort in the case where we weren't able to get the UART lock and the output looks good. It makes sense that we'd be able to do this since that means we'll just call into __qcom_geni_serial_console_write() and __qcom_geni_serial_console_write() looks much like qcom_geni_serial_poll_put_char() but with a loop. However, it seems safest to poll the FIFO and make sure it's empty before our transfer. This should reliably make sure that we're not interrupting/clobbering any existing transfers. As part of this change, we'll also avoid re-setting up a TX at the end of the console write function if we weren't able to get the lock, since accessing "port->tx_remaining" without the lock is not safe. This is only needed to re-start userspace initiated transfers. [1] https://lore.kernel.org/r/20231207170251.1.Id4817adef610302554b8aa42b090d57270dc119c@changeid Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20240112150307.2.Idb1553d1d22123c377f31eacb4486432f6c9ac8d@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-12 23:03:08 +00:00
/*
* We can only get here if an oops is in progress then we were
* unable to get the lock. This means we can't safely access
* our state variables like tx_remaining. About the best we
* can do is wait for the FIFO to be empty before we start our
* transfer, so we'll do that.
*/
qcom_geni_serial_poll_bit(uport, SE_GENI_M_IRQ_STATUS,
M_TX_FIFO_NOT_EMPTY_EN, false);
} else if ((geni_status & M_GENI_CMD_ACTIVE) && !port->tx_remaining) {
/*
* It seems we can't interrupt existing transfers if all data
* has been sent, in which case we need to look for done first.
*/
qcom_geni_serial_poll_tx_done(uport);
if (!uart_circ_empty(&uport->state->xmit)) {
irq_en = readl(uport->membase + SE_GENI_M_IRQ_EN);
writel(irq_en | M_TX_FIFO_WATERMARK_EN,
uport->membase + SE_GENI_M_IRQ_EN);
}
}
__qcom_geni_serial_console_write(uport, s, count);
serial: qcom-geni: Don't cancel/abort if we can't get the port lock As of commit d7402513c935 ("arm64: smp: IPI_CPU_STOP and IPI_CPU_CRASH_STOP should try for NMI"), if we've got pseudo-NMI enabled then we'll use it to stop CPUs at panic time. This is nice, but it does mean that there's a pretty good chance that we'll end up stopping a CPU while it holds the port lock for the console UART. Specifically, I see a CPU get stopped while holding the port lock nearly 100% of the time on my sc7180-trogdor based Chromebook by enabling the "buddy" hardlockup detector and then doing: sysctl -w kernel.hardlockup_all_cpu_backtrace=1 sysctl -w kernel.hardlockup_panic=1 echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT UART drivers are _supposed_ to handle this case OK and this is why UART drivers check "oops_in_progress" and only do a "trylock" in that case. However, before we enabled pseudo-NMI to stop CPUs it wasn't a very well-tested situation. Now that we're testing the situation a lot, it can be seen that the Qualcomm GENI UART driver is pretty broken. Specifically, when I run my test case and look at the console output I just see a bunch of garbled output like: [ 201.069084] NMI backtrace[ 201.069084] NM[ 201.069087] CPU: 6 PID: 10296 Comm: dnsproxyd Not tainted 6.7.0-06265-gb13e8c0ede12 #1 01112b9f14923cbd0b[ 201.069090] Hardware name: Google Lazor ([ 201.069092] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DI[ 201.069095] pc : smp_call_function_man[ 201.069099] That's obviously not so great. This happens because each call to the console driver exits after the data has been written to the FIFO but before it's actually been flushed out of the serial port. When we have multiple calls into the console one after the other then (if we can't get the lock) each call tells the UART to throw away any data in the FIFO that hadn't been transferred yet. I've posted up a patch to change the arm64 core to avoid this situation most of the time [1] much like x86 seems to do, but even if that patch lands the GENI driver should still be fixed. >From testing, it appears that we can just delete the cancel/abort in the case where we weren't able to get the UART lock and the output looks good. It makes sense that we'd be able to do this since that means we'll just call into __qcom_geni_serial_console_write() and __qcom_geni_serial_console_write() looks much like qcom_geni_serial_poll_put_char() but with a loop. However, it seems safest to poll the FIFO and make sure it's empty before our transfer. This should reliably make sure that we're not interrupting/clobbering any existing transfers. As part of this change, we'll also avoid re-setting up a TX at the end of the console write function if we weren't able to get the lock, since accessing "port->tx_remaining" without the lock is not safe. This is only needed to re-start userspace initiated transfers. [1] https://lore.kernel.org/r/20231207170251.1.Id4817adef610302554b8aa42b090d57270dc119c@changeid Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20240112150307.2.Idb1553d1d22123c377f31eacb4486432f6c9ac8d@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-12 23:03:08 +00:00
if (locked) {
if (port->tx_remaining)
qcom_geni_serial_setup_tx(uport, port->tx_remaining);
serial: qcom-geni: Use port lock wrappers When a serial port is used for kernel console output, then all modifications to the UART registers which are done from other contexts, e.g. getty, termios, are interference points for the kernel console. So far this has been ignored and the printk output is based on the principle of hope. The rework of the console infrastructure which aims to support threaded and atomic consoles, requires to mark sections which modify the UART registers as unsafe. This allows the atomic write function to make informed decisions and eventually to restore operational state. It also allows to prevent the regular UART code from modifying UART registers while printk output is in progress. All modifications of UART registers are guarded by the UART port lock, which provides an obvious synchronization point with the console infrastructure. To avoid adding this functionality to all UART drivers, wrap the spin_[un]lock*() invocations for uart_port::lock into helper functions which just contain the spin_[un]lock*() invocations for now. In a subsequent step these helpers will gain the console synchronization mechanisms. Converted with coccinelle. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://lore.kernel.org/r/20230914183831.587273-50-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-14 18:38:06 +00:00
uart_port_unlock_irqrestore(uport, flags);
serial: qcom-geni: Don't cancel/abort if we can't get the port lock As of commit d7402513c935 ("arm64: smp: IPI_CPU_STOP and IPI_CPU_CRASH_STOP should try for NMI"), if we've got pseudo-NMI enabled then we'll use it to stop CPUs at panic time. This is nice, but it does mean that there's a pretty good chance that we'll end up stopping a CPU while it holds the port lock for the console UART. Specifically, I see a CPU get stopped while holding the port lock nearly 100% of the time on my sc7180-trogdor based Chromebook by enabling the "buddy" hardlockup detector and then doing: sysctl -w kernel.hardlockup_all_cpu_backtrace=1 sysctl -w kernel.hardlockup_panic=1 echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT UART drivers are _supposed_ to handle this case OK and this is why UART drivers check "oops_in_progress" and only do a "trylock" in that case. However, before we enabled pseudo-NMI to stop CPUs it wasn't a very well-tested situation. Now that we're testing the situation a lot, it can be seen that the Qualcomm GENI UART driver is pretty broken. Specifically, when I run my test case and look at the console output I just see a bunch of garbled output like: [ 201.069084] NMI backtrace[ 201.069084] NM[ 201.069087] CPU: 6 PID: 10296 Comm: dnsproxyd Not tainted 6.7.0-06265-gb13e8c0ede12 #1 01112b9f14923cbd0b[ 201.069090] Hardware name: Google Lazor ([ 201.069092] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DI[ 201.069095] pc : smp_call_function_man[ 201.069099] That's obviously not so great. This happens because each call to the console driver exits after the data has been written to the FIFO but before it's actually been flushed out of the serial port. When we have multiple calls into the console one after the other then (if we can't get the lock) each call tells the UART to throw away any data in the FIFO that hadn't been transferred yet. I've posted up a patch to change the arm64 core to avoid this situation most of the time [1] much like x86 seems to do, but even if that patch lands the GENI driver should still be fixed. >From testing, it appears that we can just delete the cancel/abort in the case where we weren't able to get the UART lock and the output looks good. It makes sense that we'd be able to do this since that means we'll just call into __qcom_geni_serial_console_write() and __qcom_geni_serial_console_write() looks much like qcom_geni_serial_poll_put_char() but with a loop. However, it seems safest to poll the FIFO and make sure it's empty before our transfer. This should reliably make sure that we're not interrupting/clobbering any existing transfers. As part of this change, we'll also avoid re-setting up a TX at the end of the console write function if we weren't able to get the lock, since accessing "port->tx_remaining" without the lock is not safe. This is only needed to re-start userspace initiated transfers. [1] https://lore.kernel.org/r/20231207170251.1.Id4817adef610302554b8aa42b090d57270dc119c@changeid Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20240112150307.2.Idb1553d1d22123c377f31eacb4486432f6c9ac8d@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-12 23:03:08 +00:00
}
}
static void handle_rx_console(struct uart_port *uport, u32 bytes, bool drop)
{
u32 i;
unsigned char buf[sizeof(u32)];
struct tty_port *tport;
struct qcom_geni_serial_port *port = to_dev_port(uport);
tport = &uport->state->port;
for (i = 0; i < bytes; ) {
int c;
int chunk = min_t(int, bytes - i, BYTES_PER_FIFO_WORD);
ioread32_rep(uport->membase + SE_GENI_RX_FIFOn, buf, 1);
i += chunk;
if (drop)
continue;
for (c = 0; c < chunk; c++) {
int sysrq;
uport->icount.rx++;
if (port->brk && buf[c] == 0) {
port->brk = false;
if (uart_handle_break(uport))
continue;
}
sysrq = uart_prepare_sysrq_char(uport, buf[c]);
if (!sysrq)
tty_insert_flip_char(tport, buf[c], TTY_NORMAL);
}
}
if (!drop)
tty_flip_buffer_push(tport);
}
#else
static void handle_rx_console(struct uart_port *uport, u32 bytes, bool drop)
{
}
#endif /* CONFIG_SERIAL_QCOM_GENI_CONSOLE */
static void handle_rx_uart(struct uart_port *uport, u32 bytes, bool drop)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
struct tty_port *tport = &uport->state->port;
int ret;
ret = tty_insert_flip_string(tport, port->rx_buf, bytes);
if (ret != bytes) {
dev_err(uport->dev, "%s:Unable to push data ret %d_bytes %d\n",
__func__, ret, bytes);
WARN_ON_ONCE(1);
}
uport->icount.rx += ret;
tty_flip_buffer_push(tport);
}
static unsigned int qcom_geni_serial_tx_empty(struct uart_port *uport)
{
return !readl(uport->membase + SE_GENI_TX_FIFO_STATUS);
}
static void qcom_geni_serial_stop_tx_dma(struct uart_port *uport)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
bool done;
if (!qcom_geni_serial_main_active(uport))
return;
if (port->tx_dma_addr) {
geni_se_tx_dma_unprep(&port->se, port->tx_dma_addr,
port->tx_remaining);
port->tx_dma_addr = 0;
port->tx_remaining = 0;
}
geni_se_cancel_m_cmd(&port->se);
done = qcom_geni_serial_poll_bit(uport, SE_GENI_M_IRQ_STATUS,
M_CMD_CANCEL_EN, true);
if (!done) {
geni_se_abort_m_cmd(&port->se);
done = qcom_geni_serial_poll_bit(uport, SE_GENI_M_IRQ_STATUS,
M_CMD_ABORT_EN, true);
if (!done)
dev_err_ratelimited(uport->dev, "M_CMD_ABORT_EN not set");
writel(M_CMD_ABORT_EN, uport->membase + SE_GENI_M_IRQ_CLEAR);
}
writel(M_CMD_CANCEL_EN, uport->membase + SE_GENI_M_IRQ_CLEAR);
}
static void qcom_geni_serial_start_tx_dma(struct uart_port *uport)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
struct circ_buf *xmit = &uport->state->xmit;
unsigned int xmit_size;
int ret;
if (port->tx_dma_addr)
return;
if (uart_circ_empty(xmit))
return;
xmit_size = CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE);
qcom_geni_serial_setup_tx(uport, xmit_size);
ret = geni_se_tx_dma_prep(&port->se, &xmit->buf[xmit->tail],
xmit_size, &port->tx_dma_addr);
if (ret) {
dev_err(uport->dev, "unable to start TX SE DMA: %d\n", ret);
qcom_geni_serial_stop_tx_dma(uport);
return;
}
port->tx_remaining = xmit_size;
}
static void qcom_geni_serial_start_tx_fifo(struct uart_port *uport)
{
u32 irq_en;
if (qcom_geni_serial_main_active(uport) ||
!qcom_geni_serial_tx_empty(uport))
return;
irq_en = readl(uport->membase + SE_GENI_M_IRQ_EN);
irq_en |= M_TX_FIFO_WATERMARK_EN | M_CMD_DONE_EN;
writel(DEF_TX_WM, uport->membase + SE_GENI_TX_WATERMARK_REG);
writel(irq_en, uport->membase + SE_GENI_M_IRQ_EN);
}
static void qcom_geni_serial_stop_tx_fifo(struct uart_port *uport)
{
u32 irq_en;
struct qcom_geni_serial_port *port = to_dev_port(uport);
irq_en = readl(uport->membase + SE_GENI_M_IRQ_EN);
irq_en &= ~(M_CMD_DONE_EN | M_TX_FIFO_WATERMARK_EN);
writel(0, uport->membase + SE_GENI_TX_WATERMARK_REG);
writel(irq_en, uport->membase + SE_GENI_M_IRQ_EN);
/* Possible stop tx is called multiple times. */
if (!qcom_geni_serial_main_active(uport))
return;
geni_se_cancel_m_cmd(&port->se);
if (!qcom_geni_serial_poll_bit(uport, SE_GENI_M_IRQ_STATUS,
M_CMD_CANCEL_EN, true)) {
geni_se_abort_m_cmd(&port->se);
qcom_geni_serial_poll_bit(uport, SE_GENI_M_IRQ_STATUS,
M_CMD_ABORT_EN, true);
writel(M_CMD_ABORT_EN, uport->membase + SE_GENI_M_IRQ_CLEAR);
}
writel(M_CMD_CANCEL_EN, uport->membase + SE_GENI_M_IRQ_CLEAR);
}
static void qcom_geni_serial_handle_rx_fifo(struct uart_port *uport, bool drop)
{
u32 status;
u32 word_cnt;
u32 last_word_byte_cnt;
u32 last_word_partial;
u32 total_bytes;
status = readl(uport->membase + SE_GENI_RX_FIFO_STATUS);
word_cnt = status & RX_FIFO_WC_MSK;
last_word_partial = status & RX_LAST;
last_word_byte_cnt = (status & RX_LAST_BYTE_VALID_MSK) >>
RX_LAST_BYTE_VALID_SHFT;
if (!word_cnt)
return;
total_bytes = BYTES_PER_FIFO_WORD * (word_cnt - 1);
if (last_word_partial && last_word_byte_cnt)
total_bytes += last_word_byte_cnt;
else
total_bytes += BYTES_PER_FIFO_WORD;
handle_rx_console(uport, total_bytes, drop);
}
static void qcom_geni_serial_stop_rx_fifo(struct uart_port *uport)
{
u32 irq_en;
struct qcom_geni_serial_port *port = to_dev_port(uport);
u32 s_irq_status;
irq_en = readl(uport->membase + SE_GENI_S_IRQ_EN);
irq_en &= ~(S_RX_FIFO_WATERMARK_EN | S_RX_FIFO_LAST_EN);
writel(irq_en, uport->membase + SE_GENI_S_IRQ_EN);
irq_en = readl(uport->membase + SE_GENI_M_IRQ_EN);
irq_en &= ~(M_RX_FIFO_WATERMARK_EN | M_RX_FIFO_LAST_EN);
writel(irq_en, uport->membase + SE_GENI_M_IRQ_EN);
if (!qcom_geni_serial_secondary_active(uport))
return;
geni_se_cancel_s_cmd(&port->se);
qcom_geni_serial_poll_bit(uport, SE_GENI_S_IRQ_STATUS,
S_CMD_CANCEL_EN, true);
/*
* If timeout occurs secondary engine remains active
* and Abort sequence is executed.
*/
s_irq_status = readl(uport->membase + SE_GENI_S_IRQ_STATUS);
/* Flush the Rx buffer */
if (s_irq_status & S_RX_FIFO_LAST_EN)
qcom_geni_serial_handle_rx_fifo(uport, true);
writel(s_irq_status, uport->membase + SE_GENI_S_IRQ_CLEAR);
if (qcom_geni_serial_secondary_active(uport))
qcom_geni_serial_abort_rx(uport);
}
static void qcom_geni_serial_start_rx_fifo(struct uart_port *uport)
{
u32 irq_en;
struct qcom_geni_serial_port *port = to_dev_port(uport);
if (qcom_geni_serial_secondary_active(uport))
qcom_geni_serial_stop_rx_fifo(uport);
geni_se_setup_s_cmd(&port->se, UART_START_READ, 0);
irq_en = readl(uport->membase + SE_GENI_S_IRQ_EN);
irq_en |= S_RX_FIFO_WATERMARK_EN | S_RX_FIFO_LAST_EN;
writel(irq_en, uport->membase + SE_GENI_S_IRQ_EN);
irq_en = readl(uport->membase + SE_GENI_M_IRQ_EN);
irq_en |= M_RX_FIFO_WATERMARK_EN | M_RX_FIFO_LAST_EN;
writel(irq_en, uport->membase + SE_GENI_M_IRQ_EN);
}
static void qcom_geni_serial_stop_rx_dma(struct uart_port *uport)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
if (!qcom_geni_serial_secondary_active(uport))
return;
geni_se_cancel_s_cmd(&port->se);
qcom_geni_serial_poll_bit(uport, SE_GENI_S_IRQ_STATUS,
S_CMD_CANCEL_EN, true);
if (qcom_geni_serial_secondary_active(uport))
qcom_geni_serial_abort_rx(uport);
if (port->rx_dma_addr) {
geni_se_rx_dma_unprep(&port->se, port->rx_dma_addr,
DMA_RX_BUF_SIZE);
port->rx_dma_addr = 0;
}
}
static void qcom_geni_serial_start_rx_dma(struct uart_port *uport)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
int ret;
if (qcom_geni_serial_secondary_active(uport))
qcom_geni_serial_stop_rx_dma(uport);
geni_se_setup_s_cmd(&port->se, UART_START_READ, UART_PARAM_RFR_OPEN);
ret = geni_se_rx_dma_prep(&port->se, port->rx_buf,
DMA_RX_BUF_SIZE,
&port->rx_dma_addr);
if (ret) {
dev_err(uport->dev, "unable to start RX SE DMA: %d\n", ret);
qcom_geni_serial_stop_rx_dma(uport);
}
}
static void qcom_geni_serial_handle_rx_dma(struct uart_port *uport, bool drop)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
u32 rx_in;
int ret;
if (!qcom_geni_serial_secondary_active(uport))
return;
if (!port->rx_dma_addr)
return;
geni_se_rx_dma_unprep(&port->se, port->rx_dma_addr, DMA_RX_BUF_SIZE);
port->rx_dma_addr = 0;
rx_in = readl(uport->membase + SE_DMA_RX_LEN_IN);
if (!rx_in) {
dev_warn(uport->dev, "serial engine reports 0 RX bytes in!\n");
return;
}
if (!drop)
handle_rx_uart(uport, rx_in, drop);
ret = geni_se_rx_dma_prep(&port->se, port->rx_buf,
DMA_RX_BUF_SIZE,
&port->rx_dma_addr);
if (ret) {
dev_err(uport->dev, "unable to start RX SE DMA: %d\n", ret);
qcom_geni_serial_stop_rx_dma(uport);
}
}
static void qcom_geni_serial_start_rx(struct uart_port *uport)
{
uport->ops->start_rx(uport);
}
static void qcom_geni_serial_stop_rx(struct uart_port *uport)
{
uport->ops->stop_rx(uport);
}
static void qcom_geni_serial_stop_tx(struct uart_port *uport)
{
uport->ops->stop_tx(uport);
}
static void qcom_geni_serial_send_chunk_fifo(struct uart_port *uport,
Revert "tty: serial: simplify qcom_geni_serial_send_chunk_fifo()" This reverts commit 5c7e105cd156fc9adf5294a83623d7a40c15f9b9. As identified by KASAN, the simplification done by the cleanup patch was not legal. >From tracing through the code, it can be seen that we're transmitting from a 4096-byte circular buffer. We copy anywhere from 1-4 bytes from it each time. The simplification runs into trouble when we get near the end of the circular buffer. For instance, we might start out with xmit->tail = 4094 and we want to transfer 4 bytes. With the code before simplification this was no problem. We'd read buf[4094], buf[4095], buf[0], and buf[1]. With the new code we'll do a memcpy(&buf[4094], 4) which reads 2 bytes past the end of the buffer and then skips transmitting what's at buf[0] and buf[1]. KASAN isn't 100% consistent at reporting this for me, but to be extra confident in the analysis, I added traces of the tail and tx_bytes and then wrote a test program: while true; do echo -n "abcdefghijklmnopqrstuvwxyz0" > /dev/ttyMSM0 sleep .1 done I watched the traces over SSH and saw: qcom_geni_serial_send_chunk_fifo: 4093 4 qcom_geni_serial_send_chunk_fifo: 1 3 Which indicated that one byte should be missing. Sure enough the output that should have been: abcdefghijklmnopqrstuvwxyz0 In one case was actually missing a byte: abcdefghijklmnopqrstuvwyz0 Running "ls -al" on large directories also made the missing bytes obvious since columns didn't line up. While the original code may not be the most elegant, we only talking about copying up to 4 bytes here. Let's just go back to the code that worked. Fixes: 5c7e105cd156 ("tty: serial: simplify qcom_geni_serial_send_chunk_fifo()") Cc: stable <stable@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Jiri Slaby <jirislaby@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240304174952.1.I920a314049b345efd1f69d708e7f74d2213d0b49@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05 01:49:53 +00:00
unsigned int chunk)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
struct circ_buf *xmit = &uport->state->xmit;
Revert "tty: serial: simplify qcom_geni_serial_send_chunk_fifo()" This reverts commit 5c7e105cd156fc9adf5294a83623d7a40c15f9b9. As identified by KASAN, the simplification done by the cleanup patch was not legal. >From tracing through the code, it can be seen that we're transmitting from a 4096-byte circular buffer. We copy anywhere from 1-4 bytes from it each time. The simplification runs into trouble when we get near the end of the circular buffer. For instance, we might start out with xmit->tail = 4094 and we want to transfer 4 bytes. With the code before simplification this was no problem. We'd read buf[4094], buf[4095], buf[0], and buf[1]. With the new code we'll do a memcpy(&buf[4094], 4) which reads 2 bytes past the end of the buffer and then skips transmitting what's at buf[0] and buf[1]. KASAN isn't 100% consistent at reporting this for me, but to be extra confident in the analysis, I added traces of the tail and tx_bytes and then wrote a test program: while true; do echo -n "abcdefghijklmnopqrstuvwxyz0" > /dev/ttyMSM0 sleep .1 done I watched the traces over SSH and saw: qcom_geni_serial_send_chunk_fifo: 4093 4 qcom_geni_serial_send_chunk_fifo: 1 3 Which indicated that one byte should be missing. Sure enough the output that should have been: abcdefghijklmnopqrstuvwxyz0 In one case was actually missing a byte: abcdefghijklmnopqrstuvwyz0 Running "ls -al" on large directories also made the missing bytes obvious since columns didn't line up. While the original code may not be the most elegant, we only talking about copying up to 4 bytes here. Let's just go back to the code that worked. Fixes: 5c7e105cd156 ("tty: serial: simplify qcom_geni_serial_send_chunk_fifo()") Cc: stable <stable@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Jiri Slaby <jirislaby@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240304174952.1.I920a314049b345efd1f69d708e7f74d2213d0b49@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05 01:49:53 +00:00
unsigned int tx_bytes, c, remaining = chunk;
u8 buf[BYTES_PER_FIFO_WORD];
while (remaining) {
memset(buf, 0, sizeof(buf));
tx_bytes = min(remaining, BYTES_PER_FIFO_WORD);
Revert "tty: serial: simplify qcom_geni_serial_send_chunk_fifo()" This reverts commit 5c7e105cd156fc9adf5294a83623d7a40c15f9b9. As identified by KASAN, the simplification done by the cleanup patch was not legal. >From tracing through the code, it can be seen that we're transmitting from a 4096-byte circular buffer. We copy anywhere from 1-4 bytes from it each time. The simplification runs into trouble when we get near the end of the circular buffer. For instance, we might start out with xmit->tail = 4094 and we want to transfer 4 bytes. With the code before simplification this was no problem. We'd read buf[4094], buf[4095], buf[0], and buf[1]. With the new code we'll do a memcpy(&buf[4094], 4) which reads 2 bytes past the end of the buffer and then skips transmitting what's at buf[0] and buf[1]. KASAN isn't 100% consistent at reporting this for me, but to be extra confident in the analysis, I added traces of the tail and tx_bytes and then wrote a test program: while true; do echo -n "abcdefghijklmnopqrstuvwxyz0" > /dev/ttyMSM0 sleep .1 done I watched the traces over SSH and saw: qcom_geni_serial_send_chunk_fifo: 4093 4 qcom_geni_serial_send_chunk_fifo: 1 3 Which indicated that one byte should be missing. Sure enough the output that should have been: abcdefghijklmnopqrstuvwxyz0 In one case was actually missing a byte: abcdefghijklmnopqrstuvwyz0 Running "ls -al" on large directories also made the missing bytes obvious since columns didn't line up. While the original code may not be the most elegant, we only talking about copying up to 4 bytes here. Let's just go back to the code that worked. Fixes: 5c7e105cd156 ("tty: serial: simplify qcom_geni_serial_send_chunk_fifo()") Cc: stable <stable@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Jiri Slaby <jirislaby@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240304174952.1.I920a314049b345efd1f69d708e7f74d2213d0b49@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-05 01:49:53 +00:00
for (c = 0; c < tx_bytes ; c++) {
buf[c] = xmit->buf[xmit->tail];
uart_xmit_advance(uport, 1);
}
iowrite32_rep(uport->membase + SE_GENI_TX_FIFOn, buf, 1);
remaining -= tx_bytes;
port->tx_remaining -= tx_bytes;
}
}
static void qcom_geni_serial_handle_tx_fifo(struct uart_port *uport,
bool done, bool active)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
struct circ_buf *xmit = &uport->state->xmit;
size_t avail;
size_t pending;
u32 status;
u32 irq_en;
unsigned int chunk;
status = readl(uport->membase + SE_GENI_TX_FIFO_STATUS);
/* Complete the current tx command before taking newly added data */
if (active)
pending = port->tx_remaining;
else
pending = uart_circ_chars_pending(xmit);
/* All data has been transmitted and acknowledged as received */
if (!pending && !status && done) {
qcom_geni_serial_stop_tx_fifo(uport);
goto out_write_wakeup;
}
avail = port->tx_fifo_depth - (status & TX_FIFO_WC);
avail *= BYTES_PER_FIFO_WORD;
chunk = min(avail, pending);
if (!chunk)
goto out_write_wakeup;
if (!port->tx_remaining) {
qcom_geni_serial_setup_tx(uport, pending);
port->tx_remaining = pending;
irq_en = readl(uport->membase + SE_GENI_M_IRQ_EN);
if (!(irq_en & M_TX_FIFO_WATERMARK_EN))
writel(irq_en | M_TX_FIFO_WATERMARK_EN,
uport->membase + SE_GENI_M_IRQ_EN);
}
qcom_geni_serial_send_chunk_fifo(uport, chunk);
/*
* The tx fifo watermark is level triggered and latched. Though we had
* cleared it in qcom_geni_serial_isr it will have already reasserted
* so we must clear it again here after our writes.
*/
writel(M_TX_FIFO_WATERMARK_EN,
uport->membase + SE_GENI_M_IRQ_CLEAR);
out_write_wakeup:
if (!port->tx_remaining) {
irq_en = readl(uport->membase + SE_GENI_M_IRQ_EN);
if (irq_en & M_TX_FIFO_WATERMARK_EN)
writel(irq_en & ~M_TX_FIFO_WATERMARK_EN,
uport->membase + SE_GENI_M_IRQ_EN);
}
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(uport);
}
static void qcom_geni_serial_handle_tx_dma(struct uart_port *uport)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
struct circ_buf *xmit = &uport->state->xmit;
uart_xmit_advance(uport, port->tx_remaining);
geni_se_tx_dma_unprep(&port->se, port->tx_dma_addr, port->tx_remaining);
port->tx_dma_addr = 0;
port->tx_remaining = 0;
if (!uart_circ_empty(xmit))
qcom_geni_serial_start_tx_dma(uport);
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(uport);
}
static irqreturn_t qcom_geni_serial_isr(int isr, void *dev)
{
u32 m_irq_en;
u32 m_irq_status;
u32 s_irq_status;
u32 geni_status;
u32 dma;
u32 dma_tx_status;
u32 dma_rx_status;
struct uart_port *uport = dev;
bool drop_rx = false;
struct tty_port *tport = &uport->state->port;
struct qcom_geni_serial_port *port = to_dev_port(uport);
if (uport->suspended)
return IRQ_NONE;
serial: qcom-geni: Use port lock wrappers When a serial port is used for kernel console output, then all modifications to the UART registers which are done from other contexts, e.g. getty, termios, are interference points for the kernel console. So far this has been ignored and the printk output is based on the principle of hope. The rework of the console infrastructure which aims to support threaded and atomic consoles, requires to mark sections which modify the UART registers as unsafe. This allows the atomic write function to make informed decisions and eventually to restore operational state. It also allows to prevent the regular UART code from modifying UART registers while printk output is in progress. All modifications of UART registers are guarded by the UART port lock, which provides an obvious synchronization point with the console infrastructure. To avoid adding this functionality to all UART drivers, wrap the spin_[un]lock*() invocations for uart_port::lock into helper functions which just contain the spin_[un]lock*() invocations for now. In a subsequent step these helpers will gain the console synchronization mechanisms. Converted with coccinelle. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://lore.kernel.org/r/20230914183831.587273-50-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-14 18:38:06 +00:00
uart_port_lock(uport);
m_irq_status = readl(uport->membase + SE_GENI_M_IRQ_STATUS);
s_irq_status = readl(uport->membase + SE_GENI_S_IRQ_STATUS);
dma_tx_status = readl(uport->membase + SE_DMA_TX_IRQ_STAT);
dma_rx_status = readl(uport->membase + SE_DMA_RX_IRQ_STAT);
geni_status = readl(uport->membase + SE_GENI_STATUS);
dma = readl(uport->membase + SE_GENI_DMA_MODE_EN);
m_irq_en = readl(uport->membase + SE_GENI_M_IRQ_EN);
writel(m_irq_status, uport->membase + SE_GENI_M_IRQ_CLEAR);
writel(s_irq_status, uport->membase + SE_GENI_S_IRQ_CLEAR);
writel(dma_tx_status, uport->membase + SE_DMA_TX_IRQ_CLR);
writel(dma_rx_status, uport->membase + SE_DMA_RX_IRQ_CLR);
if (WARN_ON(m_irq_status & M_ILLEGAL_CMD_EN))
goto out_unlock;
if (s_irq_status & S_RX_FIFO_WR_ERR_EN) {
uport->icount.overrun++;
tty_insert_flip_char(tport, 0, TTY_OVERRUN);
}
if (s_irq_status & (S_GP_IRQ_0_EN | S_GP_IRQ_1_EN)) {
if (s_irq_status & S_GP_IRQ_0_EN)
uport->icount.parity++;
drop_rx = true;
} else if (s_irq_status & (S_GP_IRQ_2_EN | S_GP_IRQ_3_EN)) {
uport->icount.brk++;
port->brk = true;
}
if (dma) {
if (dma_tx_status & TX_DMA_DONE)
qcom_geni_serial_handle_tx_dma(uport);
if (dma_rx_status) {
if (dma_rx_status & RX_RESET_DONE)
goto out_unlock;
if (dma_rx_status & RX_DMA_PARITY_ERR) {
uport->icount.parity++;
drop_rx = true;
}
if (dma_rx_status & RX_DMA_BREAK)
uport->icount.brk++;
if (dma_rx_status & (RX_DMA_DONE | RX_EOT))
qcom_geni_serial_handle_rx_dma(uport, drop_rx);
}
} else {
if (m_irq_status & m_irq_en &
(M_TX_FIFO_WATERMARK_EN | M_CMD_DONE_EN))
qcom_geni_serial_handle_tx_fifo(uport,
m_irq_status & M_CMD_DONE_EN,
geni_status & M_GENI_CMD_ACTIVE);
if (s_irq_status & (S_RX_FIFO_WATERMARK_EN | S_RX_FIFO_LAST_EN))
qcom_geni_serial_handle_rx_fifo(uport, drop_rx);
}
out_unlock:
uart_unlock_and_check_sysrq(uport);
return IRQ_HANDLED;
}
tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer. Fixes: f9d690b6ece7 ("tty: serial: qcom_geni_serial: Allocate port->rx_fifo buffer in probe") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20221221164022.1087814-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21 16:40:22 +00:00
static int setup_fifos(struct qcom_geni_serial_port *port)
{
struct uart_port *uport;
tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer. Fixes: f9d690b6ece7 ("tty: serial: qcom_geni_serial: Allocate port->rx_fifo buffer in probe") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20221221164022.1087814-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21 16:40:22 +00:00
u32 old_rx_fifo_depth = port->rx_fifo_depth;
uport = &port->uport;
port->tx_fifo_depth = geni_se_get_tx_fifo_depth(&port->se);
port->tx_fifo_width = geni_se_get_tx_fifo_width(&port->se);
port->rx_fifo_depth = geni_se_get_rx_fifo_depth(&port->se);
uport->fifosize =
(port->tx_fifo_depth * port->tx_fifo_width) / BITS_PER_BYTE;
tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer. Fixes: f9d690b6ece7 ("tty: serial: qcom_geni_serial: Allocate port->rx_fifo buffer in probe") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20221221164022.1087814-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21 16:40:22 +00:00
if (port->rx_buf && (old_rx_fifo_depth != port->rx_fifo_depth) && port->rx_fifo_depth) {
/*
* Use krealloc rather than krealloc_array because rx_buf is
* accessed as 1 byte entries as well as 4 byte entries so it's
* not necessarily an array.
*/
port->rx_buf = devm_krealloc(uport->dev, port->rx_buf,
port->rx_fifo_depth * sizeof(u32),
GFP_KERNEL);
if (!port->rx_buf)
tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer. Fixes: f9d690b6ece7 ("tty: serial: qcom_geni_serial: Allocate port->rx_fifo buffer in probe") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20221221164022.1087814-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21 16:40:22 +00:00
return -ENOMEM;
}
return 0;
}
static void qcom_geni_serial_shutdown(struct uart_port *uport)
{
disable_irq(uport->irq);
if (uart_console(uport))
return;
qcom_geni_serial_stop_tx(uport);
qcom_geni_serial_stop_rx(uport);
}
static int qcom_geni_serial_port_setup(struct uart_port *uport)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
u32 rxstale = DEFAULT_BITS_PER_CHAR * STALE_TIMEOUT;
tty: serial: qcom_geni_serial: Fix serial when not used as console If you've got the "console" serial port setup to use just as a UART (AKA there is no "console=ttyMSMX" on the kernel command line) then certain initialization is skipped. When userspace later tries to do something with the port then things go boom (specifically, on my system, some sort of exception hit that caused the system to reboot itself w/ no error messages). Let's cleanup / refactor the init so that we always run the same init code regardless of whether we're using the console. To make this work, we make rely on qcom_geni_serial_pm doing its job to turn resources on. For the record, here is a trace of the order of things (after this patch) when console= is specified on the command line and we have an agetty on the port: qcom_geni_serial_pm: 4 (undefined) => 0 (on) qcom_geni_console_setup qcom_geni_serial_port_setup qcom_geni_serial_console_write qcom_geni_serial_startup qcom_geni_serial_start_tx ...and here is the order of things (after this patch) when console= is _NOT_ specified on the command line and we have an agetty port: qcom_geni_serial_pm: 4 => 0 qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_port_setup qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_start_tx Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-05 20:11:46 +00:00
u32 proto;
u32 pin_swap;
tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer. Fixes: f9d690b6ece7 ("tty: serial: qcom_geni_serial: Allocate port->rx_fifo buffer in probe") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20221221164022.1087814-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21 16:40:22 +00:00
int ret;
tty: serial: qcom_geni_serial: Fix serial when not used as console If you've got the "console" serial port setup to use just as a UART (AKA there is no "console=ttyMSMX" on the kernel command line) then certain initialization is skipped. When userspace later tries to do something with the port then things go boom (specifically, on my system, some sort of exception hit that caused the system to reboot itself w/ no error messages). Let's cleanup / refactor the init so that we always run the same init code regardless of whether we're using the console. To make this work, we make rely on qcom_geni_serial_pm doing its job to turn resources on. For the record, here is a trace of the order of things (after this patch) when console= is specified on the command line and we have an agetty on the port: qcom_geni_serial_pm: 4 (undefined) => 0 (on) qcom_geni_console_setup qcom_geni_serial_port_setup qcom_geni_serial_console_write qcom_geni_serial_startup qcom_geni_serial_start_tx ...and here is the order of things (after this patch) when console= is _NOT_ specified on the command line and we have an agetty port: qcom_geni_serial_pm: 4 => 0 qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_port_setup qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_start_tx Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-05 20:11:46 +00:00
proto = geni_se_read_proto(&port->se);
if (proto != GENI_SE_UART) {
dev_err(uport->dev, "Invalid FW loaded, proto: %d\n", proto);
return -ENXIO;
}
qcom_geni_serial_stop_rx(uport);
tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer. Fixes: f9d690b6ece7 ("tty: serial: qcom_geni_serial: Allocate port->rx_fifo buffer in probe") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20221221164022.1087814-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21 16:40:22 +00:00
ret = setup_fifos(port);
if (ret)
return ret;
writel(rxstale, uport->membase + SE_UART_RX_STALE_CNT);
pin_swap = readl(uport->membase + SE_UART_IO_MACRO_CTRL);
if (port->rx_tx_swap) {
pin_swap &= ~DEFAULT_IO_MACRO_IO2_IO3_MASK;
pin_swap |= IO_MACRO_IO2_IO3_SWAP;
}
if (port->cts_rts_swap) {
pin_swap &= ~DEFAULT_IO_MACRO_IO0_IO1_MASK;
pin_swap |= IO_MACRO_IO0_SEL;
}
/* Configure this register if RX-TX, CTS-RTS pins are swapped */
if (port->rx_tx_swap || port->cts_rts_swap)
writel(pin_swap, uport->membase + SE_UART_IO_MACRO_CTRL);
/*
* Make an unconditional cancel on the main sequencer to reset
* it else we could end up in data loss scenarios.
*/
if (uart_console(uport))
qcom_geni_serial_poll_tx_done(uport);
geni_se_config_packing(&port->se, BITS_PER_BYTE, BYTES_PER_FIFO_WORD,
false, true, true);
geni_se_init(&port->se, UART_RX_WM, port->rx_fifo_depth - 2);
geni_se_select_mode(&port->se, port->dev_data->mode);
qcom_geni_serial_start_rx(uport);
port->setup = true;
tty: serial: qcom_geni_serial: Fix serial when not used as console If you've got the "console" serial port setup to use just as a UART (AKA there is no "console=ttyMSMX" on the kernel command line) then certain initialization is skipped. When userspace later tries to do something with the port then things go boom (specifically, on my system, some sort of exception hit that caused the system to reboot itself w/ no error messages). Let's cleanup / refactor the init so that we always run the same init code regardless of whether we're using the console. To make this work, we make rely on qcom_geni_serial_pm doing its job to turn resources on. For the record, here is a trace of the order of things (after this patch) when console= is specified on the command line and we have an agetty on the port: qcom_geni_serial_pm: 4 (undefined) => 0 (on) qcom_geni_console_setup qcom_geni_serial_port_setup qcom_geni_serial_console_write qcom_geni_serial_startup qcom_geni_serial_start_tx ...and here is the order of things (after this patch) when console= is _NOT_ specified on the command line and we have an agetty port: qcom_geni_serial_pm: 4 => 0 qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_port_setup qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_start_tx Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-05 20:11:46 +00:00
return 0;
}
static int qcom_geni_serial_startup(struct uart_port *uport)
{
int ret;
struct qcom_geni_serial_port *port = to_dev_port(uport);
if (!port->setup) {
ret = qcom_geni_serial_port_setup(uport);
if (ret)
return ret;
}
enable_irq(uport->irq);
return 0;
}
static unsigned long find_clk_rate_in_tol(struct clk *clk, unsigned int desired_clk,
unsigned int *clk_div, unsigned int percent_tol)
{
unsigned long freq;
unsigned long div, maxdiv;
u64 mult;
unsigned long offset, abs_tol, achieved;
abs_tol = div_u64((u64)desired_clk * percent_tol, 100);
maxdiv = CLK_DIV_MSK >> CLK_DIV_SHFT;
div = 1;
while (div <= maxdiv) {
mult = (u64)div * desired_clk;
if (mult != (unsigned long)mult)
break;
offset = div * abs_tol;
freq = clk_round_rate(clk, mult - offset);
/* Can only get lower if we're done */
if (freq < mult - offset)
break;
/*
* Re-calculate div in case rounding skipped rates but we
* ended up at a good one, then check for a match.
*/
div = DIV_ROUND_CLOSEST(freq, desired_clk);
achieved = DIV_ROUND_CLOSEST(freq, div);
if (achieved <= desired_clk + abs_tol &&
achieved >= desired_clk - abs_tol) {
*clk_div = div;
return freq;
}
div = DIV_ROUND_UP(freq, desired_clk);
}
return 0;
}
static unsigned long get_clk_div_rate(struct clk *clk, unsigned int baud,
unsigned int sampling_rate, unsigned int *clk_div)
{
unsigned long ser_clk;
unsigned long desired_clk;
desired_clk = baud * sampling_rate;
if (!desired_clk)
return 0;
/*
* try to find a clock rate within 2% tolerance, then within 5%
*/
ser_clk = find_clk_rate_in_tol(clk, desired_clk, clk_div, 2);
if (!ser_clk)
ser_clk = find_clk_rate_in_tol(clk, desired_clk, clk_div, 5);
return ser_clk;
}
static void qcom_geni_serial_set_termios(struct uart_port *uport,
struct ktermios *termios,
const struct ktermios *old)
{
unsigned int baud;
u32 bits_per_char;
u32 tx_trans_cfg;
u32 tx_parity_cfg;
u32 rx_trans_cfg;
u32 rx_parity_cfg;
u32 stop_bit_len;
unsigned int clk_div;
u32 ser_clk_cfg;
struct qcom_geni_serial_port *port = to_dev_port(uport);
unsigned long clk_rate;
u32 ver, sampling_rate;
unsigned int avg_bw_core;
qcom_geni_serial_stop_rx(uport);
/* baud rate */
baud = uart_get_baud_rate(uport, termios, old, 300, 4000000);
port->baud = baud;
sampling_rate = UART_OVERSAMPLING;
/* Sampling rate is halved for IP versions >= 2.5 */
ver = geni_se_get_qup_hw_version(&port->se);
if (ver >= QUP_SE_VERSION_2_5)
sampling_rate /= 2;
clk_rate = get_clk_div_rate(port->se.clk, baud,
sampling_rate, &clk_div);
if (!clk_rate) {
dev_err(port->se.dev,
"Couldn't find suitable clock rate for %u\n",
baud * sampling_rate);
goto out_restart_rx;
}
dev_dbg(port->se.dev, "desired_rate = %u, clk_rate = %lu, clk_div = %u\n",
baud * sampling_rate, clk_rate, clk_div);
uport->uartclk = clk_rate;
port->clk_rate = clk_rate;
dev_pm_opp_set_rate(uport->dev, clk_rate);
ser_clk_cfg = SER_CLK_EN;
ser_clk_cfg |= clk_div << CLK_DIV_SHFT;
/*
* Bump up BW vote on CPU and CORE path as driver supports FIFO mode
* only.
*/
avg_bw_core = (baud > 115200) ? Bps_to_icc(CORE_2X_50_MHZ)
: GENI_DEFAULT_BW;
port->se.icc_paths[GENI_TO_CORE].avg_bw = avg_bw_core;
port->se.icc_paths[CPU_TO_GENI].avg_bw = Bps_to_icc(baud);
geni_icc_set_bw(&port->se);
/* parity */
tx_trans_cfg = readl(uport->membase + SE_UART_TX_TRANS_CFG);
tx_parity_cfg = readl(uport->membase + SE_UART_TX_PARITY_CFG);
rx_trans_cfg = readl(uport->membase + SE_UART_RX_TRANS_CFG);
rx_parity_cfg = readl(uport->membase + SE_UART_RX_PARITY_CFG);
if (termios->c_cflag & PARENB) {
tx_trans_cfg |= UART_TX_PAR_EN;
rx_trans_cfg |= UART_RX_PAR_EN;
tx_parity_cfg |= PAR_CALC_EN;
rx_parity_cfg |= PAR_CALC_EN;
if (termios->c_cflag & PARODD) {
tx_parity_cfg |= PAR_ODD;
rx_parity_cfg |= PAR_ODD;
} else if (termios->c_cflag & CMSPAR) {
tx_parity_cfg |= PAR_SPACE;
rx_parity_cfg |= PAR_SPACE;
} else {
tx_parity_cfg |= PAR_EVEN;
rx_parity_cfg |= PAR_EVEN;
}
} else {
tx_trans_cfg &= ~UART_TX_PAR_EN;
rx_trans_cfg &= ~UART_RX_PAR_EN;
tx_parity_cfg &= ~PAR_CALC_EN;
rx_parity_cfg &= ~PAR_CALC_EN;
}
/* bits per char */
bits_per_char = tty_get_char_size(termios->c_cflag);
/* stop bits */
if (termios->c_cflag & CSTOPB)
stop_bit_len = TX_STOP_BIT_LEN_2;
else
stop_bit_len = TX_STOP_BIT_LEN_1;
/* flow control, clear the CTS_MASK bit if using flow control. */
if (termios->c_cflag & CRTSCTS)
tx_trans_cfg &= ~UART_CTS_MASK;
else
tx_trans_cfg |= UART_CTS_MASK;
if (baud)
uart_update_timeout(uport, termios->c_cflag, baud);
if (!uart_console(uport))
writel(port->loopback,
uport->membase + SE_UART_LOOPBACK_CFG);
writel(tx_trans_cfg, uport->membase + SE_UART_TX_TRANS_CFG);
writel(tx_parity_cfg, uport->membase + SE_UART_TX_PARITY_CFG);
writel(rx_trans_cfg, uport->membase + SE_UART_RX_TRANS_CFG);
writel(rx_parity_cfg, uport->membase + SE_UART_RX_PARITY_CFG);
writel(bits_per_char, uport->membase + SE_UART_TX_WORD_LEN);
writel(bits_per_char, uport->membase + SE_UART_RX_WORD_LEN);
writel(stop_bit_len, uport->membase + SE_UART_TX_STOP_BIT_LEN);
writel(ser_clk_cfg, uport->membase + GENI_SER_M_CLK_CFG);
writel(ser_clk_cfg, uport->membase + GENI_SER_S_CLK_CFG);
out_restart_rx:
qcom_geni_serial_start_rx(uport);
}
#ifdef CONFIG_SERIAL_QCOM_GENI_CONSOLE
tty: serial: qcom_geni_serial: Drop __init from qcom_geni_console_setup When booting with heavily modularized config, the serial console may not be able to load until after init when modules that satisfy needed dependencies have time to load. Unfortunately, as qcom_geni_console_setup is marked as __init, the function may have been freed before we get to run it, causing boot time crashes such as: [ 6.469057] Unable to handle kernel paging request at virtual address ffffffe645d4e6cc [ 6.481623] Mem abort info: [ 6.484466] ESR = 0x86000007 [ 6.487557] EC = 0x21: IABT (current EL), IL = 32 bits [ 6.492929] SET = 0, FnV = 0g [ 6.496016] EA = 0, S1PTW = 0 [ 6.499202] swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008151e000 [ 6.501286] ufshcd-qcom 1d84000.ufshc: ufshcd_print_pwr_info:[RX, TX]: gear=[3, 3], lane[2, 2], pwr[FAST MODE, FAST MODE], rate = 2 [ 6.505977] [ffffffe645d4e6cc] pgd=000000017df9f003, p4d=000000017df9f003, pud=000000017df9f003, pmd=000000017df9c003, pte=0000000000000000 [ 6.505990] Internal error: Oops: 86000007 [#1] PREEMPT SMP [ 6.505995] Modules linked in: zl10353 zl10039 zl10036 zd1301_demod xc5000 xc4000 ves1x93 ves1820 tuner_xc2028 tuner_simple tuner_types tua9001 tua6100 1 [ 6.506152] isl6405 [ 6.518104] ufshcd-qcom 1d84000.ufshc: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0 [ 6.530549] horus3a helene fc2580 fc0013 fc0012 fc0011 ec100 e4000 dvb_pll ds3000 drxk drxd drx39xyj dib9000 dib8000 dib7000p dib7000m dib3000mc dibx003 [ 6.624271] CPU: 7 PID: 148 Comm: kworker/7:2 Tainted: G W 5.8.0-mainline-12021-g6defd37ba1cd #3455 [ 6.624273] Hardware name: Thundercomm Dragonboard 845c (DT) [ 6.624290] Workqueue: events deferred_probe_work_func [ 6.624296] pstate: 40c00005 (nZcv daif +PAN +UAO BTYPE=--) [ 6.624307] pc : qcom_geni_console_setup+0x0/0x110 [ 6.624316] lr : try_enable_new_console+0xa0/0x140 [ 6.624318] sp : ffffffc010843a30 [ 6.624320] x29: ffffffc010843a30 x28: ffffffe645c3e7d0 [ 6.624325] x27: ffffff80f8022180 x26: ffffffc010843b28 [ 6.637937] x25: 0000000000000000 x24: ffffffe6462a2000 [ 6.637941] x23: ffffffe646398000 x22: 0000000000000000 [ 6.637945] x21: 0000000000000000 x20: ffffffe6462a5ce8 [ 6.637952] x19: ffffffe646398e38 x18: ffffffffffffffff [ 6.680296] x17: 0000000000000000 x16: ffffffe64492b900 [ 6.680300] x15: ffffffe6461e9d08 x14: 69202930203d2064 [ 6.680305] x13: 7561625f65736162 x12: 202c363331203d20 [ 6.696434] x11: 0000000000000030 x10: 0101010101010101 [ 6.696438] x9 : 4d4d20746120304d x8 : 7f7f7f7f7f7f7f7f [ 6.707249] x7 : feff4c524c787373 x6 : 0000000000008080 [ 6.707253] x5 : 0000000000000000 x4 : 8080000000000000 [ 6.707257] x3 : 0000000000000000 x2 : ffffffe645d4e6cc [ 6.744223] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 102400000 (-34) [ 6.744966] x1 : fffffffefe74e174 x0 : ffffffe6462a5ce8 [ 6.753580] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 102400000 (-34) [ 6.761634] Call trace: [ 6.761639] qcom_geni_console_setup+0x0/0x110 [ 6.761645] register_console+0x29c/0x2f8 [ 6.767981] Bluetooth: hci0: Frame reassembly failed (-84) [ 6.775252] uart_add_one_port+0x438/0x500 [ 6.775258] qcom_geni_serial_probe+0x2c4/0x4a8 [ 6.775266] platform_drv_probe+0x58/0xa8 [ 6.855359] really_probe+0xec/0x398 [ 6.855362] driver_probe_device+0x5c/0xb8 [ 6.855367] __device_attach_driver+0x98/0xb8 [ 7.184945] bus_for_each_drv+0x74/0xd8 [ 7.188825] __device_attach+0xec/0x148 [ 7.192705] device_initial_probe+0x24/0x30 [ 7.196937] bus_probe_device+0x9c/0xa8 [ 7.200816] deferred_probe_work_func+0x7c/0xb8 [ 7.205398] process_one_work+0x20c/0x4b0 [ 7.209456] worker_thread+0x48/0x460 [ 7.213157] kthread+0x14c/0x158 [ 7.216432] ret_from_fork+0x10/0x18 [ 7.220049] Code: bad PC value [ 7.223139] ---[ end trace 73f3b21e251d5a70 ]--- Thus this patch removes the __init avoiding crash in such configs. Cc: Andy Gross <agross@kernel.org> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: linux-arm-msm@vger.kernel.org Cc: linux-serial@vger.kernel.org Suggested-by: Saravana Kannan <saravanak@google.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200811025044.70626-1-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-11 02:50:44 +00:00
static int qcom_geni_console_setup(struct console *co, char *options)
{
struct uart_port *uport;
struct qcom_geni_serial_port *port;
tty: serial: qcom_geni_serial: 115.2 is a better console default than 9600 Commit c5cbc78acf69 ("tty: serial: qcom_geni_serial: Initialize baud in qcom_geni_console_setup") fixed a bug by initting a variable that was used in some cases without initialization. However, the "default" baud rate picked by that CL was probably not the best choice. The chances that anyone out there is trying to run a system with kernel messages piped out over a 9600 baud serial port is just about nil. Console messages are printed in a blocking manner. At 9600 baud we print about 1 character per millisecond which means that printing a 40-byte message to the console will take ~40 ms. While it would probably work, it's going to make boot _very_ slow and probably cause the occasional timeout here and there in drivers (heck, even at 115200 console delays can wreck havoc). This has already bit at least two people that I'm aware of that tried to enable serial console by just adding "console=ttyMSM0" (instead of "console=ttyMSM0,115200n8") to the command line, so it seems like it'd be nice to fix. Let's switch the default to 115200. Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200911080054.1.I4c00b921c2f17b6988688046fa7be0f729f8d591@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-11 15:00:57 +00:00
int baud = 115200;
int bits = 8;
int parity = 'n';
int flow = 'n';
tty: serial: qcom_geni_serial: Fix serial when not used as console If you've got the "console" serial port setup to use just as a UART (AKA there is no "console=ttyMSMX" on the kernel command line) then certain initialization is skipped. When userspace later tries to do something with the port then things go boom (specifically, on my system, some sort of exception hit that caused the system to reboot itself w/ no error messages). Let's cleanup / refactor the init so that we always run the same init code regardless of whether we're using the console. To make this work, we make rely on qcom_geni_serial_pm doing its job to turn resources on. For the record, here is a trace of the order of things (after this patch) when console= is specified on the command line and we have an agetty on the port: qcom_geni_serial_pm: 4 (undefined) => 0 (on) qcom_geni_console_setup qcom_geni_serial_port_setup qcom_geni_serial_console_write qcom_geni_serial_startup qcom_geni_serial_start_tx ...and here is the order of things (after this patch) when console= is _NOT_ specified on the command line and we have an agetty port: qcom_geni_serial_pm: 4 => 0 qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_port_setup qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_start_tx Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-05 20:11:46 +00:00
int ret;
if (co->index >= GENI_UART_CONS_PORTS || co->index < 0)
return -ENXIO;
port = get_port_from_line(co->index, true);
if (IS_ERR(port)) {
pr_err("Invalid line %d\n", co->index);
return PTR_ERR(port);
}
uport = &port->uport;
if (unlikely(!uport->membase))
return -ENXIO;
if (!port->setup) {
tty: serial: qcom_geni_serial: Fix serial when not used as console If you've got the "console" serial port setup to use just as a UART (AKA there is no "console=ttyMSMX" on the kernel command line) then certain initialization is skipped. When userspace later tries to do something with the port then things go boom (specifically, on my system, some sort of exception hit that caused the system to reboot itself w/ no error messages). Let's cleanup / refactor the init so that we always run the same init code regardless of whether we're using the console. To make this work, we make rely on qcom_geni_serial_pm doing its job to turn resources on. For the record, here is a trace of the order of things (after this patch) when console= is specified on the command line and we have an agetty on the port: qcom_geni_serial_pm: 4 (undefined) => 0 (on) qcom_geni_console_setup qcom_geni_serial_port_setup qcom_geni_serial_console_write qcom_geni_serial_startup qcom_geni_serial_start_tx ...and here is the order of things (after this patch) when console= is _NOT_ specified on the command line and we have an agetty port: qcom_geni_serial_pm: 4 => 0 qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_port_setup qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_start_tx Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-05 20:11:46 +00:00
ret = qcom_geni_serial_port_setup(uport);
if (ret)
return ret;
}
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
return uart_set_options(uport, co, baud, parity, bits, flow);
}
static void qcom_geni_serial_earlycon_write(struct console *con,
const char *s, unsigned int n)
{
struct earlycon_device *dev = con->data;
__qcom_geni_serial_console_write(&dev->port, s, n);
}
#ifdef CONFIG_CONSOLE_POLL
static int qcom_geni_serial_earlycon_read(struct console *con,
char *s, unsigned int n)
{
struct earlycon_device *dev = con->data;
struct uart_port *uport = &dev->port;
int num_read = 0;
int ch;
while (num_read < n) {
ch = qcom_geni_serial_get_char(uport);
if (ch == NO_POLL_CHAR)
break;
s[num_read++] = ch;
}
return num_read;
}
static void __init qcom_geni_serial_enable_early_read(struct geni_se *se,
struct console *con)
{
geni_se_setup_s_cmd(se, UART_START_READ, 0);
con->read = qcom_geni_serial_earlycon_read;
}
#else
static inline void qcom_geni_serial_enable_early_read(struct geni_se *se,
struct console *con) { }
#endif
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
static struct qcom_geni_private_data earlycon_private_data;
static int __init qcom_geni_serial_earlycon_setup(struct earlycon_device *dev,
const char *opt)
{
struct uart_port *uport = &dev->port;
u32 tx_trans_cfg;
u32 tx_parity_cfg = 0; /* Disable Tx Parity */
u32 rx_trans_cfg = 0;
u32 rx_parity_cfg = 0; /* Disable Rx Parity */
u32 stop_bit_len = 0; /* Default stop bit length - 1 bit */
u32 bits_per_char;
struct geni_se se;
if (!uport->membase)
return -EINVAL;
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
uport->private_data = &earlycon_private_data;
memset(&se, 0, sizeof(se));
se.base = uport->membase;
if (geni_se_read_proto(&se) != GENI_SE_UART)
return -ENXIO;
/*
* Ignore Flow control.
* n = 8.
*/
tx_trans_cfg = UART_CTS_MASK;
bits_per_char = BITS_PER_BYTE;
/*
* Make an unconditional cancel on the main sequencer to reset
* it else we could end up in data loss scenarios.
*/
qcom_geni_serial_poll_tx_done(uport);
qcom_geni_serial_abort_rx(uport);
geni_se_config_packing(&se, BITS_PER_BYTE, BYTES_PER_FIFO_WORD,
false, true, true);
geni_se_init(&se, DEF_FIFO_DEPTH_WORDS / 2, DEF_FIFO_DEPTH_WORDS - 2);
geni_se_select_mode(&se, GENI_SE_FIFO);
writel(tx_trans_cfg, uport->membase + SE_UART_TX_TRANS_CFG);
writel(tx_parity_cfg, uport->membase + SE_UART_TX_PARITY_CFG);
writel(rx_trans_cfg, uport->membase + SE_UART_RX_TRANS_CFG);
writel(rx_parity_cfg, uport->membase + SE_UART_RX_PARITY_CFG);
writel(bits_per_char, uport->membase + SE_UART_TX_WORD_LEN);
writel(bits_per_char, uport->membase + SE_UART_RX_WORD_LEN);
writel(stop_bit_len, uport->membase + SE_UART_TX_STOP_BIT_LEN);
dev->con->write = qcom_geni_serial_earlycon_write;
dev->con->setup = NULL;
qcom_geni_serial_enable_early_read(&se, dev->con);
return 0;
}
OF_EARLYCON_DECLARE(qcom_geni, "qcom,geni-debug-uart",
qcom_geni_serial_earlycon_setup);
static int __init console_register(struct uart_driver *drv)
{
return uart_register_driver(drv);
}
static void console_unregister(struct uart_driver *drv)
{
uart_unregister_driver(drv);
}
static struct console cons_ops = {
.name = "ttyMSM",
.write = qcom_geni_serial_console_write,
.device = uart_console_device,
.setup = qcom_geni_console_setup,
.flags = CON_PRINTBUFFER,
.index = -1,
.data = &qcom_geni_console_driver,
};
static struct uart_driver qcom_geni_console_driver = {
.owner = THIS_MODULE,
.driver_name = "qcom_geni_console",
.dev_name = "ttyMSM",
.nr = GENI_UART_CONS_PORTS,
.cons = &cons_ops,
};
#else
static int console_register(struct uart_driver *drv)
{
return 0;
}
static void console_unregister(struct uart_driver *drv)
{
}
#endif /* CONFIG_SERIAL_QCOM_GENI_CONSOLE */
static struct uart_driver qcom_geni_uart_driver = {
.owner = THIS_MODULE,
.driver_name = "qcom_geni_uart",
.dev_name = "ttyHS",
.nr = GENI_UART_PORTS,
};
static void qcom_geni_serial_pm(struct uart_port *uport,
unsigned int new_state, unsigned int old_state)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
tty: serial: qcom_geni_serial: Fix serial when not used as console If you've got the "console" serial port setup to use just as a UART (AKA there is no "console=ttyMSMX" on the kernel command line) then certain initialization is skipped. When userspace later tries to do something with the port then things go boom (specifically, on my system, some sort of exception hit that caused the system to reboot itself w/ no error messages). Let's cleanup / refactor the init so that we always run the same init code regardless of whether we're using the console. To make this work, we make rely on qcom_geni_serial_pm doing its job to turn resources on. For the record, here is a trace of the order of things (after this patch) when console= is specified on the command line and we have an agetty on the port: qcom_geni_serial_pm: 4 (undefined) => 0 (on) qcom_geni_console_setup qcom_geni_serial_port_setup qcom_geni_serial_console_write qcom_geni_serial_startup qcom_geni_serial_start_tx ...and here is the order of things (after this patch) when console= is _NOT_ specified on the command line and we have an agetty port: qcom_geni_serial_pm: 4 => 0 qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_port_setup qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_start_tx Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-05 20:11:46 +00:00
/* If we've never been called, treat it as off */
if (old_state == UART_PM_STATE_UNDEFINED)
old_state = UART_PM_STATE_OFF;
if (new_state == UART_PM_STATE_ON && old_state == UART_PM_STATE_OFF) {
geni_icc_enable(&port->se);
if (port->clk_rate)
dev_pm_opp_set_rate(uport->dev, port->clk_rate);
geni_se_resources_on(&port->se);
} else if (new_state == UART_PM_STATE_OFF &&
old_state == UART_PM_STATE_ON) {
geni_se_resources_off(&port->se);
dev_pm_opp_set_rate(uport->dev, 0);
geni_icc_disable(&port->se);
}
}
static const struct uart_ops qcom_geni_console_pops = {
.tx_empty = qcom_geni_serial_tx_empty,
.stop_tx = qcom_geni_serial_stop_tx_fifo,
.start_tx = qcom_geni_serial_start_tx_fifo,
.stop_rx = qcom_geni_serial_stop_rx_fifo,
.start_rx = qcom_geni_serial_start_rx_fifo,
.set_termios = qcom_geni_serial_set_termios,
.startup = qcom_geni_serial_startup,
.request_port = qcom_geni_serial_request_port,
.config_port = qcom_geni_serial_config_port,
.shutdown = qcom_geni_serial_shutdown,
.type = qcom_geni_serial_get_type,
.set_mctrl = qcom_geni_serial_set_mctrl,
.get_mctrl = qcom_geni_serial_get_mctrl,
#ifdef CONFIG_CONSOLE_POLL
.poll_get_char = qcom_geni_serial_get_char,
.poll_put_char = qcom_geni_serial_poll_put_char,
.poll_init = qcom_geni_serial_port_setup,
#endif
.pm = qcom_geni_serial_pm,
};
static const struct uart_ops qcom_geni_uart_pops = {
.tx_empty = qcom_geni_serial_tx_empty,
.stop_tx = qcom_geni_serial_stop_tx_dma,
.start_tx = qcom_geni_serial_start_tx_dma,
.start_rx = qcom_geni_serial_start_rx_dma,
.stop_rx = qcom_geni_serial_stop_rx_dma,
.set_termios = qcom_geni_serial_set_termios,
.startup = qcom_geni_serial_startup,
.request_port = qcom_geni_serial_request_port,
.config_port = qcom_geni_serial_config_port,
.shutdown = qcom_geni_serial_shutdown,
.type = qcom_geni_serial_get_type,
.set_mctrl = qcom_geni_serial_set_mctrl,
.get_mctrl = qcom_geni_serial_get_mctrl,
.pm = qcom_geni_serial_pm,
};
static int qcom_geni_serial_probe(struct platform_device *pdev)
{
int ret = 0;
int line;
struct qcom_geni_serial_port *port;
struct uart_port *uport;
struct resource *res;
int irq;
struct uart_driver *drv;
const struct qcom_geni_device_data *data;
data = of_device_get_match_data(&pdev->dev);
if (!data)
return -EINVAL;
if (data->console) {
drv = &qcom_geni_console_driver;
line = of_alias_get_id(pdev->dev.of_node, "serial");
} else {
drv = &qcom_geni_uart_driver;
line = of_alias_get_id(pdev->dev.of_node, "serial");
if (line == -ENODEV) /* compat with non-standard aliases */
line = of_alias_get_id(pdev->dev.of_node, "hsuart");
}
port = get_port_from_line(line, data->console);
if (IS_ERR(port)) {
dev_err(&pdev->dev, "Invalid line %d\n", line);
return PTR_ERR(port);
}
uport = &port->uport;
/* Don't allow 2 drivers to access the same port */
if (uport->private_data)
return -ENODEV;
uport->dev = &pdev->dev;
port->dev_data = data;
port->se.dev = &pdev->dev;
port->se.wrapper = dev_get_drvdata(pdev->dev.parent);
port->se.clk = devm_clk_get(&pdev->dev, "se");
if (IS_ERR(port->se.clk)) {
ret = PTR_ERR(port->se.clk);
dev_err(&pdev->dev, "Err getting SE Core clk %d\n", ret);
return ret;
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -EINVAL;
uport->mapbase = res->start;
port->tx_fifo_depth = DEF_FIFO_DEPTH_WORDS;
port->rx_fifo_depth = DEF_FIFO_DEPTH_WORDS;
port->tx_fifo_width = DEF_FIFO_WIDTH_BITS;
if (!data->console) {
port->rx_buf = devm_kzalloc(uport->dev,
DMA_RX_BUF_SIZE, GFP_KERNEL);
if (!port->rx_buf)
return -ENOMEM;
}
ret = geni_icc_get(&port->se, NULL);
if (ret)
return ret;
port->se.icc_paths[GENI_TO_CORE].avg_bw = GENI_DEFAULT_BW;
port->se.icc_paths[CPU_TO_GENI].avg_bw = GENI_DEFAULT_BW;
/* Set BW for register access */
ret = geni_icc_set_bw(&port->se);
if (ret)
return ret;
tty: serial: qcom_geni_serial: Wakeup IRQ cleanup This patch is the continuation of below mentioned commits which adds wakeup feature over the UART RX line. 1)commit 3e4aaea7a039 ("tty: serial: qcom_geni_serial: IRQ cleanup")[v2] 2)commit 8b7103f31950 ("tty: serial: qcom_geni_serial: Wakeup over UART RX")[v2] The following cleanup is done based on upstream comment received on subsequent versions of the above-mentioned commits to simplifying the code. - Use devm_kasprintf API in place of scnprintf. - Use dev_pm_set_dedicated_wake_irq API that will take care of requesting and attaching wakeup irqs for devices. Also, it sets wakeirq status to WAKE_IRQ_DEDICATED_ALLOCATED as a result enabling/disabling of wake irq will be managed by suspend/resume framework. We can remove the code for enabling and disabling of wake irq from the this driver. - Use platform_get_irq_optional API to get optional wakeup IRQ for device. - Move ISR registration later in probe after uart port gets register with serial core. Patch link: - https://patchwork.kernel.org/patch/11189717/ (v3) - https://patchwork.kernel.org/patch/11227435/ (v4) - https://patchwork.kernel.org/patch/11241669/ (v5) - https://patchwork.kernel.org/patch/11258045/ (v6) Signed-off-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1578321905-25843-2-git-send-email-akashast@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-06 14:45:04 +00:00
port->name = devm_kasprintf(uport->dev, GFP_KERNEL,
"qcom_geni_serial_%s%d",
uart_console(uport) ? "console" : "uart", uport->line);
if (!port->name)
return -ENOMEM;
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;
uport->irq = irq;
uport->has_sysrq = IS_ENABLED(CONFIG_SERIAL_QCOM_GENI_CONSOLE);
if (!data->console)
tty: serial: qcom_geni_serial: Wakeup IRQ cleanup This patch is the continuation of below mentioned commits which adds wakeup feature over the UART RX line. 1)commit 3e4aaea7a039 ("tty: serial: qcom_geni_serial: IRQ cleanup")[v2] 2)commit 8b7103f31950 ("tty: serial: qcom_geni_serial: Wakeup over UART RX")[v2] The following cleanup is done based on upstream comment received on subsequent versions of the above-mentioned commits to simplifying the code. - Use devm_kasprintf API in place of scnprintf. - Use dev_pm_set_dedicated_wake_irq API that will take care of requesting and attaching wakeup irqs for devices. Also, it sets wakeirq status to WAKE_IRQ_DEDICATED_ALLOCATED as a result enabling/disabling of wake irq will be managed by suspend/resume framework. We can remove the code for enabling and disabling of wake irq from the this driver. - Use platform_get_irq_optional API to get optional wakeup IRQ for device. - Move ISR registration later in probe after uart port gets register with serial core. Patch link: - https://patchwork.kernel.org/patch/11189717/ (v3) - https://patchwork.kernel.org/patch/11227435/ (v4) - https://patchwork.kernel.org/patch/11241669/ (v5) - https://patchwork.kernel.org/patch/11258045/ (v6) Signed-off-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1578321905-25843-2-git-send-email-akashast@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-06 14:45:04 +00:00
port->wakeup_irq = platform_get_irq_optional(pdev, 1);
if (of_property_read_bool(pdev->dev.of_node, "rx-tx-swap"))
port->rx_tx_swap = true;
if (of_property_read_bool(pdev->dev.of_node, "cts-rts-swap"))
port->cts_rts_swap = true;
ret = devm_pm_opp_set_clkname(&pdev->dev, "se");
if (ret)
return ret;
/* OPP table is optional */
ret = devm_pm_opp_of_add_table(&pdev->dev);
if (ret && ret != -ENODEV) {
dev_err(&pdev->dev, "invalid OPP table in device tree\n");
return ret;
}
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
port->private_data.drv = drv;
uport->private_data = &port->private_data;
tty: serial: qcom_geni_serial: Wakeup IRQ cleanup This patch is the continuation of below mentioned commits which adds wakeup feature over the UART RX line. 1)commit 3e4aaea7a039 ("tty: serial: qcom_geni_serial: IRQ cleanup")[v2] 2)commit 8b7103f31950 ("tty: serial: qcom_geni_serial: Wakeup over UART RX")[v2] The following cleanup is done based on upstream comment received on subsequent versions of the above-mentioned commits to simplifying the code. - Use devm_kasprintf API in place of scnprintf. - Use dev_pm_set_dedicated_wake_irq API that will take care of requesting and attaching wakeup irqs for devices. Also, it sets wakeirq status to WAKE_IRQ_DEDICATED_ALLOCATED as a result enabling/disabling of wake irq will be managed by suspend/resume framework. We can remove the code for enabling and disabling of wake irq from the this driver. - Use platform_get_irq_optional API to get optional wakeup IRQ for device. - Move ISR registration later in probe after uart port gets register with serial core. Patch link: - https://patchwork.kernel.org/patch/11189717/ (v3) - https://patchwork.kernel.org/patch/11227435/ (v4) - https://patchwork.kernel.org/patch/11241669/ (v5) - https://patchwork.kernel.org/patch/11258045/ (v6) Signed-off-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1578321905-25843-2-git-send-email-akashast@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-06 14:45:04 +00:00
platform_set_drvdata(pdev, port);
irq_set_status_flags(uport->irq, IRQ_NOAUTOEN);
ret = devm_request_irq(uport->dev, uport->irq, qcom_geni_serial_isr,
IRQF_TRIGGER_HIGH, port->name, uport);
if (ret) {
dev_err(uport->dev, "Failed to get IRQ ret %d\n", ret);
return ret;
}
serial: qcom-geni: fix enabling deactivated interrupt The driver have a race, experienced only with PREEMPT_RT patchset: CPU0 | CPU1 ================================================================== qcom_geni_serial_probe | uart_add_one_port | | serdev_drv_probe | qca_serdev_probe | serdev_device_open | uart_open | uart_startup | qcom_geni_serial_startup | enable_irq | __irq_startup | WARN_ON() | IRQ not activated request_threaded_irq | irq_domain_activate_irq | The warning: 894000.serial: ttyHS1 at MMIO 0x894000 (irq = 144, base_baud = 0) is a MSM serial serial0: tty port ttyHS1 registered WARNING: CPU: 7 PID: 107 at kernel/irq/chip.c:241 __irq_startup+0x78/0xd8 ... qcom_geni_serial 894000.serial: serial engine reports 0 RX bytes in! Adding UART port triggers probe of child serial devices - serdev and eventually Qualcomm Bluetooth hci_qca driver. This opens UART port which enables the interrupt before it got activated in request_threaded_irq(). The issue originates in commit f3974413cf02 ("tty: serial: qcom_geni_serial: Wakeup IRQ cleanup") and discussion on mailing list [1]. However the above commit does not explain why the uart_add_one_port() is moved above requesting interrupt. [1] https://lore.kernel.org/all/5d9f3dfa.1c69fb81.84c4b.30bf@mx.google.com/ Fixes: f3974413cf02 ("tty: serial: qcom_geni_serial: Wakeup IRQ cleanup") Cc: <stable@vger.kernel.org> Cc: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230505152301.2181270-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-05 15:23:01 +00:00
ret = uart_add_one_port(drv, uport);
if (ret)
return ret;
tty: serial: qcom_geni_serial: Wakeup IRQ cleanup This patch is the continuation of below mentioned commits which adds wakeup feature over the UART RX line. 1)commit 3e4aaea7a039 ("tty: serial: qcom_geni_serial: IRQ cleanup")[v2] 2)commit 8b7103f31950 ("tty: serial: qcom_geni_serial: Wakeup over UART RX")[v2] The following cleanup is done based on upstream comment received on subsequent versions of the above-mentioned commits to simplifying the code. - Use devm_kasprintf API in place of scnprintf. - Use dev_pm_set_dedicated_wake_irq API that will take care of requesting and attaching wakeup irqs for devices. Also, it sets wakeirq status to WAKE_IRQ_DEDICATED_ALLOCATED as a result enabling/disabling of wake irq will be managed by suspend/resume framework. We can remove the code for enabling and disabling of wake irq from the this driver. - Use platform_get_irq_optional API to get optional wakeup IRQ for device. - Move ISR registration later in probe after uart port gets register with serial core. Patch link: - https://patchwork.kernel.org/patch/11189717/ (v3) - https://patchwork.kernel.org/patch/11227435/ (v4) - https://patchwork.kernel.org/patch/11241669/ (v5) - https://patchwork.kernel.org/patch/11258045/ (v6) Signed-off-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1578321905-25843-2-git-send-email-akashast@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-06 14:45:04 +00:00
if (port->wakeup_irq > 0) {
device_init_wakeup(&pdev->dev, true);
ret = dev_pm_set_dedicated_wake_irq(&pdev->dev,
port->wakeup_irq);
if (ret) {
device_init_wakeup(&pdev->dev, false);
uart_remove_one_port(drv, uport);
return ret;
}
}
tty: serial: qcom_geni_serial: Wakeup IRQ cleanup This patch is the continuation of below mentioned commits which adds wakeup feature over the UART RX line. 1)commit 3e4aaea7a039 ("tty: serial: qcom_geni_serial: IRQ cleanup")[v2] 2)commit 8b7103f31950 ("tty: serial: qcom_geni_serial: Wakeup over UART RX")[v2] The following cleanup is done based on upstream comment received on subsequent versions of the above-mentioned commits to simplifying the code. - Use devm_kasprintf API in place of scnprintf. - Use dev_pm_set_dedicated_wake_irq API that will take care of requesting and attaching wakeup irqs for devices. Also, it sets wakeirq status to WAKE_IRQ_DEDICATED_ALLOCATED as a result enabling/disabling of wake irq will be managed by suspend/resume framework. We can remove the code for enabling and disabling of wake irq from the this driver. - Use platform_get_irq_optional API to get optional wakeup IRQ for device. - Move ISR registration later in probe after uart port gets register with serial core. Patch link: - https://patchwork.kernel.org/patch/11189717/ (v3) - https://patchwork.kernel.org/patch/11227435/ (v4) - https://patchwork.kernel.org/patch/11241669/ (v5) - https://patchwork.kernel.org/patch/11258045/ (v6) Signed-off-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1578321905-25843-2-git-send-email-akashast@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-06 14:45:04 +00:00
return 0;
}
static void qcom_geni_serial_remove(struct platform_device *pdev)
{
struct qcom_geni_serial_port *port = platform_get_drvdata(pdev);
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
struct uart_driver *drv = port->private_data.drv;
tty: serial: qcom_geni_serial: Wakeup IRQ cleanup This patch is the continuation of below mentioned commits which adds wakeup feature over the UART RX line. 1)commit 3e4aaea7a039 ("tty: serial: qcom_geni_serial: IRQ cleanup")[v2] 2)commit 8b7103f31950 ("tty: serial: qcom_geni_serial: Wakeup over UART RX")[v2] The following cleanup is done based on upstream comment received on subsequent versions of the above-mentioned commits to simplifying the code. - Use devm_kasprintf API in place of scnprintf. - Use dev_pm_set_dedicated_wake_irq API that will take care of requesting and attaching wakeup irqs for devices. Also, it sets wakeirq status to WAKE_IRQ_DEDICATED_ALLOCATED as a result enabling/disabling of wake irq will be managed by suspend/resume framework. We can remove the code for enabling and disabling of wake irq from the this driver. - Use platform_get_irq_optional API to get optional wakeup IRQ for device. - Move ISR registration later in probe after uart port gets register with serial core. Patch link: - https://patchwork.kernel.org/patch/11189717/ (v3) - https://patchwork.kernel.org/patch/11227435/ (v4) - https://patchwork.kernel.org/patch/11241669/ (v5) - https://patchwork.kernel.org/patch/11258045/ (v6) Signed-off-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1578321905-25843-2-git-send-email-akashast@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-06 14:45:04 +00:00
dev_pm_clear_wake_irq(&pdev->dev);
device_init_wakeup(&pdev->dev, false);
uart_remove_one_port(drv, &port->uport);
}
static int qcom_geni_serial_sys_suspend(struct device *dev)
{
struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
struct uart_port *uport = &port->uport;
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
struct qcom_geni_private_data *private_data = uport->private_data;
/*
* This is done so we can hit the lowest possible state in suspend
* even with no_console_suspend
*/
if (uart_console(uport)) {
geni_icc_set_tag(&port->se, QCOM_ICC_TAG_ACTIVE_ONLY);
geni_icc_set_bw(&port->se);
}
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
return uart_suspend_port(private_data->drv, uport);
}
static int qcom_geni_serial_sys_resume(struct device *dev)
{
int ret;
struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
struct uart_port *uport = &port->uport;
serial: qcom_geni_serial: Make kgdb work even if UART isn't console 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-26 20:00:32 +00:00
struct qcom_geni_private_data *private_data = uport->private_data;
ret = uart_resume_port(private_data->drv, uport);
if (uart_console(uport)) {
geni_icc_set_tag(&port->se, QCOM_ICC_TAG_ALWAYS);
geni_icc_set_bw(&port->se);
}
return ret;
}
static int qcom_geni_serial_sys_hib_resume(struct device *dev)
{
int ret = 0;
struct uart_port *uport;
struct qcom_geni_private_data *private_data;
struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
uport = &port->uport;
private_data = uport->private_data;
if (uart_console(uport)) {
geni_icc_set_tag(&port->se, QCOM_ICC_TAG_ALWAYS);
geni_icc_set_bw(&port->se);
ret = uart_resume_port(private_data->drv, uport);
/*
* For hibernation usecase clients for
* console UART won't call port setup during restore,
* hence call port setup for console uart.
*/
qcom_geni_serial_port_setup(uport);
} else {
/*
* Peripheral register settings are lost during hibernation.
* Update setup flag such that port setup happens again
* during next session. Clients of HS-UART will close and
* open the port during hibernation.
*/
port->setup = false;
}
return ret;
}
static const struct qcom_geni_device_data qcom_geni_console_data = {
.console = true,
.mode = GENI_SE_FIFO,
};
static const struct qcom_geni_device_data qcom_geni_uart_data = {
.console = false,
.mode = GENI_SE_DMA,
};
static const struct dev_pm_ops qcom_geni_serial_pm_ops = {
.suspend = pm_sleep_ptr(qcom_geni_serial_sys_suspend),
.resume = pm_sleep_ptr(qcom_geni_serial_sys_resume),
.freeze = pm_sleep_ptr(qcom_geni_serial_sys_suspend),
.poweroff = pm_sleep_ptr(qcom_geni_serial_sys_suspend),
.restore = pm_sleep_ptr(qcom_geni_serial_sys_hib_resume),
.thaw = pm_sleep_ptr(qcom_geni_serial_sys_hib_resume),
};
static const struct of_device_id qcom_geni_serial_match_table[] = {
{
.compatible = "qcom,geni-debug-uart",
.data = &qcom_geni_console_data,
},
{
.compatible = "qcom,geni-uart",
.data = &qcom_geni_uart_data,
},
{}
};
MODULE_DEVICE_TABLE(of, qcom_geni_serial_match_table);
static struct platform_driver qcom_geni_serial_platform_driver = {
.remove_new = qcom_geni_serial_remove,
.probe = qcom_geni_serial_probe,
.driver = {
.name = "qcom_geni_serial",
.of_match_table = qcom_geni_serial_match_table,
.pm = &qcom_geni_serial_pm_ops,
},
};
static int __init qcom_geni_serial_init(void)
{
int ret;
ret = console_register(&qcom_geni_console_driver);
if (ret)
return ret;
ret = uart_register_driver(&qcom_geni_uart_driver);
if (ret) {
console_unregister(&qcom_geni_console_driver);
return ret;
}
ret = platform_driver_register(&qcom_geni_serial_platform_driver);
if (ret) {
console_unregister(&qcom_geni_console_driver);
uart_unregister_driver(&qcom_geni_uart_driver);
}
return ret;
}
module_init(qcom_geni_serial_init);
static void __exit qcom_geni_serial_exit(void)
{
platform_driver_unregister(&qcom_geni_serial_platform_driver);
console_unregister(&qcom_geni_console_driver);
uart_unregister_driver(&qcom_geni_uart_driver);
}
module_exit(qcom_geni_serial_exit);
MODULE_DESCRIPTION("Serial driver for GENI based QUP cores");
MODULE_LICENSE("GPL v2");