Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3010712imu; Mon, 17 Dec 2018 11:36:11 -0800 (PST) X-Google-Smtp-Source: AFSGD/U4lakHsdaWjFoWp3hAH9NFvB0fenWxM7MAE+lRjCKo51RwDUTp4rScMnFkqEEYO8TPiLa0 X-Received: by 2002:a17:902:8a95:: with SMTP id p21mr14084458plo.183.1545075370950; Mon, 17 Dec 2018 11:36:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545075370; cv=none; d=google.com; s=arc-20160816; b=0UW3cFmIWq8WG1kX5+0r0/HzC98FC8tkKZxNgQs825dYvZcebRb3kDsplljdIxr9pp MXW9/udIqogahp/5AsXVKaXzXAWFYuVu4wrjWCyMhtCSRJIaMSEkT+Ens858WeGYXX1F cxp0a+GIERze121kiAbKFqWfkcsHXjrR1IAwSGpog63TKZV+Wl3HrP48q7VmCmvB72G3 F12YIERJYyKloRm4Khod58Co1CiDxoljuRn82007+2Cse40Owb4k+o9p01AFATgJhHyq O5BxdJnRYrTjIEOvldpRqrm9JCtT6UT+V46SnubSSlm0F+kIaCZSaJQAlq2Iw9gZQxZf Q5hg== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:subject:from; bh=1NcZZ/56juuX5e7X8HIi9SHgm0ujZUw5+p+FFkA6piY=; b=zUMzSVobXzT7QslWNZSNkdUeM26XGF9zxWI6MO5f380EXXi8t+kh4CNzWWJ+V+H2gs xSbPSJN2ACAMKeFu7G4YzthbWS4gtiDXprJTt2iX4TKsFKEe35rEjXFsFwL4mc2Zp83v GwfBRxCVw1DV2z2QPdcNT8iYSlfNyCefvSPLgbFFJk7FAj5ikG1bYBKzmOTZUr5yXIA9 2AoljiTZNxPxDNnBMaV+Z8ZlE2bIUAm4Etml+j3JsyTjVZz6Rf1kAg4idSC1oNSbSjXC Xi9gLAFy3sq8bL5lzqoCiiEDdFWM0pcSeoMhX14Wdm6FZ3iIJTn6N2dXpewqa2SR4y0W mXMQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f12si11579979pgd.68.2018.12.17.11.35.55; Mon, 17 Dec 2018 11:36:10 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388412AbeLQRW2 (ORCPT + 99 others); Mon, 17 Dec 2018 12:22:28 -0500 Received: from mail-out.m-online.net ([212.18.0.10]:47153 "EHLO mail-out.m-online.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388301AbeLQRV4 (ORCPT ); Mon, 17 Dec 2018 12:21:56 -0500 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 43JScv0FWdz1r4vb; Mon, 17 Dec 2018 18:21:50 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 43JSct5hvqz1qvRN; Mon, 17 Dec 2018 18:21:50 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id EkGWAJdMhQO8; Mon, 17 Dec 2018 18:21:49 +0100 (CET) X-Auth-Info: zgkidFemLB6LopVG1HQXvKD6gxsi6d2hF8K5PLo8UjU= Received: from [IPv6:::1] (unknown [195.140.253.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Mon, 17 Dec 2018 18:21:49 +0100 (CET) From: Marek Vasut Subject: Re: [PATCH] Revert "serial: 8250: Fix clearing FIFOs in RS485 mode again" To: Ezequiel Garcia , Paul Burton Cc: "linux-serial@vger.kernel.org" , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Paul Burton , Daniel Jedrychowski , "linux-mips@vger.kernel.org" , stable , Ezequiel Garcia References: <20181213174834.kxdy6fphaeoivqgh@pburton-laptop> <20181216200833.27928-1-paul.burton@mips.com> <20181216213133.kwe24pif3v4wcgwp@pburton-laptop> <949fdd3d-535e-d235-f406-d5bde4658c5e@denx.de> <20181216222411.5jkexuaqxpfudj7b@pburton-laptop> <20181216223510.hxsdotf332ousinh@pburton-laptop> Message-ID: <61a3177f-4e8d-fc51-1e81-95af3baab3a8@denx.de> Date: Mon, 17 Dec 2018 18:20:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/17/2018 05:30 PM, Ezequiel Garcia wrote: > On Sun, 16 Dec 2018 at 19:35, Paul Burton wrote: >> >> Hi Ezequiel, >> >> On Sun, Dec 16, 2018 at 07:28:22PM -0300, Ezequiel Garcia wrote: >>> On Sun, 16 Dec 2018 at 19:24, Paul Burton wrote: >>>> This helps, but it only addresses one part of one of the 4 reasons I >>>> listed as motivation for my revert. For example serial8250_do_shutdown() >>>> also clearly intends to disable the FIFOs. >>>> >>> >>> OK. So, let's fix that :-) >> >> I already did, or at least tried to, on Thursday [1]. >> >>> By all means, it would be really nice to push forward and fix the garbage >>> issue on JZ4780, as well as the transmission issue on AM335x. >>> >>> AM335x is a wildly popular platform, and it's not funny to break it. >> >> Well, clearly not if it was broken in v4.10 & only just fixed..? And >> from Marek's commit message the patch in v4.10 doesn't break the whole >> system just RS485. >> > > Careful here. It's naive to consider v4.10 as old in this context. > > AM335x is used in hundreds of thousands of products, probably > "industrial" products. > Manufacturers don't always follow the kernel, and it's entirely > likely that they notice a regression only when developing a new product, > or when rebasing on top of a newer longterm kernel. > > Then again, I don't have any details about what is Marek's original fix > actually fixing. > > Marek: could you please post the test case that you used to validate your fix? > I can't find that anywhere. I can't share the testcase itself because it has no license and I didn't write it, but I can tell you what it's doing. (I'll check if I can share the testcase verbatim too, I just sent an email to the author) The test spawns two threads, one sending , one receiving. The sending thread sends 8 bytes of data from /dev/ttyS4 , the receiving thread receives the data on /dev/ttyS2 and compares the pattern. The port settings is B1000000 8N1 with rs485conf.flags set to SER_RS485_ENABLED and SER_RS485_RTS_AFTER_SEND. Sometimes the received data do not match the sent data, but rather look as if one character was left over from the previous transmission in the FIFO. Those two UARTs are connected together by two wires, without any real RS485 hardware to minimize the hardware complexity (it's easy to implement that on the pocketbeagle, which is the cheap option here). -- Best regards, Marek Vasut