From: Serge Semin <fancer.lancer@gmail.com>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Tiezhu Yang <yangtiezhu@loongson.cn>,
Huacai Chen <chenhuacai@kernel.org>,
Yinglu Yang <yangyinglu@loongson.cn>
Cc: Serge Semin <fancer.lancer@gmail.com>,
Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
Arnd Bergmann <arnd@arndb.de>,
Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>,
Aleksandar Rikalo <arikalo@gmail.com>,
Dragan Mladjenovic <dragan.mladjenovic@syrmia.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Baoquan He <bhe@redhat.com>, Chao-ying Fu <cfu@wavecomp.com>,
Mike Rapoport <rppt@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Marc Zyngier <maz@kernel.org>,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v2 1/6] mips: dmi: Fix early remap on MIPS32
Date: Sat, 2 Dec 2023 14:14:18 +0300 [thread overview]
Message-ID: <20231202111430.18059-2-fancer.lancer@gmail.com> (raw)
In-Reply-To: <20231202111430.18059-1-fancer.lancer@gmail.com>
dmi_early_remap() has been defined as ioremap_cache() which on MIPS32 gets
to be converted to the VM-based mapping. DMI early remapping is performed
at the setup_arch() stage with no VM available. So calling the
dmi_early_remap() for MIPS32 causes the system to crash at the early boot
time. Fix that by converting dmi_early_remap() to the uncached remapping
which is always available on both 32 and 64-bits MIPS systems.
Note this change shall not cause any regressions on the current DMI
support implementation because on the early boot-up stage neither MIPS32
nor MIPS64 has the cacheable ioremapping support anyway.
Fixes: be8fa1cb444c ("MIPS: Add support for Desktop Management Interface (DMI)")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
---
Note even though this patch is fully correct from the current
ioremap()-based semantics point of view and shall fix the denoted problem,
Jiaxun thinks that it's better to provide a different fix since
dmi_early_remap() doesn't work correctly on even Loongson64 - the only
currently DMI-equipped platform. In v1 discussion he promised to provide a
better fix for the problem. Until then let's consider this patch as the
only currently available solution.
Changelog v2:
- Replace ioremap_uc() with using ioremap() due to having the former one
deprecated. (@Arnd)
- Extend patch log with a note regarding the unsynched caches concern.
(@Jiaxun)
---
arch/mips/include/asm/dmi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/dmi.h b/arch/mips/include/asm/dmi.h
index 27415a288adf..dc397f630c66 100644
--- a/arch/mips/include/asm/dmi.h
+++ b/arch/mips/include/asm/dmi.h
@@ -5,7 +5,7 @@
#include <linux/io.h>
#include <linux/memblock.h>
-#define dmi_early_remap(x, l) ioremap_cache(x, l)
+#define dmi_early_remap(x, l) ioremap(x, l)
#define dmi_early_unmap(x, l) iounmap(x)
#define dmi_remap(x, l) ioremap_cache(x, l)
#define dmi_unmap(x) iounmap(x)
--
2.42.1
next prev parent reply other threads:[~2023-12-02 11:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-02 11:14 [PATCH v2 0/6] MIPS: mm: Fix some memory-related issues Serge Semin
2023-12-02 11:14 ` Serge Semin [this message]
2023-12-02 11:14 ` [PATCH v2 2/6] mips: Fix incorrect max_low_pfn adjustment Serge Semin
2023-12-02 11:14 ` [PATCH v2 3/6] mips: Fix max_mapnr being uninitialized on early stages Serge Semin
2023-12-02 11:14 ` [PATCH v2 4/6] mips: Optimize max_mapnr init procedure Serge Semin
2023-12-02 11:14 ` [PATCH v2 5/6] mips: mm: add slab availability checking in ioremap_prot Serge Semin
2023-12-02 11:14 ` [PATCH v2 6/6] mips: Set dump-stack arch description Serge Semin
2023-12-21 14:38 ` [PATCH v2 0/6] MIPS: mm: Fix some memory-related issues Thomas Bogendoerfer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231202111430.18059-2-fancer.lancer@gmail.com \
--to=fancer.lancer@gmail.com \
--cc=Alexey.Malahov@baikalelectronics.ru \
--cc=akpm@linux-foundation.org \
--cc=aleksandar.rikalo@syrmia.com \
--cc=arikalo@gmail.com \
--cc=arnd@arndb.de \
--cc=bhe@redhat.com \
--cc=cfu@wavecomp.com \
--cc=chenhuacai@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dragan.mladjenovic@syrmia.com \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maz@kernel.org \
--cc=rppt@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=willy@infradead.org \
--cc=yangtiezhu@loongson.cn \
--cc=yangyinglu@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).