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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E1282C33CA2 for ; Thu, 9 Jan 2020 17:51:47 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 C333520678 for ; Thu, 9 Jan 2020 17:51:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C333520678 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 262256E930; Thu, 9 Jan 2020 17:51:30 +0000 (UTC) X-Greylist: delayed 303 seconds by postgrey-1.36 at gabe; Wed, 08 Jan 2020 17:46:05 UTC Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [146.101.78.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 13D0C6E1DE for ; Wed, 8 Jan 2020 17:46:04 +0000 (UTC) Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-2-XMFewsroMBqNVmL4iq_bTQ-1; Wed, 08 Jan 2020 17:39:44 +0000 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 8 Jan 2020 17:39:42 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Wed, 8 Jan 2020 17:39:42 +0000 From: David Laight To: 'Christophe Leroy' , Geert Uytterhoeven Subject: RE: [RFT 00/13] iomap: Constify ioreadX() iomem argument Thread-Topic: [RFT 00/13] iomap: Constify ioreadX() iomem argument Thread-Index: AQHVxgB0oW/g95TA9k2fcgn+xgLf36fhB6DA Date: Wed, 8 Jan 2020 17:39:42 +0000 Message-ID: <334434313e1642768995acc03a51214f@AcuMS.aculab.com> References: <1578415992-24054-1-git-send-email-krzk@kernel.org> <2355489c-a207-1927-54cf-85c04b62f18f@c-s.fr> <00a43e5c-0708-d49a-9cc4-eb2ce8b4cf99@c-s.fr> In-Reply-To: <00a43e5c-0708-d49a-9cc4-eb2ce8b4cf99@c-s.fr> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-MC-Unique: XMFewsroMBqNVmL4iq_bTQ-1 X-Mimecast-Spam-Score: 0 X-Mailman-Approved-At: Thu, 09 Jan 2020 17:51:28 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rich Felker , Jiri Slaby , "Michael S. Tsirkin" , David Airlie , "nouveau@lists.freedesktop.org" , Jason Wang , DRI Development , "virtualization@lists.linux-foundation.org" , "James E.J. Bottomley" , Paul Mackerras , Linux-Arch , Dave Jiang , Yoshinori Sato , Helge Deller , Linux-sh list , Alexey Brodkin , Krzysztof Kozlowski , Ben Skeggs , Dave Airlie , Matt Turner , arcml , Nick Kossifidis , Allen Hubbe , Arnd Bergmann , Jon Mason , Ivan Kokshaysky , Thomas Gleixner , Mauro Carvalho Chehab , Kalle Valo , Richard Henderson , Parisc List , netdev , linux-wireless , Linux Kernel Mailing List , Luis Chamberlain , Vineet Gupta , alpha , "linux-ntb@googlegroups.com" , Andrew Morton , Linux Media Mailing List , linuxppc-dev , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" From: Christophe Leroy > Sent: 08 January 2020 08:49 ... > And as pointed by Arnd, the volatile is really only necessary for the > dereference itself, should the arch use dereferencing. I've had trouble with some versions of gcc and reading of 'volatile unsigned char *'. It tended to follow the memory read with an extra mask with 0xff. (I suspect that internally the value landed into a temporary 'int' variable.) I got better code using memory barriers. So putting an asm barrier for the exact location of the memory read either side of the read should have the desired effect without adding extra instructions. (You might think 'volatile' would mean that - but it doesn't.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel