From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Date: Wed, 08 Jan 2020 08:43:04 +0000 Subject: Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument Message-Id: List-Id: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Christophe Leroy 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" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com. [209.85.210.66]) by gmr-mx.google.com with ESMTPS id s12si32797pjo.0.2020.01.08.00.43.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 00:43:15 -0800 (PST) Received: by mail-ot1-f66.google.com with SMTP id a15so2864369otf.1 for ; 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" List-ID: Hi Christophe, On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy w= rote: > Le 08/01/2020 =C3=A0 09:18, Krzysztof Kozlowski a =C3=A9crit : > > 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 i= n > >>> include/asm-generic/io.h. > >> > >> As my "volatile" comment applies to iowrite*(), too, probably that sho= uld 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-harmfu= l.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 --=20 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= .org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument Date: Wed, 8 Jan 2020 09:43:04 +0100 Message-ID: References: <1578415992-24054-1-git-send-email-krzk@kernel.org> <2355489c-a207-1927-54cf-85c04b62f18f@c-s.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <2355489c-a207-1927-54cf-85c04b62f18f@c-s.fr> Sender: netdev-owner@vger.kernel.org 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.orgDave Airlie List-Id: linux-arch.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 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 68B73C00523 for ; Wed, 8 Jan 2020 08:45:10 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 26F0B206DA for ; Wed, 8 Jan 2020 08:45:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 26F0B206DA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 47t2r373r6zDqQr for ; Wed, 8 Jan 2020 19:45:07 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=209.85.210.68; helo=mail-ot1-f68.google.com; envelope-from=geert.uytterhoeven@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 47t2nz6Dj3zDq8B for ; Wed, 8 Jan 2020 19:43:17 +1100 (AEDT) Received: by mail-ot1-f68.google.com with SMTP id k14so2841428otn.4 for ; Wed, 08 Jan 2020 00:43:17 -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=asYl2TELkz7vL3MfQ2PY9fOhl7zPPdDWTR1xQVEIJMWfxHC8vlv5STnIL/t3XpfPZl LcosLqVYGkcWODX4YbK2rVG4u2zw6OhSytz2oJUqLHAlo/gFT3jKh0YeTNiK43CC7zzn TzotXH0wEHb1KZqtE6UH72eFvLTdhBGCS41XN9rWbx+P+RBwevYXmVK8KJPHO3zT4eDi 6IkHIN5w+7yTeqBtP/TVMPt0jUoYfSAmy0DKFMVio1FYbhXOXqr9YvKiqcbAZ5Q1/4Uo 7yHdDArrxtW5MIegXDP2cyWEbwhW5TZaYkKMORIVMhc2c/cq11NUNjZVG22S2S5pEB9I wSpg== X-Gm-Message-State: APjAAAXhnqLRFJiFkN+/l6Mz/mqPYIOnpTlasmB1+tHyK/WdxQxKENP/ gvcgi610rq63oK7yaWbz/sKdmMvB7cHtMx8xfeM= X-Google-Smtp-Source: APXvYqyLwchytFfBRcGzmYLq5q4p5hvwH1AjnwV9nNk5cX7+q/Njb59ahRoMRaX1Y0RAyipVtDWx7V8ZzLixl6z6dho= 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List 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 , Daniel Vetter , alpha , linux-ntb@googlegroups.com, Andrew Morton , Linux Media Mailing List , linuxppc-dev , "David S. Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi Christophe, On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy w= rote: > Le 08/01/2020 =C3=A0 09:18, Krzysztof Kozlowski a =C3=A9crit : > > 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 i= n > >>> include/asm-generic/io.h. > >> > >> As my "volatile" comment applies to iowrite*(), too, probably that sho= uld 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-harmfu= l.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 --=20 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= .org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 50CDFC33CA2 for ; Wed, 8 Jan 2020 08:43:19 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 27CD0206DA for ; Wed, 8 Jan 2020 08:43:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jWnr+dkx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 27CD0206DA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cKd2NSJkzzhOV7bttK+zq3+64yrDI3ZzuRfd9dphXXE=; b=jWnr+dkxDpvYAT GETji5bwRjyHjHm0aEAMD93bhkgGq1U148P4JKZJyot1e7ElbgZ1KNWIMYXi1RTrThf21l3lGMQpB F90JytIGktSetRyXWnkSGDy9+jS6tUXm7NsIfja6CWMhysmeawgQ2RGxa9bP2brGj58/9pMr/W5xL KGzh7bl0s7kLAf7LDScsdlHlfqYl5IMsgWiDPmBpQQBUmya+b7ZLAuDCT3mWk/zjQkLoR1JtjznQl Y/8xedfph+xUhZ1y2LSg0rsQTp09XoSlB6fWgr4/hvI65/OxmlG6XJ8m6+XieHB6fq7wtOAIglGye Org+O6Lz+rQ2m2T3+rkA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ip6vu-0005Nu-60; Wed, 08 Jan 2020 08:43:18 +0000 Received: from mail-ot1-f65.google.com ([209.85.210.65]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ip6vs-0005My-4y for linux-snps-arc@lists.infradead.org; Wed, 08 Jan 2020 08:43:17 +0000 Received: by mail-ot1-f65.google.com with SMTP id p8so2807461oth.10 for ; 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=AXaDiEI+xDTbSpXld5VqjzY1WaOl0jjRzzeUGmt3KcVwyJ0rKv/oGS34+QiJ2do/rj S0xJZ8sVwlQyxWzGd0VJS99CEfSr7YVoqqQp7CeoSBFS9eXjZTB92V5XI9IlXdJrLf2U CboCDfHevwCWkD/RpdwVkqKLV7DU2oveykWpb6QKPe//0/SstTNZKkFkQYHOjsHX3N+2 fzJQXAO3k2ZZLXb+zPZIvkW+hp2SaY7/raAwc9kTivcBxsCDWrll0FAjhjqUbMyfHzme ncvrZaG9rOLA9fpjOQ9yINDs0FXMSSfDRvyBkc9I2KXnTjZv2svc6DrctYtkCLjmcfSV BjhA== X-Gm-Message-State: APjAAAVak5xnJwwhwFcylcq7kKxdf5smqjImx1sl2A+NtLSC/oFEHQ4g iahSY5XqzYtzwaPrGTm7l085Ndt+83pomabFvKw= X-Google-Smtp-Source: APXvYqyLwchytFfBRcGzmYLq5q4p5hvwH1AjnwV9nNk5cX7+q/Njb59ahRoMRaX1Y0RAyipVtDWx7V8ZzLixl6z6dho= 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200108_004316_189720_DDE06C16 X-CRM114-Status: GOOD ( 15.34 ) X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on Synopsys ARC Processors 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 , Daniel Vetter , alpha , 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: base64 Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org SGkgQ2hyaXN0b3BoZSwKCk9uIFdlZCwgSmFuIDgsIDIwMjAgYXQgOTozNSBBTSBDaHJpc3RvcGhl IExlcm95IDxjaHJpc3RvcGhlLmxlcm95QGMtcy5mcj4gd3JvdGU6Cj4gTGUgMDgvMDEvMjAyMCDD oCAwOToxOCwgS3J6eXN6dG9mIEtvemxvd3NraSBhIMOpY3JpdCA6Cj4gPiBPbiBXZWQsIDggSmFu IDIwMjAgYXQgMDk6MTMsIEdlZXJ0IFV5dHRlcmhvZXZlbiA8Z2VlcnRAbGludXgtbTY4ay5vcmc+ IHdyb3RlOgo+ID4+IE9uIFdlZCwgSmFuIDgsIDIwMjAgYXQgOTowNyBBTSBHZWVydCBVeXR0ZXJo b2V2ZW4gPGdlZXJ0QGxpbnV4LW02OGsub3JnPiB3cm90ZToKPiA+Pj4gT24gVHVlLCBKYW4gNywg MjAyMCBhdCA1OjUzIFBNIEtyenlzenRvZiBLb3psb3dza2kgPGtyemtAa2VybmVsLm9yZz4gd3Jv dGU6Cj4gPj4+PiBUaGUgaW9yZWFkOC8xNi8zMigpIGFuZCBvdGhlcnMgaGF2ZSBpbmNvbnNpc3Rl bnQgaW50ZXJmYWNlIGFtb25nIHRoZQo+ID4+Pj4gYXJjaGl0ZWN0dXJlczogc29tZSB0YWtpbmcg YWRkcmVzcyBhcyBjb25zdCwgc29tZSBub3QuCj4gPj4+Pgo+ID4+Pj4gSXQgc2VlbXMgdGhlcmUg aXMgbm90aGluZyByZWFsbHkgc3RvcHBpbmcgYWxsIG9mIHRoZW0gdG8gdGFrZQo+ID4+Pj4gcG9p bnRlciB0byBjb25zdC4KPiA+Pj4KPiA+Pj4gU2hvdWxkbid0IGFsbCBvZiB0aGVtIHRha2UgY29u c3Qgdm9sYXRpbGUgX19pb21lbSBwb2ludGVycz8KPiA+Pj4gSXQgc2VlbXMgdGhlICJ2b2xhdGls ZSIgaXMgbWlzc2luZyBmcm9tIGFsbCBidXQgdGhlIGltcGxlbWVudGF0aW9ucyBpbgo+ID4+PiBp bmNsdWRlL2FzbS1nZW5lcmljL2lvLmguCj4gPj4KPiA+PiBBcyBteSAidm9sYXRpbGUiIGNvbW1l bnQgYXBwbGllcyB0byBpb3dyaXRlKigpLCB0b28sIHByb2JhYmx5IHRoYXQgc2hvdWxkIGJlCj4g Pj4gZG9uZSBpbiBhIHNlcGFyYXRlIHBhdGNoLgo+ID4+Cj4gPj4gSGVuY2Ugd2l0aCBwYXRjaGVz IDEtNSBzcXVhc2hlZCwgYW5kIGZvciBwYXRjaGVzIDExLTEzOgo+ID4+IFJldmlld2VkLWJ5OiBH ZWVydCBVeXR0ZXJob2V2ZW4gPGdlZXJ0K3JlbmVzYXNAZ2xpZGVyLmJlPgo+ID4KPiA+IEknbGwg YWRkIHRvIHRoaXMgb25lIGFsc28gY2hhbmdlcyB0byBpb3JlYWRYX3JlcCgpIGFuZCBhZGQgYW5v dGhlcgo+ID4gcGF0Y2ggZm9yIHZvbGF0aWxlIGZvciByZWFkcyBhbmQgd3JpdGVzLiBJIGd1ZXNz IHlvdXIgcmV2aWV3IHdpbGwgYmUKPiA+IGFwcHJlY2lhdGVkIG9uY2UgbW9yZSBiZWNhdXNlIG9m IGlvcmVhZFhfcmVwKCkKPgo+IHZvbGF0aWxlIHNob3VsZCByZWFsbHkgb25seSBiZSB1c2VkIHdo ZXJlIGRlZW1lZCBuZWNlc3Nhcnk6Cj4KPiBodHRwczovL3d3dy5rZXJuZWwub3JnL2RvYy9odG1s L2xhdGVzdC9wcm9jZXNzL3ZvbGF0aWxlLWNvbnNpZGVyZWQtaGFybWZ1bC5odG1sCj4KPiBJdCBp cyBzYWlkOiAiIC4uLiAgYWNjZXNzb3IgZnVuY3Rpb25zIG1pZ2h0IHVzZSB2b2xhdGlsZSBvbgo+ IGFyY2hpdGVjdHVyZXMgd2hlcmUgZGlyZWN0IEkvTyBtZW1vcnkgYWNjZXNzIGRvZXMgd29yay4g RXNzZW50aWFsbHksCj4gZWFjaCBhY2Nlc3NvciBjYWxsIGJlY29tZXMgYSBsaXR0bGUgY3JpdGlj YWwgc2VjdGlvbiBvbiBpdHMgb3duIGFuZAo+IGVuc3VyZXMgdGhhdCB0aGUgYWNjZXNzIGhhcHBl bnMgYXMgZXhwZWN0ZWQgYnkgdGhlIHByb2dyYW1tZXIuIgoKVGhhdCBpcyBleGFjdGx5IHRoZSB1 c2UgY2FzZSBoZXJlOiBhbGwgYWJvdmUgYXJlIGFjY2Vzc29yIGZ1bmN0aW9ucy4KCldoeSB3b3Vs ZCBpb3JlYWRYKCkgbm90IG5lZWQgdm9sYXRpbGUsIHdoaWxlIHJlYWRZKCkgZG9lcz8KCkdye29l dGplLGVldGluZ31zLAoKICAgICAgICAgICAgICAgICAgICAgICAgR2VlcnQKCi0tIApHZWVydCBV eXR0ZXJob2V2ZW4gLS0gVGhlcmUncyBsb3RzIG9mIExpbnV4IGJleW9uZCBpYTMyIC0tIGdlZXJ0 QGxpbnV4LW02OGsub3JnCgpJbiBwZXJzb25hbCBjb252ZXJzYXRpb25zIHdpdGggdGVjaG5pY2Fs IHBlb3BsZSwgSSBjYWxsIG15c2VsZiBhIGhhY2tlci4gQnV0CndoZW4gSSdtIHRhbGtpbmcgdG8g am91cm5hbGlzdHMgSSBqdXN0IHNheSAicHJvZ3JhbW1lciIgb3Igc29tZXRoaW5nIGxpa2UgdGhh dC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBMaW51cyBUb3J2YWxkcwoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtc25wcy1h cmMgbWFpbGluZyBsaXN0CmxpbnV4LXNucHMtYXJjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDov L2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1zbnBzLWFyYwo= 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 24AD8C33C9E for ; Wed, 8 Jan 2020 08:43:18 +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 05E93206DA for ; Wed, 8 Jan 2020 08:43:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 05E93206DA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org 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 055F26E875; Wed, 8 Jan 2020 08:43:17 +0000 (UTC) Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) by gabe.freedesktop.org (Postfix) with ESMTPS id 157B26E875; Wed, 8 Jan 2020 08:43:15 +0000 (UTC) Received: by mail-ot1-f68.google.com with SMTP id 77so2830194oty.6; 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=aOhBr3TitCJNylvPLMxfkUkydTLNgjtV6doBMAmIEV2XaHFoFMX7Nqg/4XKLti8XCK 1aiCSUAB6yvb19dzc4DMZlNHKum/cZzwjjYGA1d+eY+e9E4AWNsn6u+7AAQu+3x86/So +lmpRPkA8BF5Z95Pc3PLpOWzu+A4d6Jeo7vHXJv+9e+V4c5530wjoFOzGG8K+YXSJmvw tiW+muZ/rUJo22FBzHyQGmHBIKNonZxp1WiZFvAS2HAjikV677+Ts6Iy0jEkGi9FJ+WI 6+Anjy4CcXgXnB+t91U+3XQz5Ak6iBQKrkyhjfEaq95qnX/8LFauarg2O0NITYbQRgf2 c0KQ== X-Gm-Message-State: APjAAAUHq4RQAnAVTDX3gCCBkup0uzuozK4nX+gSb0B+8clV++wrtsYQ r4uzVqMPECIT7oT7CM+0yEEfpfLXnoUfAz0+GbQ= X-Google-Smtp-Source: APXvYqyLwchytFfBRcGzmYLq5q4p5hvwH1AjnwV9nNk5cX7+q/Njb59ahRoMRaX1Y0RAyipVtDWx7V8ZzLixl6z6dho= 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 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="utf-8" Content-Transfer-Encoding: base64 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" SGkgQ2hyaXN0b3BoZSwKCk9uIFdlZCwgSmFuIDgsIDIwMjAgYXQgOTozNSBBTSBDaHJpc3RvcGhl IExlcm95IDxjaHJpc3RvcGhlLmxlcm95QGMtcy5mcj4gd3JvdGU6Cj4gTGUgMDgvMDEvMjAyMCDD oCAwOToxOCwgS3J6eXN6dG9mIEtvemxvd3NraSBhIMOpY3JpdCA6Cj4gPiBPbiBXZWQsIDggSmFu IDIwMjAgYXQgMDk6MTMsIEdlZXJ0IFV5dHRlcmhvZXZlbiA8Z2VlcnRAbGludXgtbTY4ay5vcmc+ IHdyb3RlOgo+ID4+IE9uIFdlZCwgSmFuIDgsIDIwMjAgYXQgOTowNyBBTSBHZWVydCBVeXR0ZXJo b2V2ZW4gPGdlZXJ0QGxpbnV4LW02OGsub3JnPiB3cm90ZToKPiA+Pj4gT24gVHVlLCBKYW4gNywg MjAyMCBhdCA1OjUzIFBNIEtyenlzenRvZiBLb3psb3dza2kgPGtyemtAa2VybmVsLm9yZz4gd3Jv dGU6Cj4gPj4+PiBUaGUgaW9yZWFkOC8xNi8zMigpIGFuZCBvdGhlcnMgaGF2ZSBpbmNvbnNpc3Rl bnQgaW50ZXJmYWNlIGFtb25nIHRoZQo+ID4+Pj4gYXJjaGl0ZWN0dXJlczogc29tZSB0YWtpbmcg YWRkcmVzcyBhcyBjb25zdCwgc29tZSBub3QuCj4gPj4+Pgo+ID4+Pj4gSXQgc2VlbXMgdGhlcmUg aXMgbm90aGluZyByZWFsbHkgc3RvcHBpbmcgYWxsIG9mIHRoZW0gdG8gdGFrZQo+ID4+Pj4gcG9p bnRlciB0byBjb25zdC4KPiA+Pj4KPiA+Pj4gU2hvdWxkbid0IGFsbCBvZiB0aGVtIHRha2UgY29u c3Qgdm9sYXRpbGUgX19pb21lbSBwb2ludGVycz8KPiA+Pj4gSXQgc2VlbXMgdGhlICJ2b2xhdGls ZSIgaXMgbWlzc2luZyBmcm9tIGFsbCBidXQgdGhlIGltcGxlbWVudGF0aW9ucyBpbgo+ID4+PiBp bmNsdWRlL2FzbS1nZW5lcmljL2lvLmguCj4gPj4KPiA+PiBBcyBteSAidm9sYXRpbGUiIGNvbW1l bnQgYXBwbGllcyB0byBpb3dyaXRlKigpLCB0b28sIHByb2JhYmx5IHRoYXQgc2hvdWxkIGJlCj4g Pj4gZG9uZSBpbiBhIHNlcGFyYXRlIHBhdGNoLgo+ID4+Cj4gPj4gSGVuY2Ugd2l0aCBwYXRjaGVz IDEtNSBzcXVhc2hlZCwgYW5kIGZvciBwYXRjaGVzIDExLTEzOgo+ID4+IFJldmlld2VkLWJ5OiBH ZWVydCBVeXR0ZXJob2V2ZW4gPGdlZXJ0K3JlbmVzYXNAZ2xpZGVyLmJlPgo+ID4KPiA+IEknbGwg YWRkIHRvIHRoaXMgb25lIGFsc28gY2hhbmdlcyB0byBpb3JlYWRYX3JlcCgpIGFuZCBhZGQgYW5v dGhlcgo+ID4gcGF0Y2ggZm9yIHZvbGF0aWxlIGZvciByZWFkcyBhbmQgd3JpdGVzLiBJIGd1ZXNz IHlvdXIgcmV2aWV3IHdpbGwgYmUKPiA+IGFwcHJlY2lhdGVkIG9uY2UgbW9yZSBiZWNhdXNlIG9m IGlvcmVhZFhfcmVwKCkKPgo+IHZvbGF0aWxlIHNob3VsZCByZWFsbHkgb25seSBiZSB1c2VkIHdo ZXJlIGRlZW1lZCBuZWNlc3Nhcnk6Cj4KPiBodHRwczovL3d3dy5rZXJuZWwub3JnL2RvYy9odG1s L2xhdGVzdC9wcm9jZXNzL3ZvbGF0aWxlLWNvbnNpZGVyZWQtaGFybWZ1bC5odG1sCj4KPiBJdCBp cyBzYWlkOiAiIC4uLiAgYWNjZXNzb3IgZnVuY3Rpb25zIG1pZ2h0IHVzZSB2b2xhdGlsZSBvbgo+ IGFyY2hpdGVjdHVyZXMgd2hlcmUgZGlyZWN0IEkvTyBtZW1vcnkgYWNjZXNzIGRvZXMgd29yay4g RXNzZW50aWFsbHksCj4gZWFjaCBhY2Nlc3NvciBjYWxsIGJlY29tZXMgYSBsaXR0bGUgY3JpdGlj YWwgc2VjdGlvbiBvbiBpdHMgb3duIGFuZAo+IGVuc3VyZXMgdGhhdCB0aGUgYWNjZXNzIGhhcHBl bnMgYXMgZXhwZWN0ZWQgYnkgdGhlIHByb2dyYW1tZXIuIgoKVGhhdCBpcyBleGFjdGx5IHRoZSB1 c2UgY2FzZSBoZXJlOiBhbGwgYWJvdmUgYXJlIGFjY2Vzc29yIGZ1bmN0aW9ucy4KCldoeSB3b3Vs ZCBpb3JlYWRYKCkgbm90IG5lZWQgdm9sYXRpbGUsIHdoaWxlIHJlYWRZKCkgZG9lcz8KCkdye29l dGplLGVldGluZ31zLAoKICAgICAgICAgICAgICAgICAgICAgICAgR2VlcnQKCi0tIApHZWVydCBV eXR0ZXJob2V2ZW4gLS0gVGhlcmUncyBsb3RzIG9mIExpbnV4IGJleW9uZCBpYTMyIC0tIGdlZXJ0 QGxpbnV4LW02OGsub3JnCgpJbiBwZXJzb25hbCBjb252ZXJzYXRpb25zIHdpdGggdGVjaG5pY2Fs IHBlb3BsZSwgSSBjYWxsIG15c2VsZiBhIGhhY2tlci4gQnV0CndoZW4gSSdtIHRhbGtpbmcgdG8g am91cm5hbGlzdHMgSSBqdXN0IHNheSAicHJvZ3JhbW1lciIgb3Igc29tZXRoaW5nIGxpa2UgdGhh dC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBMaW51cyBUb3J2YWxkcwpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFp bGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument Date: Wed, 8 Jan 2020 09:43:04 +0100 Message-ID: References: <1578415992-24054-1-git-send-email-krzk@kernel.org> <2355489c-a207-1927-54cf-85c04b62f18f@c-s.fr> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <2355489c-a207-1927-54cf-85c04b62f18f@c-s.fr> Sender: netdev-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8" 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 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