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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 94B23C43381 for ; Tue, 19 Feb 2019 11:36:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6B8152086A for ; Tue, 19 Feb 2019 11:36:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727765AbfBSLgU (ORCPT ); Tue, 19 Feb 2019 06:36:20 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:44048 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725772AbfBSLgU (ORCPT ); Tue, 19 Feb 2019 06:36:20 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E98D8EBD; Tue, 19 Feb 2019 03:36:18 -0800 (PST) Received: from fuggles.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6AA423F720; Tue, 19 Feb 2019 03:36:11 -0800 (PST) Date: Tue, 19 Feb 2019 11:36:09 +0000 From: Will Deacon To: Arnd Bergmann Cc: Thomas Petazzoni , linux-arch , Linux Kernel Mailing List , "Paul E. McKenney" , Benjamin Herrenschmidt , Peter Zijlstra , Andrea Parri , Daniel Lustig , David Howells , Alan Stern , Linus Torvalds , Thomas Petazzoni , Gregory CLEMENT , Russell King - ARM Linux Subject: Re: [RFC PATCH] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section Message-ID: <20190219113609.GC4027@fuggles.cambridge.arm.com> References: <20190211172948.3322-1-will.deacon@arm.com> <20190218162954.GB16713@fuggles.cambridge.arm.com> <20190218175625.GD16713@fuggles.cambridge.arm.com> <20190219112747.7db95e58@windsurf.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1+86 (6f28e57d73f2) () Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 19, 2019 at 12:31:50PM +0100, Arnd Bergmann wrote: > On Tue, Feb 19, 2019 at 11:27 AM Thomas Petazzoni > wrote: > > On Mon, 18 Feb 2019 21:37:25 +0100 > > Arnd Bergmann wrote: > > > > > Ah, it seems we actually do that on 32-bit ARM, at least on one platform, > > > see 6a02734d420f ("ARM: mvebu: map PCI I/O regions strongly ordered") > > > and prior commits. > > > > Yes, some Marvell Armada 32-bit platforms have an errata that require > > the PCI MEM and PCI I/O regions to be mapped strongly ordered. > > > > BTW, this requirement prevents us from using the pci_remap_iospace() > > API from drivers/pci, because it assumes page attributes of > > pgprot_device(PAGE_KERNEL). That's why we're still using the > > ARM-specific pci_ioremap_io() function. > > Ok. > > > > > I would still prefer to document the weaker semantics as the portable > > > > interface, unless there are portable drivers relying on this today (which > > > > would imply that it's widely supported by other architectures). > > > > > > I don't know of any portable driver that actually relies on it, but > > > that's mainly because there are very few portable drivers that > > > use inb()/outb() in the first place. How many of those require > > > the non-posted behavior I don't know > > > > > > Adding Thomas, Gregory and Russell to Cc, as they were involved > > > in the discussion that led to the 32-bit change, maybe they are > > > aware of a specific example. > > > > I'm just arriving in the middle of this thread, and I'm not sure to > > understand what is the question. If the question is whether PCI I/O is > > really used in practice, then I've never seen it be used with Marvell > > platforms (but I'm also not aware of all PCIe devices people are > > using). I personally have a hacked-up version of the e1000e driver > > that intentionally does some PCI I/O accesses, that I use as a way to > > validate that PCI I/O support is minimally working, but that's it. > > The main question is whether we know of a portable (not specific > to a single architecture) driver for PCIe (or PCI, but probably not ISA) > that uses outb/outw/outl in a way that relies on the on-posted > behavior of those, compared to posted writeb/writew/writel that are > only required to complete before another I/O operation on the same > device but whose completion is not ordered with regard to the rest of > the system. > > I think an example of this would be a driver using outb() to disable > an interrupt, and then relying on the the interrupt no longer happening > after the outb(). Isn't that racy already? i.e. the interrupt could fire just before you disabled it, but not get delivered by the irq controller until after you'd disabled it at the device? Will