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 DE80BC4167B for ; Tue, 28 Nov 2023 11:34:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 68C596B02FD; Tue, 28 Nov 2023 06:34:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 63D7C6B02FF; Tue, 28 Nov 2023 06:34:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 504A56B0300; Tue, 28 Nov 2023 06:34:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 38CDE6B02FD for ; Tue, 28 Nov 2023 06:34:13 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 135F012018A for ; Tue, 28 Nov 2023 11:34:13 +0000 (UTC) X-FDA: 81507154386.10.E937DCB Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf25.hostedemail.com (Postfix) with ESMTP id 1D758A001F for ; Tue, 28 Nov 2023 11:34:10 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ahiZr2AY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of fancer.lancer@gmail.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=fancer.lancer@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701171251; 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=HinylyjMIV3zakyLQJjGGG/zA6qqtkTIM5z3ZBjPgUw=; b=TagJUcQGEL6caRAjQ7HnszxK6wYrv89m52JVRJDEsjjG+cXZqWvTT7Yzf/oUGF2fApqieK IBj5dRxdfB8020yewQlq9jppTgcO55nJQKv10dVGO3de+kgsTanfD/l5ncDH3iQ4OEJvGQ OM0zTxtlbqt+zDgC+rYsA6/psNgNto4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ahiZr2AY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of fancer.lancer@gmail.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=fancer.lancer@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701171251; a=rsa-sha256; cv=none; b=0EQPhCManIN7M3X+4Rxz1qgH1dAgSXdN4WHM1XJL3JCAwPb4lVs70od4EIolSjtjSriI8B ShvtDxGlnKDdEd9GopKE9iy1Lujg9R7vH2pt8obNudtINAySlQTkt9yWasSOYDhaiBBl0S cFl32ydXLmFsTooudLuHHncvM3TSooQ= Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-50bbfad8758so292410e87.3 for ; Tue, 28 Nov 2023 03:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701171249; x=1701776049; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=HinylyjMIV3zakyLQJjGGG/zA6qqtkTIM5z3ZBjPgUw=; b=ahiZr2AYIuJtgzJ8WJ+pv1XL3rGLHurThOA+8O+eqvOXN8rZ8Wwbt48kc7e0YNVbhd kK1YnctsrBROWajXl+PyeFIGwhnCQPr9y10r8WBSkhNY39eAfGYZqwkh/PDGGZA4xK3Q ba+6UFI3FLCxP+Tymj+oXTVAzi4dqtv8oY8jyAGpCKjc1ScrOSqUpvte3P9qUYePo7m3 UgnWPHfpXhzELXyathlKx4eOck/4a8lqaR/YJtBZB610uizgtR4s3iruY5vQudbBh1M9 ++Ie+IQGHBNPWKGJ/50TWsjsNKnWeED3tjZBwZCRPfAC4qL6XhZTs4/r3QfzeLNyrClW 7J2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701171249; x=1701776049; h=in-reply-to:content-transfer-encoding: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=HinylyjMIV3zakyLQJjGGG/zA6qqtkTIM5z3ZBjPgUw=; b=q1AmOVSOLTRk7ufMq7NwpZQ9kXgdjzwv0TaX1mwjNig2vNGP9EBTR8cpY27AoHCp9t ryXfnLNhK+Y3hBdbkarRBbjGZQaiPPW5tygvd23Cdc2bw+Duso1gobplti+MHq6cHJDy ZzdCH3EuvWCxLYHNluZ9D2Tc2UvKh5m88PiWJgR9rxjxqRrZx6EThAYWZ5D9E6OtmYWj jkfF/l18DuzrOtBsZUsRpqmnF4mM7dhCIuCy4GLlySC/zCCYR3rGmMj1A3WBYhTwmUnx CZo8JX5LGq8ymaLBZO8qvikdZ0oNrQ9vJMj59UTzk2owk55UpTtlkOCYTDpTGDJahdRo 0NzQ== X-Gm-Message-State: AOJu0YwnItilWqeoNA/ATYKBYunFODbukty+IGPdcGFytFaYr2Wfz9jJ zy8Tma/juUfePPwdKAUYLEo= X-Google-Smtp-Source: AGHT+IGE5qifJckMD+F1s0FDK+EpXSW5ug9B4iWKSn8uouCdGMtyGXXLIyjxoyEEXslH/qHIkCjT9w== X-Received: by 2002:ac2:4c48:0:b0:507:b7db:1deb with SMTP id o8-20020ac24c48000000b00507b7db1debmr11909699lfk.38.1701171249157; Tue, 28 Nov 2023 03:34:09 -0800 (PST) Received: from mobilestation ([178.176.56.174]) by smtp.gmail.com with ESMTPSA id k20-20020ac24574000000b00507a8789b43sm1820151lfm.269.2023.11.28.03.34.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Nov 2023 03:34:08 -0800 (PST) Date: Tue, 28 Nov 2023 14:34:05 +0300 From: Serge Semin To: Jiaxun Yang Cc: Thomas Bogendoerfer , Arnd Bergmann , 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: <3pgnihbrp5orh4tmj45fipbfoxdwzjh6uefitdpcea2vgkarcm@d56gv3areswl> References: <8ca730b9-fa8c-46ea-bdc5-158da0f29c3a@app.fastmail.com> <245d3985-9085-4be0-8c74-d95d06334584@app.fastmail.com> <3iksuovvsln3cw3xpmjd7f7xixfvwaneu4ok56fnookvyolpco@wrxxew3thgnq> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 1D758A001F X-Stat-Signature: f9o8yty5snaqywpartjp6stp5sp99t66 X-Rspam-User: X-HE-Tag: 1701171250-233269 X-HE-Meta: U2FsdGVkX19BgIRlHWqE01PWfJ5PVfciBKXrO9j9CAgxaE6vsLSvV4DPWUkqR1FP+xvcl5R6vV2ZvjRvbutI0YJxNjc9Dfm4iIlQ9brv8/6Zw0OQ0xB0sHrYiHVR4uMsgNNbI2E7EVca1raYVLxe3kV8CsGe+XTHV0RNlwK69ZZB4QBMgZPmskeBe57dA+1tcwp7tQUIpZzCyGa4/Ehm5ZPk8180WNEEdah2QCICBThVhTODfVQVOMdPZJTspe0V4STMgRzaawAaMtMrbNzZ0uYzD2hz21biW96raNlvgwxeFQODGaa4B0/gEAOsdNxRQui3A24yGv+RG+OUTZ68CSlwjxs83HNH5DTj+QlAgULGS8HoLnC1axHYHHYj5ObrOjaKl5xWPWn3vzZW0DcztOo14rmSrwvvZGY6J7MUi7mWmg/2tfBd/bXYNGiMx0gf+C08ciAV+/HOVsOSYgv7iC6Z2+uuVQspYBDB5777A+lxzW/7Inzura+yyxs07wbc1Mddr3eR4ZTeuI+h6hPrtaVkUJutRULsjVXQGgpgghgY9NYE+WPxMMqBKrhqF6CMfAggvSUf1kcibc7VeTnXMQCfO13OmtcpUjbn0TqXjlxECNhEuQLh2GShySi5DT2JgBbEqU4oe93WhPlp2jIs+r50x+OiXvTjYtEew91f5C+HiGD27TxWge1rZ7SI1A0FPslp/0e6w7kV0SQZ5/GFMiZkk6A5sw6nvDiJILu26d8hOOytIlN1M0ZABswDD1jw190+iY5O/oIk8tRTLupf1D60YeKOEoFVsfWzCqvwPNizeiACMFhaAkHpQ4S+TkGRaYhI+xDmvqlTwq/3sF3IjMXpaUnJcCi9JQm4bZtuMoqxDuVz4yraS1Snu7/vw992rv0nkuHfaXy17WJC2sRh5ADrJhfeGCbkHgDuf3KSb918relTu1rzSWyK60YHdNg5dSPvprmEaBUI4t7Gl3+ nJ6dEskR BeSm3RDnV+I9qxJy5xnxFIujSlsEX5kPaambjkUauBTGsePUnLnGbAMqZvQQ0aqiu36XT44t1nYM0jYKNp/GQJBT8fQZsId/mcKvR2OwlO/HG3urpes2veja1Fxf8z7LOAt2hLoSn7Zx2IuRnFzM1/t5WstohOu5p5isxt3VMr8OI6vFfYEgwF4B93rPgyP3WxnDURksc7FLi7qVE1uEPN3iklUgfd5DslRk64sF3KU4IbI1wrozPRHvnyslt2q42M5SN4jT0u2s0GDyz8KV/k1zeIL2fc/ewFTlcdvvFSj//trAlRzV32robkkYCGbWk6y3uG1zLO/ESrw+FogenW9Ho662kOnxnvKH4vAXpWKbEXWqIxq9TKW7zbawh6tpIVngZ1S1bxCTGUEZPHUGUg0VUKkIWaj/sPcSk3h0JliMj8Kk2lOBXoHxPv1KUny4yCO+stLcANOLfVDx1zXn0zoWOmlp3/CDehMe3R5LPQKfmRw0luMMuM4WkZA440t+D8rVAtg78CXA27t11vQzTt8NwbU6G0QQbBqBIikjJO8vKMNHgjVNbRL8vQQ== 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 Mon, Nov 27, 2023 at 09:08:11PM +0000, Jiaxun Yang wrote: > > > 在2023年11月27日十一月 下午4:23，Serge Semin写道： > [...] > >> I just made a quick grep in tree, and it seems like we don't have much > >> user of ioremap_cache (as well as ioremap_uc/wc) here so I think it is > >> a safe assumption. > > > > I wouldn't say there aren't much users. ioremap_wc() and it's > > devm-version is widely utilized in the GPU and network and some other > > subsystems. ioremap_cache() isn't widespread indeed. In anyway even a > > single user must be supported in safely calling the method if it's > > provided by the arch-code, otherwise the method could be considered as > > just a bogus stub to have the kernel successfully built. I bet you'll > > agree with that. But that's not the point in this case, > > > > A bit later you also noted: > > > > On Fri, Nov 24, 2023 at 10:34:49PM +0000, Jiaxun Yang wrote: > >> A nip, _page_cachable_default is set in cpu_cache_init() as well. We'd > >> better move it to cpu-probe.c, or give it a reasonable default value. > > > > Right. Thanks. To be honest I haven't noticed that before your > > message. _page_cachable_default is indeed initialized in the > > cpu_cache_init() method, several steps after it would be used in the > > framework of dmi_remap_early(). On the other hand ioremap_cache() is > > defined as ioremap_prot() with the _page_cachable_default variable > > passed. So my code will still correctly work unless > > _page_cachable_default is pre-initialized with something other than > > zero. On the other hand we can't easily change its default value > > because it will affect and likely break the r3k (CPU_R3000) and Octeon > > based platforms, because it's utilized to initialize the > > protection-map table. Of course we can fix the r3k_cache_init() and > > octeon_cache_init() methods too so they would get the > > _page_cachable_default variable back to zero, but it will also make > > things around it more complicated. > > > > Also note, moving the _page_cachable_default initialization to the > > earlier stages like cpu_probe() won't work better because the field > > value may get change for instance in the framework of the smp_setup() > > function (see cps_smp_setup()). > > > > So after all the considerations above this solution now looks even > > clumsier than before.( Any idea how to make it better? > > I think the best solution maybe just use CKSEG0 to setup map here. > > Btw I was thinking about 64 bit here, I thought for 64bit we would > just embedded prot into XKPHYS, however I quickly figure out > ioremap_cache was never implemented properly on 64-bit system, > so does ioremap_wc. > > > u64 base = (flags == _CACHE_UNCACHED ? IO_BASE : UNCAC_BASE); > > Which is always uncached mapping. Indeed. Thanks for pointing that out. In the last days several times I was looking at that line and for some reason UNCAC_BASE seemed as CAC_BASE to me.) Based on what both IO_BASE and UNCAC_BASE are defined as of the uncached region anyway, then it should be safe for any currently supported MIPS64 (including the Loongson's) to use ioremap() in place of dmi_early_remap(). So basically my current patch in the subject won't change the method semantics. Let's not to try to fix a problem which doesn't exist then, and keep the patch as is especially seeing that the alternatives might still cause some troubles. Will you be ok with that? -Serge(y) > > >> > [...] > > > > Note the memory might be clobbered even before dmi_setup() for > > instance by means of the early_memtest() method. In anyway it would be > > better if the system booloader would have already reserved the DMI > > memory (in DTB) or it would have been done by the platform-specific > > plat_mem_setup() method. > > Unfortunately, too many machines are shipped with those badly designed > firmware. We rely on dmi_setup code to scan and preserve dmi table from > random location in memory. > > > > >> The second is we may have some early quirks depends on DMI > >> information. > > > > Which quirks do you mean to be dependent in between the current > > dmi_setup() call place and the cpu_cache_init() method invocation? > > I think we don't have any for now. > > -- > - Jiaxun