| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20180905233259.GA22824@google.com>
Date: Wed, 5 Sep 2018 16:32:59 -0700
From: Matthias Kaehlcke <mka@...omium.org>
To: Douglas Anderson <dianders@...omium.org>
Cc: gregkh@...uxfoundation.org, linux-arm-msm@...r.kernel.org,
evgreen@...omium.org, swboyd@...omium.org,
linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
Jiri Slaby <jslaby@...e.com>
Subject: Re: [PATCH] tty: serial: qcom_geni_serial: Fix serial when not used
as console
On Wed, Sep 05, 2018 at 01:11:46PM -0700, Douglas Anderson wrote:
> 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@...omium.org>
> ---
>
> drivers/tty/serial/qcom_geni_serial.c | 55 +++++++++++++--------------
> 1 file changed, 26 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
> index 29ec34387246..99103c67e1dc 100644
> --- a/drivers/tty/serial/qcom_geni_serial.c
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -851,6 +851,23 @@ static int qcom_geni_serial_port_setup(struct uart_port *uport)
> {
> struct qcom_geni_serial_port *port = to_dev_port(uport, uport);
> unsigned int rxstale = DEFAULT_BITS_PER_CHAR * STALE_TIMEOUT;
> + u32 proto;
> +
> + if (uart_console(uport))
> + port->tx_bytes_pw = 1;
> + else
> + port->tx_bytes_pw = 4;
> + port->rx_bytes_pw = RX_BYTES_PW;
> +
> + 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);
This wasn't done earlier in qcom_geni_serial_startup() (but it was in
qcom_geni_console_setup()). I guess this extra stop of RX for the
'uart' shouldn't do any harm.
> +
> + get_tx_fifo_size(port);
>
> set_rfr_wm(port);
> writel_relaxed(rxstale, uport->membase + SE_UART_RX_STALE_CNT);
> @@ -874,30 +891,19 @@ static int qcom_geni_serial_port_setup(struct uart_port *uport)
> return -ENOMEM;
> }
> port->setup = true;
> +
> return 0;
> }
>
> static int qcom_geni_serial_startup(struct uart_port *uport)
> {
> int ret;
> - u32 proto;
> struct qcom_geni_serial_port *port = to_dev_port(uport, uport);
>
> scnprintf(port->name, sizeof(port->name),
> "qcom_serial_%s%d",
> (uart_console(uport) ? "console" : "uart"), uport->line);
>
> - if (!uart_console(uport)) {
> - port->tx_bytes_pw = 4;
> - port->rx_bytes_pw = RX_BYTES_PW;
> - }
> - 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;
> - }
> -
> - get_tx_fifo_size(port);
> if (!port->setup) {
> ret = qcom_geni_serial_port_setup(uport);
> if (ret)
> @@ -1056,6 +1062,7 @@ static int __init qcom_geni_console_setup(struct console *co, char *options)
> int bits = 8;
> int parity = 'n';
> int flow = 'n';
> + int ret;
>
> if (co->index >= GENI_UART_CONS_PORTS || co->index < 0)
> return -ENXIO;
> @@ -1071,21 +1078,10 @@ static int __init qcom_geni_console_setup(struct console *co, char *options)
> if (unlikely(!uport->membase))
> return -ENXIO;
>
> - if (geni_se_resources_on(&port->se)) {
> - dev_err(port->se.dev, "Error turning on resources\n");
> - return -ENXIO;
> - }
> -
> - if (unlikely(geni_se_read_proto(&port->se) != GENI_SE_UART)) {
> - geni_se_resources_off(&port->se);
> - return -ENXIO;
> - }
> -
> if (!port->setup) {
> - port->tx_bytes_pw = 1;
> - port->rx_bytes_pw = RX_BYTES_PW;
> - qcom_geni_serial_stop_rx(uport);
> - qcom_geni_serial_port_setup(uport);
> + ret = qcom_geni_serial_port_setup(uport);
> + if (ret)
> + return ret;
> }
>
> if (options)
> @@ -1203,11 +1199,12 @@ static void qcom_geni_serial_pm(struct uart_port *uport,
> {
> struct qcom_geni_serial_port *port = to_dev_port(uport, uport);
>
> + /* 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_se_resources_on(&port->se);
> - else if (!uart_console(uport) && (new_state == UART_PM_STATE_ON &&
> - old_state == UART_PM_STATE_UNDEFINED))
> - 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);
Seems like a good refactoring, besides fixing the problem when booting
without 'console=ttyMSMx'.
Reviewed-by: Matthias Kaehlcke <mka@...omium.org>
Powered by blists - more mailing lists