Received: by 2002:a17:90b:8d0:0:0:0:0 with SMTP id ds16csp4880195pjb; Mon, 27 Jul 2020 07:28:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzUTtjYovBZs8gxgglCRQEM4828jdwsI8IB9Kzr0vcUNvA7nL0rnYt20F/j91/b6LH4npTh X-Received: by 2002:a17:906:1e83:: with SMTP id e3mr21929966ejj.7.1595860117012; Mon, 27 Jul 2020 07:28:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595860117; cv=none; d=google.com; s=arc-20160816; b=QkVumAxl7DQyYutc+QF5+shDaMEObDaAciC6AiWMlAwJGhoJLuKLHAFXfJOvRPgcgs HjJutk1JyJR0q9FEXgTnFdcqfqtTjcsJvVj4EPtdM2/BplJUYEfh/oYMm6mcCTyIAUJv fwJlv26kngfKDOit6VsIrm8V+ngvSiSYKkx2Ui2zIidAZ05+wRBDuwnaM4cmnNRTquFy mSipXTUocxQVero7PGNGDF0oZKCB7B+36Eq76ccFOK3TwkQMn9tOVQztRrDXvcwR6b1b T85/Tw8ZDjeU2op2qdRvjw6+s/5gBPtrzd/MC5TszJVFcvHDVHvOaaj4U//KwrTpiTKk T07A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=BsrQH/OPC/L6ffv0+biWcCg1qg63el8ggAmveVhQscU=; b=b5u94nj/Z8tG0ZbkIdEJvvj0BFtWHjHDiRuLxIEhZKx+uzQiaMKWU2y5ZWB2fL6dEA oMWGykqJFEQscrw4fqgh90VNmkS+JXylOxpB6/OQM8e0FKjiOcuS3fa7oskZP4em7qJu sqbsZjB8VBggs1mcjy07d5onHtFTMC8nYNk1MherW/17QqitpREKsV/PXGlOCI/c57uH ZjzrGGXmgNBuZa962dyd0Gt90BYp1hesncBhCH4q6MVA11ggpOdKrgPMJc8YqFJKCmbA 0YYOVbEfJ61YkzWeDCZBqFX1nZbl0b35BOXCPyJTnXVaIxDoZHy7AINfy6DW9jb4nn+F 1bnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ShXpyZqf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v7si2084596edd.551.2020.07.27.07.28.14; Mon, 27 Jul 2020 07:28:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ShXpyZqf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732668AbgG0O06 (ORCPT + 99 others); Mon, 27 Jul 2020 10:26:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:56640 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732586AbgG0O0X (ORCPT ); Mon, 27 Jul 2020 10:26:23 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4989D2070A; Mon, 27 Jul 2020 14:26:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595859982; bh=E+BR9EdvyGC9s+9bLovBA98KcWWEMTwM8cetg0PK9+8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ShXpyZqfTv9GpSJX8lwmAeltv7GyxktilP+WJ939pq/7hkbNiu5TiAAL7eXfqAurO sqR6HRzQZiHk9y7XYj+rNQFQBBQLrfQZEYcWtAwBsMi6tws5f9lyOcWbjJEW67eEIR 0GKVQPdUAMxFz32gj7QfZgR5FIQvjHUNEHm0abY8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Daniel Winkler , Serge Semin , Claire Chang Subject: [PATCH 5.7 153/179] serial: 8250_mtk: Fix high-speed baud rates clamping Date: Mon, 27 Jul 2020 16:05:28 +0200 Message-Id: <20200727134940.123629368@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200727134932.659499757@linuxfoundation.org> References: <20200727134932.659499757@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Serge Semin commit 551e553f0d4ab623e2a6f424ab5834f9c7b5229c upstream. Commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") fixed limits of a baud rate setting for a generic 8250 port. In other words since that commit the baud rate has been permitted to be within [uartclk / 16 / UART_DIV_MAX; uartclk / 16], which is absolutely normal for a standard 8250 UART port. But there are custom 8250 ports, which provide extended baud rate limits. In particular the Mediatek 8250 port can work with baud rates up to "uartclk" speed. Normally that and any other peculiarity is supposed to be handled in a custom set_termios() callback implemented in the vendor-specific 8250-port glue-driver. Currently that is how it's done for the most of the vendor-specific 8250 ports, but for some reason for Mediatek a solution has been spread out to both the glue-driver and to the generic 8250-port code. Due to that a bug has been introduced, which permitted the extended baud rate limit for all even for standard 8250-ports. The bug has been fixed by the commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") by narrowing the baud rates limit back down to the normal bounds. Unfortunately by doing so we also broke the Mediatek-specific extended bauds feature. A fix of the problem described above is twofold. First since we can't get back the extended baud rate limits feature to the generic set_termios() function and that method supports only a standard baud rates range, the requested baud rate must be locally stored before calling it and then restored back to the new termios structure after the generic set_termios() finished its magic business. By doing so we still use the serial8250_do_set_termios() method to set the LCR/MCR/FCR/etc. registers, while the extended baud rate setting procedure will be performed later in the custom Mediatek-specific set_termios() callback. Second since a true baud rate is now fully calculated in the custom set_termios() method we need to locally update the port timeout by calling the uart_update_timeout() function. After the fixes described above are implemented in the 8250_mtk.c driver, the Mediatek 8250-port should get back to normally working with extended baud rates. Link: https://lore.kernel.org/linux-serial/20200701211337.3027448-1-danielwinkler@google.com Fixes: 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") Reported-by: Daniel Winkler Signed-off-by: Serge Semin Cc: stable Tested-by: Claire Chang Link: https://lore.kernel.org/r/20200714124113.20918-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman --- drivers/tty/serial/8250/8250_mtk.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/tty/serial/8250/8250_mtk.c +++ b/drivers/tty/serial/8250/8250_mtk.c @@ -306,8 +306,21 @@ mtk8250_set_termios(struct uart_port *po } #endif + /* + * Store the requested baud rate before calling the generic 8250 + * set_termios method. Standard 8250 port expects bauds to be + * no higher than (uartclk / 16) so the baud will be clamped if it + * gets out of that bound. Mediatek 8250 port supports speed + * higher than that, therefore we'll get original baud rate back + * after calling the generic set_termios method and recalculate + * the speed later in this method. + */ + baud = tty_termios_baud_rate(termios); + serial8250_do_set_termios(port, termios, old); + tty_termios_encode_baud_rate(termios, baud, baud); + /* * Mediatek UARTs use an extra highspeed register (MTK_UART_HIGHS) * @@ -339,6 +352,11 @@ mtk8250_set_termios(struct uart_port *po */ spin_lock_irqsave(&port->lock, flags); + /* + * Update the per-port timeout. + */ + uart_update_timeout(port, termios->c_cflag, baud); + /* set DLAB we have cval saved in up->lcr from the call to the core */ serial_port_out(port, UART_LCR, up->lcr | UART_LCR_DLAB); serial_dl_write(up, quot);