Having cpu_data as a parameterless macro can easily cause build failures
because it can be a variable name like in linux/pm_domain.h [1]. So,
remove the macro and convert its only user. Because this architecture
cannot do SMP, remove the whole SMP block, too. Only compile tested due
to no hardware.
Signed-off-by: Wolfram Sang <[email protected]>
[1] https://lists.01.org/pipermail/kbuild-all/2014-February/003252.html
---
arch/avr32/include/asm/bugs.h | 2 +-
arch/avr32/include/asm/processor.h | 7 +------
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/avr32/include/asm/bugs.h b/arch/avr32/include/asm/bugs.h
index 7635e77..278661b 100644
--- a/arch/avr32/include/asm/bugs.h
+++ b/arch/avr32/include/asm/bugs.h
@@ -9,7 +9,7 @@
static void __init check_bugs(void)
{
- cpu_data->loops_per_jiffy = loops_per_jiffy;
+ boot_cpu_data.loops_per_jiffy = loops_per_jiffy;
}
#endif /* __ASM_AVR32_BUGS_H */
diff --git a/arch/avr32/include/asm/processor.h b/arch/avr32/include/asm/processor.h
index 48d71c5..972adcc 100644
--- a/arch/avr32/include/asm/processor.h
+++ b/arch/avr32/include/asm/processor.h
@@ -83,13 +83,8 @@ static inline unsigned int avr32_get_chip_revision(struct avr32_cpuinfo *cpu)
extern struct avr32_cpuinfo boot_cpu_data;
-#ifdef CONFIG_SMP
-extern struct avr32_cpuinfo cpu_data[];
-#define current_cpu_data cpu_data[smp_processor_id()]
-#else
-#define cpu_data (&boot_cpu_data)
+/* No SMP support so far */
#define current_cpu_data boot_cpu_data
-#endif
/* This decides where the kernel will search for a free chunk of vm
* space during mmap's
--
1.8.5.1
Around Sat 22 Feb 2014 09:28:27 +0100 or thereabout, Wolfram Sang wrote:
> Having cpu_data as a parameterless macro can easily cause build failures
> because it can be a variable name like in linux/pm_domain.h [1]. So,
> remove the macro and convert its only user. Because this architecture
> cannot do SMP, remove the whole SMP block, too. Only compile tested due
> to no hardware.
Looks sane, AVR32 doesn't support SMP, so this change should be fine.
> Signed-off-by: Wolfram Sang <[email protected]>
>
Acked-by: Hans-Christian Egtvedt <[email protected]>
> [1] https://lists.01.org/pipermail/kbuild-all/2014-February/003252.html
>
clockevents/3.15 branch, mens what you have queued up for 3.15?
I can queue this in my linux-next, and send Linus an early pull request the
moment 3.14 is released.
> ---
>
> arch/avr32/include/asm/bugs.h | 2 +-
> arch/avr32/include/asm/processor.h | 7 +------
> 2 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/arch/avr32/include/asm/bugs.h b/arch/avr32/include/asm/bugs.h
> index 7635e77..278661b 100644
> --- a/arch/avr32/include/asm/bugs.h
> +++ b/arch/avr32/include/asm/bugs.h
> @@ -9,7 +9,7 @@
>
> static void __init check_bugs(void)
> {
> - cpu_data->loops_per_jiffy = loops_per_jiffy;
> + boot_cpu_data.loops_per_jiffy = loops_per_jiffy;
> }
>
> #endif /* __ASM_AVR32_BUGS_H */
> diff --git a/arch/avr32/include/asm/processor.h b/arch/avr32/include/asm/processor.h
> index 48d71c5..972adcc 100644
> --- a/arch/avr32/include/asm/processor.h
> +++ b/arch/avr32/include/asm/processor.h
> @@ -83,13 +83,8 @@ static inline unsigned int avr32_get_chip_revision(struct avr32_cpuinfo *cpu)
>
> extern struct avr32_cpuinfo boot_cpu_data;
>
> -#ifdef CONFIG_SMP
> -extern struct avr32_cpuinfo cpu_data[];
> -#define current_cpu_data cpu_data[smp_processor_id()]
> -#else
> -#define cpu_data (&boot_cpu_data)
> +/* No SMP support so far */
> #define current_cpu_data boot_cpu_data
> -#endif
>
> /* This decides where the kernel will search for a free chunk of vm
> * space during mmap's
--
mvh
Hans-Christian Egtvedt
On Mon, Feb 24, 2014 at 08:28:20AM +0100, Hans-Christian Egtvedt wrote:
> Around Sat 22 Feb 2014 09:28:27 +0100 or thereabout, Wolfram Sang wrote:
> > Having cpu_data as a parameterless macro can easily cause build failures
> > because it can be a variable name like in linux/pm_domain.h [1]. So,
> > remove the macro and convert its only user. Because this architecture
> > cannot do SMP, remove the whole SMP block, too. Only compile tested due
> > to no hardware.
>
> Looks sane, AVR32 doesn't support SMP, so this change should be fine.
Great!
> > [1] https://lists.01.org/pipermail/kbuild-all/2014-February/003252.html
> >
>
> clockevents/3.15 branch, mens what you have queued up for 3.15?
Daniel has picked up changes from me for 3.15, yes. Because those
contain COMPILE_TEST this build failure was triggered.
> I can queue this in my linux-next, and send Linus an early pull request the
> moment 3.14 is released.
That would be the best solution IMO. Thanks!
All the best,
Wolfram
On Mon, Feb 24, 2014 at 08:28:20AM +0100, Hans-Christian Egtvedt wrote:
> Around Sat 22 Feb 2014 09:28:27 +0100 or thereabout, Wolfram Sang wrote:
> > Having cpu_data as a parameterless macro can easily cause build failures
> > because it can be a variable name like in linux/pm_domain.h [1]. So,
> > remove the macro and convert its only user. Because this architecture
> > cannot do SMP, remove the whole SMP block, too. Only compile tested due
> > to no hardware.
>
> Looks sane, AVR32 doesn't support SMP, so this change should be fine.
>
> > Signed-off-by: Wolfram Sang <[email protected]>
> >
>
> Acked-by: Hans-Christian Egtvedt <[email protected]>
>
> > [1] https://lists.01.org/pipermail/kbuild-all/2014-February/003252.html
> >
>
> clockevents/3.15 branch, mens what you have queued up for 3.15?
>
> I can queue this in my linux-next, and send Linus an early pull request the
> moment 3.14 is released.
Have you done this already? I can't find it, yet I see the pull request
for the clocks is already out.
Around Tue 01 Apr 2014 11:55:22 +0200 or thereabout, Wolfram Sang wrote:
> On Mon, Feb 24, 2014 at 08:28:20AM +0100, Hans-Christian Egtvedt wrote:
>> Around Sat 22 Feb 2014 09:28:27 +0100 or thereabout, Wolfram Sang wrote:
>> > Having cpu_data as a parameterless macro can easily cause build failures
>> > because it can be a variable name like in linux/pm_domain.h [1]. So,
>> > remove the macro and convert its only user. Because this architecture
>> > cannot do SMP, remove the whole SMP block, too. Only compile tested due
>> > to no hardware.
>>
>> Looks sane, AVR32 doesn't support SMP, so this change should be fine.
>>
>> > Signed-off-by: Wolfram Sang <[email protected]>
>> >
>>
>> Acked-by: Hans-Christian Egtvedt <[email protected]>
>>
>> > [1] https://lists.01.org/pipermail/kbuild-all/2014-February/003252.html
>> >
>>
>> clockevents/3.15 branch, mens what you have queued up for 3.15?
>>
>> I can queue this in my linux-next, and send Linus an early pull request the
>> moment 3.14 is released.
>
> Have you done this already? I can't find it, yet I see the pull request
> for the clocks is already out.
I sent a pull request to Torvalds some hours ago, the branch is available at
https://git.kernel.org/cgit/linux/kernel/git/egtvedt/linux-avr32.git/log/?h=for-linus
--
mvh
Hans-Christian Egtvedt
> I sent a pull request to Torvalds some hours ago, the branch is available at
> https://git.kernel.org/cgit/linux/kernel/git/egtvedt/linux-avr32.git/log/?h=for-linus
Thanks!