From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F946C4363A for ; Tue, 20 Oct 2020 22:27:51 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DF13B2225C for ; Tue, 20 Oct 2020 22:27:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=aj.id.au header.i=@aj.id.au header.b="QLbpD3tP"; dkim=temperror (0-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Pcp4fBRN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DF13B2225C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=aj.id.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4CG7YH0vxrzDqgd for ; Wed, 21 Oct 2020 09:27:47 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=aj.id.au (client-ip=66.111.4.221; helo=new1-smtp.messagingengine.com; envelope-from=andrew@aj.id.au; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=aj.id.au Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=aj.id.au header.i=@aj.id.au header.a=rsa-sha256 header.s=fm1 header.b=QLbpD3tP; dkim=pass (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm1 header.b=Pcp4fBRN; dkim-atps=neutral Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4CG7Wj1m7YzDqdG; Wed, 21 Oct 2020 09:26:24 +1100 (AEDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 2D30C580304; Tue, 20 Oct 2020 18:26:21 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute3.internal (MEProxy); Tue, 20 Oct 2020 18:26:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=tHKl5ShHGM26aw0ab4WfiwYyOOZYZHB qMfpsajmzAwM=; b=QLbpD3tPmAXiqlMlcnfoj1G+xvLNn4/Nil+G0dtaCoqPso7 QEkIrTRQuRs8Km6UVvFRpYUNI03y9qluqo6feuVeoPHjTTeJTIgMDGNtMA+fiNvw RtVrsUjJha8Y6NR2hLP1KmSDVXxgTJXNsq6J3G0PrgCoporAxbxdpLAG3weXfil0 shG7VOfkOIktACzcB6KYGxbUy0ZoIYR6kBRje2xaUUD4Vwfe039cu/h+N3QXYKjW zUCVM7d6VTgaawPkFLCUw0MqdVjAz3U+IyBGZQlXPKcx33WTFemMgG9ccyQMgXyG rJOiU82qSLpb4c2sqkTqsiOcL9Jl4G9st8mE1ug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=tHKl5S hHGM26aw0ab4WfiwYyOOZYZHBqMfpsajmzAwM=; b=Pcp4fBRN5WzP53LIltbB6A RCrwHSFFMcxtRgZyn22cxfBD91KT8CTJvw3ZtYltd5h/lAyoAUSZPJUrOEdDIMJk KKwDkTnH6JV/hTrCWUUDO0PjgXyqcVO89PZXZNTX0hlAajaW60vx3K/CqDEKNjvu NVIi9VUWnH4bLux9YCeflHx4Skvcn+xJP8NPXrC71cTwAi3DWZTVzMVPlF2zooOj 60Qvc9tSMv/L2Kmj5jllocNWH4Iwf3YIuKJyI1G52K46oW8Klf128ZK5KVlSA/UK dLibWFO2uyW0LJJZGVN/SP+DjLmfLCXFoJgPhXBntr3fBJFtEgXRsGx9APOtPtjg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeeggddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehnughr vgifucflvghffhgvrhihfdcuoegrnhgurhgvfiesrghjrdhiugdrrghuqeenucggtffrrg htthgvrhhnpeehhfefkefgkeduveehffehieehudejfeejveejfedugfefuedtuedvhefh veeuffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grnhgurhgvfiesrghjrdhiugdrrghu X-ME-Proxy:

Received: by mailuser.nyi.internal (Postfix, from userid 501) id 36A4BE00A8; Tue, 20 Oct 2020 18:26:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-502-gfef6c88-fm-20201019.001-gfef6c888 Mime-Version: 1.0 Message-Id: <529612e1-c6c4-4d33-91df-2a30bf2e1675@www.fastmail.com> In-Reply-To: <32bfb619bbb3cd6f52f9e5da205673702fed228f.camel@kernel.crashing.org> References: <20201019073908.32262-1-dylan_hung@aspeedtech.com> <20201019120040.3152ea0b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

<32bfb619bbb3cd6f52f9e5da205673702fed228f.camel@kernel.crashing.org> Date: Wed, 21 Oct 2020 08:55:58 +1030 From: "Andrew Jeffery" To: "Benjamin Herrenschmidt" , "Arnd Bergmann" , "Dylan Hung" Subject: Re: [PATCH] net: ftgmac100: Fix missing TX-poll issue Content-Type: text/plain X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: BMC-SW , linux-aspeed , Po-Yu Chuang , netdev , OpenBMC Maillist , Linux Kernel Mailing List , Jakub Kicinski , David Miller Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" On Wed, 21 Oct 2020, at 08:40, Benjamin Herrenschmidt wrote: > On Tue, 2020-10-20 at 21:49 +0200, Arnd Bergmann wrote: > > On Tue, Oct 20, 2020 at 11:37 AM Dylan Hung wrote: > > > > +1 @first is system memory from dma_alloc_coherent(), right? > > > > > > > > You shouldn't have to do this. Is coherent DMA memory broken on your > > > > platform? > > > > > > It is about the arbitration on the DRAM controller. There are two queues in the dram controller, one is for the CPU access and the other is for the HW engines. > > > When CPU issues a store command, the dram controller just acknowledges cpu's request and pushes the request into the queue. Then CPU triggers the HW MAC engine, the HW engine starts to fetch the DMA memory. > > > But since the cpu's request may still stay in the queue, the HW engine may fetch the wrong data. > > Actually, I take back what I said earlier, the above seems to imply > this is more generic. > > Dylan, please confirm, does this affect *all* DMA capable devices ? If > yes, then it's a really really bad design bug in your chips > unfortunately and the proper fix is indeed to make dma_wmb() do a dummy > read of some sort (what address though ? would any dummy non-cachable > page do ?) to force the data out as *all* drivers will potentially be > affected. > > I was under the impression that it was a specific timing issue in the > vhub and ethernet parts, but if it's more generic then it needs to be > fixed globally. > We see a similar issue in the XDMA engine where it can transfer stale data to the host. I think the driver ended up using memcpy_toio() to work around that despite using a DMA reserved memory region.