From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: YunQiang Su <wzssyqa@gmail.com>,
Tiezhu Yang <yangtiezhu@loongson.cn>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-mips <linux-mips@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Xuefeng Li <lixuefeng@loongson.cn>
Subject: Re: [PATCH] MIPS: Limit check_bugs32() under CONFIG_32BIT
Date: Thu, 9 Apr 2020 17:15:27 +0100 (BST) [thread overview]
Message-ID: <alpine.LFD.2.21.2004091704570.596385@eddie.linux-mips.org> (raw)
In-Reply-To: <7A98E39B-EDCF-496D-9525-0160A368361B@flygoat.com>
On Thu, 9 Apr 2020, Jiaxun Yang wrote:
> > Why is using Kconfig supposed to be better? Several configurations
> >support multiple processor types (e.g. swappable CPU daugthercards or
> >FPGA
> >soft-cores) and having to list CPU types across platforms as CPUs are
> >added is going to be a maintenance nightmare. Whereas having
> >workarounds
> >or panics associated with run-time determination of the actual CPU type
> >
> >guarantees they will trigger where necessary. The use of `init'
> >sections
> >assures the reclaim of memory for use after bootstrap.
>
> Actually I meant let bug checks depends on Kconfig's CPU selection.
>
> It's guaranteed that you can only select one kind of CPU one time,
> to prevent the overhead of checking bugs on irrelevant processors.
That makes no sense to me sorry. When you select say a MIPS32r2 CPU for
a Malta configuration, you can run it with a 4KE, 24K, 24KE, 34K, 74K,
1004K, M14K, and probably a few other CPUs I have forgotten about. Are
you suggesting now that you want to require a separate kernel
configuration for each of these CPUs?
> And we still have to check PRID/CPUTYPE during boot to enable
> proper workarounds, because the Kconfig options are telling about the possibility,
> which means a processor potentially has some kinds of bug.
>
> In this case, M34K's errata should depends on or selected by
> CPU_MIPS32_R2 in Kconfig.
>
> So there won't be any nightmare, but only reduced code :-)
You'll need to manually maintain CPU assignment to configurations, which
is not needed now.
Anyway, please show your patch to let us see any improvement brought by
it and we can discuss it then.
Maciej
next prev parent reply other threads:[~2020-04-09 16:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-09 3:10 [PATCH] MIPS: Limit check_bugs32() under CONFIG_32BIT Tiezhu Yang
2020-04-09 4:43 ` YunQiang Su
2020-04-09 7:09 ` Jiaxun Yang
2020-04-09 15:07 ` Maciej W. Rozycki
2020-04-09 15:47 ` Jiaxun Yang
2020-04-09 16:15 ` Maciej W. Rozycki [this message]
2020-04-09 20:48 ` Jiaxun Yang
2020-04-11 7:37 ` YunQiang Su
2020-04-11 10:38 ` Jiaxun Yang
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=alpine.LFD.2.21.2004091704570.596385@eddie.linux-mips.org \
--to=macro@linux-mips.org \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=lixuefeng@loongson.cn \
--cc=tsbogend@alpha.franken.de \
--cc=wzssyqa@gmail.com \
--cc=yangtiezhu@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