Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp504131ybl; Wed, 8 Jan 2020 00:43:46 -0800 (PST) X-Google-Smtp-Source: APXvYqxnjHzRWFDRVF+8FGBr4hu3kEtVbIACVhwZLlyuR5UcermHqcGbYwovAuAbd+cGgL77boIu X-Received: by 2002:a05:6808:208:: with SMTP id l8mr2160637oie.112.1578473026326; Wed, 08 Jan 2020 00:43:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578473026; cv=none; d=google.com; s=arc-20160816; b=nZAzpxbN5WLLa4omKPCzl/SDb5jf5StGYaqmLlPuF/nk0sC94i3tx1oSBjsWLNF07M ZoEl/K4pEunzqgu1FjMIi3fKKmP/rGL6p7FMyJztPnIlex0wxRt47Cn3XQgTnKsdl2wT Hg6FX8I2OBEr6at9fWU/JkoxVVjLD37//f+9P+2d0ewHLTGJfWgeYfKnax+kfq+UKZnw JW2uD+R2guxW3vQVOqq3S2tcmXJbP05MyfL4Y3L5EqrqSYsFVXltOY+uG6ed1IUO7Qry 05E/94OGzGFpAKBAgzCIb198PTGseOfzfQFjEgc6rKgfl2425GBAq3/+riBdjPBrBwQU 3oDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=Qor40JXSYJXl+NupmOG0pP5nHTsu4Gt8dmeIiMExJYs=; b=KPeTgLcm3n5am8hbwjOGmyNcYM5qXxwGEhZnbjPKlHhXKsKjt7EXfgaQIWLQ2IiQZJ aO9LPer8AJ/ua5a8MGYTMoEbhqru+E68qaxufQkOS6yYaKavtWzqV5FopofWNx6NUtzt v+Q81JcUSZTTst3RMsjmjFmjKs1mqrJzic08UM0FRclZdqFS5TIx9tOjEX7lRSK8wfdh FJesx+BYVzmWuojwwywGYF6KSaYvFrQ7xo09sl/oT5j672B2FIwP/QEHVUgVbY9Vb3tr HCjaoTCpJsdc7LnFA/8niyoE6A6sWLnrCfexi/Jv7ahaU6z3NUBDpReM2YUQmNy7L294 09Vg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 10si1364914ois.76.2020.01.08.00.43.34; Wed, 08 Jan 2020 00:43:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727433AbgAHInR convert rfc822-to-8bit (ORCPT + 99 others); Wed, 8 Jan 2020 03:43:17 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:40726 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726313AbgAHInQ (ORCPT ); Wed, 8 Jan 2020 03:43:16 -0500 Received: by mail-ot1-f65.google.com with SMTP id w21so2828269otj.7; Wed, 08 Jan 2020 00:43:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7cWBGOss6IZmXIImkX09JkN+lqirutcjNONiaHMIXk4=; b=BUZNvBP6HUEzjF14WcEA8/f1NgJEx+rvIhju7kJhaRzdXsdM2BqykKFLcexUFcuSwc 3Zd5HqsLEjGA4Dmp74XXYheyBlTN1Draz4VZtOytrnqtMidtF1bdYJJlOzbe18KLuBv6 xqp6Suf4TGYMKVEQj8rK7zDX5CNqHCSo3USUFj+yhGgUkrSoHvqybDjeyJ5kO3qxxJxF chDoDrkACkggurqW0rIzhutuKOpRtAn7g+xyXu1pcIx6EjVRuUlekFQbDe5zcoAJr/Su DGqrrnHic1E4zp2x+786IQ3/hoYGGnFwN6CPb9wXBNxv+RYozHpuFlxYYRmFFE7oayHU wTUQ== X-Gm-Message-State: APjAAAUS4u9An3bnhgc77tAWe5sfclqYZ6JVMacIGosQccRxXkknwjcT 4xRXp5qtdBaL2ZrDZucmOIbNmhwQd7NuBWsWYuM= X-Received: by 2002:a9d:6a84:: with SMTP id l4mr3302303otq.145.1578472995351; Wed, 08 Jan 2020 00:43:15 -0800 (PST) MIME-Version: 1.0 References: <1578415992-24054-1-git-send-email-krzk@kernel.org> <2355489c-a207-1927-54cf-85c04b62f18f@c-s.fr> In-Reply-To: <2355489c-a207-1927-54cf-85c04b62f18f@c-s.fr> From: Geert Uytterhoeven Date: Wed, 8 Jan 2020 09:43:04 +0100 Message-ID: Subject: Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument To: Christophe Leroy Cc: Krzysztof Kozlowski , Rich Felker , Jiri Slaby , "Michael S. Tsirkin" , David Airlie , Jason Wang , DRI Development , virtualization@lists.linux-foundation.org, "James E.J. Bottomley" , netdev , Paul Mackerras , Linux-Arch , Dave Jiang , Yoshinori Sato , Helge Deller , Linux-sh list , Alexey Brodkin , Ben Skeggs , nouveau@lists.freedesktop.org, Dave Airlie , Matt Turner , arcml , Nick Kossifidis , Allen Hubbe , Arnd Bergmann , alpha , Ivan Kokshaysky , Thomas Gleixner , Mauro Carvalho Chehab , Kalle Valo , Richard Henderson , Parisc List , Vineet Gupta , linux-wireless , Linux Kernel Mailing List , Luis Chamberlain , Daniel Vetter , Jon Mason , linux-ntb@googlegroups.com, Andrew Morton , Linux Media Mailing List , linuxppc-dev , "David S. Miller" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Hi Christophe, On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy wrote: > Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit : > > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote: > >> On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven wrote: > >>> On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote: > >>>> The ioread8/16/32() and others have inconsistent interface among the > >>>> architectures: some taking address as const, some not. > >>>> > >>>> It seems there is nothing really stopping all of them to take > >>>> pointer to const. > >>> > >>> Shouldn't all of them take const volatile __iomem pointers? > >>> It seems the "volatile" is missing from all but the implementations in > >>> include/asm-generic/io.h. > >> > >> As my "volatile" comment applies to iowrite*(), too, probably that should be > >> done in a separate patch. > >> > >> Hence with patches 1-5 squashed, and for patches 11-13: > >> Reviewed-by: Geert Uytterhoeven > > > > I'll add to this one also changes to ioreadX_rep() and add another > > patch for volatile for reads and writes. I guess your review will be > > appreciated once more because of ioreadX_rep() > > volatile should really only be used where deemed necessary: > > https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html > > It is said: " ... accessor functions might use volatile on > architectures where direct I/O memory access does work. Essentially, > each accessor call becomes a little critical section on its own and > ensures that the access happens as expected by the programmer." That is exactly the use case here: all above are accessor functions. Why would ioreadX() not need volatile, while readY() does? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds