Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp6314643rwi; Sun, 23 Oct 2022 22:46:01 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5nlXMDgVQ37BhigPaHPHDq/P5jXtMHwBXQ2k4OZY0tlj7vVWewnFExLtMGHuOmj4ASqK6R X-Received: by 2002:aa7:88c9:0:b0:56b:e851:5b65 with SMTP id k9-20020aa788c9000000b0056be8515b65mr1689879pff.74.1666590360998; Sun, 23 Oct 2022 22:46:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666590360; cv=none; d=google.com; s=arc-20160816; b=bNtf9pqjOrDOfcRyQrR5lEzD1jLOvxyzrccw1k34sn3O6DDl14byPuBtMHpQ22OvkS lSAml0RbNjWRIwxHrojP4QC3nqxghrKcfkBgK40FfNMq1hSSRw4jZPTvSH+Y3KHcV+7a DsoMXL5PkRzTv1ErhMwbO+ugw4OeMyMD5Fw5RsMHdyKKf5UJmur0q9ihBPIYAM+C0cbY QdKDcZ/U5u6KClaXjl5nhK5A8bYWo4oXX6qH3E4mpDJejxcrJI1PHh2FPZkTRtgm5U7/ iUSVn4XeclAsBMShItb5dvjKGWXDcGlk6S2wXfgCyufvU+jhy9foiW7NyOfqLMljF4N9 JfcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ymwRKE3+7YqR4eR+aBXUZBwl21ZreXMp6BCuuBr5UeI=; b=h7xe+S0qsyj6q12Lc1elyq/fi7MfE5PulOrmw2fukqWkVuniSzgNYfbAQXb/LsFf1Z bC0ppguDUyqJCrgYEy5ifTX0MDmPtHSFVO48lw2oHw2tNGMYZyhtk72MN6nIyumme/Yh jPWrPpagwfH+8tv4dcyO/0n0Pqe96JJG9CBE5gOhK+DNFF5ibb2Fb3sLh9fF62YacXz3 XeQT/gw5Lni9monWKxPfahMpd90xqVJ8iEqGCYY209vM4dxKSzyiVcUWPZG/PkAx2noN Gtb4hY6MJOA63pZZ1WeBzGG2NWjWxqXYAFBBoOXy3iIFyjZj1LpEQ3WCfCptAWn9r1fS VUmA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o3-20020a17090ab88300b00202c850b5a8si7745450pjr.11.2022.10.23.22.45.49; Sun, 23 Oct 2022 22:46:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229904AbiJXF2h (ORCPT + 99 others); Mon, 24 Oct 2022 01:28:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229562AbiJXF2g (ORCPT ); Mon, 24 Oct 2022 01:28:36 -0400 Received: from muru.com (muru.com [72.249.23.125]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D7DEC7B29E; Sun, 23 Oct 2022 22:28:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id F082D822A; Mon, 24 Oct 2022 05:19:19 +0000 (UTC) Date: Mon, 24 Oct 2022 08:28:32 +0300 From: Tony Lindgren To: Ilpo =?utf-8?B?SsOkcnZpbmVu?= Cc: Sebastian Andrzej Siewior , Matthias Schiffer , Greg Kroah-Hartman , Jiri Slaby , Peter Hurley , linux-serial , LKML , Nishanth Menon , linux-omap@vger.kernel.org Subject: Re: [PATCH] serial: 8250_omap: remove wait loop from Errata i202 workaround Message-ID: References: <20221013112339.2540767-1-matthias.schiffer@ew.tq-group.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Adding Nishanth to Cc also. * Ilpo Järvinen [221017 12:06]: > On Mon, 17 Oct 2022, Sebastian Andrzej Siewior wrote: > > > On 2022-10-17 11:12:41 [+0300], Ilpo Järvinen wrote: > > > On Thu, 13 Oct 2022, Matthias Schiffer wrote: > > > > > > > We were occasionally seeing the "Errata i202: timedout" on an AM335x > > > > board when repeatedly opening and closing a UART connected to an active > > > > sender. As new input may arrive at any time, it is possible to miss the > > > > "RX FIFO empty" condition, forcing the loop to wait until it times out. > > > > > > I can see this problem could occur and why your patch fixes it. > > > > > > > Nothing in the i202 Advisory states that such a wait is even necessary; > > > > other FIFO clear functions like serial8250_clear_fifos() do not wait > > > > either. For this reason, it seems safe to remove the wait, fixing the > > > > mentioned issue. > > > > > > Checking the commit that added this driver and the loop along with it, > > > there was no information why it would be needed there either. > > > > I don't remember all the details but I do remember that I never hit it. > > The idea back then was to document what appears the problem and then > > once there is a reproducer address it _or_ when there is another problem > > check if it aligns with the output here (so that _this_ problem's origin > > could be this). This was part of address all known chip erratas and > > copied from omap-serial at the time so that the 8250 does not miss > > anything. > > Looking closer, this is still part of the omap-serial driver and it was > > introduced in commit > > 0003450964357 ("omap2/3/4: serial: errata i202: fix for MDR1 access") > > I found that one too but it doesn't give any explanation for it either. > In fact, the wait for empty is mysteriously missing from the itemized > description of the workaround in the commit message. > > > If someone found a way to trigger this output which is unrelated to the > > expected cause then this is clearly not helping nor intended. > > > > I would prefer to keep the loop and replace the disturbing output with a > > comment describing _why_ the FIFO might remain non-empty after a flush. > > > > In worst cases that loop causes a delay of less than 0.5ms while setting > > a baud rate so I doubt that this is causing a real problem. This sounds like a safe solution for me if it's needed. > > Either way I would like to see Tony's ACK before this is getting removed > > as suggested in this patch. > > Thanks for chimming in. > > I went to do some lore searching and came across this thread (it should > be added with Link: tag the patch regardless of its final form): > https://lore.kernel.org/linux-omap/4BBF61FE.3060807@ti.com/ Nishanth, do you have any more info on checking for fifo empty here? Regards, Tony