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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56C6EC61DA4 for ; Thu, 16 Feb 2023 12:42:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229719AbjBPMms (ORCPT ); Thu, 16 Feb 2023 07:42:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229725AbjBPMmo (ORCPT ); Thu, 16 Feb 2023 07:42:44 -0500 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B883311C1; Thu, 16 Feb 2023 04:42:11 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8C9095C00BE; Thu, 16 Feb 2023 07:42:08 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Thu, 16 Feb 2023 07:42:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1676551328; x=1676637728; bh=4av0BcgO57 q6PB48qfskBTT3lQalafxs0+Jkv9f+ETk=; b=fwdeBLH8dTHrGbPNhRjaH73LJ4 g4YLate0C/+/NPvvKigVGKh3hgOLc7x0K8dOTpvE4yhsoD9MnXdvPq3PwbNjY1dN 0Fx76WBWTnnH8D/hnn3ienM9XCsQfQ0vWKorriw0dvI8UCZ9X/nsQvht+pvdaO0m 9Uz+/yHQCUVIKYg8xCUR87WSl3bOlgi/FBwWwpEmb1HXEV9oU+Nux1chsF6/m7bG QaLKoAFXxPxFHMiG73SV0xUi4b2edzxivQoB+J79vY6fSLZ77YGXRw0bR/29pOyI GnuBLVdTFm+U1ExWgLUOX7s4+jZCdzNyYiVUUAR33fEcUnh61qmIbxjhgmrQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1676551328; x=1676637728; bh=4av0BcgO57q6PB48qfskBTT3lQal afxs0+Jkv9f+ETk=; b=dEoQmo4s0anb3S3N8HPNR0ZZy/aYvoMKXJiWyaxfG4rX GcF3gnjZrskxj9C1nFPjFXzF5ozgikRom25Co8ySi30qJMDV7ZS85l6IbscIcemL 1rR2PHTRRkJ/G5MgjlpPv5zEcvofztTP27zMPfzjCfsMOnJDPSn1oZVEz8obbhfS RaQGXt1ds3uFrJP3HansNLJYIEpapHmSmyxt0ewbaRkeQqIY49j4ogeX/gZ5CFGF mH7DaiocUH0ch7JWFch8/AXvOrN/6RwfNLtbHlI522U8taigMBdhgpIVnacDWeL1 IviOVslVI6VdnsDXky35glkRGZFULHo/T2lMlfwzyQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeijedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id DD2F1B60086; Thu, 16 Feb 2023 07:42:07 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-156-g081acc5ed5-fm-20230206.001-g081acc5e Mime-Version: 1.0 Message-Id: In-Reply-To: <20230216123419.461016-5-bhe@redhat.com> References: <20230216123419.461016-1-bhe@redhat.com> <20230216123419.461016-5-bhe@redhat.com> Date: Thu, 16 Feb 2023 13:41:49 +0100 From: "Arnd Bergmann" To: "Baoquan He" , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, "Andrew Morton" , "Christophe Leroy" , "Christoph Hellwig" , "Alexander Gordeev" , "Kefeng Wang" , "Niklas Schnelle" , "David Laight" , "Stafford Horne" , Linux-Arch Subject: Re: [PATCH v4 04/16] mm: ioremap: allow ARCH to have its own ioremap method definition Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 16, 2023, at 13:34, Baoquan He wrote: > Architectures can be converted to GENERIC_IOREMAP, to take standard > ioremap_xxx() and iounmap() way. But some ARCH-es could have specific > handling for ioremap_prot(), ioremap() and iounmap(), than standard > methods. > > In oder to convert these ARCH-es to take GENERIC_IOREMAP, allow these > architecutres to have their own ioremap_prot(), ioremap() and iounmap() > definitions. > > Signed-off-by: Baoquan He > Cc: Arnd Bergmann > Cc: Kefeng Wang > Cc: linux-arch@vger.kernel.org Acked-by: Arnd Bergmann