Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933780AbbLOVzj (ORCPT ); Tue, 15 Dec 2015 16:55:39 -0500 Received: from mout.kundenserver.de ([212.227.126.133]:51080 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752227AbbLOVzh (ORCPT ); Tue, 15 Dec 2015 16:55:37 -0500 From: Arnd Bergmann To: Timur Tabi Cc: Christopher Covington , Florian Fainelli , Gilad Avidov , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, sdharia@codeaurora.org, shankerd@codeaurora.org, gregkh@linuxfoundation.org, vikrams@codeaurora.org Subject: Re: [PATCH] net: emac: emac gigabit ethernet controller driver Date: Tue, 15 Dec 2015 22:55:27 +0100 Message-ID: <2492153.N3Ga92jYtq@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56708183.4090005@codeaurora.org> References: <1450138740-32562-1-git-send-email-gavidov@codeaurora.org> <1579270.z2ZaCA4LQo@wuerfel> <56708183.4090005@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:m5ewqnZot+9IwY5N9tOycku7sFojQuE6Vq14lg7hOdE98qaVmpq /APfSaiy9nOM1BAJ9tenmzFZ+HGgctINRcST020o7LU1Gtkyo9MbZTdZ1PdR04usYF19qY+ flYycaNAFU5cun+D9KjmV0kRq6+DKCgP8oauEzB+nDpTNSY1w5wsaU7v1cAX/YZUYlv1D3y QKbwACOuX8F50QmVwGpFA== X-UI-Out-Filterresults: notjunk:1;V01:K0:inlVdxbS3A0=:jF2gsR5NMholSt1/4ym/EC OZgOXCm2zC1sW35tkd9Uu39YKtSsQolZc+ey8yDo1h8h3eI7x0fGPjmjOscXn6QSShVzfPGTi WskUjIpLE35TsnVkdTq1mmzVh5sj5RPnEm2j/QSlCyzlyXvfnMXiu5PiuJZphLw+G/pGSi4Xn 3VD0XSFKCrV/p39m21LsedfkAHRdNz07qKaiWSSNgi1O87YVwBvbSPdtEONznDRs2Dt50PkzO lPEQ6pmBAt5UqHiJ8GJtYAU0ZuacLnP/PanqF7BwLUkvBnXm95H7gYJbeuR6ClhkJsoXKcLiy J7Dram4iss9Bk1tlFLEuPYZyM0Y+QXAf3g/yEMUzNz1nczM5YCLDJiYH7uAf1qcHHEgBHDPeD cPmY1qbYiD38qx4G6rTfFE785F1Ib5y64/kzRSVMt77srXwmLaFFPjthVj0OLpR2gVYuDlYh+ Y+Tmxu3y0s6ZKV833CdXJnaYUgZiWnSBzhPdRWYUYFSD/HPlSLZboeBcbJVssAWjIGhEeICAs KeVwhj6vdCMz8DX0IGp8puVPriFtl/+qmDfos0i3WC8JSXDLKM5s1GydZyUukhuQvKfO6zyHH bS8QRAMcG9dkA/fDQMibIBhcj1TOEXrUY5jvhyQMcK4cZ4Jz79XDViTWX5j+a8dheFEoTLW1m fn7p5DWFQECXu8RhwBCOnkR7g9QJUgqn+Kw/FPBgzKq1U5Ctgz9Wr+a8DWbTIJCYQrpogtkkw cM/h1LwA+lzd8xKh Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1437 Lines: 29 On Tuesday 15 December 2015 15:09:23 Timur Tabi wrote: > Arnd Bergmann wrote: > > If that's in the probe() called from it function, just use writel() everywhere, > > a few extra microseconds won't kill the boot time. In general, if a user would > > notice the difference, use the relaxed version and add a comment to explain > > how you proved it's correct, otherwise stay with the default accessors. > > What about adding a wmb() after the last writel()? This driver does > that a lot. Is that something we want to discourage? I can understand > how we would want to make sure that the last write is posted before the > function exits. Please explain in a comment specifically which race you are closing by ensuring that the write gets posted. What does it race against? As I said earlier, guaranteeing that a write gets posted does not mean it has arrived at the device, we only get that behavior after a subsequent read from the same device, but you don't need a wmb() between the write and the read to guarantee this. If you have an odd bus that does not follow those rules, it may in fact be best to have a separate set of I/O accessors and not use readl/writel at all. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/