From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-a5-smtp.messagingengine.com (fout-a5-smtp.messagingengine.com [103.168.172.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 89DE71D6194 for ; Thu, 20 Mar 2025 09:21:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.148 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742462517; cv=none; b=l5Zaonz7sAQ2xyNRl0ehk8BMc2MpPNxyMgSmyhzxt4aohgUVBvbfFo3pu1K/QMRrBEuI5TH9h9Fe/DWuISHqnm6R07K+SrUZpOpYNXRgOZccQyzCmOG4RFkIeBXEEjdxwRT7XSN6UUFHM1JFf/YHiQCivn56KzrGqT+Qozssens= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742462517; c=relaxed/simple; bh=TKt9Etbyd+6lbrjcqrPujBy370zZM6JfyA35fvk4SUE=; h=MIME-Version:Date:From:To:Message-Id:In-Reply-To:References: Subject:Content-Type; b=CFmFgb+HnNM5QPOklzkcgupqQnTvdw5QlaJi6PGbfOx7hvxWmc3eH5MrQt2PNQgPGKW+ggF4u4b90xwoCXDD275qxmoJhdsJ4QTX/vGpDo6GK4bhgQqgLf8ozI2dDATGhYR9g3WRIBWQthZ1SiwGGhZnydjRFZcHNij1qOI9mio= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=UZUcr4fx; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=jLPI9mzx; arc=none smtp.client-ip=103.168.172.148 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="UZUcr4fx"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="jLPI9mzx" Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.phl.internal (Postfix) with ESMTP id 5FF471382D7C; Thu, 20 Mar 2025 05:21:53 -0400 (EDT) Received: from phl-imap-11 ([10.202.2.101]) by phl-compute-07.internal (MEProxy); Thu, 20 Mar 2025 05:21:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1742462513; x=1742548913; bh=bQtSbsAebIiFW2nPgYN3fEu05hmxSDGpViPkOh0koQY=; b= UZUcr4fx0KomfbUqK39EysoFlxL9GhmhTZMPcCYxOz4b/G6z/eM3ebkeTdXToCbK 5SiGo+qH5s/HQZw+d4PGWXNQuEeHnhN7M7+JSpLpmdQ4YqvhEh4YwqkXzGKmFqpF sjFEB1m8CUAtFPKEwaHyEFUtSl4UCUPog+l+T4PZUhB4s5DAfREqpk7Oyyq74bRE Xu83hvKcooGVjp2MoPzr0S5lcAzaYbRq1sa7Aao6p+Whp1lUiHyoXy61YoDF6TJH 1VLUcW4tCnSyTmTWgffkJC4cZQYhbtL11PEl6RPanqD/6pR3485/FWpgLuWc5FhD aMLyteTXwpqUEHvYqN3Dsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1742462513; x=1742548913; bh=b QtSbsAebIiFW2nPgYN3fEu05hmxSDGpViPkOh0koQY=; b=jLPI9mzxH/l3E0zsf SzC9PLwK8Ff7q42HgpNcoebmCDgABrfYWmVYYgLcoNzAk9vzRJCnXUY8yGQf9l6/ lMNbgexOaWdfgwzfEOvj0Ts6iInMyDIWEgfJZYEFdSHu+kWj/VEDy28pgl02te9u JFyiOic06liT4waRmKRaLd4LT6YT4LNy2cEJou4firkiz7NPfiZwQGVxWbGh++e9 Cl1zsl9L/putUkRmO7MR2I0t1vO/L7NBwzxDTNxBZv+khkFeGBWVb1JXX3Ibzn14 XBBofO/z0orgipB1c1coFL0e+w90+oK14xPH2OxXbV4a5Byt22VRrQMeaOMyDMzk VCvRQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddugeejkeefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepofggfffhvffkjghfufgtgfesthejredtredt tdenucfhrhhomhepfdetrhhnugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusg druggvqeenucggtffrrghtthgvrhhnpefhkeeltdfffefhgffhteetheeuhffgteeghfdt ueefudeuleetgfehtdejieffhfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrrhhnugesrghrnhgusgdruggvpdhnsggprhgtphhtthhopedv vddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprghnshhhuhhmrghnrdhkhhgrnh guuhgrlhesrghrmhdrtghomhdprhgtphhtthhopegtrghtrghlihhnrdhmrghrihhnrghs segrrhhmrdgtohhmpdhrtghpthhtoheprhihrghnrdhrohgsvghrthhssegrrhhmrdgtoh hmpdhrtghpthhtohepvhhinhgtvghniihordhfrhgrshgtihhnohesrghrmhdrtghomhdp rhgtphhtthhopegtuhhihihunhhhuhhisegshihtvggurghntggvrdgtohhmpdhrtghpth htoheplhhugihurdhkvghrnhgvlhessgihthgvuggrnhgtvgdrtghomhdprhgtphhtthho pehsthhurghrthdrmhgvnhgvfhihsegtohgurghsihhprdgtohhmpdhrtghpthhtoheptg hhrhhishhtohhphhgvrdhlvghrohihsegtshhgrhhouhhprdgvuhdprhgtphhtthhopehp rghlmhgvrhesuggrsggsvghlthdrtghomh X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 65F342220072; Thu, 20 Mar 2025 05:21:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: T4d23c9949082f1fa Date: Thu, 20 Mar 2025 10:21:19 +0100 From: "Arnd Bergmann" To: "Yunhui Cui" , "Paul Walmsley" , "Palmer Dabbelt" , "Albert Ou" , "Alexandre Ghiti" , "Anshuman Khandual" , "Andrew Morton" , "Ingo Molnar" , "Catalin Marinas" , "Ryan Roberts" , "Kirill A. Shutemov" , "Nam Cao" , =?UTF-8?Q?Bj=C3=B6rn_T=C3=B6pel?= , "Stuart Menefy" , "Xu Lu" , "Vincenzo Frascino" , "Samuel Holland" , "Christophe Leroy" , "Dawei Li" , "Mike Rapoport" , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Message-Id: <9256ca10-323d-41b4-b935-5281f925d50c@app.fastmail.com> In-Reply-To: <20250320084428.51151-1-cuiyunhui@bytedance.com> References: <20250320084428.51151-1-cuiyunhui@bytedance.com> Subject: Re: [PATCH] riscv: introduce the ioremap_prot() function Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, Mar 20, 2025, at 09:44, Yunhui Cui wrote: > It's advisable to avoid mapping memory with the non-cache attribute. > This is because issues may arise when the same physical address is > mapped as both cacheable and non-cacheable simultaneously, such as > in the case of hardware prefetching. > > Signed-off-by: Yunhui Cui Makes sense to me. Ideally we'd have the check in generic_ioremap_prot(), but I believe this would break on (at least) x86 because of legacy callers of ioremap() on memory. > diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h > index a0e51840b9db..736c5557bd06 100644 > --- a/arch/riscv/include/asm/io.h > +++ b/arch/riscv/include/asm/io.h > @@ -133,6 +133,8 @@ __io_writes_outs(outs, u64, q, __io_pbr(), __io_paw()) > #define outsq(addr, buffer, count) __outsq(PCI_IOBASE + (addr), buffer, count) > #endif > > +#define ioremap_prot ioremap_prot > + > #include > > #ifdef CONFIG_MMU This feels slightly wrong to me, the "#define foo foo" method is normally used to override a declaration or inline function with another one, but this one only overrides the implementation, not the declaration. I see the same is done on arc, arm64, parisc, powerpc, s390, sh and xtensa, so we can keep this one as well, but it would be nice to change all of these to a less surprising approach. Maybe we should just remove these macros from asm/io.h and the trivial wrapper from mm/ioremap.c, and instead change the other architectures that have GENERIC_IOREMAP to use #define ioremap_prot generic_ioremap_prot It seems this would be only csky, hexagon, (some) loongarch and openrisc. Arnd