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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 97B37C433E0 for ; Tue, 9 Mar 2021 20:31:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 633D6650E5 for ; Tue, 9 Mar 2021 20:31:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231657AbhCIUag (ORCPT ); Tue, 9 Mar 2021 15:30:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231634AbhCIUad (ORCPT ); Tue, 9 Mar 2021 15:30:33 -0500 Received: from mail.marcansoft.com (marcansoft.com [IPv6:2a01:298:fe:f::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83276C06174A; Tue, 9 Mar 2021 12:30:33 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id D16A73FA6A; Tue, 9 Mar 2021 20:29:54 +0000 (UTC) Subject: Re: [RFT PATCH v3 10/27] docs: driver-api: device-io: Document ioremap() variants & access funcs To: Arnd Bergmann , Andy Shevchenko Cc: Linus Walleij , Linux ARM , Marc Zyngier , Rob Herring , Olof Johansson , Krzysztof Kozlowski , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Will Deacon , Mark Rutland , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "open list:SERIAL DRIVERS" , Linux Doc Mailing List , linux-samsung-soc , Linux-Arch , "linux-kernel@vger.kernel.org" References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-11-marcan@marcan.st> From: Hector Martin Message-ID: <5eb23b42-5fda-0524-8666-0eb2c37b4ac1@marcan.st> Date: Wed, 10 Mar 2021 05:29:52 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: es-ES Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On 06/03/2021 00.51, Arnd Bergmann wrote: > On Fri, Mar 5, 2021 at 4:09 PM Andy Shevchenko > wrote: >> On Fri, Mar 5, 2021 at 12:25 PM Linus Walleij wrote: >>> On Thu, Mar 4, 2021 at 10:40 PM Hector Martin wrote: >>> >>>> This documents the newly introduced ioremap_np() along with all the >>>> other common ioremap() variants, and some higher-level abstractions >>>> available. >>>> >>>> Signed-off-by: Hector Martin >>> >>> I like this, I just want one change: >>> >>> Put the common ioremap() on top in all paragraphs, so the norm >>> comes before the exceptions. >>> >>> I.e. it is weird to mention ioremap_np() before mentioning ioremap(). >> >> +1 here. That is what I have stumbled upon reading carefully. > > In that case, the order should probably be: > > ioremap > ioremap_wc > ioremap_wt > ioremap_np > ioremap_uc > ioremap_cache > > Going from most common to least common, rather than going from > strongest to weakest. Yeah, I was dwelling on the issue of ioremap_np being first when I wrote that... this alternative works for me, I'll sort it like this then. It'll just need some re-wording to make it all flow properly. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub