[PATCH 09/19] mfd/twl4030: don't warn about uninitialized return code

[PATCH 09/19] mfd/twl4030: don't warn about uninitialized return code

[Arnd Bergmann]

On Friday 25 January 2013 15:25:03 Peter Ujfalusi wrote:
> On 01/25/2013 03:14 PM, Arnd Bergmann wrote:
> > If the twl4030_write_script function gets called with
> > a zero length argument, its return value does not
> > get set. We know that all scripts have a nonzero
> > length, but returning an error in case they ever
> > do is probably appropriate.
> > 
> > Without this patch, building omap2plus_defconfig results in:
> > 
> > drivers/mfd/twl4030-power.c: In function 'load_twl4030_script':
> > drivers/mfd/twl4030-power.c:414:5: error: 'err' may be used uninitialized in this function
> 
> I've fixed up Kevin's email since he is no longer with TI and added Tero to
> the CC list since this is *something*-power on OMAP platforms 
> 
> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

Thanks!

I also got the mailing list address wrong on all mails, so I'll
retransmit the whole series in a bit, just waiting for other
quick comments to come in.

	Arnd

[PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263

[Arnd Bergmann]

On Friday 25 January 2013 16:42:19 Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:14 Fri 25 Jan     , Arnd Bergmann wrote:
> > For the past three years, we have had a #warning in
> > mach-at91 about the sdram_selfrefresh_enable or
> > at91sam9_standby functions possibly not working on
> > at91sam9263. In the meantime a function was added
> > to do the right thing on at91sam9g45, which looks like
> > it should also work on '9263.
> > 
> > This patch blindly removes the warning and changes the
> > at91sam9263 to use the same code at at91sam9g45, which
> > may or may not be the right solution. If it is not,
> > maybe someone could provide a better fix.
> it's not
> 
> the 9g45 use DDR Controler where the 9263 use a SDRAM controler
> 

Ah, right. What about this one then?

	Arnd
	
8<-----
Subject: [PATCH] ARM: at91: suspend both memory controllers on at91sam9263

For the past three years, we have had a #warning in
mach-at91 about the sdram_selfrefresh_enable or
at91sam9_standby functions possibly not working on
at91sam9263. In the meantime a function was added
to do the right thing on at91sam9g45, which looks like
it should also work on '9263.

This patch blindly removes the warning and changes the
at91sam9263 to use the same code at at91sam9g45, which
may or may not be the right solution. If it is not,
maybe someone could provide a better fix.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0c63815..4c67946 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -38,6 +38,8 @@ static int at91_enter_idle(struct cpuidle_device *dev,
 		at91rm9200_standby();
 	else if (cpu_is_at91sam9g45())
 		at91sam9g45_standby();
+	else if (cpu_is_at91sam9263())
+		at91sam9263_standby();
 	else
 		at91sam9_standby();
 
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index adb6db8..b8017c1 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -267,6 +267,8 @@ static int at91_pm_enter(suspend_state_t state)
 				at91rm9200_standby();
 			else if (cpu_is_at91sam9g45())
 				at91sam9g45_standby();
+			else if (cpu_is_at91sam9263())
+				at91sam9263_standby();
 			else
 				at91sam9_standby();
 			break;
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 38f467c..2f5908f 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -70,13 +70,31 @@ static inline void at91sam9g45_standby(void)
 	at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
 }
 
-#ifdef CONFIG_SOC_AT91SAM9263
-/*
- * FIXME either or both the SDRAM controllers (EB0, EB1) might be in use;
- * handle those cases both here and in the Suspend-To-RAM support.
+/* We manage both DDRAM/SDRAM controllers, we need more than one value to
+ * remember.
  */
-#warning Assuming EB1 SDRAM controller is *NOT* used
-#endif
+static inline void at91sam9263_standby(void)
+{
+	u32 lpr0, lpr1;
+	u32 saved_lpr0, saved_lpr1;
+
+	saved_lpr1 = at91_ramc_read(1, AT91_SDRAMC_LPR);
+	lpr1 = saved_lpr1 & ~AT91_SDRAMC_LPCB;
+	lpr1 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
+
+	saved_lpr0 = at91_ramc_read(0, AT91_SDRAMC_LPR);
+	lpr0 = saved_lpr0 & ~AT91_SDRAMC_LPCB;
+	lpr0 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
+
+	/* self-refresh mode now */
+	at91_ramc_write(0, AT91_SDRAMC_LPR, lpr0);
+	at91_ramc_write(1, AT91_SDRAMC_LPR, lpr1);
+
+	cpu_do_idle();
+
+	at91_ramc_write(0, AT91_SDRAMC_LPR, saved_lpr0);
+	at91_ramc_write(1, AT91_SDRAMC_LPR, saved_lpr1);
+}
 
 static inline void at91sam9_standby(void)
 {

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Dave Martin]

On Fri, Jan 25, 2013 at 11:44:14AM -0500, Steven Rostedt wrote:
> [ I got an error with linux-arm-kernel at list.infradead.org and had to
> remove from CC ]

Blame Arnd :)

> 
> On Fri, 2013-01-25 at 16:26 +0000, Dave Martin wrote:
> 
> > However, if the purpose if making return_address() notrace is just to
> > prevent infinite recursion, where finite recursion is safe, then it
> > feels fixable as described above.
> > 
> > Steven, do you know whether such an approach might be safe?
> > 
> 
> I rewrote the function trace recursion code (see linux-next). The
> function tracer wont recurse on itself. If the return_address() is only
> used by callbacks and not directly by the mcount(ftrace_caller), then
> after the first trace, ftrace wont let recursion of the callback. IOW,
> callbacks of ftrace don't need to worry about re-entrancy at the same
> context level (but do for different contexts, ie. normal, irq, softirq
> and NMI).
> 
> (commit edc15cafcbfa3d73f819cae99885a2e35e4cbce5 in linux-next and
> friends)

Cool.  Are you aware of return_address being used elsewhere?  Currently
I'm not aware of anything else which uses it, and grep is not finding
any calls outside ftrace.h that I can see.

Cheers
---Dave

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Steven Rostedt]

On Fri, 2013-01-25 at 16:59 +0000, Dave Martin wrote:

> Cool.  Are you aware of return_address being used elsewhere?  Currently
> I'm not aware of anything else which uses it, and grep is not finding
> any calls outside ftrace.h that I can see.

softirq.c has a trace_preempt_off() use of CALLER_ADDR1.

kernel/sched/core.c has CALLER_ADDR1, 2 an 3.

-- Steve

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Dave Martin]

On Fri, Jan 25, 2013 at 12:08:23PM -0500, Steven Rostedt wrote:
> On Fri, 2013-01-25 at 16:59 +0000, Dave Martin wrote:
> 
> > Cool.  Are you aware of return_address being used elsewhere?  Currently
> > I'm not aware of anything else which uses it, and grep is not finding
> > any calls outside ftrace.h that I can see.
> 
> softirq.c has a trace_preempt_off() use of CALLER_ADDR1.
> 
> kernel/sched/core.c has CALLER_ADDR1, 2 an 3.

These cases look safe to me ... sched/core.c:get_parent_ip() looks like
it uses notrace purely to avoid the spurious extra frame which it would
otherwise insert, and the code in softirq.c doesn't appear to be in a
notrace context.

Am I being too optimistic, or does that match your understanding?

Cheers
---Dave

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Arnd Bergmann]

On Friday 25 January 2013, Dave Martin wrote:
> On Fri, Jan 25, 2013 at 11:44:14AM -0500, Steven Rostedt wrote:
> > [ I got an error with linux-arm-kernel at list.infradead.org and had to
> > remove from CC ]
> 
> Blame Arnd :)
>

Sorry about that, I now posted the entire series again with the right
mailing list address.

	ARnd

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Keun-O Park]

Hello guys,

Could you please review the patch of fixing bug first of returning
wrong address when using frame pointer?
I am wondering if the first patch is not delivered to the mailing.

~~~~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~~~~~~~~
>From 3a60b536d22a2043d735c890a9aac9e7cb72de8f Mon Sep 17 00:00:00 2001
From: sahara <keun-o.park@windriver.com>
Date: Thu, 3 Jan 2013 17:12:37 +0900
Subject: [PATCH 1/2] arm: fix returning wrong CALLER_ADDRx

This makes return_address return correct value for ftrace feature.
unwind_frame does not update frame->lr but frame->pc for backtrace.
And, the initialization for data.addr was missing so that wrong value
returned when unwind_frame failed.

Signed-off-by: sahara <keun-o.park@windriver.com>
---
 arch/arm/kernel/return_address.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
index 8085417..fafedd8 100644
--- a/arch/arm/kernel/return_address.c
+++ b/arch/arm/kernel/return_address.c
@@ -26,7 +26,7 @@ static int save_return_addr(struct stackframe *frame, void *d)
        struct return_address_data *data = d;

        if (!data->level) {
-               data->addr = (void *)frame->lr;
+               data->addr = (void *)frame->pc;

                return 1;
        } else {
@@ -41,7 +41,8 @@ void *return_address(unsigned int level)
        struct stackframe frame;
        register unsigned long current_sp asm ("sp");

-       data.level = level + 1;
+       data.level = level + 2;
+       data.addr = NULL;

        frame.fp = (unsigned long)__builtin_frame_address(0);
        frame.sp = current_sp;
-- 
1.7.1
~~~~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~~~~~~~~

Without this patch, when I added the following printk line and did
sync command,
it returned wrong return addresses using frame pointer.

Added line in __bdi_start_writeback():
+ printk("TEST: CALLER_ADDR0=(%pS), CALLER_ADDR1=(%pS),
CALLER_ADDR2=(%pS)\n", (void *)CALLER_ADDR0, (void *)CALLER_ADDR1,
(void *)CALLER_ADDR2);

Call sequence:
sys_sync() -> wakeup_flusher_threads() -> __bdi_start_writeback()

Result of sync after boot up:
~ # sync
TEST: CALLER_ADDR0=(wakeup_flusher_threads+0x9c/0xb8),
CALLER_ADDR1=(__bdi_start_writeback+0x30/0x120),
CALLER_ADDR2=(__bdi_start_writeback+0x3c/0x120)

As you see, the result of CALLER_ADDR1 and CALLER_ADDR2 is wrong.

With this patch, you will be able to see the following result.
~ # sync
TEST: CALLER_ADDR0=(wakeup_flusher_threads+0x9c/0xb8),
CALLER_ADDR1=(sys_sync+0x34/0xac),
CALLER_ADDR2=(ret_fast_syscall+0x0/0x48)

Based on this patch, if you apply the second patch which enables the
arm unwind,
and turning on CONFIG_ARM_UNWIND, you will see the correct result.

What I am currently concerning is if I use unwind info and ftrace's irqsoff,
I presume the ftrace might need architecture specific function to make
irqsoff work correctly.
For example, when I tried to test irqsoff, I got the message from
trace like the following.

     cat-563     0d...    2us+: __irq_svc <-_raw_spin_unlock_irqrestore

Actually I could see the call sequence from the end of the trace.
~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~
 => gic_handle_irq
 => __irq_svc
 => _raw_spin_unlock_irqrestore
 => uart_start
 => uart_write
~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~
Seeing this call sequences, the output need to be
'_raw_spin_unlock_irqrestore <- uart_start'.
But, the CALLER_ADDR1 in trace_hardirqs_off() returned correct value.
So there's no problem in output.
I think trace_hardirqs_off() should call CALLER_ADDR1 and CALLER_ADDR2
respectively for its arguments for start_critical_timing(). This
thought leads me to the necessity of creating architecture specific
trace_hardirqs_off function. Any opinion on this?

-- kpark

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Dave Martin]

On Mon, Jan 28, 2013 at 11:33:11AM +0900, Keun-O Park wrote:
> Hello guys,
> 
> Could you please review the patch of fixing bug first of returning
> wrong address when using frame pointer?
> I am wondering if the first patch is not delivered to the mailing.

I posted a similar patch to alkml a couple of months ago, but I got
no response and it looks like I forgot about it.

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129381.html

[...]

> 
> ~~~~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~~~~~~~~
> From 3a60b536d22a2043d735c890a9aac9e7cb72de8f Mon Sep 17 00:00:00 2001
> From: sahara <keun-o.park@windriver.com>
> Date: Thu, 3 Jan 2013 17:12:37 +0900
> Subject: [PATCH 1/2] arm: fix returning wrong CALLER_ADDRx
> 
> This makes return_address return correct value for ftrace feature.
> unwind_frame does not update frame->lr but frame->pc for backtrace.
> And, the initialization for data.addr was missing so that wrong value
> returned when unwind_frame failed.
> 
> Signed-off-by: sahara <keun-o.park@windriver.com>
> ---
>  arch/arm/kernel/return_address.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
> index 8085417..fafedd8 100644
> --- a/arch/arm/kernel/return_address.c
> +++ b/arch/arm/kernel/return_address.c
> @@ -26,7 +26,7 @@ static int save_return_addr(struct stackframe *frame, void *d)
>         struct return_address_data *data = d;
> 
>         if (!data->level) {
> -               data->addr = (void *)frame->lr;
> +               data->addr = (void *)frame->pc;
> 
>                 return 1;
>         } else {
> @@ -41,7 +41,8 @@ void *return_address(unsigned int level)
>         struct stackframe frame;
>         register unsigned long current_sp asm ("sp");
> 
> -       data.level = level + 1;
> +       data.level = level + 2;
> +       data.addr = NULL;

Can you explain why this is needed?  I think I concluded it wasn't
necessary, but you may be right -- I think if walk_stackframe()
fails to unwind the next frame just after data.level reaches zero,
then data.addr can remain unset and return_address() may return
uninitialised garbage.

Initialising data.addr to NULL before we start seems a good way
to avoid that.

Cheers
---Dave

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Keun-O Park]

On Mon, Jan 28, 2013 at 9:50 PM, Dave Martin <dave.martin@linaro.org> wrote:
> On Mon, Jan 28, 2013 at 11:33:11AM +0900, Keun-O Park wrote:
>> Hello guys,
>>
>> Could you please review the patch of fixing bug first of returning
>> wrong address when using frame pointer?
>> I am wondering if the first patch is not delivered to the mailing.
>
> I posted a similar patch to alkml a couple of months ago, but I got
> no response and it looks like I forgot about it.
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129381.html

Yes, same except initialization of data.addr. :)
This means there might be no one interested in using
ftrace-irqsoff/premptoff in ARM during a couple of months?


>
> [...]
>
>>
>> ~~~~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~~~~~~~~
>> From 3a60b536d22a2043d735c890a9aac9e7cb72de8f Mon Sep 17 00:00:00 2001
>> From: sahara <keun-o.park@windriver.com>
>> Date: Thu, 3 Jan 2013 17:12:37 +0900
>> Subject: [PATCH 1/2] arm: fix returning wrong CALLER_ADDRx
>>
>> This makes return_address return correct value for ftrace feature.
>> unwind_frame does not update frame->lr but frame->pc for backtrace.
>> And, the initialization for data.addr was missing so that wrong value
>> returned when unwind_frame failed.
>>
>> Signed-off-by: sahara <keun-o.park@windriver.com>
>> ---
>>  arch/arm/kernel/return_address.c |    5 +++--
>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
>> index 8085417..fafedd8 100644
>> --- a/arch/arm/kernel/return_address.c
>> +++ b/arch/arm/kernel/return_address.c
>> @@ -26,7 +26,7 @@ static int save_return_addr(struct stackframe *frame, void *d)
>>         struct return_address_data *data = d;
>>
>>         if (!data->level) {
>> -               data->addr = (void *)frame->lr;
>> +               data->addr = (void *)frame->pc;
>>
>>                 return 1;
>>         } else {
>> @@ -41,7 +41,8 @@ void *return_address(unsigned int level)
>>         struct stackframe frame;
>>         register unsigned long current_sp asm ("sp");
>>
>> -       data.level = level + 1;
>> +       data.level = level + 2;
>> +       data.addr = NULL;
>
> Can you explain why this is needed?  I think I concluded it wasn't
> necessary, but you may be right -- I think if walk_stackframe()
> fails to unwind the next frame just after data.level reaches zero,
> then data.addr can remain unset and return_address() may return
> uninitialised garbage.

That's correct.
Here is the examples of reproducing the problem.
I added one line printk for test in wakeup_flusher_threads() in
fs/fs-writeback.c.
And then after boot up, I synced.

[TEST#1 : print CALLER_ADDR0, 1 and 2]
Without initialization of data.addr:
~ # sync
TEST: CALLER_ADDR0=(sys_sync+0x34/0xac),
CALLER_ADDR1=(ret_fast_syscall+0x0/0x48),
CALLER_ADDR2=(ret_fast_syscall+0x0/0x48)
With initialization of data.addr:
~ # sync
TEST: CALLER_ADDR0=(sys_sync+0x34/0xac),
CALLER_ADDR1=(ret_fast_syscall+0x0/0x48), CALLER_ADDR2=(  (null))

[TEST#2 : print CALLER_ADDR0 and 2]
Without initialization of data.addr:
~ # sync
TEST: CALLER_ADDR0=(sys_sync+0x34/0xac), CALLER_ADDR2=(0x872fffb0)
With initialization of data.addr:
~ # sync
TEST: CALLER_ADDR0=(sys_sync+0x34/0xac), CALLER_ADDR2=((null))

As you see, when unwind_fame() fails right after data.level reaches zero,
the routine returns data.addr which has uninitialized garbage value.

-- kpark

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Arnd Bergmann]

On Tuesday 29 January 2013, Keun-O Park wrote:
> On Mon, Jan 28, 2013 at 9:50 PM, Dave Martin <dave.martin@linaro.org> wrote:
> > On Mon, Jan 28, 2013 at 11:33:11AM +0900, Keun-O Park wrote:
> >> Hello guys,
> >>
> >> Could you please review the patch of fixing bug first of returning
> >> wrong address when using frame pointer?
> >> I am wondering if the first patch is not delivered to the mailing.
> >
> > I posted a similar patch to alkml a couple of months ago, but I got
> > no response and it looks like I forgot about it.
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129381.html
> 
> Yes, same except initialization of data.addr. :)
> This means there might be no one interested in using
> ftrace-irqsoff/premptoff in ARM during a couple of months?


It's been almost a year since we last discussed the patches that were
posted by Dave and sahara, but nothing has changed in the mainline kernel.

Any chance that someone could be motivated to pick this work up again
and finally fix return_address().

	Arnd

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Russell King - ARM Linux]

On Tue, Jan 07, 2014 at 03:33:34PM +0100, Arnd Bergmann wrote:
> On Tuesday 29 January 2013, Keun-O Park wrote:
> > On Mon, Jan 28, 2013 at 9:50 PM, Dave Martin <dave.martin@linaro.org> wrote:
> > > On Mon, Jan 28, 2013 at 11:33:11AM +0900, Keun-O Park wrote:
> > >> Hello guys,
> > >>
> > >> Could you please review the patch of fixing bug first of returning
> > >> wrong address when using frame pointer?
> > >> I am wondering if the first patch is not delivered to the mailing.
> > >
> > > I posted a similar patch to alkml a couple of months ago, but I got
> > > no response and it looks like I forgot about it.
> > >
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129381.html
> > 
> > Yes, same except initialization of data.addr. :)
> > This means there might be no one interested in using
> > ftrace-irqsoff/premptoff in ARM during a couple of months?
> 
> 
> It's been almost a year since we last discussed the patches that were
> posted by Dave and sahara, but nothing has changed in the mainline kernel.
> 
> Any chance that someone could be motivated to pick this work up again
> and finally fix return_address().

I thought that we had _actively_ decided that we would not use the
unwinder for these paths - that it was too expensive for these paths,
and you had to use frame pointers instead.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Arnd Bergmann]

On Tuesday 07 January 2014 14:41:30 Russell King - ARM Linux wrote:
> On Tue, Jan 07, 2014 at 03:33:34PM +0100, Arnd Bergmann wrote:
> > 
> > 
> > It's been almost a year since we last discussed the patches that were
> > posted by Dave and sahara, but nothing has changed in the mainline kernel.
> > 
> > Any chance that someone could be motivated to pick this work up again
> > and finally fix return_address().
> 
> I thought that we had _actively_ decided that we would not use the
> unwinder for these paths - that it was too expensive for these paths,
> and you had to use frame pointers instead.

I don't remember that discussion, but it may well be. What does
that mean for the #warning in return_address.c then? Can we
just use the frame pointer version based on CONFIG_FRAME_POINTER
and ignore whether CONFIG_ARM_UNWIND is set as the patch below,
or did I misunderstand?

	Arnd

diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index f89515a..3247370 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -32,7 +32,7 @@ extern void ftrace_call_old(void);
 
 #ifndef __ASSEMBLY__
 
-#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
+#if defined(CONFIG_FRAME_POINTER)
 /*
  * return_address uses walk_stackframe to do it's work.  If both
  * CONFIG_FRAME_POINTER=y and CONFIG_ARM_UNWIND=y walk_stackframe uses unwind
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index a30fc9b..c713f46 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -16,13 +16,14 @@ CFLAGS_REMOVE_return_address.o = -pg
 # Object file lists.
 
 obj-y		:= elf.o entry-common.o irq.o opcodes.o \
-		   process.o ptrace.o return_address.o \
+		   process.o ptrace.o \
 		   setup.o signal.o sigreturn_codes.o \
 		   stacktrace.o sys_arm.o time.o traps.o
 
 obj-$(CONFIG_ATAGS)		+= atags_parse.o
 obj-$(CONFIG_ATAGS_PROC)	+= atags_proc.o
 obj-$(CONFIG_DEPRECATED_PARAM_STRUCT) += atags_compat.o
+obj-$(CONFIG_FRAME_POINTER)	+= return_address.o
 
 ifeq ($(CONFIG_CPU_V7M),y)
 obj-y		+= entry-v7m.o v7m.o
diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
index fafedd8..d9f2c15 100644
--- a/arch/arm/kernel/return_address.c
+++ b/arch/arm/kernel/return_address.c
@@ -10,8 +10,6 @@
  */
 #include <linux/export.h>
 #include <linux/ftrace.h>
-
-#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
 #include <linux/sched.h>
 
 #include <asm/stacktrace.h>
@@ -56,18 +54,4 @@ void *return_address(unsigned int level)
 	else
 		return NULL;
 }
-
-#else /* if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND) */
-
-#if defined(CONFIG_ARM_UNWIND)
-#warning "TODO: return_address should use unwind tables"
-#endif
-
-void *return_address(unsigned int level)
-{
-	return NULL;
-}
-
-#endif /* if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND) / else */
-
 EXPORT_SYMBOL_GPL(return_address);

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Dave Martin]

On Tue, Jan 07, 2014 at 03:48:25PM +0000, Arnd Bergmann wrote:
> On Tuesday 07 January 2014 14:41:30 Russell King - ARM Linux wrote:
> > On Tue, Jan 07, 2014 at 03:33:34PM +0100, Arnd Bergmann wrote:
> > > 
> > > 
> > > It's been almost a year since we last discussed the patches that were
> > > posted by Dave and sahara, but nothing has changed in the mainline kernel.
> > > 
> > > Any chance that someone could be motivated to pick this work up again
> > > and finally fix return_address().
> > 
> > I thought that we had _actively_ decided that we would not use the
> > unwinder for these paths - that it was too expensive for these paths,
> > and you had to use frame pointers instead.
> 
> I don't remember that discussion, but it may well be. What does
> that mean for the #warning in return_address.c then? Can we
> just use the frame pointer version based on CONFIG_FRAME_POINTER
> and ignore whether CONFIG_ARM_UNWIND is set as the patch below,
> or did I misunderstand?

For an ARM kernel this may work, but I thought that for THUMB2_KERNEL
there just isn't usable a framepointer at all.

If so, the only choices are to use the unwinder and accept the cost, or
to decide that return_address() will never work without
CONFIG_FRAMEPOINTER and remove the build-time warning.


My other concern was that we might end up in a recursive trace due to
the use of non-notrace core functions in the unwinder.  But I seem to
remember Steve Rostedt saying the the tracer guards against recursive
invocation nowadays -- if so, that shouldn't be a problem.

Cheers
---Dave

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Steven Rostedt]

On Tue, 7 Jan 2014 16:36:29 +0000
Dave Martin <Dave.Martin@arm.com> wrote:

> My other concern was that we might end up in a recursive trace due to
> the use of non-notrace core functions in the unwinder.  But I seem to
> remember Steve Rostedt saying the the tracer guards against recursive
> invocation nowadays -- if so, that shouldn't be a problem.

I guess it matters what type of tracing you are talking about. The
function tracer protects against all recursive contexts (normal,
softirq, irq and NMI) and so does the ring buffer (same levels).

Those may be the only ones that matter, as things like events shouldn't
recurse, unless you have an event in the unwinder itself. But that's
where you take the doctor's advice of "don't do that".

-- Steve

[PATCHv2 00/19] ARM: common warning fixes

[Arnd Bergmann]

Hi everyone,

[fixing an embarrasing typo in the linux-arm-kernel
 mailing list address, sorry about the re-send]

This series fixes all the known build warnings on
ARM with any of the defconfig files. Most of these
patches are regressions and warn about code that
changed in linux-3.8, so it would be nice to
fix those before the release.

The patch for the ARM_UNWIND warning is added
here for completeness: The warning is old and
particularly annoying, but the patch is not ready
for inclusion.

I have more patches like these for less important
issues, in four classes:

1. warnings and errors that are only present in linux-next
2. warnings about allyesconfig/allnoconfig/allmodconfig
   builds.
3. warnings and errors for various randconfig combinations
4. 'maybe-uninitialized' gcc warnings that only appear
   with gcc-3.7 or 3.8. There are quite a lot of them.

I will get to those once this series is sorted out.
Since there are no interdepencies between the patches,
my preference is to have them applied by the individual
subsystem maintainers. Anything that has not at
least made it into linux-next by the next merge window
and has not received a 'NAK' or been obsoleted by
another patch, I plan to submit as part of an arm-soc
branch for 3.9.

Arnd Bergmann (18):
  ARM: shmobile: fix defconfig warning on CONFIG_USB
  ARM: disable virt_to_bus/virt_to_bus almost everywhere
  ARM: msm: proc_comm_boot_wait should not be __init
  oss/dmabuf: use dma_map_single
  sched: warnings in kernel/sched/fair.c
  sched/debug: fix format string for 32 bit platforms
  scripts/sortextable: silence script output
  lockdep: avoid warning about unused variables
  mfd/twl4030: don't warn about uninitialized return code
  watchdog: at91sam9: at91_wdt_dt_ids cannot be __init
  regmap: avoid undefined return from regmap_read_debugfs
  pinctrl: exynos: don't mark probing functions as __init
  pinctrl: nomadik: nmk_prcm_gpiocr_get_mode may be unused
  spi/atmel: remove incorrect __exit_p()
  sunrpc: don't warn for unused variable 'buf'
  ARM: sa1100: don't warn about mach/ide.h
  input/joystick: use get_cycles on ARM
  ARM: at91: suspend both memory controllers on at91sam9263

sahara (1):
  [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

 arch/arm/Kconfig                     |  4 ++++
 arch/arm/configs/marzen_defconfig    |  1 -
 arch/arm/configs/shark_defconfig     |  1 -
 arch/arm/include/asm/dma.h           |  2 +-
 arch/arm/include/asm/ftrace.h        |  6 ++----
 arch/arm/include/asm/memory.h        |  2 ++
 arch/arm/kernel/Makefile             | 12 +++++-------
 arch/arm/kernel/return_address.c     | 10 +++-------
 arch/arm/kernel/stacktrace.c         |  3 +++
 arch/arm/mach-at91/cpuidle.c         |  2 ++
 arch/arm/mach-at91/pm.c              |  2 ++
 arch/arm/mach-at91/pm.h              | 30 ++++++++++++++++++++++++------
 arch/arm/mach-msm/proc_comm.h        |  2 +-
 arch/arm/mach-sa1100/lart.c          |  3 ---
 drivers/base/regmap/regmap-debugfs.c |  2 +-
 drivers/input/joystick/analog.c      |  8 ++------
 drivers/mfd/twl4030-power.c          |  2 +-
 drivers/pinctrl/pinctrl-exynos5440.c | 10 +++++-----
 drivers/pinctrl/pinctrl-nomadik.c    |  2 +-
 drivers/spi/spi-atmel.c              |  2 +-
 drivers/watchdog/at91sam9_wdt.c      |  2 +-
 include/linux/lockdep.h              |  2 +-
 kernel/sched/debug.c                 |  4 ++--
 kernel/sched/fair.c                  |  2 +-
 kernel/trace/trace_irqsoff.c         | 26 ++++++++++++--------------
 net/sunrpc/svc.c                     |  2 +-
 scripts/sortextable.h                |  2 +-
 sound/oss/dmabuf.c                   |  3 ++-
 28 files changed, 81 insertions(+), 68 deletions(-)

-- 
1.8.0

[PATCH 01/19] ARM: shmobile: fix defconfig warning on CONFIG_USB

[Arnd Bergmann]

A recent update to the marzen_defconfig introduced a
duplicate CONFIG_USB=y line. This removes one of the
two.

arch/arm/configs/marzen_defconfig:86:warning: override: reassigning to symbol USB

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Simon Horman <horms@verge.net.au>
Cc: linux-sh at vger.kernel.org
---
 arch/arm/configs/marzen_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig
index 728a43c..afb17d6 100644
--- a/arch/arm/configs/marzen_defconfig
+++ b/arch/arm/configs/marzen_defconfig
@@ -83,7 +83,6 @@ CONFIG_USB=y
 CONFIG_USB_RCAR_PHY=y
 CONFIG_MMC=y
 CONFIG_MMC_SDHI=y
-CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
-- 
1.8.0

[PATCH 01/19] ARM: shmobile: fix defconfig warning on CONFIG_USB

[Simon Horman]

On Fri, Jan 25, 2013 at 10:44:00PM +0000, Arnd Bergmann wrote:
> A recent update to the marzen_defconfig introduced a
> duplicate CONFIG_USB=y line. This removes one of the
> two.
> 
> arch/arm/configs/marzen_defconfig:86:warning: override: reassigning to symbol USB


Acked-by: Simon Horman <horms+renesas@verge.net.au>

[PATCH 02/19] ARM: disable virt_to_bus/virt_to_bus almost everywhere

[Arnd Bergmann]

We are getting a number of warnings about the use of the deprecated
bus_to_virt function in drivers using the ARM ISA DMA API:

drivers/parport/parport_pc.c: In function 'parport_pc_fifo_write_block_dma':
drivers/parport/parport_pc.c:622:3: warning: 'bus_to_virt' is deprecated
(declared at arch/arm/include/asm/memory.h:253) [-Wdeprecated-declarations]

This is only because that function gets used by the inline
set_dma_addr() helper. We know that any driver for the ISA DMA API
is correctly using the DMA addresses, so we can change this
to use the __bus_to_virt() function instead, which does not warn.

After this, there are no remaining drivers that are used on
any defconfigs on ARM using virt_to_bus or bus_to_virt, with
the exception of the OSS sound driver. That driver is only used
on RiscPC, NetWinder and Shark, so we can set ARCH_NO_VIRT_TO_BUS
on all other platforms and hide the deprecated functions, which
is far more effective than marking them as deprecated, in order
to avoid any new users of that code.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
 arch/arm/Kconfig                 | 4 ++++
 arch/arm/configs/shark_defconfig | 1 -
 arch/arm/include/asm/dma.h       | 2 +-
 arch/arm/include/asm/memory.h    | 2 ++
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..91d4aea 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1450,6 +1450,10 @@ config ISA_DMA
 	bool
 	select ISA_DMA_API
 
+config ARCH_NO_VIRT_TO_BUS
+	def_bool y
+	depends on !ARCH_RPC && !ARCH_NETWINDER && !ARCH_SHARK
+
 # Select ISA DMA interface
 config ISA_DMA_API
 	bool
diff --git a/arch/arm/configs/shark_defconfig b/arch/arm/configs/shark_defconfig
index caa07db..e319b2c 100644
--- a/arch/arm/configs/shark_defconfig
+++ b/arch/arm/configs/shark_defconfig
@@ -73,7 +73,6 @@ CONFIG_PARTITION_ADVANCED=y
 CONFIG_NLS_CODEPAGE_437=m
 CONFIG_NLS_CODEPAGE_850=m
 CONFIG_NLS_ISO8859_1=m
-# CONFIG_ENABLE_WARN_DEPRECATED is not set
 # CONFIG_ENABLE_MUST_CHECK is not set
 CONFIG_DEBUG_KERNEL=y
 # CONFIG_SCHED_DEBUG is not set
diff --git a/arch/arm/include/asm/dma.h b/arch/arm/include/asm/dma.h
index 5694a0d..58b8c6a 100644
--- a/arch/arm/include/asm/dma.h
+++ b/arch/arm/include/asm/dma.h
@@ -105,7 +105,7 @@ extern void set_dma_sg(unsigned int chan, struct scatterlist *sg, int nr_sg);
  */
 extern void __set_dma_addr(unsigned int chan, void *addr);
 #define set_dma_addr(chan, addr)				\
-	__set_dma_addr(chan, bus_to_virt(addr))
+	__set_dma_addr(chan, (void *)__bus_to_virt(addr))
 
 /* Set the DMA byte count for this channel
  *
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 73cf03a..b11105c 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -245,6 +245,7 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define __bus_to_pfn(x)	__phys_to_pfn(x)
 #endif
 
+#ifdef CONFIG_VIRT_TO_BUS
 static inline __deprecated unsigned long virt_to_bus(void *x)
 {
 	return __virt_to_bus((unsigned long)x);
@@ -254,6 +255,7 @@ static inline __deprecated void *bus_to_virt(unsigned long x)
 {
 	return (void *)__bus_to_virt(x);
 }
+#endif
 
 /*
  * Conversion between a struct page and a physical address.
-- 
1.8.0

[PATCH 03/19] ARM: msm: proc_comm_boot_wait should not be __init

[Arnd Bergmann]

msm_smd_probe is a driver probe function and may get
called after the __init time, so it must not call
any __init function, as the link-time warning reports.
Take away the __init annotation on proc_comm_boot_wait
to fix this.

Without this patch, building msm_defconfig results in:

WARNING: vmlinux.o(.text+0xb048): Section mismatch in reference from the function msm_smd_probe() to the function .init.text:proc_comm_boot_wait()
The function msm_smd_probe() references
the function __init proc_comm_boot_wait().
This is often because msm_smd_probe lacks a __init
annotation or the annotation of proc_comm_boot_wait is wrong.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Brown <davidb@codeaurora.org>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: linux-arm-msm at vger.kernel.org
---
 arch/arm/mach-msm/proc_comm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-msm/proc_comm.h b/arch/arm/mach-msm/proc_comm.h
index 12da4ca..e8d043a 100644
--- a/arch/arm/mach-msm/proc_comm.h
+++ b/arch/arm/mach-msm/proc_comm.h
@@ -253,6 +253,6 @@ enum {
 		(((drvstr) & 0xF) << 17))
 
 int msm_proc_comm(unsigned cmd, unsigned *data1, unsigned *data2);
-void __init proc_comm_boot_wait(void);
+void proc_comm_boot_wait(void);
 
 #endif
-- 
1.8.0

[PATCH 04/19] oss/dmabuf: use dma_map_single

[Arnd Bergmann]

The virt_to_bus/bus_to_virt functions have been deprecated
for as long as I can remember, and they are used in very
few remaining instances, usually in obscure ISA device
drivers. The OSS sound drivers are the only ones that are
still used on the ARM architecture, and only on some of
the earliest StrongARM machines.

The problem for converting the OSS subsystem to use
dma_map_single instead is that the caller of virt_to_bus
does not have a device pointer, since the subsystem has
never been ported to use the common device infrastructure.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel at alsa-project.org
---
 sound/oss/dmabuf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/oss/dmabuf.c b/sound/oss/dmabuf.c
index bcc3e8e..a59c888 100644
--- a/sound/oss/dmabuf.c
+++ b/sound/oss/dmabuf.c
@@ -114,7 +114,7 @@ static int sound_alloc_dmap(struct dma_buffparms *dmap)
 		}
 	}
 	dmap->raw_buf = start_addr;
-	dmap->raw_buf_phys = virt_to_bus(start_addr);
+	dmap->raw_buf_phys = dma_map_single(NULL, start_addr, dmap->buffsize, DMA_BIDIRECTIONAL);
 
 	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
 		SetPageReserved(page);
@@ -139,6 +139,7 @@ static void sound_free_dmap(struct dma_buffparms *dmap)
 	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
 		ClearPageReserved(page);
 
+	dma_unmap_single(NULL, dmap->raw_buf_phys, dmap->buffsize, DMA_BIDIRECTIONAL);
 	free_pages((unsigned long) dmap->raw_buf, sz);
 	dmap->raw_buf = NULL;
 }
-- 
1.8.0

[PATCH 05/19] sched: warnings in kernel/sched/fair.c

[Arnd Bergmann]

a4c96ae319 "sched: Unthrottle rt runqueues in __disable_runtime()"
turned the unthrottle_offline_cfs_rqs function into a static symbol,
which now triggers a warning about it being potentially unused:

kernel/sched/fair.c:2055:13: warning: 'unthrottle_offline_cfs_rqs' defined but not used [-Wunused-function]

Marking it __maybe_unused shuts up the gcc warning and lets the
compiler safely drop the function body when it's not being used.

To reproduce, build the ARM bcm2835_defconfig.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Boonstoppel <pboonstoppel@nvidia.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Turner <pjt@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
---
 kernel/sched/fair.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 5eea870..81fa536 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2663,7 +2663,7 @@ static void destroy_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
 	hrtimer_cancel(&cfs_b->slack_timer);
 }
 
-static void unthrottle_offline_cfs_rqs(struct rq *rq)
+static void __maybe_unused unthrottle_offline_cfs_rqs(struct rq *rq)
 {
 	struct cfs_rq *cfs_rq;
 
-- 
1.8.0

[PATCH 06/19] sched/debug: fix format string for 32 bit platforms

[Arnd Bergmann]

The type returned from atomic64_t can be either unsigned
long or unsigned long long, depending on the architecture.
Using a cast to unsigned long long lets us use the same
format string for all architectures.

Without this patch, building with scheduler debugging
enabled results in:

kernel/sched/debug.c: In function 'print_cfs_rq':
kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'long long int' [-Wformat]
kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int' [-Wformat]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paul Turner <pjt@google.com>
---
 kernel/sched/debug.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 2cd3c1b..7ae4c4c 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -222,8 +222,8 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
 			cfs_rq->runnable_load_avg);
 	SEQ_printf(m, "  .%-30s: %lld\n", "blocked_load_avg",
 			cfs_rq->blocked_load_avg);
-	SEQ_printf(m, "  .%-30s: %ld\n", "tg_load_avg",
-			atomic64_read(&cfs_rq->tg->load_avg));
+	SEQ_printf(m, "  .%-30s: %lld\n", "tg_load_avg",
+			(unsigned long long)atomic64_read(&cfs_rq->tg->load_avg));
 	SEQ_printf(m, "  .%-30s: %lld\n", "tg_load_contrib",
 			cfs_rq->tg_load_contrib);
 	SEQ_printf(m, "  .%-30s: %d\n", "tg_runnable_contrib",
-- 
1.8.0

[PATCH 07/19] scripts/sortextable: silence script output

[Arnd Bergmann]

The exception table sorter outputs one line every time
it gets called, e.g. 'sort done marker at 66dc00', which
is slightly annoying when doing 'make -s' which is otherwise
completely silent. Since that output is not helpful to
most people building the kernel, turn it off by default.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Daney <david.daney@cavium.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
---
 scripts/sortextable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/sortextable.h b/scripts/sortextable.h
index e4fd45b..f5eb43d 100644
--- a/scripts/sortextable.h
+++ b/scripts/sortextable.h
@@ -182,7 +182,7 @@ do_func(Elf_Ehdr *ehdr, char const *const fname, table_sort_t custom_sort)
 		_r(&sort_needed_sym->st_value) -
 		_r(&sort_needed_sec->sh_addr);
 
-#if 1
+#if 0
 	printf("sort done marker at %lx\n",
 	       (unsigned long)((char *)sort_done_location - (char *)ehdr));
 #endif
-- 
1.8.0

[PATCH 08/19] lockdep: avoid warning about unused variables

[Arnd Bergmann]

When lockdep is disabled, a call to lockdep_assert_held
does not use its argument, which results in a compiler
warning if nothing else in the same function uses
that variable. An instance of this was introduced
by c9a49628819 "nfsd: make client_lock per net".

Without this patch, building ARM cerfcube_defconfig results in:

fs/nfsd/nfs4state.c: In function 'free_client':
fs/nfsd/nfs4state.c:1047:19: error: unused variable 'nn' [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
 include/linux/lockdep.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 2bca44b..f05631e 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -410,7 +410,7 @@ struct lock_class_key { };
 
 #define lockdep_depth(tsk)	(0)
 
-#define lockdep_assert_held(l)			do { } while (0)
+#define lockdep_assert_held(l)			do { (void)(l); } while (0)
 
 #define lockdep_recursing(tsk)			(0)
 
-- 
1.8.0

[PATCH 09/19] mfd/twl4030: don't warn about uninitialized return code

[Arnd Bergmann]

If the twl4030_write_script function gets called with
a zero length argument, its return value does not
get set. We know that all scripts have a nonzero
length, but returning an error in case they ever
do is probably appropriate.

Without this patch, building omap2plus_defconfig results in:

drivers/mfd/twl4030-power.c: In function 'load_twl4030_script':
drivers/mfd/twl4030-power.c:414:5: error: 'err' may be used uninitialized in this function

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Kristo, Tero" <t-kristo@ti.com>
---
 drivers/mfd/twl4030-power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 4dae241..dd362c1 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -159,7 +159,7 @@ out:
 static int twl4030_write_script(u8 address, struct twl4030_ins *script,
 				       int len)
 {
-	int err;
+	int err = -EINVAL;
 
 	for (; len; len--, address++, script++) {
 		if (len == 1) {
-- 
1.8.0

[PATCH 09/19] mfd/twl4030: don't warn about uninitialized return code

[Samuel Ortiz]

Hi Arnd,

On Fri, Jan 25, 2013 at 10:44:08PM +0000, Arnd Bergmann wrote:
> If the twl4030_write_script function gets called with
> a zero length argument, its return value does not
> get set. We know that all scripts have a nonzero
> length, but returning an error in case they ever
> do is probably appropriate.
> 
> Without this patch, building omap2plus_defconfig results in:
> 
> drivers/mfd/twl4030-power.c: In function 'load_twl4030_script':
> drivers/mfd/twl4030-power.c:414:5: error: 'err' may be used uninitialized in this function
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: "Kristo, Tero" <t-kristo@ti.com>
> ---
>  drivers/mfd/twl4030-power.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to my for-linus branch, thanks.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

[PATCH 10/19] watchdog: at91sam9: at91_wdt_dt_ids cannot be __init

[Arnd Bergmann]

The device IDs are referenced by the driver and potentially
used beyond the init time, as kbuild correctly warns
about. Remove the __initconst annotation.

Without this patch, building at91_dt_defconfig results in:

WARNING: drivers/watchdog/built-in.o(.data+0x28): Section mismatch in reference from the variable at91wdt_driver to the (unknown reference) .init.rodata:(unknown)
The variable at91wdt_driver references
the (unknown reference) __initconst (unknown)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: linux-watchdog at vger.kernel.org
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
---
 drivers/watchdog/at91sam9_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index dc42e44..6dad954 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -304,7 +304,7 @@ static int __exit at91wdt_remove(struct platform_device *pdev)
 }
 
 #if defined(CONFIG_OF)
-static const struct of_device_id at91_wdt_dt_ids[] __initconst = {
+static const struct of_device_id at91_wdt_dt_ids[] = {
 	{ .compatible = "atmel,at91sam9260-wdt" },
 	{ /* sentinel */ }
 };
-- 
1.8.0

[PATCH 10/19] watchdog: at91sam9: at91_wdt_dt_ids cannot be __init

[Nicolas Ferre]

On 01/25/2013 11:44 PM, Arnd Bergmann :
> The device IDs are referenced by the driver and potentially
> used beyond the init time, as kbuild correctly warns
> about. Remove the __initconst annotation.
> 
> Without this patch, building at91_dt_defconfig results in:
> 
> WARNING: drivers/watchdog/built-in.o(.data+0x28): Section mismatch in reference from the variable at91wdt_driver to the (unknown reference) .init.rodata:(unknown)
> The variable at91wdt_driver references
> the (unknown reference) __initconst (unknown)
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Wim Van Sebroeck <wim@iguana.be>
> Cc: linux-watchdog at vger.kernel.org
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Thanks,

> Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
> ---
>  drivers/watchdog/at91sam9_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
> index dc42e44..6dad954 100644
> --- a/drivers/watchdog/at91sam9_wdt.c
> +++ b/drivers/watchdog/at91sam9_wdt.c
> @@ -304,7 +304,7 @@ static int __exit at91wdt_remove(struct platform_device *pdev)
>  }
>  
>  #if defined(CONFIG_OF)
> -static const struct of_device_id at91_wdt_dt_ids[] __initconst = {
> +static const struct of_device_id at91_wdt_dt_ids[] = {
>  	{ .compatible = "atmel,at91sam9260-wdt" },
>  	{ /* sentinel */ }
>  };
> 


-- 
Nicolas Ferre

[PATCH 10/19] watchdog: at91sam9: at91_wdt_dt_ids cannot be __init

[Fabio Porcedda]

On Mon, Jan 28, 2013 at 9:32 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> On 01/25/2013 11:44 PM, Arnd Bergmann :
>> The device IDs are referenced by the driver and potentially
>> used beyond the init time, as kbuild correctly warns
>> about. Remove the __initconst annotation.
>>
>> Without this patch, building at91_dt_defconfig results in:
>>
>> WARNING: drivers/watchdog/built-in.o(.data+0x28): Section mismatch in reference from the variable at91wdt_driver to the (unknown reference) .init.rodata:(unknown)
>> The variable at91wdt_driver references
>> the (unknown reference) __initconst (unknown)
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Wim Van Sebroeck <wim@iguana.be>
>> Cc: linux-watchdog at vger.kernel.org
>> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Thanks,
>
>> Cc: Fabio Porcedda <fabio.porcedda@gmail.com>

Tested-by: Fabio Porcedda <fabio.porcedda@gmail.com>

Thanks.

>> ---
>>  drivers/watchdog/at91sam9_wdt.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
>> index dc42e44..6dad954 100644
>> --- a/drivers/watchdog/at91sam9_wdt.c
>> +++ b/drivers/watchdog/at91sam9_wdt.c
>> @@ -304,7 +304,7 @@ static int __exit at91wdt_remove(struct platform_device *pdev)
>>  }
>>
>>  #if defined(CONFIG_OF)
>> -static const struct of_device_id at91_wdt_dt_ids[] __initconst = {
>> +static const struct of_device_id at91_wdt_dt_ids[] = {
>>       { .compatible = "atmel,at91sam9260-wdt" },
>>       { /* sentinel */ }
>>  };
>>
>
>
> --
> Nicolas Ferre



--
Fabio Porcedda

[PATCH 10/19] watchdog: at91sam9: at91_wdt_dt_ids cannot be __init

[Fabio Porcedda]

Hi Arnd,

On Fri, Jan 25, 2013 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The device IDs are referenced by the driver and potentially
> used beyond the init time, as kbuild correctly warns
> about. Remove the __initconst annotation.
>
> Without this patch, building at91_dt_defconfig results in:
>
> WARNING: drivers/watchdog/built-in.o(.data+0x28): Section mismatch in reference from the variable at91wdt_driver to the (unknown reference) .init.rodata:(unknown)
> The variable at91wdt_driver references
> the (unknown reference) __initconst (unknown)

Thanks for fixing my commit.

Best regards

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Wim Van Sebroeck <wim@iguana.be>
> Cc: linux-watchdog at vger.kernel.org
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
> ---
>  drivers/watchdog/at91sam9_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
> index dc42e44..6dad954 100644
> --- a/drivers/watchdog/at91sam9_wdt.c
> +++ b/drivers/watchdog/at91sam9_wdt.c
> @@ -304,7 +304,7 @@ static int __exit at91wdt_remove(struct platform_device *pdev)
>  }
>
>  #if defined(CONFIG_OF)
> -static const struct of_device_id at91_wdt_dt_ids[] __initconst = {
> +static const struct of_device_id at91_wdt_dt_ids[] = {
>         { .compatible = "atmel,at91sam9260-wdt" },
>         { /* sentinel */ }
>  };
> --
> 1.8.0
>

--
Fabio Porcedda

[PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs

[Arnd Bergmann]

Gcc warns about the case where regmap_read_debugfs tries
to walk an empty map->debugfs_off_cache list, which results
in uninitialized variable getting returned.

Setting this variable to 0 first avoids the warning and
the potentially undefined value.

Without this patch, building mxs_defconfig results in:

drivers/base/regmap/regmap-debugfs.c: In function 'regmap_read_debugfs':
drivers/base/regmap/regmap-debugfs.c:147:9: : warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/base/regmap/regmap-debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/regmap/regmap-debugfs.c b/drivers/base/regmap/regmap-debugfs.c
index 46a213a..31cc656 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -80,7 +80,7 @@ static unsigned int regmap_debugfs_get_dump_start(struct regmap *map,
 {
 	struct regmap_debugfs_off_cache *c = NULL;
 	loff_t p = 0;
-	unsigned int i, ret;
+	unsigned int i, ret = 0;
 
 	/*
 	 * If we don't have a cache build one so we don't have to do a
-- 
1.8.0

[PATCH 12/19] pinctrl: exynos: don't mark probing functions as __init

[Arnd Bergmann]

Functions called from a driver probe() method must not be
marked __init, because they may get called after the
init phase is done, when the device shows up late, or
because of deferred probing.

Without this patch, building exynos_defconfig results in
multiple warnings like:

WARNING: drivers/pinctrl/built-in.o(.text+0x51bc): Section mismatch in reference from the function exynos5440_pinctrl_probe() to the function .init.text:exynos5440_gpiolib_register()
The function exynos5440_pinctrl_probe() references
the function __init exynos5440_gpiolib_register().
This is often because exynos5440_pinctrl_probe lacks a __init
annotation or the annotation of exynos5440_gpiolib_register is wrong.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
---
 drivers/pinctrl/pinctrl-exynos5440.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-exynos5440.c b/drivers/pinctrl/pinctrl-exynos5440.c
index de05b64..1427299 100644
--- a/drivers/pinctrl/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/pinctrl-exynos5440.c
@@ -599,7 +599,7 @@ static int exynos5440_gpio_direction_output(struct gpio_chip *gc, unsigned offse
 }
 
 /* parse the pin numbers listed in the 'samsung,exynos5440-pins' property */
-static int __init exynos5440_pinctrl_parse_dt_pins(struct platform_device *pdev,
+static int exynos5440_pinctrl_parse_dt_pins(struct platform_device *pdev,
 			struct device_node *cfg_np, unsigned int **pin_list,
 			unsigned int *npins)
 {
@@ -630,7 +630,7 @@ static int __init exynos5440_pinctrl_parse_dt_pins(struct platform_device *pdev,
  * Parse the information about all the available pin groups and pin functions
  * from device node of the pin-controller.
  */
-static int __init exynos5440_pinctrl_parse_dt(struct platform_device *pdev,
+static int exynos5440_pinctrl_parse_dt(struct platform_device *pdev,
 				struct exynos5440_pinctrl_priv_data *priv)
 {
 	struct device *dev = &pdev->dev;
@@ -723,7 +723,7 @@ static int __init exynos5440_pinctrl_parse_dt(struct platform_device *pdev,
 }
 
 /* register the pinctrl interface with the pinctrl subsystem */
-static int __init exynos5440_pinctrl_register(struct platform_device *pdev,
+static int exynos5440_pinctrl_register(struct platform_device *pdev,
 				struct exynos5440_pinctrl_priv_data *priv)
 {
 	struct device *dev = &pdev->dev;
@@ -798,7 +798,7 @@ static int __init exynos5440_pinctrl_register(struct platform_device *pdev,
 }
 
 /* register the gpiolib interface with the gpiolib subsystem */
-static int __init exynos5440_gpiolib_register(struct platform_device *pdev,
+static int exynos5440_gpiolib_register(struct platform_device *pdev,
 				struct exynos5440_pinctrl_priv_data *priv)
 {
 	struct gpio_chip *gc;
@@ -831,7 +831,7 @@ static int __init exynos5440_gpiolib_register(struct platform_device *pdev,
 }
 
 /* unregister the gpiolib interface with the gpiolib subsystem */
-static int __init exynos5440_gpiolib_unregister(struct platform_device *pdev,
+static int exynos5440_gpiolib_unregister(struct platform_device *pdev,
 				struct exynos5440_pinctrl_priv_data *priv)
 {
 	int ret = gpiochip_remove(priv->gc);
-- 
1.8.0

[PATCH 13/19] pinctrl: nomadik: nmk_prcm_gpiocr_get_mode may be unused

[Arnd Bergmann]

nmk_prcm_gpiocr_get_mode is only needed for debugfs output at
the moment, which can be compile-time disabled. Marking
the function __maybe_unused still gives us compile-time
coverage, but avoids a gcc warning.

Without this patch, building nhk8815_defconfig results in:

drivers/pinctrl/pinctrl-nomadik.c:676:12: warning: 'nmk_prcm_gpiocr_get_mode' defined but not used [-Wunused-function]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jean-Nicolas Graux <jean-nicolas.graux@stericsson.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
---
 drivers/pinctrl/pinctrl-nomadik.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index 1bb16ff..5767b18 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -676,7 +676,7 @@ int nmk_gpio_set_mode(int gpio, int gpio_mode)
 }
 EXPORT_SYMBOL(nmk_gpio_set_mode);
 
-static int nmk_prcm_gpiocr_get_mode(struct pinctrl_dev *pctldev, int gpio)
+static int __maybe_unused nmk_prcm_gpiocr_get_mode(struct pinctrl_dev *pctldev, int gpio)
 {
 	int i;
 	u16 reg;
-- 
1.8.0

[PATCH 14/19] spi/atmel: remove incorrect __exit_p()

[Arnd Bergmann]

Since we no longer allow building without hotplug, the
atmel_spi_remove function is always present and we should
not use __exit_p() to refer to it.

Without this patch, building at91_dt_defconfig results in:

drivers/spi/spi-atmel.c:1006:12: warning: 'atmel_spi_remove' defined but not used [-Wunused-function]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: spi-devel-general at lists.sourceforge.net
---
 drivers/spi/spi-atmel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index ab34497..656d137 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1088,7 +1088,7 @@ static struct platform_driver atmel_spi_driver = {
 	.suspend	= atmel_spi_suspend,
 	.resume		= atmel_spi_resume,
 	.probe		= atmel_spi_probe,
-	.remove		= __exit_p(atmel_spi_remove),
+	.remove		= atmel_spi_remove,
 };
 module_platform_driver(atmel_spi_driver);
 
-- 
1.8.0

[PATCH 14/19] spi/atmel: remove incorrect __exit_p()

[Nicolas Ferre]

On 01/25/2013 11:44 PM, Arnd Bergmann :
> Since we no longer allow building without hotplug, the
> atmel_spi_remove function is always present and we should
> not use __exit_p() to refer to it.
> 
> Without this patch, building at91_dt_defconfig results in:
> 
> drivers/spi/spi-atmel.c:1006:12: warning: 'atmel_spi_remove' defined but not used [-Wunused-function]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: spi-devel-general at lists.sourceforge.net
> ---
>  drivers/spi/spi-atmel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index ab34497..656d137 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1088,7 +1088,7 @@ static struct platform_driver atmel_spi_driver = {
>  	.suspend	= atmel_spi_suspend,
>  	.resume		= atmel_spi_resume,
>  	.probe		= atmel_spi_probe,
> -	.remove		= __exit_p(atmel_spi_remove),
> +	.remove		= atmel_spi_remove,
>  };
>  module_platform_driver(atmel_spi_driver);
>  
> 


-- 
Nicolas Ferre

[PATCH 15/19] sunrpc: don't warn for unused variable 'buf'

[Arnd Bergmann]

When RPC_DEBUG is unset, the dprintk() macro does nothing,
causing the 'buf' variable in svc_printk to become unused.
Marking it as __maybe_unused avoids a harmless gcc warning.

Without this patch, building at91_dt_defconfig results in:

net/sunrpc/svc.c: In function 'svc_printk':
net/sunrpc/svc.c:1051:7: warning: unused variable 'buf' [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: "J. Bruce Fields" <bfields@redhat.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: linux-nfs at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 net/sunrpc/svc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index dbf12ac..b1f5223 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -1047,7 +1047,7 @@ void svc_printk(struct svc_rqst *rqstp, const char *fmt, ...)
 {
 	struct va_format vaf;
 	va_list args;
-	char 	buf[RPC_MAX_ADDRBUFLEN];
+	char buf[RPC_MAX_ADDRBUFLEN] __maybe_unused;
 
 	va_start(args, fmt);
 
-- 
1.8.0

[PATCH 15/19] sunrpc: don't warn for unused variable 'buf'

[Myklebust, Trond]

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, January 25, 2013 5:44 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org; Arnd Bergmann; J. Bruce Fields;
> Myklebust, Trond; linux-nfs at vger.kernel.org; netdev at vger.kernel.org
> Subject: [PATCH 15/19] sunrpc: don't warn for unused variable 'buf'
> 
> When RPC_DEBUG is unset, the dprintk() macro does nothing, causing the
> 'buf' variable in svc_printk to become unused.
> Marking it as __maybe_unused avoids a harmless gcc warning.
> 
> Without this patch, building at91_dt_defconfig results in:
> 
> net/sunrpc/svc.c: In function 'svc_printk':
> net/sunrpc/svc.c:1051:7: warning: unused variable 'buf' [-Wunused-variable]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: "J. Bruce Fields" <bfields@redhat.com>
> Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
> Cc: linux-nfs at vger.kernel.org
> Cc: netdev at vger.kernel.org
> ---
>  net/sunrpc/svc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c index dbf12ac..b1f5223
> 100644
> --- a/net/sunrpc/svc.c
> +++ b/net/sunrpc/svc.c
> @@ -1047,7 +1047,7 @@ void svc_printk(struct svc_rqst *rqstp, const char
> *fmt, ...)  {
>  	struct va_format vaf;
>  	va_list args;
> -	char 	buf[RPC_MAX_ADDRBUFLEN];
> +	char buf[RPC_MAX_ADDRBUFLEN] __maybe_unused;
> 
>  	va_start(args, fmt);

Alternatively, just declare it using the RPC_IFDEBUG() macro.

Cheers
  Trond

[PATCH 15/19] sunrpc: don't warn for unused variable 'buf'

[Arnd Bergmann]

On Friday 25 January 2013, Myklebust, Trond wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Marking it as __maybe_unused avoids a harmless gcc warning.
> 
> Alternatively, just declare it using the RPC_IFDEBUG() macro.

Right, makes sense: that's more consistent with other functions
doing the same thing. Thanks for taking a look.

	Arnd

8<----

>From 3b2baeac061bd60dbf14bb61bcc03cbd64c85ac4 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 26 Nov 2012 22:46:26 +0000
Subject: [PATCH] sunrpc: don't warn for unused variable 'buf'

When RPC_DEBUG is unset, the dprintk() macro does nothing,
causing the 'buf' variable in svc_printk to become unused.
Enclosing it in RPC_IFDEBUG avoids a harmless gcc warning.

Without this patch, building at91_dt_defconfig results in:

net/sunrpc/svc.c: In function 'svc_printk':
net/sunrpc/svc.c:1051:7: warning: unused variable 'buf' [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: "J. Bruce Fields" <bfields@redhat.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: linux-nfs at vger.kernel.org
Cc: netdev at vger.kernel.org

diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index dbf12ac..9485e66 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -1047,7 +1047,7 @@ void svc_printk(struct svc_rqst *rqstp, const char *fmt, ...)
 {
 	struct va_format vaf;
 	va_list args;
-	char 	buf[RPC_MAX_ADDRBUFLEN];
+	RPC_IFDEBUG(char buf[RPC_MAX_ADDRBUFLEN]);
 
 	va_start(args, fmt);
 

[PATCH 15/19] sunrpc: don't warn for unused variable 'buf'

[Russell King - ARM Linux]

On Fri, Jan 25, 2013 at 11:45:25PM +0000, Arnd Bergmann wrote:
> On Friday 25 January 2013, Myklebust, Trond wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > Marking it as __maybe_unused avoids a harmless gcc warning.
> > 
> > Alternatively, just declare it using the RPC_IFDEBUG() macro.
> 
> Right, makes sense: that's more consistent with other functions
> doing the same thing. Thanks for taking a look.

NAK.

There is already a fix queued up as a result of a previous report I
sent, but for some reason (which I didn't question) it was decided
not to queue it for -rc.

See Bruce's reply on lkml: 20130108212816.GA24572 at fieldses.org

[PATCH 15/19] sunrpc: don't warn for unused variable 'buf'

[Arnd Bergmann]

On Saturday 26 January 2013, Russell King - ARM Linux wrote:
> On Fri, Jan 25, 2013 at 11:45:25PM +0000, Arnd Bergmann wrote:
> > On Friday 25 January 2013, Myklebust, Trond wrote:
> > > > -----Original Message-----
> > > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > > Marking it as __maybe_unused avoids a harmless gcc warning.
> > > 
> > > Alternatively, just declare it using the RPC_IFDEBUG() macro.
> > 
> > Right, makes sense: that's more consistent with other functions
> > doing the same thing. Thanks for taking a look.
> 
> NAK.
> 
> There is already a fix queued up as a result of a previous report I
> sent, but for some reason (which I didn't question) it was decided
> not to queue it for -rc.
> 
> See Bruce's reply on lkml: 20130108212816.GA24572 at fieldses.org

Ok, makes sense. Then again, if that fix is queued for 3.9, maybe
it still makes sense to take the simpler fix into 3.8, and remove
it in 3.9 along with the other instances of RPC_IFDEBUG.

	Arnd

[PATCH 15/19] sunrpc: don't warn for unused variable 'buf'

[J. Bruce Fields]

On Sat, Jan 26, 2013 at 01:34:56PM +0000, Arnd Bergmann wrote:
> On Saturday 26 January 2013, Russell King - ARM Linux wrote:
> > On Fri, Jan 25, 2013 at 11:45:25PM +0000, Arnd Bergmann wrote:
> > > On Friday 25 January 2013, Myklebust, Trond wrote:
> > > > > -----Original Message-----
> > > > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > > > Marking it as __maybe_unused avoids a harmless gcc warning.
> > > > 
> > > > Alternatively, just declare it using the RPC_IFDEBUG() macro.
> > > 
> > > Right, makes sense: that's more consistent with other functions
> > > doing the same thing. Thanks for taking a look.
> > 
> > NAK.
> > 
> > There is already a fix queued up as a result of a previous report I
> > sent, but for some reason (which I didn't question) it was decided
> > not to queue it for -rc.
> > 
> > See Bruce's reply on lkml: 20130108212816.GA24572 at fieldses.org

Apologies, I've seen so many "stop sending me post-rc1 patches that
don't fix serious crashes!" flames.

I guess obviousl compile fixes should be an exception--if nothing else
it'd save a lot of duplicated work as this is something like the 3rd
patch I've seen for this.

--b.

> 
> Ok, makes sense. Then again, if that fix is queued for 3.9, maybe
> it still makes sense to take the simpler fix into 3.8, and remove
> it in 3.9 along with the other instances of RPC_IFDEBUG.

[PATCH 16/19] ARM: sa1100: don't warn about mach/ide.h

[Arnd Bergmann]

This warning has existed since before the start of (git) history.
Apparently nobody has bothered to fix it in a long time, and
this is unlikely to change. Note that the file that the warning
refers to has moved to a different location and was subsequently
deleted in 2008.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
 arch/arm/mach-sa1100/lart.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-sa1100/lart.c b/arch/arm/mach-sa1100/lart.c
index f69f78f..bca7e60 100644
--- a/arch/arm/mach-sa1100/lart.c
+++ b/arch/arm/mach-sa1100/lart.c
@@ -24,9 +24,6 @@
 
 #include "generic.h"
 
-
-#warning "include/asm/arch-sa1100/ide.h needs fixing for lart"
-
 static struct mcp_plat_data lart_mcp_data = {
 	.mccr0		= MCCR0_ADM,
 	.sclk_rate	= 11981000,
-- 
1.8.0

[PATCH 17/19] input/joystick: use get_cycles on ARM

[Arnd Bergmann]

ARM normally has an accurate clock source, so
we can theoretically use analog joysticks more
accurately and at the same time avoid the
build warning

 #warning Precise timer not defined for this architecture.

from the joystick driver.

Now, why anybody would use that driver no ARM I have no
idea, but Ben Dooks enabled it in the s3c2410_defconfig
along with a bunch of other drivers, even though that
platform has neither ISA nor PCI support. It still
seems to be the right thing to fix this quirk.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Vojtech Pavlik <vojtech@suse.cz>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 drivers/input/joystick/analog.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index 358cd7e..9c3e3c1 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -158,14 +158,10 @@ static unsigned int get_time_pit(void)
 #define GET_TIME(x)	rdtscl(x)
 #define DELTA(x,y)	((y)-(x))
 #define TIME_NAME	"TSC"
-#elif defined(__alpha__)
+#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM)
 #define GET_TIME(x)	do { x = get_cycles(); } while (0)
 #define DELTA(x,y)	((y)-(x))
-#define TIME_NAME	"PCC"
-#elif defined(CONFIG_MN10300)
-#define GET_TIME(x)	do { x = get_cycles(); } while (0)
-#define DELTA(x, y)	((x) - (y))
-#define TIME_NAME	"TSC"
+#define TIME_NAME	"get_cycles"
 #else
 #define FAKE_TIME
 static unsigned long analog_faketime = 0;
-- 
1.8.0

[PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263

[Arnd Bergmann]

For the past three years, we have had a #warning in
mach-at91 about the sdram_selfrefresh_enable or
at91sam9_standby functions possibly not working on
at91sam9263. In the meantime a function was added
to do the right thing on at91sam9g45, which looks like
it should also work on '9263.

This patch blindly removes the warning and changes the
at91sam9263 to use the same code at at91sam9g45, which
may or may not be the right solution. If it is not,
maybe someone could provide a better fix.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
---
 arch/arm/mach-at91/cpuidle.c |  2 ++
 arch/arm/mach-at91/pm.c      |  2 ++
 arch/arm/mach-at91/pm.h      | 30 ++++++++++++++++++++++++------
 3 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0c63815..4c67946 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -38,6 +38,8 @@ static int at91_enter_idle(struct cpuidle_device *dev,
 		at91rm9200_standby();
 	else if (cpu_is_at91sam9g45())
 		at91sam9g45_standby();
+	else if (cpu_is_at91sam9263())
+		at91sam9263_standby();
 	else
 		at91sam9_standby();
 
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index adb6db8..b8017c1 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -267,6 +267,8 @@ static int at91_pm_enter(suspend_state_t state)
 				at91rm9200_standby();
 			else if (cpu_is_at91sam9g45())
 				at91sam9g45_standby();
+			else if (cpu_is_at91sam9263())
+				at91sam9263_standby();
 			else
 				at91sam9_standby();
 			break;
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 38f467c..2f5908f 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -70,13 +70,31 @@ static inline void at91sam9g45_standby(void)
 	at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
 }
 
-#ifdef CONFIG_SOC_AT91SAM9263
-/*
- * FIXME either or both the SDRAM controllers (EB0, EB1) might be in use;
- * handle those cases both here and in the Suspend-To-RAM support.
+/* We manage both DDRAM/SDRAM controllers, we need more than one value to
+ * remember.
  */
-#warning Assuming EB1 SDRAM controller is *NOT* used
-#endif
+static inline void at91sam9263_standby(void)
+{
+	u32 lpr0, lpr1;
+	u32 saved_lpr0, saved_lpr1;
+
+	saved_lpr1 = at91_ramc_read(1, AT91_SDRAMC_LPR);
+	lpr1 = saved_lpr1 & ~AT91_SDRAMC_LPCB;
+	lpr1 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
+
+	saved_lpr0 = at91_ramc_read(0, AT91_SDRAMC_LPR);
+	lpr0 = saved_lpr0 & ~AT91_SDRAMC_LPCB;
+	lpr0 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
+
+	/* self-refresh mode now */
+	at91_ramc_write(0, AT91_SDRAMC_LPR, lpr0);
+	at91_ramc_write(1, AT91_SDRAMC_LPR, lpr1);
+
+	cpu_do_idle();
+
+	at91_ramc_write(0, AT91_SDRAMC_LPR, saved_lpr0);
+	at91_ramc_write(1, AT91_SDRAMC_LPR, saved_lpr1);
+}
 
 static inline void at91sam9_standby(void)
 {
-- 
1.8.0

[PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263

[Nicolas Ferre]

I come back to this for AT91


On 01/25/2013 11:44 PM, Arnd Bergmann :
> For the past three years, we have had a #warning in
> mach-at91 about the sdram_selfrefresh_enable or
> at91sam9_standby functions possibly not working on
> at91sam9263. In the meantime a function was added
> to do the right thing on at91sam9g45, which looks like
> it should also work on '9263.
> 
> This patch blindly removes the warning and changes the
> at91sam9263 to use the same code at at91sam9g45, which
> may or may not be the right solution. If it is not,
> maybe someone could provide a better fix.

Maybe you can remove this paragraph: now you are using the proper fix
with proper RAM type.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

What is the future of this patch series: do you want us to take this
patch separately or to you want to apply the whole series on the arm-soc
tree?


> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>

Moreover, this patch my conflict with Daniel's current initiative to
move cpuidle driver to its own directory: how do we coordinate with each
other?

Arnd,
Thanks a lot for having taking care of this old warning...


Best regards,

> ---
>  arch/arm/mach-at91/cpuidle.c |  2 ++
>  arch/arm/mach-at91/pm.c      |  2 ++
>  arch/arm/mach-at91/pm.h      | 30 ++++++++++++++++++++++++------
>  3 files changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
> index 0c63815..4c67946 100644
> --- a/arch/arm/mach-at91/cpuidle.c
> +++ b/arch/arm/mach-at91/cpuidle.c
> @@ -38,6 +38,8 @@ static int at91_enter_idle(struct cpuidle_device *dev,
>  		at91rm9200_standby();
>  	else if (cpu_is_at91sam9g45())
>  		at91sam9g45_standby();
> +	else if (cpu_is_at91sam9263())
> +		at91sam9263_standby();
>  	else
>  		at91sam9_standby();
>  
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index adb6db8..b8017c1 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -267,6 +267,8 @@ static int at91_pm_enter(suspend_state_t state)
>  				at91rm9200_standby();
>  			else if (cpu_is_at91sam9g45())
>  				at91sam9g45_standby();
> +			else if (cpu_is_at91sam9263())
> +				at91sam9263_standby();
>  			else
>  				at91sam9_standby();
>  			break;
> diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
> index 38f467c..2f5908f 100644
> --- a/arch/arm/mach-at91/pm.h
> +++ b/arch/arm/mach-at91/pm.h
> @@ -70,13 +70,31 @@ static inline void at91sam9g45_standby(void)
>  	at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
>  }
>  
> -#ifdef CONFIG_SOC_AT91SAM9263
> -/*
> - * FIXME either or both the SDRAM controllers (EB0, EB1) might be in use;
> - * handle those cases both here and in the Suspend-To-RAM support.
> +/* We manage both DDRAM/SDRAM controllers, we need more than one value to
> + * remember.
>   */
> -#warning Assuming EB1 SDRAM controller is *NOT* used
> -#endif
> +static inline void at91sam9263_standby(void)
> +{
> +	u32 lpr0, lpr1;
> +	u32 saved_lpr0, saved_lpr1;
> +
> +	saved_lpr1 = at91_ramc_read(1, AT91_SDRAMC_LPR);
> +	lpr1 = saved_lpr1 & ~AT91_SDRAMC_LPCB;
> +	lpr1 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
> +
> +	saved_lpr0 = at91_ramc_read(0, AT91_SDRAMC_LPR);
> +	lpr0 = saved_lpr0 & ~AT91_SDRAMC_LPCB;
> +	lpr0 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
> +
> +	/* self-refresh mode now */
> +	at91_ramc_write(0, AT91_SDRAMC_LPR, lpr0);
> +	at91_ramc_write(1, AT91_SDRAMC_LPR, lpr1);
> +
> +	cpu_do_idle();
> +
> +	at91_ramc_write(0, AT91_SDRAMC_LPR, saved_lpr0);
> +	at91_ramc_write(1, AT91_SDRAMC_LPR, saved_lpr1);
> +}
>  
>  static inline void at91sam9_standby(void)
>  {
> 


-- 
Nicolas Ferre

[PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263

[Arnd Bergmann]

On Thursday 18 April 2013, Nicolas Ferre wrote:

> > This patch blindly removes the warning and changes the
> > at91sam9263 to use the same code at at91sam9g45, which
> > may or may not be the right solution. If it is not,
> > maybe someone could provide a better fix.
> 
> Maybe you can remove this paragraph: now you are using the proper fix
> with proper RAM type.
> 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> 
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> 
> What is the future of this patch series: do you want us to take this
> patch separately or to you want to apply the whole series on the arm-soc
> tree?

I'd prefer if you could just apply or forward it to an appropriate tree.

Most of the other patches have found their way into mainline by now.

> > Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> > Cc: Andrew Victor <linux@maxim.org.za>
> > Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
> > Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> 
> Moreover, this patch my conflict with Daniel's current initiative to
> move cpuidle driver to its own directory: how do we coordinate with each
> other?

Maybe you can make sure it actually works and send it to Daniel to apply on
top of his other patches?

	Arnd

[PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263

[Nicolas Ferre]

On 04/18/2013 04:15 PM, Arnd Bergmann :
> On Thursday 18 April 2013, Nicolas Ferre wrote:
> 
>>> This patch blindly removes the warning and changes the
>>> at91sam9263 to use the same code at at91sam9g45, which
>>> may or may not be the right solution. If it is not,
>>> maybe someone could provide a better fix.
>>
>> Maybe you can remove this paragraph: now you are using the proper fix
>> with proper RAM type.
>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
>>
>> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>
>> What is the future of this patch series: do you want us to take this
>> patch separately or to you want to apply the whole series on the arm-soc
>> tree?
> 
> I'd prefer if you could just apply or forward it to an appropriate tree.
> 
> Most of the other patches have found their way into mainline by now.
> 
>>> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
>>> Cc: Andrew Victor <linux@maxim.org.za>
>>> Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
>>> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>>
>> Moreover, this patch my conflict with Daniel's current initiative to
>> move cpuidle driver to its own directory: how do we coordinate with each
>> other?
> 
> Maybe you can make sure it actually works and send it to Daniel to apply on
> top of his other patches?

Well, as Daniel's patches are still under construction, I stack this one
on the at91-3.10-soc branch and let Daniel rebase his work on top of a
3.10-rc1-ish tree...

Best regards,
-- 
Nicolas Ferre

[PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263

[Arnd Bergmann]

On Thursday 18 April 2013, Nicolas Ferre wrote:
> > Maybe you can make sure it actually works and send it to Daniel to apply on
> > top of his other patches?
> 
> Well, as Daniel's patches are still under construction, I stack this one
> on the at91-3.10-soc branch and let Daniel rebase his work on top of a
> 3.10-rc1-ish tree...

Ok, sounds fine too.

	Arnd

[PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263

[Daniel Lezcano]

On 04/18/2013 04:19 PM, Nicolas Ferre wrote:
> On 04/18/2013 04:15 PM, Arnd Bergmann :
>> On Thursday 18 April 2013, Nicolas Ferre wrote:
>>
>>>> This patch blindly removes the warning and changes the
>>>> at91sam9263 to use the same code at at91sam9g45, which
>>>> may or may not be the right solution. If it is not,
>>>> maybe someone could provide a better fix.
>>>
>>> Maybe you can remove this paragraph: now you are using the proper fix
>>> with proper RAM type.
>>>
>>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>>> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
>>>
>>> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>>
>>> What is the future of this patch series: do you want us to take this
>>> patch separately or to you want to apply the whole series on the arm-soc
>>> tree?
>>
>> I'd prefer if you could just apply or forward it to an appropriate tree.
>>
>> Most of the other patches have found their way into mainline by now.
>>
>>>> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
>>>> Cc: Andrew Victor <linux@maxim.org.za>
>>>> Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
>>>> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>
>>> Moreover, this patch my conflict with Daniel's current initiative to
>>> move cpuidle driver to its own directory: how do we coordinate with each
>>> other?
>>
>> Maybe you can make sure it actually works and send it to Daniel to apply on
>> top of his other patches?
> 
> Well, as Daniel's patches are still under construction, I stack this one
> on the at91-3.10-soc branch and let Daniel rebase his work on top of a
> 3.10-rc1-ish tree...

No problem.

Thanks
  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND

[Arnd Bergmann]

From: sahara <keun-o.park@windriver.com>

This is a reminder that we still need to fix the return_address
function to work correctly with the unwinder. Keun-O Park has
made this attempt in the past, which is still under discussion[1],
and Dave Martin has also mentioned that he would provide a
solution for this problem.

Right now, this patch makes the warning go away and provides
an implementation of return_address for the arm unwinder, but
causes other problems, so we should *not* apply it. I will
keep sending this patch until we have a better solution.

[1] http://lkml.org/lkml/2013/1/11/493

Original changelog:

This fixes a warning saying:

    warning: #warning "TODO: return_address should use unwind tables"

And, this enables return_address using unwind information. If ARM_UNWIND is
selected, unwind_frame in unwind.c will be called in walk_stackframe.

Signed-off-by: sahara <keun-o.park@windriver.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Dave Martin <dave.martin@linaro.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Russell King <linux@arm.linux.org.uk>
---
 arch/arm/include/asm/ftrace.h    |  6 ++----
 arch/arm/kernel/Makefile         | 12 +++++-------
 arch/arm/kernel/return_address.c | 10 +++-------
 arch/arm/kernel/stacktrace.c     |  3 +++
 kernel/trace/trace_irqsoff.c     | 26 ++++++++++++--------------
 5 files changed, 25 insertions(+), 32 deletions(-)

diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index f89515a..3552ad9 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -32,13 +32,11 @@ extern void ftrace_call_old(void);
 
 #ifndef __ASSEMBLY__
 
-#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
+#if defined(CONFIG_FRAME_POINTER) || defined(CONFIG_ARM_UNWIND)
 /*
  * return_address uses walk_stackframe to do it's work.  If both
  * CONFIG_FRAME_POINTER=y and CONFIG_ARM_UNWIND=y walk_stackframe uses unwind
- * information.  For this to work in the function tracer many functions would
- * have to be marked with __notrace.  So for now just depend on
- * !CONFIG_ARM_UNWIND.
+ * information.
  */
 
 void *return_address(unsigned int);
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5bbec7b..09a0d64 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -5,13 +5,11 @@
 CPPFLAGS_vmlinux.lds := -DTEXT_OFFSET=$(TEXT_OFFSET)
 AFLAGS_head.o        := -DTEXT_OFFSET=$(TEXT_OFFSET)
 
-ifdef CONFIG_FUNCTION_TRACER
-CFLAGS_REMOVE_ftrace.o = -pg
-CFLAGS_REMOVE_insn.o = -pg
-CFLAGS_REMOVE_patch.o = -pg
-endif
-
-CFLAGS_REMOVE_return_address.o = -pg
+CFLAGS_REMOVE_ftrace.o		= -pg
+CFLAGS_REMOVE_insn.o		= -pg
+CFLAGS_REMOVE_patch.o		= -pg
+CFLAGS_REMOVE_unwind.o		= -pg
+CFLAGS_REMOVE_return_address.o	= -pg
 
 # Object file lists.
 
diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
index 8085417..ccb5e37 100644
--- a/arch/arm/kernel/return_address.c
+++ b/arch/arm/kernel/return_address.c
@@ -11,7 +11,7 @@
 #include <linux/export.h>
 #include <linux/ftrace.h>
 
-#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
+#if defined(CONFIG_FRAME_POINTER) || defined(CONFIG_ARM_UNWIND)
 #include <linux/sched.h>
 
 #include <asm/stacktrace.h>
@@ -56,17 +56,13 @@ void *return_address(unsigned int level)
 		return NULL;
 }
 
-#else /* if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND) */
-
-#if defined(CONFIG_ARM_UNWIND)
-#warning "TODO: return_address should use unwind tables"
-#endif
+#else /* CONFIG_FRAME_POINTER || CONFIG_ARM_UNWIND */
 
 void *return_address(unsigned int level)
 {
 	return NULL;
 }
 
-#endif /* if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND) / else */
+#endif /* CONFIG_FRAME_POINTER || CONFIG_ARM_UNWIND */
 
 EXPORT_SYMBOL_GPL(return_address);
diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
index 00f79e5..aab144b 100644
--- a/arch/arm/kernel/stacktrace.c
+++ b/arch/arm/kernel/stacktrace.c
@@ -6,6 +6,9 @@
 
 #if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
 /*
+ * If both CONFIG_FRAME_POINTER=y and CONFIG_ARM_UNWIND=y walk_stackframe uses
+ * unwind information. So for now just depend on !CONFIG_ARM_UNWIND.
+ *
  * Unwind the current stack frame and store the new register values in the
  * structure passed as argument. Unwinding is equivalent to a function return,
  * hence the new PC value rather than LR should be used for backtrace.
diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
index 713a2ca..6f207ed 100644
--- a/kernel/trace/trace_irqsoff.c
+++ b/kernel/trace/trace_irqsoff.c
@@ -483,20 +483,6 @@ inline void print_irqtrace_events(struct task_struct *curr)
 /*
  * We are only interested in hardirq on/off events:
  */
-void trace_hardirqs_on(void)
-{
-	if (!preempt_trace() && irq_trace())
-		stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
-}
-EXPORT_SYMBOL(trace_hardirqs_on);
-
-void trace_hardirqs_off(void)
-{
-	if (!preempt_trace() && irq_trace())
-		start_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
-}
-EXPORT_SYMBOL(trace_hardirqs_off);
-
 void trace_hardirqs_on_caller(unsigned long caller_addr)
 {
 	if (!preempt_trace() && irq_trace())
@@ -504,6 +490,12 @@ void trace_hardirqs_on_caller(unsigned long caller_addr)
 }
 EXPORT_SYMBOL(trace_hardirqs_on_caller);
 
+void trace_hardirqs_on(void)
+{
+	trace_hardirqs_on_caller(CALLER_ADDR0);
+}
+EXPORT_SYMBOL(trace_hardirqs_on);
+
 void trace_hardirqs_off_caller(unsigned long caller_addr)
 {
 	if (!preempt_trace() && irq_trace())
@@ -511,6 +503,12 @@ void trace_hardirqs_off_caller(unsigned long caller_addr)
 }
 EXPORT_SYMBOL(trace_hardirqs_off_caller);
 
+void trace_hardirqs_off(void)
+{
+	trace_hardirqs_off_caller(CALLER_ADDR0);
+}
+EXPORT_SYMBOL(trace_hardirqs_off);
+
 #endif /* CONFIG_PROVE_LOCKING */
 #endif /*  CONFIG_IRQSOFF_TRACER */
 
-- 
1.8.0

[PATCHv2 00/19] ARM: common warning fixes

[Russell King - ARM Linux]

On Fri, Jan 25, 2013 at 10:43:59PM +0000, Arnd Bergmann wrote:
> I will get to those once this series is sorted out.
> Since there are no interdepencies between the patches,
> my preference is to have them applied by the individual
> subsystem maintainers. Anything that has not at
> least made it into linux-next by the next merge window
> and has not received a 'NAK' or been obsoleted by
> another patch, I plan to submit as part of an arm-soc
> branch for 3.9.

And, last night we have new warnings.  My allnoconfigs no longer build
cleanly because of new vexpress section mismatches in the mfd code.

It seems to me that you're on a loosing battle unless you test the tree
and drop code _before_ propaging it out if it adds new warnings... force
the pain of these warnings down on to others so that they learn to create
better code in the first place.

[PATCHv2 00/19] ARM: common warning fixes

[Arnd Bergmann]

On Saturday 26 January 2013, Russell King - ARM Linux wrote:
> On Fri, Jan 25, 2013 at 10:43:59PM +0000, Arnd Bergmann wrote:
> > I will get to those once this series is sorted out.
> > Since there are no interdepencies between the patches,
> > my preference is to have them applied by the individual
> > subsystem maintainers. Anything that has not at
> > least made it into linux-next by the next merge window
> > and has not received a 'NAK' or been obsoleted by
> > another patch, I plan to submit as part of an arm-soc
> > branch for 3.9.
> 
> And, last night we have new warnings.  My allnoconfigs no longer build
> cleanly because of new vexpress section mismatches in the mfd code.

Yes, I already sent a patch yesterday. The problem was a regression
that came in through the arm-soc tree unfortunately, but I can easily
fix it then.

> It seems to me that you're on a loosing battle unless you test the tree
> and drop code before propaging it out if it adds new warnings... force
> the pain of these warnings down on to others so that they learn to create
> better code in the first place.

That was always the idea, right now I mainly try to get back to the almost
clean state I had some time ago.

The largest problem right now is gcc-4.7, which adds a lot of new bogus
warnings.

	Arnd

[PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs

[Mark Brown]

On Sat, Jan 26, 2013 at 12:42:26PM +0800, Mark Brown wrote:
> On Fri, Jan 25, 2013 at 02:14:28PM +0000, Arnd Bergmann wrote:
> > Gcc warns about the case where regmap_read_debugfs tries

> Are you sure about that function name?

> > to walk an empty map->debugfs_off_cache list, which results
> > in uninitialized variable getting returned.

> > Setting this variable to 0 first avoids the warning and
> > the potentially undefined value.

> This probably won't apply against current code as there's already a
> better fix there, in general just picking a value to initialise masks
> errors.

Resending with corrected list address; to be clear please don't send
this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130126/27ae051d/attachment.sig>

[PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs

[Arnd Bergmann]

On Saturday 26 January 2013, Mark Brown wrote:
> On Fri, Jan 25, 2013 at 02:14:28PM +0000, Arnd Bergmann wrote:
> > Gcc warns about the case where regmap_read_debugfs tries
> 
> Are you sure about that function name?

Yes, regmap_read_debugfs uses the return value from
regmap_debugfs_get_dump_start, for which gcc found
a path that returns the uninitialized value.

> > to walk an empty map->debugfs_off_cache list, which results
> > in uninitialized variable getting returned.
> 
> > Setting this variable to 0 first avoids the warning and
> > the potentially undefined value.
> 
> This probably won't apply against current code as there's already a
> better fix there, in general just picking a value to initialise masks
> errors.

I agree on the general rule not to do this, and I'm trying to avoid it
in the cases where I can find a better fix, but here I could not
(mostly because I could not figure out what this code actually
does. Thanks for taking a look.

Which code is the current version? Is your fix headed for 3.8 inclusion?

I still see the warning in 3.8-rc5 as well as yesterday's linux-next,
with gcc-4.6, 4.7 and 4.8-pre.

	Arnd

[PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs

[Mark Brown]

On Sat, Jan 26, 2013 at 09:17:27AM +0000, Arnd Bergmann wrote:
> On Saturday 26 January 2013, Mark Brown wrote:
> > On Fri, Jan 25, 2013 at 02:14:28PM +0000, Arnd Bergmann wrote:

> > > Gcc warns about the case where regmap_read_debugfs tries

> > Are you sure about that function name?

> Yes, regmap_read_debugfs uses the return value from
> regmap_debugfs_get_dump_start, for which gcc found
> a path that returns the uninitialized value.

> > > to walk an empty map->debugfs_off_cache list, which results
> > > in uninitialized variable getting returned.

This is the bit that makes me think you're talking about the wrong
function - regmap_debugfs_read() never looks at the off_cache list.

> > > Setting this variable to 0 first avoids the warning and
> > > the potentially undefined value.

> > This probably won't apply against current code as there's already a
> > better fix there, in general just picking a value to initialise masks
> > errors.

> I agree on the general rule not to do this, and I'm trying to avoid it
> in the cases where I can find a better fix, but here I could not
> (mostly because I could not figure out what this code actually
> does. Thanks for taking a look.

> Which code is the current version? Is your fix headed for 3.8 inclusion?

It's all in mainline already.

> I still see the warning in 3.8-rc5 as well as yesterday's linux-next,
> with gcc-4.6, 4.7 and 4.8-pre.

Oh, ffs.  This is a false positive from the compiler - there is no case
where it can actually do this as we will bail out before the walk if the
list is empty so we'll always take at least one trip through our
list_for_each_entry() and either return or set ret.  It should be smart
enough to work out that the list_empty() means list_for_each_entry()
will iterate over at least one entry or more conservative in what it
warns about.

In any case, your change will break things - this is an example of why
just picking a random value to assign is unhelpful.  You'd need to
return base to avoid confusing the callers but even then doing it at the
start of the function is overkill, it excludes a bunch of paths.  I
guess we can work around it by putting a redundant assignment of pos and
ret before the loop :/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130126/252c1e41/attachment.sig>

[PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs

[Russell King - ARM Linux]

On Sat, Jan 26, 2013 at 05:49:29PM +0800, Mark Brown wrote:
> Oh, ffs.  This is a false positive from the compiler - there is no case
> where it can actually do this as we will bail out before the walk if the
> list is empty so we'll always take at least one trip through our
> list_for_each_entry() and either return or set ret.  It should be smart
> enough to work out that the list_empty() means list_for_each_entry()
> will iterate over at least one entry or more conservative in what it
> warns about.

Why not code the function in a way that avoids the problem altogether?

	/*
	 * This should never happen; we return above if we fail to
	 * allocate and we should never be in this code if there are
	 * no registers at all.
	 */
-	if (list_empty(&map->debugfs_off_cache)) {
-		WARN_ON(list_empty(&map->debugfs_off_cache));
-		return base;
-	}
+	WARN_ON(list_empty(&map->debugfs_off_cache));
+	ret = base;

	/* Find the relevant block */
	list_for_each_entry(c, &map->debugfs_off_cache, list) {
		if (from >= c->min && from <= c->max) {
			*pos = c->min;
			return c->base_reg;
		}

		*pos = c->min;
		ret = c->base_reg;
	}

	return ret;

[PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs

[Mark Brown]

On Sat, Jan 26, 2013 at 09:59:16AM +0000, Russell King - ARM Linux wrote:

> Why not code the function in a way that avoids the problem altogether?

That'd do the trick too; feel free to submit a patch...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130126/d93dd193/attachment.sig>

[PATCH 11/19] regmap: avoid undefined return from regmap_read_debugfs

[Russell King - ARM Linux]

On Sat, Jan 26, 2013 at 06:03:28PM +0800, Mark Brown wrote:
> On Sat, Jan 26, 2013 at 09:59:16AM +0000, Russell King - ARM Linux wrote:
> 
> > Why not code the function in a way that avoids the problem altogether?
> 
> That'd do the trick too; feel free to submit a patch...

Sorry, got other things which need doing, so if you want that expect it
sometime next month if I even remember.

[PATCH 11/19] regmap: regmap: avoid spurious warning in regmap_read_debugfs

[Arnd Bergmann]

From: Russell King <rmk+kernel@arm.linux.org.uk>

Gcc warns about the case where regmap_read_debugfs tries to walk an
empty map->debugfs_off_cache list, which would results in uninitialized
variable getting returned, if we hadn't checked the same condition
just before that.

After an originally suggested inferior patch from Arnd Bergmann,
this is the solution that Russell King came up with, sidestepping
the problem by merging the error case for an empty list with the
normal path.

Without this patch, building mxs_defconfig results in:

drivers/base/regmap/regmap-debugfs.c: In function 'regmap_read_debugfs':
drivers/base/regmap/regmap-debugfs.c:147:9: : warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]

Reported-by: Vincent Stehle <v-stehle@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/drivers/base/regmap/regmap-debugfs.c b/drivers/base/regmap/regmap-debugfs.c
index 41b65f6..ef35c25 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -128,10 +128,8 @@ static unsigned int regmap_debugfs_get_dump_start(struct regmap *map,
 	 * allocate and we should never be in this code if there are
 	 * no registers at all.
 	 */
-	if (list_empty(&map->debugfs_off_cache)) {
-		WARN_ON(list_empty(&map->debugfs_off_cache));
-		return base;
-	}
+	WARN_ON(list_empty(&map->debugfs_off_cache));
+	ret = base;
 
 	/* Find the relevant block */
 	list_for_each_entry(c, &map->debugfs_off_cache, list) {

[PATCH 11/19] regmap: regmap: avoid spurious warning in regmap_read_debugfs

[Mark Brown]

On Sat, Jan 26, 2013 at 11:45:35AM +0000, Arnd Bergmann wrote:

> Gcc warns about the case where regmap_read_debugfs tries to walk an
> empty map->debugfs_off_cache list, which would results in uninitialized
> variable getting returned, if we hadn't checked the same condition
> just before that.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130127/52b0ef7a/attachment.sig>

[PATCH 03/19] ARM: msm: proc_comm_boot_wait should not be __init

[Olof Johansson]

On Fri, Jan 25, 2013 at 10:16:31AM -0800, David Brown wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > msm_smd_probe is a driver probe function and may get
> > called after the __init time, so it must not call
> > any __init function, as the link-time warning reports.
> > Take away the __init annotation on proc_comm_boot_wait
> > to fix this.
> >
> > Without this patch, building msm_defconfig results in:
> >
> > WARNING: vmlinux.o(.text+0xb048): Section mismatch in reference from the function msm_smd_probe() to the function .init.text:proc_comm_boot_wait()
> > The function msm_smd_probe() references
> > the function __init proc_comm_boot_wait().
> > This is often because msm_smd_probe lacks a __init
> > annotation or the annotation of proc_comm_boot_wait is wrong.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: David Brown <davidb@codeaurora.org>
> > Cc: Bryan Huntsman <bryanh@codeaurora.org>
> > Cc: Daniel Walker <c_dwalke@quicinc.com>
> > Cc: linux-arm-msm at vger.kernel.org
> > ---
> >  arch/arm/mach-msm/proc_comm.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Arnd, you're welcome to pull this into your tree:
> Acked-by: David Brown <davidb@codeaurora.org>
> 
> I don't forsee any conflicts with upcoming patches.

Applied.


-Olof