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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDC0EC433F5 for ; Thu, 28 Apr 2022 15:46:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A6686B00AC; Thu, 28 Apr 2022 11:46:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 52E4C6B00AD; Thu, 28 Apr 2022 11:46:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CE3E6B00AE; Thu, 28 Apr 2022 11:46:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 2CE096B00AC for ; Thu, 28 Apr 2022 11:46:11 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F2B582A5B2 for ; Thu, 28 Apr 2022 15:46:10 +0000 (UTC) X-FDA: 79406714142.25.B152A99 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf01.hostedemail.com (Postfix) with ESMTP id 3BD4B4006E for ; Thu, 28 Apr 2022 15:46:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=H8t3i1Ilo0TsM4g1vXvltMjUgO5KYNHNYngAHD4WDa0=; b=rfhN9PZLACHZ4LhiiVnE+Rumfm fq8WiCT2P2F6C18PE0vD1csAJKP1ZOnry5Mbcscy1AmrKHq0gyrctYuoG38DUaUspoiQvoWBszq9H 6DP2CKgyushXlZfDCqCv05gBVyNBijQnD3gdjTYX44BXc5Zwru6Xc6tLnGcE6u9ySieym1iq3d/0+ mlHEiGsJ7GRrgjSaPjQXQ37qFBnv755Z/ajUBFiZr95aoYxosXE6CU8W3GRsf01MeHzRfskxAjZ3D 9SOJGtcL5+mwMMeCFuZrwOXjSYJLdSmBzPBKv7VKv7YGhZWU0W4p6aV2vtTr7ZLARjMjbPhiscvKg xCOQYFQA==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nk6LB-007iRi-Db; Thu, 28 Apr 2022 15:46:01 +0000 Date: Thu, 28 Apr 2022 08:46:01 -0700 From: Christoph Hellwig To: Kefeng Wang Cc: Andrew Morton , Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 2/4] mm: ioremap: Add arch_ioremap/iounmap_check() Message-ID: References: <20220427121413.168468-1-wangkefeng.wang@huawei.com> <20220427121413.168468-3-wangkefeng.wang@huawei.com> <20220427100411.8eaf54c51767c3e2b0b070a5@linux-foundation.org> <8d5c41a6-0478-bd5c-a37b-06a37101fc31@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8d5c41a6-0478-bd5c-a37b-06a37101fc31@huawei.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3BD4B4006E X-Stat-Signature: 54wymc6ix45gyn75rqrzcu497nbou8qu X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=rfhN9PZL; spf=none (imf01.hostedemail.com: domain of BATV+662a636c1b7b18200861+6822+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+662a636c1b7b18200861+6822+infradead.org+hch@bombadil.srs.infradead.org; dmarc=none X-HE-Tag: 1651160765-168502 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 28, 2022 at 02:16:39PM +0800, Kefeng Wang wrote: > > Pet peeve. The word "check" is a poor one. I gives no sense of what > > the function is checking and it gives no sense of how the function's > > return value relates to the thing which it checks. > > > > Maybe it returns 0 on success and -EINVAL on failure. Don't know! > > > > Don't you think that better names would be io_remap_ok(), > > io_remap_valid(), io_remap_allowed(), etc? > > Will use arch_ioremap/unmap_allowed(), and I'd like to keep return bool > > for now if there is no special requirements. Actually, there are a few architectures that can successfully ioreamp without setting up new ptes, e.g. mips. So I think I'd name them just arch_ioremap and arch_iounmap, and return a "void __Ń–omem *" from arch_ioremap, where: - IS_ERR means return an error - NULL means continue to remap - a non-NULL, non-IS_ERR pointer is directly returned.