Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

15 views
Skip to first unread message

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:01 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Peter Boonstoppel <pboons...@nvidia.com>
Cc: Peter Zijlstra <a.p.zi...@chello.nl>
Cc: Paul Turner <p...@google.com>
Cc: Ingo Molnar <mi...@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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:01 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Nicolas Ferre <nicola...@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plag...@jcrosoft.com>
Cc: Andrew Victor <li...@maxim.org.za>
Cc: Albin Tonnerre <albin.t...@free-electrons.com>
Cc: Daniel Lezcano <daniel....@linaro.org>
---
arch/arm/mach-at91/cpuidle.c | 2 +-
arch/arm/mach-at91/pm.c | 2 +-
arch/arm/mach-at91/pm.h | 8 --------
3 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0c63815..208d486 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -36,7 +36,7 @@ static int at91_enter_idle(struct cpuidle_device *dev,
{
if (cpu_is_at91rm9200())
at91rm9200_standby();
- else if (cpu_is_at91sam9g45())
+ else if (cpu_is_at91sam9g45() || cpu_is_at91sam9263())
at91sam9g45_standby();
else
at91sam9_standby();
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index adb6db8..f6bd4fa 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -265,7 +265,7 @@ static int at91_pm_enter(suspend_state_t state)
*/
if (cpu_is_at91rm9200())
at91rm9200_standby();
- else if (cpu_is_at91sam9g45())
+ else if (cpu_is_at91sam9g45() || cpu_is_at91sam9263())
at91sam9g45_standby();
else
at91sam9_standby();
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 38f467c..5252216 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -70,14 +70,6 @@ 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.
- */
-#warning Assuming EB1 SDRAM controller is *NOT* used
-#endif
-
static inline void at91sam9_standby(void)
{
u32 saved_lpr, lpr;

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:01 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Paul Turner <p...@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",

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:02 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Mark Brown <bro...@opensource.wolfsonmicro.com>
Cc: Greg Kroah-Hartman <gre...@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

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:02 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Nicolas Ferre <nicola...@atmel.com>
Cc: Grant Likely <grant....@secretlab.ca>
Cc: spi-deve...@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);

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:01 AM1/25/13
to
Hi everyone,

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

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'
mac80211: avoid a build warning
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 | 8 --------
arch/arm/mach-msm/proc_comm.h | 2 +-
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/mac80211/tx.c | 8 ++++----
net/sunrpc/svc.c | 2 +-
scripts/sortextable.h | 2 +-
sound/oss/dmabuf.c | 3 ++-
28 files changed, 59 insertions(+), 73 deletions(-)

--
1.8.0

Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Linus Walleij <linus....@linaro.org>
Cc: Mark Brown <bro...@opensource.wolfsonmicro.com>
Cc: Nicolas Ferre <nicola...@atmel.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Russell King <li...@arm.linux.org.uk>
Cc: Samuel Ortiz <sa...@linux.intel.com>
Cc: net...@vger.kernel.org

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:01 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Stanislav Kinsbursky <skins...@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

Johannes Berg

unread,
Jan 25, 2013, 9:20:02 AM1/25/13
to
On Fri, 2013-01-25 at 14:14 +0000, Arnd Bergmann wrote:
> gcc cannot prove that the value of sdata->vif.type does not
> change between the switch() statement and the second
> comparison to NL80211_IFTYPE_AP, causing a harmless
> warning.
> Slightly reordering the code makes the warning go away
> with no functional change.

Thanks!

Applied.

johannes

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:02 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Dmitry Torokhov <dmitry....@gmail.com>
Cc: Vojtech Pavlik <voj...@suse.cz>
Cc: Ben Dooks <ben-...@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

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:03 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Jean-Nicolas Graux <jean-nico...@stericsson.com>
Cc: Linus Walleij <linus....@linaro.org>
Cc: Srinidhi Kasagar <srinidhi...@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

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:03 AM1/25/13
to
gcc cannot prove that the value of sdata->vif.type does not
change between the switch() statement and the second
comparison to NL80211_IFTYPE_AP, causing a harmless
warning.
Slightly reordering the code makes the warning go away
with no functional change.

Without this patch, building ARM at91sam9g45_defconfig with
gcc-4.6 results in:

net/mac80211/tx.c: In function 'ieee80211_subif_start_xmit':
net/mac80211/tx.c:1797:22: warning: 'chanctx_conf' may be used uninitialized in this function [-Wuninitialized]

Signed-off-by: Arnd Bergmann <ar...@arndb.de>
Cc: Johannes Berg <joha...@sipsolutions.net>
Cc: "John W. Linville" <linv...@tuxdriver.com>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: linux-w...@vger.kernel.org
Cc: net...@vger.kernel.org
---
net/mac80211/tx.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index e9eadc4..df589bf 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1784,16 +1784,16 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
break;
/* fall through */
case NL80211_IFTYPE_AP:
+ if (sdata->vif.type == NL80211_IFTYPE_AP)
+ chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
+ if (!chanctx_conf)
+ goto fail_rcu;
fc |= cpu_to_le16(IEEE80211_FCTL_FROMDS);
/* DA BSSID SA */
memcpy(hdr.addr1, skb->data, ETH_ALEN);
memcpy(hdr.addr2, sdata->vif.addr, ETH_ALEN);
memcpy(hdr.addr3, skb->data + ETH_ALEN, ETH_ALEN);
hdrlen = 24;
- if (sdata->vif.type == NL80211_IFTYPE_AP)
- chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
- if (!chanctx_conf)
- goto fail_rcu;
band = chanctx_conf->def.chan->band;
break;
case NL80211_IFTYPE_WDS:
--
1.8.0

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:03 AM1/25/13
to
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 <ar...@arndb.de>
Cc: "J. Bruce Fields" <bfi...@redhat.com>
Cc: Trond Myklebust <Trond.M...@netapp.com>
Cc: linu...@vger.kernel.org
Cc: net...@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

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:03 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Samuel Ortiz <sa...@linux.intel.com>
Cc: Peter Ujfalusi <peter.u...@ti.com>
Cc: Kevin Hilman <khi...@ti.com>
Cc: Amit Kucheria <amit.k...@linaro.org>
---
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

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:02 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Linus Walleij <linus....@linaro.org>
Cc: Tomasz Figa <t.f...@samsung.com>
Cc: Kukjin Kim <kgen...@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

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:03 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Wim Van Sebroeck <w...@iguana.be>
Cc: linux-w...@vger.kernel.org
Cc: Nicolas Ferre <nicola...@atmel.com>
Cc: Fabio Porcedda <fabio.p...@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

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:03 AM1/25/13
to
From: sahara <keun-...@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-...@windriver.com>
Signed-off-by: Arnd Bergmann <ar...@arndb.de>
Cc: Dave Martin <dave....@linaro.org>
Cc: Steven Rostedt <ros...@goodmis.org>
Cc: Russell King <li...@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

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:02 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Simon Horman <ho...@verge.net.au>
Cc: linu...@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

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:02 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Russell King <li...@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

Arnd Bergmann

unread,
Jan 25, 2013, 9:20:02 AM1/25/13
to
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 <ar...@arndb.de>
Cc: David Daney <david...@cavium.com>
Cc: "H. Peter Anvin" <h...@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

Arnd Bergmann

unread,
Jan 25, 2013, 9:30:02 AM1/25/13
to
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 <ar...@arndb.de>
Cc: David Brown <dav...@codeaurora.org>
Cc: Bryan Huntsman <bry...@codeaurora.org>
Cc: Daniel Walker <c_dw...@quicinc.com>
Cc: linux-...@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

Arnd Bergmann

unread,
Jan 25, 2013, 9:30:02 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Jaroslav Kysela <pe...@perex.cz>
Cc: Takashi Iwai <ti...@suse.de>
Cc: alsa-...@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

Peter Ujfalusi

unread,
Jan 25, 2013, 9:30:02 AM1/25/13
to
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.u...@ti.com>

> Signed-off-by: Arnd Bergmann <ar...@arndb.de>
> Cc: Samuel Ortiz <sa...@linux.intel.com>
> Cc: Peter Ujfalusi <peter.u...@ti.com>
> Cc: Kevin Hilman <khi...@ti.com>
> Cc: Amit Kucheria <amit.k...@linaro.org>
> ---
> 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) {
>


--
P�ter

Amit Kucheria

unread,
Jan 25, 2013, 9:40:01 AM1/25/13
to
On Fri, Jan 25, 2013 at 2:14 PM, Arnd Bergmann <ar...@arndb.de> 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

Reviewed-by: Amit Kucheria <amit.k...@linaro.org>

Arnd Bergmann

unread,
Jan 25, 2013, 9:40:02 AM1/25/13
to
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.u...@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

Jean-Christophe PLAGNIOL-VILLARD

unread,
Jan 25, 2013, 11:00:01 AM1/25/13
to
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

Best Regards,
J.

Arnd Bergmann

unread,
Jan 25, 2013, 11:00:02 AM1/25/13
to
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 <ar...@arndb.de>
Cc: Nicolas Ferre <nicola...@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plag...@jcrosoft.com>
Cc: Andrew Victor <li...@maxim.org.za>
Cc: Albin Tonnerre <albin.t...@free-electrons.com>
Cc: Daniel Lezcano <daniel....@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)
{

Paul Turner

unread,
Jan 25, 2013, 11:10:02 AM1/25/13
to
On Fri, Jan 25, 2013 at 6:14 AM, Arnd Bergmann <ar...@arndb.de> wrote:
> 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 <ar...@arndb.de>
> Cc: Peter Boonstoppel <pboons...@nvidia.com>
> Cc: Peter Zijlstra <a.p.zi...@chello.nl>
> Cc: Paul Turner <p...@google.com>
> Cc: Ingo Molnar <mi...@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)

Looks good.

Reviewed-by: Paul Turner <p...@google.com>

> {
> struct cfs_rq *cfs_rq;
>
> --
> 1.8.0

Paul Turner

unread,
Jan 25, 2013, 11:10:02 AM1/25/13
to
On Fri, Jan 25, 2013 at 6:14 AM, Arnd Bergmann <ar...@arndb.de> wrote:
Looks good.

Reviewed-by: Paul Turner <p...@google.com>

Dave Martin

unread,
Jan 25, 2013, 11:40:01 AM1/25/13
to
On Fri, Jan 25, 2013 at 02:14:36PM +0000, Arnd Bergmann wrote:
> From: sahara <keun-...@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.

I did have a brief look at this a few months back, but ran out of ideas
for a quick fix. The unwinder implementation is too complex to just
rip out all the calls to traced common code without a significant rewrite.

One possibility would be to make unwind_frame check a flag (either a percpu
flag, or more likely a thread flag if unwind_frame can be called in
preemptible context -- I can't see why not) to prevent it self-recursing.
If self-recursion occurs through the ftrace code, unwind_frame would
just return an error instead of going into a self-recursion loop.

This would still mean that traced functions could get called from inside
return_address() once before recursion is quenched. If this would break
ftrace, I'm not sure how to fix it.

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?

Cheers
---Dave

Steven Rostedt

unread,
Jan 25, 2013, 11:50:01 AM1/25/13
to
[ I got an error with linux-ar...@list.infradead.org and had to
remove from CC ]

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)

-- Steve

Dave Martin

unread,
Jan 25, 2013, 12:10:02 PM1/25/13
to
On Fri, Jan 25, 2013 at 11:44:14AM -0500, Steven Rostedt wrote:
> [ I got an error with linux-ar...@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

Steven Rostedt

unread,
Jan 25, 2013, 12:10:03 PM1/25/13
to
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

Dave Martin

unread,
Jan 25, 2013, 12:30:01 PM1/25/13
to
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

Kukjin Kim

unread,
Jan 25, 2013, 1:00:01 PM1/25/13
to
Arnd Bergmann wrote:
>
> 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 <ar...@arndb.de>
> Cc: Linus Walleij <linus....@linaro.org>
> Cc: Tomasz Figa <t.f...@samsung.com>
> Cc: Kukjin Kim <kgen...@samsung.com>

Acked-by: Kukjin Kim <kgen...@samsung.com>

Thanks.

- Kukjin

David Brown

unread,
Jan 25, 2013, 1:20:02 PM1/25/13
to
Arnd Bergmann <ar...@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 <ar...@arndb.de>
> Cc: David Brown <dav...@codeaurora.org>
> Cc: Bryan Huntsman <bry...@codeaurora.org>
> Cc: Daniel Walker <c_dw...@quicinc.com>
> Cc: linux-...@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 <dav...@codeaurora.org>

I don't forsee any conflicts with upcoming patches.

David

--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:02 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Nicolas Ferre <nicola...@atmel.com>
Cc: Grant Likely <grant....@secretlab.ca>
Cc: spi-deve...@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

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:02 PM1/25/13
to
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(-)

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:02 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Paul Turner <p...@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",

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:02 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Linus Walleij <linus....@linaro.org>
Cc: Tomasz Figa <t.f...@samsung.com>
Cc: Kukjin Kim <kgen...@samsung.com>

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:02 PM1/25/13
to
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 <ar...@arndb.de>
Cc: David Brown <dav...@codeaurora.org>
Cc: Bryan Huntsman <bry...@codeaurora.org>
Cc: linux-...@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

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:02 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Jean-Nicolas Graux <jean-nico...@stericsson.com>
Cc: Linus Walleij <linus....@linaro.org>
Cc: Srinidhi Kasagar <srinidhi...@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;

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:02 PM1/25/13
to
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 <ar...@arndb.de>
Cc: "J. Bruce Fields" <bfi...@redhat.com>
Cc: Trond Myklebust <Trond.M...@netapp.com>
Cc: linu...@vger.kernel.org
Cc: net...@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);

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:02 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Nicolas Ferre <nicola...@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plag...@jcrosoft.com>
Cc: Andrew Victor <li...@maxim.org.za>
Cc: Albin Tonnerre <albin.t...@free-electrons.com>
Cc: Daniel Lezcano <daniel....@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(-)

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:02 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Simon Horman <ho...@verge.net.au>
Cc: linu...@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

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:02 PM1/25/13
to
From: sahara <keun-...@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-...@windriver.com>
Signed-off-by: Arnd Bergmann <ar...@arndb.de>
Cc: Dave Martin <dave....@linaro.org>
Cc: Steven Rostedt <ros...@goodmis.org>
Cc: Russell King <li...@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 +++

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:03 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Russell King <li...@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,

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:02 PM1/25/13
to
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 <ar...@arndb.de>
Cc: David Daney <david...@cavium.com>
Cc: "H. Peter Anvin" <h...@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

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:03 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Mark Brown <bro...@opensource.wolfsonmicro.com>
Cc: Greg Kroah-Hartman <gre...@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

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:03 PM1/25/13
to
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 <ar...@arndb.de>
Reviewed-by: Peter Ujfalusi <peter.u...@ti.com>
Reviewed-by: Amit Kucheria <amit.k...@linaro.org>
Cc: Samuel Ortiz <sa...@linux.intel.com>
Cc: Kevin Hilman <khi...@deeprootsystems.com>
Cc: "Kristo, Tero" <t-kr...@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) {

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:03 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Peter Boonstoppel <pboons...@nvidia.com>
Cc: Peter Zijlstra <a.p.zi...@chello.nl>
Cc: Paul Turner <p...@google.com>
Cc: Ingo Molnar <mi...@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;

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:03 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Wim Van Sebroeck <w...@iguana.be>
Cc: linux-w...@vger.kernel.org
Cc: Nicolas Ferre <nicola...@atmel.com>
Cc: Fabio Porcedda <fabio.p...@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 */ }
};

Arnd Bergmann

unread,
Jan 25, 2013, 5:50:03 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Dmitry Torokhov <dmitry....@gmail.com>
Cc: Vojtech Pavlik <voj...@suse.cz>
Cc: Ben Dooks <ben-...@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;

Arnd Bergmann

unread,
Jan 25, 2013, 6:00:01 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Jaroslav Kysela <pe...@perex.cz>
Cc: Takashi Iwai <ti...@suse.de>
Cc: alsa-...@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;

Arnd Bergmann

unread,
Jan 25, 2013, 6:00:01 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Stanislav Kinsbursky <skins...@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)

Arnd Bergmann

unread,
Jan 25, 2013, 6:00:01 PM1/25/13
to
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 <ar...@arndb.de>
Cc: Russell King <li...@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.

Myklebust, Trond

unread,
Jan 25, 2013, 6:10:02 PM1/25/13
to
Alternatively, just declare it using the RPC_IFDEBUG() macro.

Cheers
Trond

David Daney

unread,
Jan 25, 2013, 6:10:02 PM1/25/13
to
On 01/25/2013 06:14 AM, Arnd Bergmann wrote:
> 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 <ar...@arndb.de>
> Cc: David Daney <david...@cavium.com>
> Cc: "H. Peter Anvin" <h...@zytor.com>

Leaving that enabled was an oversight. Thanks for fixing it...

Acked-by: David Daney <david...@cavium.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
>

Arnd Bergmann

unread,
Jan 25, 2013, 6:50:02 PM1/25/13
to
On Friday 25 January 2013, Myklebust, Trond wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:ar...@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 <ar...@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 <ar...@arndb.de>
Cc: "J. Bruce Fields" <bfi...@redhat.com>
Cc: Trond Myklebust <Trond.M...@netapp.com>
Cc: linu...@vger.kernel.org
Cc: net...@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);

Arnd Bergmann

unread,
Jan 25, 2013, 7:50:02 PM1/25/13
to
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-ar...@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

Mark Brown

unread,
Jan 25, 2013, 11:50:01 PM1/25/13
to
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.
signature.asc

Mark Brown

unread,
Jan 26, 2013, 12:00:01 AM1/26/13
to
Resending with corrected list address; to be clear please don't send
this.
signature.asc

Arnd Bergmann

unread,
Jan 26, 2013, 4:20:01 AM1/26/13
to
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

Mark Brown

unread,
Jan 26, 2013, 4:50:01 AM1/26/13
to
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 :/
signature.asc

Russell King - ARM Linux

unread,
Jan 26, 2013, 5:00:01 AM1/26/13
to
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;

Russell King - ARM Linux

unread,
Jan 26, 2013, 5:10:01 AM1/26/13
to
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.

Russell King - ARM Linux

unread,
Jan 26, 2013, 5:10:01 AM1/26/13
to
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.

Mark Brown

unread,
Jan 26, 2013, 5:10:02 AM1/26/13
to
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?

signature.asc

Russell King - ARM Linux

unread,
Jan 26, 2013, 6:10:02 AM1/26/13
to
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:ar...@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: 20130108212...@fieldses.org

Arnd Bergmann

unread,
Jan 26, 2013, 6:50:02 AM1/26/13
to
From: Russell King <rmk+k...@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-st...@ti.com>
Cc: Mark Brown <bro...@opensource.wolfsonmicro.com>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <ar...@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) {

tip-bot for Arnd Bergmann

unread,
Jan 26, 2013, 7:20:01 AM1/26/13
to
Commit-ID: 38dc3348e36d6cbe6ad51d771e4db948cda5b0e3
Gitweb: http://git.kernel.org/tip/38dc3348e36d6cbe6ad51d771e4db948cda5b0e3
Author: Arnd Bergmann <ar...@arndb.de>
AuthorDate: Fri, 25 Jan 2013 14:14:22 +0000
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Fri, 25 Jan 2013 15:23:14 +0100

sched: Fix warning in kernel/sched/fair.c

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 <ar...@arndb.de>
Cc: Peter Boonstoppel <pboons...@nvidia.com>
Cc: Peter Zijlstra <a.p.zi...@chello.nl>
Cc: Paul Turner <p...@google.com>
Cc: linux-ar...@list.infradead.org
Link: http://lkml.kernel.org/r/1359123276-15833-6-...@arndb.de
Signed-off-by: Ingo Molnar <mi...@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;

tip-bot for Arnd Bergmann

unread,
Jan 26, 2013, 7:20:02 AM1/26/13
to
Commit-ID: cff3c124a7e82ca0ea1d6864b27ef18c403c0773
Gitweb: http://git.kernel.org/tip/cff3c124a7e82ca0ea1d6864b27ef18c403c0773
Author: Arnd Bergmann <ar...@arndb.de>
AuthorDate: Fri, 25 Jan 2013 14:14:23 +0000
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Fri, 25 Jan 2013 15:23:15 +0100

sched/debug: Fix format string for 32-bit platforms

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 <ar...@arndb.de>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Paul Turner <p...@google.com>
Cc: linux-ar...@list.infradead.org
Link: http://lkml.kernel.org/r/1359123276-15833-7-...@arndb.de
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
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",

Arnd Bergmann

unread,
Jan 26, 2013, 8:40:02 AM1/26/13
to
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:ar...@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: 20130108212...@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

Arnd Bergmann

unread,
Jan 26, 2013, 8:40:02 AM1/26/13
to
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

Samuel Ortiz

unread,
Jan 26, 2013, 7:50:02 PM1/26/13
to
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 <ar...@arndb.de>
> Reviewed-by: Peter Ujfalusi <peter.u...@ti.com>
> Reviewed-by: Amit Kucheria <amit.k...@linaro.org>
> Cc: Samuel Ortiz <sa...@linux.intel.com>
> Cc: Kevin Hilman <khi...@deeprootsystems.com>
> Cc: "Kristo, Tero" <t-kr...@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/

Mark Brown

unread,
Jan 26, 2013, 10:00:02 PM1/26/13
to
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.
signature.asc

Simon Horman

unread,
Jan 27, 2013, 7:30:01 PM1/27/13
to
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+...@verge.net.au>

Keun-O Park

unread,
Jan 27, 2013, 9:40:01 PM1/27/13
to
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-...@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-...@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

Nicolas Ferre

unread,
Jan 28, 2013, 3:40:02 AM1/28/13
to
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 <ar...@arndb.de>
> Cc: Nicolas Ferre <nicola...@atmel.com>

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

> Cc: Grant Likely <grant....@secretlab.ca>
> Cc: spi-deve...@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

Nicolas Ferre

unread,
Jan 28, 2013, 3:40:02 AM1/28/13
to
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 <ar...@arndb.de>
> Cc: Wim Van Sebroeck <w...@iguana.be>
> Cc: linux-w...@vger.kernel.org
> Cc: Nicolas Ferre <nicola...@atmel.com>

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

Thanks,

> Cc: Fabio Porcedda <fabio.p...@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 */ }

Fabio Porcedda

unread,
Jan 28, 2013, 5:00:02 AM1/28/13
to
Hi Arnd,

On Fri, Jan 25, 2013 at 11:44 PM, Arnd Bergmann <ar...@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 <ar...@arndb.de>
> Cc: Wim Van Sebroeck <w...@iguana.be>
> Cc: linux-w...@vger.kernel.org
> Cc: Nicolas Ferre <nicola...@atmel.com>
> Cc: Fabio Porcedda <fabio.p...@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

Fabio Porcedda

unread,
Jan 28, 2013, 5:20:01 AM1/28/13
to
On Mon, Jan 28, 2013 at 9:32 AM, Nicolas Ferre <nicola...@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 <ar...@arndb.de>
>> Cc: Wim Van Sebroeck <w...@iguana.be>
>> Cc: linux-w...@vger.kernel.org
>> Cc: Nicolas Ferre <nicola...@atmel.com>
>
> Acked-by: Nicolas Ferre <nicola...@atmel.com>
>
> Thanks,
>
>> Cc: Fabio Porcedda <fabio.p...@gmail.com>

Tested-by: Fabio Porcedda <fabio.p...@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

Dave Martin

unread,
Jan 28, 2013, 8:00:02 AM1/28/13
to
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

[...]
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

J. Bruce Fields

unread,
Jan 28, 2013, 6:20:02 PM1/28/13
to
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:ar...@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: 20130108212...@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.


Keun-O Park

unread,
Jan 28, 2013, 9:20:01 PM1/28/13
to
On Mon, Jan 28, 2013 at 9:50 PM, Dave Martin <dave....@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?
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

Linus Walleij

unread,
Jan 29, 2013, 5:10:02 PM1/29/13
to
On Fri, Jan 25, 2013 at 3:14 PM, Arnd Bergmann <ar...@arndb.de> wrote:

> 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 <ar...@arndb.de>
> Cc: Linus Walleij <linus....@linaro.org>
> Cc: Tomasz Figa <t.f...@samsung.com>
> Cc: Kukjin Kim <kgen...@samsung.com>

Applied with Kukjin's ACK, thanks!

Yours,
Linus Walleij

Linus Walleij

unread,
Jan 29, 2013, 5:20:01 PM1/29/13
to
On Fri, Jan 25, 2013 at 3:14 PM, Arnd Bergmann <ar...@arndb.de> wrote:

> 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 <ar...@arndb.de>
> Cc: Jean-Nicolas Graux <jean-nico...@stericsson.com>
> Cc: Linus Walleij <linus....@linaro.org>
> Cc: Srinidhi Kasagar <srinidhi...@stericsson.com>

Patch applied, thanks!

Wim Van Sebroeck

unread,
Jan 30, 2013, 2:40:02 PM1/30/13
to
Hi Arnd,

> 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 <ar...@arndb.de>
> Cc: Wim Van Sebroeck <w...@iguana.be>
> Cc: linux-w...@vger.kernel.org
> Cc: Nicolas Ferre <nicola...@atmel.com>
> Cc: Fabio Porcedda <fabio.p...@gmail.com>

Added to linux-watchdog-next.

Kind regards,
Wim.

Grant Likely

unread,
Feb 5, 2013, 8:40:01 AM2/5/13
to
On Fri, 25 Jan 2013 14:14:31 +0000, Arnd Bergmann <ar...@arndb.de> wrote:
> 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]

Looks good, but I took a deeper look and it is incomplete. I found an
whole bunch more references. I've crafted a new patch to get rid of
them. I'll post and commit it to my tree.

g.

Olof Johansson

unread,
Feb 11, 2013, 8:50:02 PM2/11/13
to
On Fri, Jan 25, 2013 at 10:16:31AM -0800, David Brown wrote:
> Arnd Bergmann <ar...@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 <ar...@arndb.de>
> > Cc: David Brown <dav...@codeaurora.org>
> > Cc: Bryan Huntsman <bry...@codeaurora.org>
> > Cc: Daniel Walker <c_dw...@quicinc.com>
> > Cc: linux-...@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 <dav...@codeaurora.org>
>
> I don't forsee any conflicts with upcoming patches.

Applied.


-Olof

Nicolas Ferre

unread,
Apr 18, 2013, 9:50:02 AM4/18/13
to
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 <ar...@arndb.de>
> Cc: Nicolas Ferre <nicola...@atmel.com>

Acked-by: Nicolas Ferre <nicola...@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 <plag...@jcrosoft.com>
> Cc: Andrew Victor <li...@maxim.org.za>
> Cc: Albin Tonnerre <albin.t...@free-electrons.com>
> Cc: Daniel Lezcano <daniel....@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

Arnd Bergmann

unread,
Apr 18, 2013, 10:20:02 AM4/18/13
to
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 <ar...@arndb.de>
> > Cc: Nicolas Ferre <nicola...@atmel.com>
>
> Acked-by: Nicolas Ferre <nicola...@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 <plag...@jcrosoft.com>
> > Cc: Andrew Victor <li...@maxim.org.za>
> > Cc: Albin Tonnerre <albin.t...@free-electrons.com>
> > Cc: Daniel Lezcano <daniel....@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

Nicolas Ferre

unread,
Apr 18, 2013, 10:30:02 AM4/18/13
to
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 <ar...@arndb.de>
>>> Cc: Nicolas Ferre <nicola...@atmel.com>
>>
>> Acked-by: Nicolas Ferre <nicola...@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 <plag...@jcrosoft.com>
>>> Cc: Andrew Victor <li...@maxim.org.za>
>>> Cc: Albin Tonnerre <albin.t...@free-electrons.com>
>>> Cc: Daniel Lezcano <daniel....@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

Arnd Bergmann

unread,
Apr 18, 2013, 10:30:02 AM4/18/13
to
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

Daniel Lezcano

unread,
Apr 18, 2013, 10:40:02 AM4/18/13
to
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

Arnd Bergmann

unread,
Jan 7, 2014, 9:40:01 AM1/7/14
to
On Tuesday 29 January 2013, Keun-O Park wrote:
> On Mon, Jan 28, 2013 at 9:50 PM, Dave Martin <dave....@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

Russell King - ARM Linux

unread,
Jan 7, 2014, 9:50:01 AM1/7/14
to
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....@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".

Arnd Bergmann

unread,
Jan 7, 2014, 10:50:02 AM1/7/14
to
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);

Dave Martin

unread,
Jan 7, 2014, 11:40:02 AM1/7/14
to
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

Steven Rostedt

unread,
Jan 7, 2014, 1:40:02 PM1/7/14
to
On Tue, 7 Jan 2014 16:36:29 +0000
Dave Martin <Dave....@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
0 new messages