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 70E9CC4167B for ; Thu, 30 Nov 2023 19:26:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E61566B0481; Thu, 30 Nov 2023 14:26:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E11476B0486; Thu, 30 Nov 2023 14:26:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD9456B0487; Thu, 30 Nov 2023 14:26:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BCFCC6B0481 for ; Thu, 30 Nov 2023 14:26:27 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8B5191C0314 for ; Thu, 30 Nov 2023 19:26:27 +0000 (UTC) X-FDA: 81515602014.19.39350D3 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf11.hostedemail.com (Postfix) with ESMTP id 820EC40007 for ; Thu, 30 Nov 2023 19:26:25 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MROtsBr8; spf=pass (imf11.hostedemail.com: domain of fancer.lancer@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=fancer.lancer@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701372385; a=rsa-sha256; cv=none; b=Uog9AaGoqMvo04tlEFFHVJOPwiJlTEyyrWylR3bhHZmYa2Z6gSuEeWObaKLGOJH5cxUUoC Tif60CQtNeuybt9RiQhPWr5xfBuvVQj8Ll5dASGj0EB1Z3PAhk8AZwVF/hrnA9AVvooGhY 0AXaKy5dvxud8vfdOibrHlH2AEykGPY= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MROtsBr8; spf=pass (imf11.hostedemail.com: domain of fancer.lancer@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=fancer.lancer@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701372385; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lMs74unU7j3F1FusL/0cihts5RibnCIqAyk58UQbGC0=; b=wpjCJYJQFPeoskPz9BC8NKCxLCkg46oLZMGQPILYK90ouH4nhsKKc2L6D9nIgkskTiHFmx gbUEBEV2ARxA3/9rufMmSZJBku6j4aM9flkDQugzb5TpHCj5+g6TbpPKbjFyAswO1N6spS WteAUruMSbIbSfRqpGLZWp7W0T8kr30= Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-50bc8e37b5fso1903081e87.0 for ; Thu, 30 Nov 2023 11:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701372384; x=1701977184; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lMs74unU7j3F1FusL/0cihts5RibnCIqAyk58UQbGC0=; b=MROtsBr8L7yj9gRH1n3gz+N55ByHEwIyTQzcwnOfnDWbtch+TKkDpxJ66ja9Zhq+Kp kxxS00Ui8+qWh6vnXhjCdxwOasUCl/GB7ySWcX6TExFb2JiU3yOLLny9/9TaI7e/QJkj K+f0PK/J7xfy5LIDorMjqHh3IpGpubMaJvPRlF25hXwUIGV7LNRbCdzKmNqb0y8pOwt0 FMeHzQfmwKk/r/xs7kqd2LLyt4yzYDS4+Tc2/BfPjN/eMl9iUN2YmObVt/C1Xr6mEm6N XRO8vEyNElRQ0+yMJJl2zsO+t224csXsmAE5LA9C3wQfyGBQfNNjfTOIDDhbA52SiG2K qEhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701372384; x=1701977184; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lMs74unU7j3F1FusL/0cihts5RibnCIqAyk58UQbGC0=; b=YSvIGq/Ac7mzo+P5QbQo/EVv6g+VNmiuWz2tN8tRVP/4NBCtmqvpM/LpUsxzCMPpNf JDWVU2R1VNsY0/4BtJu7WM1uQwAl1dzOumqmCxtbjWMn+f/HAQQQo4Lrn8MtqUms90uq v0bZU7XA40HceFt4EF4hLra2U7eWVBiLt3bV/mdsCGfZHUFHEXRk7q2hQ8edf5JMxuHO Ku1NDD9bC3TQ+QmSAQa8VgK+VvLuEQ3I5zLHtq1Afc3kd7V15PIU2czg0T31laK37FQ1 sOI+eCHLGIhlP/wGAc0EJ3C/Oc/2UpsYoYDPQfL69A+xqgdHk2yKxStwpktm6Qnm5Omy STOw== X-Gm-Message-State: AOJu0YxC5+ZJ7XfWB8HPE/ErP72gsp+fX1wmGPd/DocJGyCqQID1kGpT ln/oPhyRt/4AOahCxrzNUYI= X-Google-Smtp-Source: AGHT+IHCWGwWvalIBKki4YozNtwRGbiGw1Q30A2/Q59Vc29DchiDIMWyT7SoQeCsB1Kr6b9roa+Ruw== X-Received: by 2002:ac2:59c1:0:b0:50b:d764:76c1 with SMTP id x1-20020ac259c1000000b0050bd76476c1mr8537lfn.80.1701372383383; Thu, 30 Nov 2023 11:26:23 -0800 (PST) Received: from mobilestation ([95.79.203.166]) by smtp.gmail.com with ESMTPSA id g11-20020a19ee0b000000b0050bc96db130sm234767lfb.275.2023.11.30.11.26.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Nov 2023 11:26:23 -0800 (PST) Date: Thu, 30 Nov 2023 22:26:20 +0300 From: Serge Semin To: Arnd Bergmann Cc: Jiaxun Yang , Thomas Bogendoerfer , Andrew Morton , Mike Rapoport , Matthew Wilcox , Tiezhu Yang , Huacai Chen , Yinglu Yang , Alexey Malahov , Aleksandar Rikalo , Aleksandar Rikalo , Dragan Mladjenovic , Chao-ying Fu , Marc Zyngier , "linux-mips@vger.kernel.org" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/7] mips: dmi: Fix early remap on MIPS32 Message-ID: <2b6pgqupd7uv5la5h52zczdfkpbtnn3xbz2oqjhqpyiqv6ew35@t2vb7vteespn> References: <245d3985-9085-4be0-8c74-d95d06334584@app.fastmail.com> <3iksuovvsln3cw3xpmjd7f7xixfvwaneu4ok56fnookvyolpco@wrxxew3thgnq> <00c225bf-ed99-4721-9d6a-1e58cdffc79f@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c225bf-ed99-4721-9d6a-1e58cdffc79f@app.fastmail.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 820EC40007 X-Stat-Signature: g8rjoa7e4wjn46uzbuqt7q5yuqk78bk5 X-Rspam-User: X-HE-Tag: 1701372385-44632 X-HE-Meta: U2FsdGVkX18Iu/Vh/UpbA6DB7BYp5ebSqiy+xgvMigMgJA9UPLNLuSOvA1gzXbq6gt3ddaicXmIdZNxvBzo4M/49tLgwUjeDTWKi9wBRL5H1ZhfxY0QiS0kfNmqDQ+mqE7MMEiGpTj1xu25lytQmFcH5TDVAYdirMyRm2uD3QmGJCN5WxiWDDU9Uk1vJzgmZbPmzmryvdOrvv/TvWDalo/BcJx6qT9KNec9vyx1L/4s2caZUVdUCT3t2NKRyEeOuFvLqFDrI4lepmmRGJSTGCdfuFClMbX+jeYtdqS5sA69kNgzdpvkehTjfgs7xTTDR7iemKBHbqJu6rIfeutmRc2hOaNuGX8NFtLQyld2VvQgQBhB2KyUYZVns/ZCojWUNx87wH/scGhIm6Y/XLJTFnrUvyQiIH96Sf07Gd4N8e/xBqiCVCZVVya6+uZhYtR2rtCSmnfTgiWW1fKyMiXo+4fGG695VLU0ZTLrSMGX+Z/gSwV55xbfoI5nhtD+MPsn1J3iUTlXin6gCc6U5U5WfUoMdVu4jPsOdQHc/HiLZR5mgEhvYP6UzpKc6gNOshJb52n8NUX8y7cXf3v7mUOidQkLrn0ziMzLPc2WVSb/4OguJogx5b/sJ2bNhMpSDT6XBdXsdHHg1W75wg1CuBhSKjQj4EtSurKckUAg7qCMVQsUTg8UCzpDzGbkVGKB3tQwQfYR3GXpBv2MtVtcglCIX8HFN/g+V5L8TwwJFXSaqlxLS+LndJg9qXBGlhcduE9oQGQUpUWB0iN6+MW8Mcbqxd69kA2wc/S/D3RyoN0foGFJPWirBvhW3XLrhvymxVMdeKsmM2pJrc5Yaj/eQYyb2kNM9SotDrndMb82YP3woY0wco7623bg59gpudFlAqrSOkZUPDAueG2h0JKwGMkfQOR3ivf+wITfm6lzSeLaJ/yMPeDzbogRuy9ckUUhmoh/xIoH9JPXFjHkEP1+zumz IhCjp6oK pb+PHp1PQegop3BgIKLL4KuIE7WvGF20AiFWtk3qsQJk5ye2xw/tJe24YXtTsDCbnLn6cglp+OB2//mTVh5FzG/jas9LDM3F61pOsk0dmREhhtuX7rbrQt1VAIaJLpZWLElAeGnVt7hQ/HlSykHSdgPAI8t8rWd0j1xty6N9VF7TVX71kTwe4Umb1Tsb2FB1yXkVShvM5Ggo5VP0TA5OAQrmFSPS3zwXHyQ7yT8lst0n/0FKtAfTwFp4op4M423WifpDabka/TTck8Id7+WBGnWJ7XV/xaqULKyw/ufCEBilJHs81pB5Df4qEmItcKYyKY6pXgupTdO8r3cZnMlZh4N6fqgjpAulQhDxa4UiWXOyfwftfsklGwD6Xmg7VW+vs4rVapZUa0ABgw6E5K/km0SiFb7t752uPf6SxjkURVE5oqoeNDjC7tKxPzkXGi4Xz4HZh3cplgWVgX2T9xpbirWmiQkv89qE/B91o/6W2smQ/NDYkezvN8DUb28QwFeF6BcxuKBYBadUHSke90Ovu1+d2YFToXXOS7J7J8TxjLXOxlP7MMXSICMKu7w== 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: List-Subscribe: List-Unsubscribe: On Tue, Nov 28, 2023 at 10:59:10PM +0100, Arnd Bergmann wrote: > On Tue, Nov 28, 2023, at 14:52, Serge Semin wrote: > > On Tue, Nov 28, 2023 at 01:41:51PM +0100, Arnd Bergmann wrote: > >> On Mon, Nov 27, 2023, at 17:23, Serge Semin wrote: > >> > On Fri, Nov 24, 2023 at 10:03:49PM +0000, Jiaxun Yang wrote: > >> but ioremap_cache() is generally underspecified because the > >> resulting pointer is neither safe to dereference nor to pass into > >> readl()/writel()/memcpy_fromio() on all architectures. > > > > I don't know about ARM64 (which for instance has it utilized to access > > the DMI region), but at least in case of MIPS32 (a fortiori MIPS64 > > seeing the ioremap_cache() method actually returns a pointer to the > > uncached region) I don't see a reason why it wouldn't be safe in both > > cases described by you. All IO and memory regions are accessed by the > > generic load and store instructions. The only difference is that the > > MMIO-space accessors normally implies additional barriers, which just > > slow down the execution, but shouldn't cause any other problem. Could > > you clarify why do you think otherwise? > > On arch/powerpc, CONFIG_PPC_INDIRECT_MMIO makes all ioremap() > type functions return a token that can be passed into the readl/writel > family but that is not a pointer you can dereference. > > On s390, the mechanism is different, but similarly __iomem > tokens are not pointers at all. Ah, you meant that it was not generically safe. Then your were correct for sure. I was talking about the MIPS arch, which doesn't differentiate normal and IO memory pointers: all of them are accessed by the same instructions. So ioremap_prot() returns just a normal pointer there, which can be safely de-referenced. > > >> There was an effort to convert the remaining ioremap_cache() calls > >> into memremap() a few years ago, not sure if that's still being worked > >> on but it would be the right thing to do. > > > > I see. Thanks for the pointing out to that. I guess it could be done > > for MIPS too (at least on our MIPS32 platform DMI is just a memory > > region pre-initialized by the bootloader), but the conversion would > > require much efforts. Alas currently I can't afford to get it > > implemented in the framework of this patchset. (I saved your note in > > my MIPS TODO list though. Let's hope eventually I'll be able to get > > back to this topic.) > > I just noticed that the only architectures that actually provide > ioremap_cache() are x86, arm, arm64, mips, loongarch, powerpc, sh > and xtensa. The ones that have ACPI support still definitely > need it, most of the other ones can probably be fixed without > too much trouble. Ok. Thanks. I'll have a look at that on my free time. -Serge(y) > > Arnd