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 67A5BC4167B for ; Mon, 27 Nov 2023 21:08:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D53A66B02C9; Mon, 27 Nov 2023 16:08:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D037B6B02DB; Mon, 27 Nov 2023 16:08:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7C4E6B02E5; Mon, 27 Nov 2023 16:08:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A53456B02C9 for ; Mon, 27 Nov 2023 16:08:57 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8012F16083F for ; Mon, 27 Nov 2023 21:08:57 +0000 (UTC) X-FDA: 81504973914.05.594C112 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by imf17.hostedemail.com (Postfix) with ESMTP id 3FECF4000C for ; Mon, 27 Nov 2023 21:08:55 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=flygoat.com header.s=fm2 header.b=OqM1Ivhy; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=oMtl2vfZ; dmarc=pass (policy=none) header.from=flygoat.com; spf=pass (imf17.hostedemail.com: domain of jiaxun.yang@flygoat.com designates 66.111.4.27 as permitted sender) smtp.mailfrom=jiaxun.yang@flygoat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701119335; 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=O7eAZBa/VWWZ/OXR3VR79aB+uaJ9c4U23L/jIs+R/4I=; b=QGfv588UKEvlvHAGDyy31Bi72F/Ou27DAzdwJOyKV9ccBQcArU8WTvczlmAYBgYO/LULab OfJ6ues29oPJuUwCpoO0VNf61YfPIHTW/zN/bX5Vo9BchvlDDyrqH8i9JLj9EekPx0k2dn lhbclz+Pz1TojVIdYeJV5OyvcCxoHjs= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=flygoat.com header.s=fm2 header.b=OqM1Ivhy; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=oMtl2vfZ; dmarc=pass (policy=none) header.from=flygoat.com; spf=pass (imf17.hostedemail.com: domain of jiaxun.yang@flygoat.com designates 66.111.4.27 as permitted sender) smtp.mailfrom=jiaxun.yang@flygoat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701119335; a=rsa-sha256; cv=none; b=gV5gWVKDGVkWzx5fnMgTXqs1ijCE18mCWQzeQZ+fUwLBG672j1Qp79tUADkC5InXJJQnOM 6qJu8CVbZsnXYhUOb64CEEpL2s48cBuVNugtg2SUifNIe2jEcN5/CjPcoffmew0Qqj0m2e 90u+4i/GsC5HULYbvs+eTS2Qu8hhFEo= Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6F5F35C004E; Mon, 27 Nov 2023 16:08:54 -0500 (EST) Received: from imap44 ([10.202.2.94]) by compute3.internal (MEProxy); Mon, 27 Nov 2023 16:08:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flygoat.com; h= cc: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:sender:subject:subject:to:to; s=fm2; t= 1701119334; x=1701205734; bh=O7eAZBa/VWWZ/OXR3VR79aB+uaJ9c4U23L/ jIs+R/4I=; b=OqM1IvhywGfmb7/kGPg8aPxMlu17gR4i5CH9/cqoelecohlYpCR /c1Og9aPbItY0RcGuLHayz3h1Mmo51jLTPjledQBGtv7CLQBdtOywUqY3ebesdjh w/KgFo9dTiMaWYN65I0ofo05JauvgXGn59f0x6BjzkONfKGyBzpoP6Owy4rButba YVA2NRJuSEI+ePvSTkdk4V3idMP6d5l57axFknSG3n+MRxRmc87fsZGMrocrGevy /MeOyX413+ioZH7CnQns3dUBQU3yBOoOltb1i1Bs48iNWsKwZ5C/U8Hijrfe7CMb C4yY9q8rs0vcpj0rd2e2wARn3LeaEBpgmgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1701119334; x=1701205734; bh=O7eAZBa/VWWZ/OXR3VR79aB+uaJ9c4U23L/ jIs+R/4I=; b=oMtl2vfZKze5RZUv5gkgqJtSL34cqE0nGLzcTGh1dlkFMyNcSYs Bps/C/1fM/uMFwg+7atKxp9YinmkIQnzIQ5L29wxAxcacsEwETBDMiC+7amaMbXT PceJaJx609MSuf4COEB7azsvh2zagVy0aAxxbTd5fEDm+SsxdCnuiukTrLAIc5Hn jnQBi7Pnnqoc6nOi1St+ZKNFQ5wg0gZ3nvuguKV/5wG25Vy5TtwQEmhCCO3Zz+Pl J/0YHmxFPThmKOyyza8A75mNqp2TMRHiaRXfmdOKg6SydW+V9YjkKHvYmaEsR516 lZMKyhcGMuVTBXXq6C7CIE+DsQiVzHXmL7w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeiuddgudegjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgfgsehtqhertderreejnecuhfhrohhmpedf lfhirgiguhhnucgjrghnghdfuceojhhirgiguhhnrdihrghnghesfhhlhihgohgrthdrtg homheqnecuggftrfgrthhtvghrnhepudefgeeftedugeehffdtheefgfevffelfefghefh jeeugeevtefhudduvdeihefgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepjhhirgiguhhnrdihrghnghesfhhlhihgohgrthdrtghomh X-ME-Proxy: Feedback-ID: ifd894703:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 14CA836A0075; Mon, 27 Nov 2023 16:08:53 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1234-gac66594aae-fm-20231122.001-gac66594a MIME-Version: 1.0 Message-Id: In-Reply-To: References: <20231122182419.30633-2-fancer.lancer@gmail.com> <8ca730b9-fa8c-46ea-bdc5-158da0f29c3a@app.fastmail.com> <245d3985-9085-4be0-8c74-d95d06334584@app.fastmail.com> <3iksuovvsln3cw3xpmjd7f7xixfvwaneu4ok56fnookvyolpco@wrxxew3thgnq> Date: Mon, 27 Nov 2023 21:08:11 +0000 From: "Jiaxun Yang" To: "Serge Semin" 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 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 3FECF4000C X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 9uy8gstxaum91far5cmdoei1whzjkzpq X-HE-Tag: 1701119335-389091 X-HE-Meta: U2FsdGVkX18yXKpcqg0LbxbZF55Q27d4iQk4CrYufRY5SKseuFwVlhag++PcE5RTHk4tfDqwoi7fy8zVDueaTEezJ0vblYtaZjeUlg2IlQvxydOS003snJTUigvwuwMVkB0rcNVQAauwm0AjPt5DjLVs1CvkGgDvM2vg+SB3vHWCZD3JPPxty1+GNDAxxOztFsZN+VHwQLj+5eJERMzWeyzdOmxvq6ZsIzHiRrmuEuLRJGtdSX4lOCtW6ahT3Dkb46A7+weCmJ5CyMDvHspPedhacnkHg76t1m/lTldFInFiulXeoTquw02oPMiRmODNSfP+k36kzjNc12dpIR3Deqv4otrrXgIkcqqLWXjT0S7iaatEjis8WHWjf2StCy7294BqrXhh7jtDhp4EyqgmoAFGZc+zKQR95ApGqh8AZ1cNR1mQP59M1gxmvD5MyL3OkWac7+wvMn9RYbtJP3h01714PZgZCg8ZvHtXPhKcGIiF5UF3y8y40e0rN2u8WZJ0+bZiQaUuLdXDaElLXZ+M7o9Bx7LkLOt6PNE9zwjIMDWTL8Dw21DecVXNA6TCNMzxEdPeBPAmmF9V1Q88FW6mtv3BZ0wjBk6VGeUaWdlLVPloScxqnOP7wPKLJpo/KUrNiw6UbdqF2bPzg9E7pufkWTAJyYaGdwK22YATJx0aXVSt8PVaRZTzjqVHC0V8vwKkHZ+Y0GkQRMV1D5vFL23bXq57feDXSjbA8ORQfF2OHv56OJm0Hlyy/fTjbUK3W74v7Kf2CGVUIef8tW5+RK5OB0dWdzEC61GTyNJ3cHbcXtvFYBilLk0o88JeIGBsoipqA8iO08FbhkBL0Y9l3B0Woej8TBx9mgTkAUbFlLxRXTnsZ//0JmUywlAwx286av7yJ8jOvarOtn541XeuC3BJiGKvHbQleqA4Nf7ytnJRke/B3ZGkublDyOjKaCL5Wnu7ypKU3aMd9LD5c5TaEbe w5ZcwcLw suOUY6J7+KqV9s/VtkIFm2weOU7MP4LFOcoUG8J6XYFJ25ygraPcGhdkkZoP+eu5/yPOwe85mkGM60C1Te2EFCPL+XbQ7mafBCm/74ELR3QVlGT8i2jfgHlQHdW2snCFrDtRbv4DSmoPGwLpwP5rJwkh6skBSxrjqkteDctpU9hOPS8iKDfPw3EwPzYSsoV3+vtkL/IPovCNLkwjw2656fZ5T3YgQ5lVZO62e1hiy+zdKjn7Mw92nCpVka6aEF2sZuYHF4yW8YWfTAjl33Q0iTlGXwpRqV+tFpZsc9me0e1+1vJGV4PmZelOt/8KgpdVQCrIcBUG+LAGNWfNHu6fa0eiuuQ== 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: =E5=9C=A82023=E5=B9=B411=E6=9C=8827=E6=97=A5=E5=8D=81=E4=B8=80=E6=9C=88 = =E4=B8=8B=E5=8D=884:23=EF=BC=8CSerge Semin=E5=86=99=E9=81=93=EF=BC=9A [...] >> 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 =3D (flags =3D=3D _CACHE_UNCACHED ? IO_BASE : UNCAC_BASE); Which is always uncached mapping. >>=20 [...] > > 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. --=20 - Jiaxun