From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A0EC714AA0 for ; Fri, 28 Jul 2023 19:34:17 +0000 (UTC) Received: from pandora.armlinux.org.uk (unknown [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45E97E69; Fri, 28 Jul 2023 12:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fPenveROvmLP9xK4bVQXMQSFpU0bLGq9l0utMcWGrfM=; b=S3P1XhiNI7tuydMrFHMGOtysw4 y7VxJlfdAExXJizqj4Qwc25CAaVdYRwdYTPeALneag129u+mW6NnjT+T7k+1BVbMz+6GnQ6+zyvVC 5D/9nWvpNBg6jeMWlTkQqS1v1Vjh6m0kkwvLLrcDyceBa4zN8zpSuc+kjysseEjfRfV+FRPavTh3I 2bEi9qFHbGOxrV/B3SdL+Wi8gKML0mDxdC/hgbe7PHi4k2/FvVElp9vrZNON7d8E+42y6XEfwhOfh Z+s9pckqRxtpCUryeXfQx6shKLGrkvw7ZIZ02ie2f7et1TgNMLqrVWXt/zXpXur+ZGbxJDiZM4Cza KjzCUZCQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:47138) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qPTDb-0007kx-2V; Fri, 28 Jul 2023 20:33:43 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1qPTDW-0005B7-3J; Fri, 28 Jul 2023 20:33:38 +0100 Date: Fri, 28 Jul 2023 20:33:38 +0100 From: "Russell King (Oracle)" To: Frank Li Cc: Will Deacon , Andrew Halaney , Shenwei Wang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Shawn Guo , Sascha Hauer , Neil Armstrong , Kevin Hilman , Vinod Koul , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Jerome Brunet , Martin Blumenstingl , Bhupesh Sharma , Nobuhiro Iwamatsu , Simon Horman , Bartosz Golaszewski , Wong Vee Khee , Revanth Kumar Uppala , Jochen Henneberg , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org, imx@lists.linux.dev Subject: Re: [PATCH v2 net 2/2] net: stmmac: dwmac-imx: pause the TXC clock in fixed-link Message-ID: References: <20230727152503.2199550-1-shenwei.wang@nxp.com> <20230727152503.2199550-3-shenwei.wang@nxp.com> <4govb566nypifbtqp5lcbsjhvoyble5luww3onaa2liinboguf@4kgihys6vhrg> <20230728153611.GH21718@willie-the-truck> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,RDNS_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On Fri, Jul 28, 2023 at 12:29:46PM -0400, Frank Li wrote: > On Fri, Jul 28, 2023 at 04:36:12PM +0100, Will Deacon wrote: > > Yes, I don't think wmb() is the right thing here. If you need to ensure > > that the write to MAC_CTRL_REG has taken effect, then you'll need to go > > through some device-specific sequence which probably involves reading > > something back. If you just need things to arrive in order eventually, > > the memory type already gives you that. > > > > It's also worth pointing out that udelay() isn't necessarily ordered wrt > > MMIO writes, so that usleep_range() might need some help as well. > > Hi Deacon: > > Does it means below pattern will be problem? > > 1.writel() > 2.udelay() > 3.writel() Yes, it can be a problem - because the first write may take a while to hit the hardware. It's been this way ever since PCI became a thing, even on x86 hardware. PCI posting rules are that writes can be posted into the various bridges in the bus structure and forwarded on at some point later. However, reads are not allowed to bypass writes - which means that if one reads from a PCI device, the preceeding writes need to be flushed out of the bridges _in the path to the device being read_. So, if we take an example and apply it to PCI: writel() udelay(100) writel() readl() The device could well see nothing for a while, and then two consecutive writes and a read in quick succession. > It may not wait enough time between 1 and 3. I think the above pattern > is quite common in driver code. I am not sure if usleep_range involve > MMIO to get current counter, ARM may use cp15 to get local timer counter. There are no guarantees, even on x86, that udelay() offers anything to space device writes apart. If this pattern is popular in drivers, and it's critical to the drivers operation, then it's technically buggy - and it's been that way for at least a couple of decades! One might get away with it (maybe the hardware isn't delaying the writes?) but the kernel has never guaranteed that writel(), udelay(), writel() will space the two writes apart by the specified delay. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!