From: Konrad Eisele <konrad@gaisler.com>
To: sparclinux@vger.kernel.org
Subject: Re: [PATCH 7/7] sparc-leon specific SRMMU initialization and
Date: Thu, 11 Jun 2009 06:58:47 +0000 [thread overview]
Message-ID: <4A30ABD5.90801@gaisler.com> (raw)
In-Reply-To: <4A2E45EE.40007@gaisler.com>
>> enum mbus_module srmmu_modtype;
>> @@ -568,6 +572,11 @@ static void srmmu_switch_mm(struct mm_st
>> srmmu_ctxd_set(&srmmu_context_table[mm->context], mm->pgd);
>> }
>>
>> +#ifdef CONFIG_SPARC_LEON
>> + flush_tlb_mm(0);
>> + if (leon_flush_during_switch)
>> + leon_flush_cache_all();
>> +#endif
>> if (is_hypersparc)
>> hyper_flush_whole_icache();
>>
>
> Hmm... it would be nice to match the style of the statement after
> this, something like:
>
> if (is_leon) {
> flush_tlb_mm(0);
> if (leon_flush_during_switch)
> leon_flush_cache_all();
> }
>
> But that would mean that the leon_flush_during_switch and
> leon_flush_cache_all() would have to be defined for the non-SPARC_LEON
> case, which isn't what you're trying to do here, however if
> leon_flush_cache_all() is defined as a blank function, the compiler
> *should* optimise all this away.
>
I'm not shure what to do here. I wonder weather
if (is_leon) {
is better than a
#ifdef CONFIG_SPARC_LEON
it seems to me that the later is better.
It seems to me that in case of the former you have to have the
implicit knowledge that the compiler will optimize away the
function calls (and you have to search your way through the source
code to come to a conclusion that it will), and this is quite more
complex and disturbing than a #ifdef. I'd think #ifdef CONFIG_SPARC_LEON
is much cleaner.
Moreover it is not in line with the general strategy: to make leon-specific
parts be only compiled in when CONFIG_SPARC_LEON is defined. Then all leon_mm.c
and leon_kernel.c should also be compiled in always and protected with is_leon()
instead of only compiling it in the CONFIG_SPARC_LEON case...
But, hey, he, who checkes in, decides. Maybe Dave Miller can say how it should be.
-- Konrad
next prev parent reply other threads:[~2009-06-11 6:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-09 11:22 [PATCH 7/7] sparc-leon specific SRMMU initialization Konrad Eisele
2009-06-09 20:16 ` Sam Ravnborg
2009-06-10 10:24 ` [PATCH 7/7] sparc-leon specific SRMMU initialization and konrad
2009-06-10 23:54 ` Julian Calaby
2009-06-11 6:58 ` Konrad Eisele [this message]
2009-06-11 7:36 ` Julian Calaby
2009-06-11 7:50 ` Konrad Eisele
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=4A30ABD5.90801@gaisler.com \
--to=konrad@gaisler.com \
--cc=sparclinux@vger.kernel.org \
/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.