[PATCH] ARM: Re-enable TRACE_IRQFLAGS_SUPPORT on ARMv7-M

[Maxime Coquelin]

2015-06-09 0:47 GMT+02:00 Russell King - ARM Linux <linux at arm.linux.org.uk>:
> On Tue, Jun 09, 2015 at 12:24:48AM +0200, Maxime Coquelin wrote:
>> Commit cb1293e2f594 ("ARM: 8375/1: disable some options on ARMv7-M") causes
>> build failure on ARMv7-M machines:
>>
>>   CC      arch/arm/kernel/asm-offsets.s
>> In file included from include/linux/sem.h:5:0,
>>                  from include/linux/sched.h:35,
>>                  from arch/arm/kernel/asm-offsets.c:14:
>> include/linux/rcupdate.h: In function 'rcu_read_lock_sched_held':
>> include/linux/rcupdate.h:539:2: error: implicit declaration of function 'arch_irqs_disabled' [-Werror=implicit-function-declaration]
>>   return preempt_count() != 0 || irqs_disabled();
>>   ^
>
> The real solution is to provide a definition _in asm-generic_ for
> arch_irqs_disabled(), rather than having almost every arch doing:
>
> static inline bool arch_irqs_disabled(void)
> {
>         return arch_irqs_disabled_flags(arch_local_save_flags());
> }
>
> I'm personally refusing to take a patch for ARM which adds yet another
> copy of the above.  This is, after all, exactly the kind of stuff that
> should be in asm-generic, or if not, in include/linux but overridable
> by arch stuff.
>
> We keep going between the two extremes of "lets push lots of stuff into
> arch stuff" and "lets try to extract the common bits out of arch code".
>
> Let's try and settle on one approach, and apply it universally.

I agree on the idea but I don't measure all the impacts it would have.

>
> In the mean time, I think the right answer is to drop Arnd's patch -
> subsituting a randconfig build error for a useful-config build error
> is not something we want to do - and even partially reverting the
> patch results in randconfig build errors returning, so...

Ok, should I send a revert, or you can still drop Arnd's patch directly?

Thanks,
Maxime