public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: linux-kernel@vger.kernel.org,
	Rusty Russell <rusty@rustcorp.com.au>,
	Ralf Baechle <ralf@linux-mips.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	linux-mips@linux-mips.org
Subject: Re: mips build failures due to commit 8dd928915a73 (mips: fix up obsolete cpu function usage)
Date: Mon, 20 Apr 2015 21:11:00 -0700	[thread overview]
Message-ID: <5535CDD4.8090900@roeck-us.net> (raw)
In-Reply-To: <20150420210933.GB31618@fuloong-minipc.musicnaut.iki.fi>

On 04/20/2015 02:09 PM, Aaro Koskinen wrote:
> Hi,
>
> On Mon, Apr 20, 2015 at 12:40:28PM -0700, Guenter Roeck wrote:
>> the upstream kernel fails to build mips:nlm_xlp_defconfig,
>> mips:nlm_xlp_defconfig, mips:cavium_octeon_defconfig, and possibly
>> other targets, with errors such as
>>
>> arch/mips/kernel/smp.c:211:2: error:
>> 	passing argument 2 of 'cpumask_set_cpu' discards 'volatile' qualifier
>> 	from pointer target type
>> arch/mips/kernel/process.c:52:2: error:
>> 	passing argument 2 of 'cpumask_test_cpu' discards 'volatile' qualifier
>> 	from pointer target type
>> arch/mips/cavium-octeon/smp.c:242:2: error:
>> 	passing argument 2 of 'cpumask_clear_cpu' discards 'volatile' qualifier
>> 	from pointer target type
>>
>> The problem was introduced with commit 8dd928915a73 (" mips: fix up
>> obsolete cpu function usage"). I would send a patch to fix it, but I
>> am not sure if removing 'volatile' from the variable declaration(s)
>> would be a good idea.
>
> I think removing volatile from cpu_callin_map declaration should be OK,
> since test_cpu (only reader) uses test_bit which takes care of it:
>
> 	static inline int test_bit(int nr, const volatile unsigned long *addr)
>

I ran two tests with nlm_xlp_defconfig:

- add volatile to the second argument of cpumask_set_cpu() and cpumask_test_cpu():
   vmlinux image size 194664946
- remove volatile from cpu_callin_map:
   vmlinux image size 194664066

Given that, I am not sure I understand the impact of removing volatile
from cpu_callin_map. Maybe it is just better optimization without
volatile. Maybe there is no impact. Maybe the use of volatile is wrong
to start with ('Volatile Considered Harmful' comes into mind).
Maybe the use of volatile for cpu_callin_map is wrong for other architectures
as well (powerpc, ia64). Either case, I don't know to code well enough to
make this call.

Guenter


  reply	other threads:[~2015-04-21  4:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-20 19:40 mips build failures due to commit 8dd928915a73 (mips: fix up obsolete cpu function usage) Guenter Roeck
2015-04-20 20:06 ` Ralf Baechle
2015-04-20 20:19   ` Guenter Roeck
2015-04-20 21:09 ` Aaro Koskinen
2015-04-21  4:11   ` Guenter Roeck [this message]
2015-04-21  4:15   ` Rusty Russell
2015-04-21 15:41     ` Guenter Roeck
2015-04-22  2:59       ` Florian Fainelli
2015-04-27 13:03       ` Aaro Koskinen
2015-04-27 13:44         ` Paul Martin

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=5535CDD4.8090900@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=aaro.koskinen@iki.fi \
    --cc=f.fainelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=rusty@rustcorp.com.au \
    /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