Message ID | 20230928151631.149333-2-jcmvbkbc@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp3535953vqu; Thu, 28 Sep 2023 12:08:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH4CWx5YP8fk9XdmpMifSXUJF13yFFUoOCHV/3vp6DTEIpbOTYo4cqBisPJJYtJgJ79E/2q X-Received: by 2002:a17:90b:118d:b0:268:808:8e82 with SMTP id gk13-20020a17090b118d00b0026808088e82mr3459261pjb.1.1695928081839; Thu, 28 Sep 2023 12:08:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695928081; cv=none; d=google.com; s=arc-20160816; b=A1EiOP/Kn/cseCJuifbcSPXRKSbSHJBpOzBctzAtERd9GP9v/Jp6L4yQd3kIuRI3tp cCaOV8qmPSA0IrGn5z8i/tR9b1+spXRN6oPGjL6KIALpkbc2ZvqVdSjGhoFgMY7kC9fK h12iHQHXMkeIXVaaoDCA7U2Et3yod0mnr6gR+8gHsM2HdCr8y9YKTtLUV6GA7jKv3q4B tx4ekjJNB9O0InueuzVard91J1z2pMArlU++2sM0FVsJ6FYiuoC+K2Hg1MFATnh/RumJ KVS/TBroINvWgDGm61wq8VB5C8eQ3eSWiJDOGEwlRcqC9sbQ8LjiEeqeVYaDFlM3KrmJ 5z/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=USo4wRG0tKgJ2qeKHabBE6AhpAZ7DR66yrvaU6oGcec=; fh=oqMYt5FzSjXDp/dSMFfnsNSIER/pF2eV0abPard7Ac0=; b=RM3d0CnQlLZwRaUVpJEJwnWWa8iQqKCo9Ojq9H25WDmWoo0l7/TGhmOuuhPhbEXHEn AsMi8VDNOqMNsvCd2e9MbtDKKnxBXnDSVS7kL2PCoLQqK5yMoUgvRM7nPTOBqSg+CnWe BnH3wGV11GVsCbIKwEjmYT6zJ898dHLKzyUMViABCNFyMcvnDxLn0pXnaKV9L26cKmKz kKrpBnm2iN/IkK7uguZyoj+H75ZP7If/zSVUb/7//P9plGzBq4HFHxw4rMi5CADgsueA l7Lk5vj7Q5FwRdiMJySP2uf8cTP2zFtzvQFENZUbpaIxOeOtpMnPCNinmDrXsSsvBXRR rDBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=AWwCq4xs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id on17-20020a17090b1d1100b002777ccd05bcsi9114123pjb.25.2023.09.28.12.08.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Sep 2023 12:08:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=AWwCq4xs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 322FD805190B; Thu, 28 Sep 2023 08:31:53 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231984AbjI1PaY (ORCPT <rfc822;pwkd43@gmail.com> + 21 others); Thu, 28 Sep 2023 11:30:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231913AbjI1PaS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 28 Sep 2023 11:30:18 -0400 Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14C38AC; Thu, 28 Sep 2023 08:30:17 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id 41be03b00d2f7-570a432468bso10819349a12.0; Thu, 28 Sep 2023 08:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695915016; x=1696519816; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=USo4wRG0tKgJ2qeKHabBE6AhpAZ7DR66yrvaU6oGcec=; b=AWwCq4xsLU0qAmwirSv+y2wkqOCv1vIhFw9CP0JdrIvF0Ci03uID9XiQ6rtZ56GUey 34z9oAmyFYc9t8DBAzdmXrLyOr0Udac9iq/o6plNGv6cZehdObmxCU0FdGWrP7aBQEjC WXnBiKM6VGevw8oMJD0sHXtpEDQYnVNjHkFi58/+OQzzGCbMA/EnSMK5fEABlePRQy18 ViSem7eTZRiVXVSb4+dH7R/nXv1LwJ8QiKgBidohSEg1Qxm/xBzxiOBivEVti5jdUuN8 nphtZduzaOvb4Q9phpiXe9Y2LIKY46wh8c7yGBHYfaKcbyZun5exh1YnSoLHzZgX0rxi 0ASg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695915016; x=1696519816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=USo4wRG0tKgJ2qeKHabBE6AhpAZ7DR66yrvaU6oGcec=; b=kVCKXmi9EFArSWKgFo9e8oyJD2VBoMXeEjoUUqRqEsebvhLXiUja7GwmD9HwnXchbA lTi6fpgtj9CMWMuY8IQ3QJ+xPrXf0sL+T0xg91ju/pd2G9bS2i5jYycy8ItPJwyohWh/ 7KXFwG+erze1tsdo3cNuuN+OcTSDt0Xc07FEnB0c9ZkTLlgnEOloPBLnr4LuYjfmA64A r9XBvYZBwj+ioL8igi895/MHsI6mLz2WPWcrgnmKMmqBNjhUf7pLrV44Jr7ZDGWficTv RnCa6eqD6Lwe+mdy3k/7y7qcczrbp9gA0FwhwhMU2LN2hr2f5SEdPR/xXm1Aokn38g0Y aBWg== X-Gm-Message-State: AOJu0Yz+9WqiTZa7IKPbSnYqdXUPz46vScChjpnnPILlDEi5Cx9B6MzX PsGUuV6jy9mm8hy2hu9wxgUzZYFJQFg= X-Received: by 2002:a17:90a:fe98:b0:279:e19:86db with SMTP id co24-20020a17090afe9800b002790e1986dbmr2568851pjb.8.1695915016137; Thu, 28 Sep 2023 08:30:16 -0700 (PDT) Received: from octofox.hsd1.ca.comcast.net ([2601:646:a201:19d0:a19c:f3d0:698d:f7a]) by smtp.gmail.com with ESMTPSA id m6-20020a17090a414600b00274a9f8e82asm3892318pjg.51.2023.09.28.08.30.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Sep 2023 08:30:15 -0700 (PDT) From: Max Filippov <jcmvbkbc@gmail.com> To: linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, devicetree@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jiri Slaby <jirislaby@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, =?utf-8?q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>, Max Filippov <jcmvbkbc@gmail.com> Subject: [PATCH v4 1/5] serial: core: tidy invalid baudrate handling in uart_get_baud_rate Date: Thu, 28 Sep 2023 08:16:27 -0700 Message-Id: <20230928151631.149333-2-jcmvbkbc@gmail.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20230928151631.149333-1-jcmvbkbc@gmail.com> References: <20230928151631.149333-1-jcmvbkbc@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 28 Sep 2023 08:31:53 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778309484227542932 X-GMAIL-MSGID: 1778309484227542932 |
Series |
serial: add drivers for the ESP32xx serial devices
|
|
Commit Message
Max Filippov
Sept. 28, 2023, 3:16 p.m. UTC
uart_get_baud_rate has input parameters 'min' and 'max' limiting the
range of acceptable baud rates from the caller's perspective. If neither
current or old termios structures have acceptable baud rate setting and
9600 is not in the min/max range either the function returns 0 and
issues a warning.
However for a UART that does not support speed of 9600 baud this is
expected behavior.
Clarify that 0 can be (and always could be) returned from the
uart_get_baud_rate. Don't issue a warning in that case.
Move the warinng to the uart_get_divisor instead, which is often called
with the uart_get_baud_rate return value.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
Changes v3->v4:
- drop WARN_ON from uart_get_divisor()
drivers/tty/serial/serial_core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Comments
On Thu, 28 Sep 2023, Max Filippov wrote: > uart_get_baud_rate has input parameters 'min' and 'max' limiting the > range of acceptable baud rates from the caller's perspective. If neither > current or old termios structures have acceptable baud rate setting and > 9600 is not in the min/max range either the function returns 0 and > issues a warning. > However for a UART that does not support speed of 9600 baud this is > expected behavior. > Clarify that 0 can be (and always could be) returned from the > uart_get_baud_rate. Don't issue a warning in that case. > Move the warinng to the uart_get_divisor instead, which is often called > with the uart_get_baud_rate return value. > > Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> > --- > Changes v3->v4: > - drop WARN_ON from uart_get_divisor() > > drivers/tty/serial/serial_core.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c > index 7bdc21d5e13b..3f130fe9f1a0 100644 > --- a/drivers/tty/serial/serial_core.c > +++ b/drivers/tty/serial/serial_core.c > @@ -431,7 +431,7 @@ EXPORT_SYMBOL(uart_update_timeout); > * baud. > * > * If the new baud rate is invalid, try the @old termios setting. If it's still > - * invalid, we try 9600 baud. > + * invalid, we try 9600 baud. If that is also invalid 0 is returned. > * > * The @termios structure is updated to reflect the baud rate we're actually > * going to be using. Don't do this for the case where B0 is requested ("hang > @@ -515,8 +515,6 @@ uart_get_baud_rate(struct uart_port *port, struct ktermios *termios, > max - 1, max - 1); > } > } > - /* Should never happen */ > - WARN_ON(1); > return 0; > } > EXPORT_SYMBOL(uart_get_baud_rate); While looking into this, I found this old commit: commit 16ae2a877bf4179737921235e85ceffd7b79354f Author: Alan Cox <alan@linux.intel.com> Date: Mon Jan 4 16:26:21 2010 +0000 serial: Fix crash if the minimum rate of the device is > 9600 baud In that situation if the old rate is invalid and the new rate is invalid and the chip cannot do 9600 baud we report zero, which makes all the drivers explode. Instead force the rate based on min/max But for some reason it does not work as advertized here? What is the exact cause for that? Is something wrong with how min/max have that +1/-1 there or what?
On Thu, Sep 28, 2023 at 11:34 PM Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote: > While looking into this, I found this old commit: > > commit 16ae2a877bf4179737921235e85ceffd7b79354f > Author: Alan Cox <alan@linux.intel.com> > Date: Mon Jan 4 16:26:21 2010 +0000 > > serial: Fix crash if the minimum rate of the device is > 9600 baud > > In that situation if the old rate is invalid and the new rate is invalid > and the chip cannot do 9600 baud we report zero, which makes all the > drivers explode. > > Instead force the rate based on min/max > > But for some reason it does not work as advertized here? What is the exact > cause for that? In my case I see that tty_termios_encode_baud_rate() is called with ibaud == obaud == 9769, but it finds the closest rate 9600, which is within 2% of the actual minimum, but is outside the min/max range supported by the hardware. > Is something wrong with how min/max have that +1/-1 there or what?
On Thu, Sep 28, 2023 at 08:16:27AM -0700, Max Filippov wrote: > uart_get_baud_rate has input parameters 'min' and 'max' limiting the > range of acceptable baud rates from the caller's perspective. If neither > current or old termios structures have acceptable baud rate setting and > 9600 is not in the min/max range either the function returns 0 and > issues a warning. > However for a UART that does not support speed of 9600 baud this is > expected behavior. > Clarify that 0 can be (and always could be) returned from the > uart_get_baud_rate. Don't issue a warning in that case. > Move the warinng to the uart_get_divisor instead, which is often called > with the uart_get_baud_rate return value. This doesn't match up with the patch contents anymore :(
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 7bdc21d5e13b..3f130fe9f1a0 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -431,7 +431,7 @@ EXPORT_SYMBOL(uart_update_timeout); * baud. * * If the new baud rate is invalid, try the @old termios setting. If it's still - * invalid, we try 9600 baud. + * invalid, we try 9600 baud. If that is also invalid 0 is returned. * * The @termios structure is updated to reflect the baud rate we're actually * going to be using. Don't do this for the case where B0 is requested ("hang @@ -515,8 +515,6 @@ uart_get_baud_rate(struct uart_port *port, struct ktermios *termios, max - 1, max - 1); } } - /* Should never happen */ - WARN_ON(1); return 0; } EXPORT_SYMBOL(uart_get_baud_rate);