From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Tiezhu Yang <yangtiezhu@loongson.cn>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
Xuefeng Li <lixuefeng@loongson.cn>
Subject: Re: [PATCH v2] MIPS: Limit check_bugs32() to affected platform
Date: Wed, 15 Apr 2020 10:31:18 +0200 [thread overview]
Message-ID: <20200415083117.GA3125@alpha.franken.de> (raw)
In-Reply-To: <5e575f15-4efc-7bf7-e266-d01aca094bbc@loongson.cn>
On Wed, Apr 15, 2020 at 09:48:30AM +0800, Tiezhu Yang wrote:
> On 04/15/2020 01:32 AM, Thomas Bogendoerfer wrote:
> >On Sat, Apr 11, 2020 at 10:32:02AM +0800, Tiezhu Yang wrote:
> >>On 04/11/2020 12:25 AM, Florian Fainelli wrote:
> >>>On 4/9/2020 8:20 PM, Tiezhu Yang wrote:
> >>>>In the current code, check_bugs32() only handles MIPS32 CPU type CPU_34K,
> >>>>it is better to build and call it on the affected platform.
> >>>>
> >>>>Move check_bugs32() to the new added 34k-bugs32.c to indicate the fact that
> >>>>the code is specific to the 34k CPU, and also add CONFIG_CPU_34K_BUGS32 to
> >>>>control whether or not check the bugs.
> >>>>
> >>>>Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> >>>This is not a whole lot of code, so moving this to a separate
> >>>translation unit seems a bit heavy handed, also file renames, albeit
> >>>tracked properly by git are always a challenge when doing back ports.
> >>Hi Florian,
> >>
> >>There exists the following three ways to do it, I'm fine either way,
> >>maybe the first way looks better. Let us wait for the MIPS maintainer
> >>to say what he prefer.
> >>
> >>Hi Thomas,
> >>
> >>What is your opinion?
> >I don't see a reason for doing that at all. The 34K workaround is only
> >compiled in if CONFIG_SYS_HAS_CPU_MIPS32_R2 is defined.
>
> Hi Thomas,
>
> Thanks for your reply. My initial thought is to build and call check_bugs32() only for 34K CPU,
> because it is useless for other CPU types.
>
> Do you mean to use the following modification?
no, IMHO we don't need to change anything here. There is not much to save
here.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
prev parent reply other threads:[~2020-04-15 8:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-10 3:20 [PATCH v2] MIPS: Limit check_bugs32() to affected platform Tiezhu Yang
2020-04-10 4:18 ` Jiaxun Yang
2020-04-10 8:36 ` Jiaxun Yang
2020-04-10 16:25 ` Florian Fainelli
2020-04-11 2:32 ` Tiezhu Yang
2020-04-14 17:32 ` Thomas Bogendoerfer
2020-04-15 1:48 ` Tiezhu Yang
2020-04-15 8:31 ` Thomas Bogendoerfer [this message]
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=20200415083117.GA3125@alpha.franken.de \
--to=tsbogend@alpha.franken.de \
--cc=f.fainelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=lixuefeng@loongson.cn \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.