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 CACBBC32792 for ; Tue, 23 Aug 2022 01:19:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1E3248D0002; Mon, 22 Aug 2022 21:19:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 191EF8D0001; Mon, 22 Aug 2022 21:19:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05A738D0002; Mon, 22 Aug 2022 21:19:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id DDCB58D0001 for ; Mon, 22 Aug 2022 21:19:21 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6A949412FB for ; Tue, 23 Aug 2022 01:19:18 +0000 (UTC) X-FDA: 79829099196.03.51402A9 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf24.hostedemail.com (Postfix) with ESMTP id DA62F18003C for ; Tue, 23 Aug 2022 01:19:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661217557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CW2EFXmVRUt9BFAcUrpKBhy5C51otkLjmqsQzxzTVC0=; b=AP56FeDlcKPRAoQeAZ/BrTuqPwcFTvVIHNEI/QCDe3flR0jYxZ5kpHoqcIkzJSJoPsheXK Y8C0EU5EKHuVTsxe36GTApuQ33dYF+GgVBOLX65k2Qf3WXV83VFDjwaHsSTLQfeNPQuHvk vTAOUDLdRzlRrYDSrtzafNCQRpkIGL8= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-636-FAm2T8xXOvKveTwz3C7yew-1; Mon, 22 Aug 2022 21:19:14 -0400 X-MC-Unique: FAm2T8xXOvKveTwz3C7yew-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 83D9D3C01E12; Tue, 23 Aug 2022 01:19:13 +0000 (UTC) Received: from localhost (ovpn-12-31.pek2.redhat.com [10.72.12.31]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4AD202026D4C; Tue, 23 Aug 2022 01:19:11 +0000 (UTC) Date: Tue, 23 Aug 2022 09:19:07 +0800 From: Baoquan He To: Christophe Leroy Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "hch@infradead.org" , "agordeev@linux.ibm.com" , "wangkefeng.wang@huawei.com" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v2 02/11] mm: ioremap: fixup the physical address and page prot Message-ID: References: <20220820003125.353570-1-bhe@redhat.com> <20220820003125.353570-3-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661217557; a=rsa-sha256; cv=none; b=EEFIRCj4spheGsqfhNmHdmA/1rxBWt70ei4UjgEmLUAbGwxV+/tW2NPjGoePyxHgg05WRF HG7CTwDCkZU9uBraoXq8ppYAscM+UlLpLr+zVPJarpnhhqjiGNQiizdTtC8oIRDmfTdVEK gMrEsnF4HWnLdu6gM7PrtBLXKQSwBlI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AP56FeDl; spf=pass (imf24.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661217557; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CW2EFXmVRUt9BFAcUrpKBhy5C51otkLjmqsQzxzTVC0=; b=kzkxqi2ys4nLt4xCaF0SgXQSdPUktss3ewQz00LbbzzY+yc8apzdfaqfRXDjEG18bgPlnQ aAwPh/15w7MR1WXL6kt09jbQqpH2HIt/coyb9LrRF4obaDl9CCDioeamSresSmQtpZoq2B 9/1mo9/QuLjp028HMWiFlY/+akXuli8= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DA62F18003C Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AP56FeDl; spf=pass (imf24.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: kr37d338y5rmspbo6cuos9q48t1i9oi6 X-Rspam-User: X-HE-Tag: 1661217557-530950 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 08/22/22 at 06:30am, Christophe Leroy wrote: > > > Le 20/08/2022 à 02:31, Baoquan He a écrit : > > On some architectures, the physical address need be fixed up before > > doing mapping, e.g, parisc. And on architectures, e.g arc, the > > parameter 'prot' passed into ioremap_prot() need be adjusted too. > > > > In oder to convert them to take GENERIC_IOREMAP method, we need wrap > > the address fixing up code and page prot adjusting code into arch_ioremap() > > and pass the new address and 'prot' out for ioremap_prot() handling. > > Is it really the best approach ? Wouldn't it be better to have helpers > to do that, those helpers being called by the ioremap_prot(), instead of > doing it inside the arch_ioremap() function ? This is suggested too by Alexander during his v1 reviewing. I tried, but feel the current way taken in this patchset is better. Because not all architecutres need the address fix up, only parisc, and only few need adjust the 'prot'. Introducing other helpers seems too much, that only increases the complexity of of ioremap() and the generic GENERIC_IOREMAP method for people to understand and take. > > > > > This is a preparation patch, no functionality change. > > Could this be squashed into previous patch ? Yep, will do. Thanks.