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=-4.0 required=3.0 tests=BAYES_00,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 156F2C4320E for ; Tue, 17 Aug 2021 08:12:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EBC0360F22 for ; Tue, 17 Aug 2021 08:12:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238921AbhHQINW convert rfc822-to-8bit (ORCPT ); Tue, 17 Aug 2021 04:13:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:34522 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239134AbhHQINP (ORCPT ); Tue, 17 Aug 2021 04:13:15 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 61B9560F22; Tue, 17 Aug 2021 08:12:42 +0000 (UTC) Received: from 109-170-232-56.xdsl.murphx.net ([109.170.232.56] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mFuDA-005TPf-JW; Tue, 17 Aug 2021 09:12:40 +0100 Date: Tue, 17 Aug 2021 09:12:40 +0100 Message-ID: <87sfz8zdzb.wl-maz@kernel.org> From: Marc Zyngier To: Arnd Bergmann Cc: Alyssa Rosenzweig , linux-pci , Bjorn Helgaas , Rob Herring , Lorenzo Pieralisi , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , Stan Skowronek , Mark Kettenis , Sven Peter , Hector Martin , DTML , Linux Kernel Mailing List Subject: Re: [RFC PATCH 2/2] PCI: apple: Add driver for the Apple M1 In-Reply-To: References: <20210815042525.36878-1-alyssa@rosenzweig.io> <20210815042525.36878-3-alyssa@rosenzweig.io> <87a6lj17d1.wl-maz@kernel.org> <87tujpyrxu.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-SA-Exim-Connect-IP: 109.170.232.56 X-SA-Exim-Rcpt-To: arnd@kernel.org, alyssa@rosenzweig.io, linux-pci@vger.kernel.org, bhelgaas@google.com, robh+dt@kernel.org, lorenzo.pieralisi@arm.com, kw@linux.com, stan@corellium.com, kettenis@openbsd.org, sven@svenpeter.dev, marcan@marcan.st, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, 17 Aug 2021 08:34:35 +0100, Arnd Bergmann wrote: > > On Mon, Aug 16, 2021 at 11:57 PM Marc Zyngier wrote: > > On Mon, 16 Aug 2021 02:31:40 +0100, Alyssa Rosenzweig wrote: > > > > > > Please use relaxed accessors. If the barriers are actually needed, > > > > please document what you are ordering against. This applies throughout > > > > the patch. > > > > > > Relaxed accessors are used throughout in v2... it Works For Me™ but no > > > guarantees I didn't introduce a race... > > > > That's not exactly what I wanted to read... You really need to make an > > informed decision on the need of barriers. If the MMIO write needs to > > be ordered after a main memory write (i.e. a memory write that is > > consumed by the device you are subsequently writing to), you then need > > a barrier. If, as I suspect, the device isn't DMA capable and doesn't > > require ordering with the rest of the memory accesses, then no > > barriers are required. > > My normal rule is to always use the normal accessors, and only use > any special variants if this is either required for correct operation > (e.g. heavy barriers on arm32 may call code that must not recursively > use heavy barriers) or that you have proven to /both/ be correct and > relevant for performance. IOW, don't use the relaxed accessors just > because it isn't wrong in your driver, other developers may copy the > code into a driver that can't do it. And that exactly the reason why I think we should *not* use heavy accessors if they are not required. I have little sympathy for blindly copied code, and spreading unnecessary barriers means that we cannot further reason about the actual ordering requirements. In other words, blanket use of heavy MMIO accessors to guarantee memory ordering is not dissimilar to reintroducing the BKL because we don't want people to worry about concurrency. M. -- Without deviation from the norm, progress is not possible.