From patchwork Fri Aug 3 11:38:41 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick DELAUNAY X-Patchwork-Id: 953209 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.denx.de (client-ip=81.169.180.215; helo=lists.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=st.com Received: from lists.denx.de (dione.denx.de [81.169.180.215]) by ozlabs.org (Postfix) with ESMTP id 41hlWq4HVzz9s0n for ; Fri, 3 Aug 2018 21:42:14 +1000 (AEST) Received: by lists.denx.de (Postfix, from userid 105) id 85325C220C8; Fri, 3 Aug 2018 11:42:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lists.denx.de (localhost [IPv6:::1]) by lists.denx.de (Postfix) with ESMTP id 3363EC21E34; Fri, 3 Aug 2018 11:42:05 +0000 (UTC) Received: by lists.denx.de (Postfix, from userid 105) id EF66BC21E34; Fri, 3 Aug 2018 11:42:02 +0000 (UTC) Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by lists.denx.de (Postfix) with ESMTPS id A6539C21E16 for ; Fri, 3 Aug 2018 11:42:02 +0000 (UTC) Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx08-.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w73Bd9Xx011453; Fri, 3 Aug 2018 13:41:59 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 2kmnrr85fs-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 03 Aug 2018 13:41:59 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C5ACA31; Fri, 3 Aug 2018 11:41:58 +0000 (GMT) Received: from Webmail-eu.st.com (Safex1hubcas23.st.com [10.75.90.46]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 945F94DBB; Fri, 3 Aug 2018 11:41:58 +0000 (GMT) Received: from SAFEX1HUBCAS24.st.com (10.75.90.95) by SAFEX1HUBCAS23.st.com (10.75.90.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 3 Aug 2018 13:41:58 +0200 Received: from localhost (10.201.23.85) by webmail-ga.st.com (10.75.90.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 3 Aug 2018 13:41:58 +0200 From: Patrick Delaunay To: Date: Fri, 3 Aug 2018 13:38:41 +0200 Message-ID: <1533296325-2490-1-git-send-email-patrick.delaunay@st.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 X-Originating-IP: [10.201.23.85] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-03_04:, , signatures=0 Cc: Stefan Roese , Heinrich Schuchardt , Alexander Graf , Joe Hershberger , Soeren Moch , Wilson Lee , U-Boot STM32 Subject: [U-Boot] [PATCH 0/4] Solve issue with serial rx buffer when MUX is deactivated X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.18 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" When I activate CONFIG_SERIAL_RX_BUFFER on my board without CONSOLE_MUX, I have a strange behavior in console: a new prompt is displayed continuously I check the call stack cread_line (common/cli_readline.c) => getcmd_getch (common/cli_readline.c) ==> fgetc (common/console.c) ===> console_tstc (common/console.c) ====> stdio_devices[file]->get() =====> _serial_getc() (drivers/serial/serial-uclass.c) and the data reads from rx buffer but it is garbage as tstc is not called PS: I have no issue when CONSOLE_MUX is activated because in this case the tstc() is always called in fgetc loop. My first solution to update the rx buffer management, to avoid the issue: static int _serial_getc(struct udevice *dev) { struct serial_dev_priv *upriv = dev_get_uclass_priv(dev); char val; if (upriv->rd_ptr == upriv->wr_ptr) __serial_tstc(dev); if (upriv->rd_ptr == upriv->wr_ptr) return 0; /* error : no data to read */ val = upriv->buf[upriv->rd_ptr++]; upriv->rd_ptr %= CONFIG_SERIAL_RX_BUFFER_SIZE; return val; } With this first patch, I see that that WATCHDOG is not reloaded and the getc() error value 0x0 wasn't correctly handle in cli; the issue is alway present and the behavior change (getc function is no more blocking): the caller needs to handle the error and reload the watchdog. To summarize, I see several issues in the current U-Boot code: - No protection on the rx buffer in _serial_getc(): the current code assumed that tstc() is alway called but it is dangerous - error for getc() (read value = 0x0) is not handled in cread_line() - in console.c, tstc() is not called when CONSOLE_MUX is not activated In this patchset I try to solve all these issues by separate patch but perhaps only the first correction on the rx buffer is really mandatory. On my board stm32mp1 ev1 the issue is solved. Patrick Delaunay (4): stm32mp1: activate serial rx buffer serial: protect access to serial rx buffer console: unify fgetc function when console MUX is deactivated cli: handle getch error common/cli_readline.c | 4 ++++ common/console.c | 9 +++++---- configs/stm32mp15_basic_defconfig | 1 + drivers/serial/serial-uclass.c | 3 +++ 4 files changed, 13 insertions(+), 4 deletions(-)