* [PATCH 11/16] pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
The sharpsl_pcmcia_ops structure gets passed into
sa11xx_drv_pcmcia_probe, where it gets accessed at run-time,
unlike all other pcmcia drivers that pass their structures
into platform_device_add_data, which makes a copy.
This means the gcc warning is valid and the structure
must not be marked as __initdata.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Pavel Machek <pavel@suse.cz>
Cc: linux-pcmcia at lists.infradead.org
Cc: Jochen Friedrich <jochen@scram.de>
Cc: stable at vger.kernel.org
---
drivers/pcmcia/pxa2xx_sharpsl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pcmcia/pxa2xx_sharpsl.c b/drivers/pcmcia/pxa2xx_sharpsl.c
index b066273..7dd879c 100644
--- a/drivers/pcmcia/pxa2xx_sharpsl.c
+++ b/drivers/pcmcia/pxa2xx_sharpsl.c
@@ -194,7 +194,7 @@ static void sharpsl_pcmcia_socket_suspend(struct soc_pcmcia_socket *skt)
sharpsl_pcmcia_init_reset(skt);
}
-static struct pcmcia_low_level sharpsl_pcmcia_ops __initdata = {
+static struct pcmcia_low_level sharpsl_pcmcia_ops = {
.owner = THIS_MODULE,
.hw_init = sharpsl_pcmcia_hw_init,
.socket_state = sharpsl_pcmcia_socket_state,
--
1.7.10
^ permalink raw reply related
* [PATCH 10/16] clk: don't mark clkdev_add_table as init
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
s3c2440_clk_add is a subsys_interface method and calls clkdev_add_table,
which means we might be calling it after the __init section is
discarded.
Without this patch, building mini2440_defconfig results in:
WARNING: vmlinux.o(.text+0x9848): Section mismatch in reference from the function s3c2440_clk_add() to the function .init.text:clkdev_add_table()
The function s3c2440_clk_add() references
the function __init clkdev_add_table().
This is often because s3c2440_clk_add lacks a __init
annotation or the annotation of clkdev_add_table is wrong.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/clk/clkdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..6956857 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -179,7 +179,7 @@ void clkdev_add(struct clk_lookup *cl)
}
EXPORT_SYMBOL(clkdev_add);
-void __init clkdev_add_table(struct clk_lookup *cl, size_t num)
+void clkdev_add_table(struct clk_lookup *cl, size_t num)
{
mutex_lock(&clocks_mutex);
while (num--) {
--
1.7.10
^ permalink raw reply related
* [PATCH 09/16] USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
The __devinit section is going away soon, but while it's
still there, we get a correct warning about
ehci_orion_conf_mbus_windows being discarded before
its caller, so it should be marked __devinit rather than
__init.
Without this patch, building dove_defconfig results in:
WARNING: drivers/usb/host/built-in.o(.devinit.text+0x8a4): Section mismatch in reference from the function ehci_orion_drv_probe() to the function .init.text:ehci_orion_conf_mbus_windows()
The function __devinit ehci_orion_drv_probe() references
a function __init ehci_orion_conf_mbus_windows().
If ehci_orion_conf_mbus_windows is only used by ehci_orion_drv_probe then
annotate ehci_orion_conf_mbus_windows with a matching annotation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb at vger.kernel.org
---
drivers/usb/host/ehci-orion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index 8892d36..1f5dd5e 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -160,7 +160,7 @@ static const struct hc_driver ehci_orion_hc_driver = {
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
};
-static void __init
+static void __devinit
ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
const struct mbus_dram_target_info *dram)
{
--
1.7.10
^ permalink raw reply related
* [PATCH 08/16] ipvs: fix ip_vs_set_timeout debug messages
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
The ip_vs_set_timeout function sets timeouts for TCP and UDP, which
can be enabled independently at compile time. The debug message
always prints both timeouts that are passed into the function,
but if one is disabled, the message will show uninitialized data.
This splits the debug message into two separte IP_VS_DBG statements
that are in the same #ifdef section to ensure we only print the
text about what is actually going on.
Without this patch, building ARM ixp4xx_defconfig results in:
net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev at vger.kernel.org
Cc: Simon Horman <horms@verge.net.au>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: netfilter-devel at vger.kernel.org
Cc: netfilter at vger.kernel.org
Cc: coreteam at netfilter.org
---
net/netfilter/ipvs/ip_vs_ctl.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index f51013c..f3a66c3 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -2237,12 +2237,11 @@ static int ip_vs_set_timeout(struct net *net, struct ip_vs_timeout_user *u)
struct ip_vs_proto_data *pd;
#endif
- IP_VS_DBG(2, "Setting timeout tcp:%d tcpfin:%d udp:%d\n",
+#ifdef CONFIG_IP_VS_PROTO_TCP
+ IP_VS_DBG(2, "Setting timeout tcp:%d tcpfin:%d\n",
u->tcp_timeout,
- u->tcp_fin_timeout,
- u->udp_timeout);
+ u->tcp_fin_timeout);
-#ifdef CONFIG_IP_VS_PROTO_TCP
if (u->tcp_timeout) {
pd = ip_vs_proto_data_get(net, IPPROTO_TCP);
pd->timeout_table[IP_VS_TCP_S_ESTABLISHED]
@@ -2257,6 +2256,9 @@ static int ip_vs_set_timeout(struct net *net, struct ip_vs_timeout_user *u)
#endif
#ifdef CONFIG_IP_VS_PROTO_UDP
+ IP_VS_DBG(2, "Setting timeout udp:%d\n",
+ u->udp_timeout);
+
if (u->udp_timeout) {
pd = ip_vs_proto_data_get(net, IPPROTO_UDP);
pd->timeout_table[IP_VS_UDP_S_NORMAL]
--
1.7.10
^ permalink raw reply related
* [PATCH 07/16] cgroup: fix warning when building without any subsys
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
In a configuration where the base cgroup support is enabled but
every single cgroup subsys is turned off, CGROUP_BUILTIN_SUBSYS_COUNT
is zero, which causes the sanity check code in cgroup_load_subsys
to trigger:
BUG_ON(ss->subsys_id >= CGROUP_BUILTIN_SUBSYS_COUNT);
BUG_ON(subsys[ss->subsys_id] != ss);
Gcc first confirms that subsys_id cannot be 0 or larger and consequently
warns in the second line.
kernel/cgroup.c: In function 'cgroup_load_subsys':
kernel/cgroup.c:4326:38: warning: array subscript is below array bounds [-Warray-bounds]
Since the subsys_id can never be less than zero, we can just change the
type to an unsigned int, which makes the warning go away.
Found by building ARM cns3420vb_defconfig.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tejun Heo <tj@kernel.org>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Ben Blum <bblum@andrew.cmu.edu>
---
include/linux/cgroup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index c90eaa8..26b99df 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -475,7 +475,7 @@ struct cgroup_subsys {
void (*post_clone)(struct cgroup *cgrp);
void (*bind)(struct cgroup *root);
- int subsys_id;
+ unsigned int subsys_id;
int active;
int disabled;
int early_init;
--
1.7.10
^ permalink raw reply related
* [PATCH 06/16] mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
The definition of ARCH_SLAB_MINALIGN is architecture dependent
and can be either of type size_t or int. Comparing that value
with ARCH_KMALLOC_MINALIGN can cause harmless warnings on
platforms where they are different. Since both are always
small positive integer numbers, using the size_t type to compare
them is safe and gets rid of the warning.
Without this patch, building ARM collie_defconfig results in:
mm/slob.c: In function '__kmalloc_node':
mm/slob.c:431:152: warning: comparison of distinct pointer types lacks a cast [enabled by default]
mm/slob.c: In function 'kfree':
mm/slob.c:484:153: warning: comparison of distinct pointer types lacks a cast [enabled by default]
mm/slob.c: In function 'ksize':
mm/slob.c:503:153: warning: comparison of distinct pointer types lacks a cast [enabled by default]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
---
mm/slob.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/slob.c b/mm/slob.c
index 45d4ca7..497c55e 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -428,7 +428,7 @@ out:
void *__kmalloc_node(size_t size, gfp_t gfp, int node)
{
unsigned int *m;
- int align = max(ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);
+ int align = max_t(size_t, ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);
void *ret;
gfp &= gfp_allowed_mask;
@@ -481,7 +481,7 @@ void kfree(const void *block)
sp = virt_to_page(block);
if (PageSlab(sp)) {
- int align = max(ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);
+ int align = max_t(size_t, ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);
unsigned int *m = (unsigned int *)(block - align);
slob_free(m, *m + align);
} else
@@ -500,7 +500,7 @@ size_t ksize(const void *block)
sp = virt_to_page(block);
if (PageSlab(sp)) {
- int align = max(ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);
+ int align = max_t(size_t, ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);
unsigned int *m = (unsigned int *)(block - align);
return SLOB_UNITS(*m) * SLOB_UNIT;
} else
--
1.7.10
^ permalink raw reply related
* [PATCH 05/16] vfs: bogus warnings in fs/namei.c
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
The follow_link() function always initializes its *p argument,
or returns an error, but not all versions of gcc figure this
out, so we have to work around this using the uninitialized_var()
macro.
Without this patch, building with arm-linux-gnueabi-gcc-4.6 results in:
fs/namei.c: In function 'link_path_walk':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:1544:9: note: 'cookie' was declared here
fs/namei.c: In function 'path_lookupat':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:1934:10: note: 'cookie' was declared here
fs/namei.c: In function 'path_openat':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:2899:9: note: 'cookie' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel at vger.kernel.org
Cc: Jan Kara <jack@suse.cz>
---
fs/namei.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index dd1ed1b..62a1725 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1543,7 +1543,7 @@ static inline int nested_symlink(struct path *path, struct nameidata *nd)
do {
struct path link = *path;
- void *cookie;
+ void *uninitialized_var(cookie);
res = follow_link(&link, nd, &cookie);
if (res)
@@ -1933,7 +1933,7 @@ static int path_lookupat(int dfd, const char *name,
if (!err && !(flags & LOOKUP_PARENT)) {
err = lookup_last(nd, &path);
while (err > 0) {
- void *cookie;
+ void *uninitialized_var(cookie);
struct path link = path;
err = may_follow_link(&link, nd);
if (unlikely(err))
@@ -2902,7 +2902,7 @@ static struct file *path_openat(int dfd, const char *pathname,
error = do_last(nd, &path, file, op, &opened, pathname);
while (unlikely(error > 0)) { /* trailing symlink */
struct path link = path;
- void *cookie;
+ void *uninitialized_var(cookie);
if (!(nd->flags & LOOKUP_FOLLOW)) {
path_put_conditional(&path, nd);
path_put(&nd->path);
--
1.7.10
^ permalink raw reply related
* [PATCH 04/16] SCSI: ARM: make fas216_dumpinfo function conditional
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
The fas216_dumpinfo function is only used by __fas216_checkmagic,
which is conditionally compiled, so we should put both functions
inside of the same #ifdef.
Without this patch, building rpc_defconfig results in:
drivers/scsi/arm/fas216.c:182:13: warning: 'fas216_dumpinfo' defined but not used [-Wunused-function]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-scsi at vger.kernel.org
---
drivers/scsi/arm/fas216.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/arm/fas216.c b/drivers/scsi/arm/fas216.c
index 6206a66..737554c 100644
--- a/drivers/scsi/arm/fas216.c
+++ b/drivers/scsi/arm/fas216.c
@@ -179,6 +179,7 @@ static void print_SCp(struct scsi_pointer *SCp, const char *prefix, const char *
SCp->buffers_residual, suffix);
}
+#ifdef CHECK_STRUCTURE
static void fas216_dumpinfo(FAS216_Info *info)
{
static int used = 0;
@@ -223,7 +224,6 @@ static void fas216_dumpinfo(FAS216_Info *info)
info->internal_done, info->magic_end);
}
-#ifdef CHECK_STRUCTURE
static void __fas216_checkmagic(FAS216_Info *info, const char *func)
{
int corruption = 0;
--
1.7.10
^ permalink raw reply related
* [PATCH 03/16] SCSI: ARM: ncr5380/oak uses no interrupts
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
The ncr5380 driver is included by multiple board specific
drivers, which may or may not use the interrupt handler.
The oak variant doesn't, and should set the DONT_USE_INTR
macro.
Without this patch, building rpc_defconfig results in:
drivers/scsi/arm/../NCR5380.c:1160:20: warning: 'oakscsi_intr' defined but not used [-Wunused-function]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-scsi at vger.kernel.org
---
drivers/scsi/arm/oak.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/arm/oak.c b/drivers/scsi/arm/oak.c
index d25f944..fc6a5aa 100644
--- a/drivers/scsi/arm/oak.c
+++ b/drivers/scsi/arm/oak.c
@@ -21,6 +21,7 @@
/*#define PSEUDO_DMA*/
#define OAKSCSI_PUBLIC_RELEASE 1
+#define DONT_USE_INTR
#define priv(host) ((struct NCR5380_hostdata *)(host)->hostdata)
#define NCR5380_local_declare() void __iomem *_base
--
1.7.10
^ permalink raw reply related
* [PATCH 02/16] ARM: binfmt_flat: unused variable 'persistent'
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
The flat_get_addr_from_rp() macro does not use the 'persistent' argument
on ARM, causing a harmless compiler warning. A cast to void removes
that warning.
Without this patch, building at91x40_defconfig results in:
fs/binfmt_flat.c: In function 'load_flat_file':
fs/binfmt_flat.c:746:17: warning: unused variable 'persistent' [-Wunused-variable]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Ungerer <gerg@uclinux.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Bryan Wu <bryan.wu@canonical.com>
---
arch/arm/include/asm/flat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/flat.h b/arch/arm/include/asm/flat.h
index 59426a4..e847d23 100644
--- a/arch/arm/include/asm/flat.h
+++ b/arch/arm/include/asm/flat.h
@@ -8,7 +8,7 @@
#define flat_argvp_envp_on_stack() 1
#define flat_old_ram_flag(flags) (flags)
#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
-#define flat_get_addr_from_rp(rp, relval, flags, persistent) get_unaligned(rp)
+#define flat_get_addr_from_rp(rp, relval, flags, persistent) ((void)persistent,get_unaligned(rp))
#define flat_put_addr_at_rp(rp, val, relval) put_unaligned(val,rp)
#define flat_get_relocate_addr(rel) (rel)
#define flat_set_persistent(relval, p) 0
--
1.7.10
^ permalink raw reply related
* [PATCH 01/16] ARM: warnings in arch/arm/include/asm/uaccess.h
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-1-git-send-email-arnd@arndb.de>
On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate
their arguments, which may lead to harmless build warnings in some
code where the variables are not used otherwise. Adding a cast to void
gets rid of the warning and does not make any semantic changes.
Without this patch, building at91x40_defconfig results in:
fs/read_write.c: In function 'rw_copy_check_uvector':
fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Ungerer <gerg@uclinux.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/include/asm/uaccess.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 77bd79f..7e1f760 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -200,8 +200,8 @@ extern int __put_user_8(void *, unsigned long long);
#define USER_DS KERNEL_DS
#define segment_eq(a,b) (1)
-#define __addr_ok(addr) (1)
-#define __range_ok(addr,size) (0)
+#define __addr_ok(addr) ((void)(addr),1)
+#define __range_ok(addr,size) ((void)(addr),0)
#define get_fs() (KERNEL_DS)
static inline void set_fs(mm_segment_t fs)
--
1.7.10
^ permalink raw reply related
* [PATCH 00/16] ARM: mostly harmless gcc warnings
From: Arnd Bergmann @ 2012-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In my attempt to weed out all warnings in ARM defconfigs, this
is the latest installment of patches. Ideally these could all
go through the respective subsystem maintainer trees, but
for any patches I don't hear anything back on, I will just
merge them through the arm-soc tree.
Arnd
Arnd Bergmann (16):
ARM: warnings in arch/arm/include/asm/uaccess.h
ARM: binfmt_flat: unused variable 'persistent'
SCSI: ARM: ncr5380/oak uses no interrupts
SCSI: ARM: make fas216_dumpinfo function conditional
vfs: bogus warnings in fs/namei.c
mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN
cgroup: fix warning when building without any subsys
ipvs: fix ip_vs_set_timeout debug messages
USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit
clk: don't mark clkdev_add_table as init
pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops
video: mark nuc900fb_map_video_memory as __devinit
ARM: be really quiet when building with 'make -s'
ARM: pxa: armcore: fix PCI PIO warnings
spi/s3c64xx: use correct dma_transfer_direction type
ARM: pass -marm to gcc by default for both C and assembler
arch/arm/Makefile | 13 +++++++------
arch/arm/boot/Makefile | 10 +++++-----
arch/arm/common/it8152.c | 12 +++++++++---
arch/arm/include/asm/flat.h | 2 +-
arch/arm/include/asm/uaccess.h | 4 ++--
arch/arm/tools/Makefile | 2 +-
drivers/clk/clkdev.c | 2 +-
drivers/pcmcia/pxa2xx_sharpsl.c | 2 +-
drivers/scsi/arm/fas216.c | 2 +-
drivers/scsi/arm/oak.c | 1 +
drivers/spi/spi-s3c64xx.c | 2 +-
drivers/usb/host/ehci-orion.c | 2 +-
drivers/video/nuc900fb.c | 2 +-
fs/namei.c | 6 +++---
include/linux/cgroup.h | 2 +-
mm/slob.c | 6 +++---
net/netfilter/ipvs/ip_vs_ctl.c | 10 ++++++----
17 files changed, 45 insertions(+), 35 deletions(-)
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Ben Blum <bblum@andrew.cmu.edu>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Dave Martin <dave.martin@linaro.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Greg Ungerer <gerg@uclinux.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Jan Kara <jack@suse.cz>
Cc: Jochen Friedrich <jochen@scram.de>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Mike Rapoport <mike@compulab.co.il>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Pavel Machek <pavel@suse.cz>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Simon Horman <horms@verge.net.au>
Cc: Tejun Heo <tj@kernel.org>
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: coreteam at netfilter.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-fbdev at vger.kernel.org
Cc: linux-fsdevel at vger.kernel.org
Cc: linux-pcmcia at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-scsi at vger.kernel.org
Cc: linux-usb at vger.kernel.org
Cc: netdev at vger.kernel.org
Cc: netfilter-devel at vger.kernel.org
Cc: netfilter at vger.kernel.org
Cc: spi-devel-general at lists.sourceforge.net
--
1.7.10
^ permalink raw reply
* [PATCH] ARM: pxa: Fix build error caused by sram.h rename
From: Chris Ball @ 2012-10-05 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210022027.45461.arnd@arndb.de>
Hi Arnd,
On Tue, Oct 02 2012, Arnd Bergmann wrote:
> On Tuesday 02 October 2012, Chris Ball wrote:
>> Commit 293b2da1b61 ("ARM: pxa: move platform_data definitions")
>> renamed arch/arm/mach-mmp/include/mach/sram.h to
>> include/linux/platform_data/dma-mmp_tdma.h, but didn't update
>> mmp-pcm.c which uses the header. Fix the build error.
>>
>> Signed-off-by: Chris Ball <cjb@laptop.org>
>> ---
>> sound/soc/pxa/mmp-pcm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Sorry I didn't catch this earlier. The file was only recently added
> and somehow didn't appear in my build tests.
Thanks. Do you want to send this to mainline, or should Mark do it?
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* alignment faults in 3.6
From: Rob Herring @ 2012-10-05 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005140556.GQ4625@n2100.arm.linux.org.uk>
On 10/05/2012 09:05 AM, Russell King - ARM Linux wrote:
> On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
>> On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
>>> Does it matter? I'm just relaying the argument against adding __packed
>>> which was used before we were forced (by the networking folk) to implement
>>> the alignment fault handler.
>>
>> It doesn't really matter what will be accepted or not as adding __packed
>> to struct iphdr doesn't fix the problem anyway. gcc still emits a ldm.
>> The only way I've found to eliminate the alignment fault is adding a
>> barrier between the 2 loads. That seems like a compiler issue to me if
>> there is not a better fix.
>
> Even so, please test the patch I've sent you in the sub-thread - that
> needs testing whether or not GCC is at fault. Will's patch to add the
> warnings _has_ uncovered a potential issue with the use of __get_user()
> in some parts of the ARM specific kernel, and I really need you to test
> that while you're experiencing this problem.
I've tested your patch and it appears to fix things. Thanks!
Now on to getting rid of faults on practically every single received IP
packet:
Multi: 9871002
RX packets:9872010 errors:0 dropped:0 overruns:0 frame:0
Rob
^ permalink raw reply
* [PATCH 4/4] mtd: nand: omap2: Add data correction support
From: Ivan Djelic @ 2012-10-05 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <518397C60809E147AF5323E0420B992E3E9B8A65@DBDE01.ent.ti.com>
On Fri, Oct 05, 2012 at 09:51:50AM +0100, Philip, Avinash wrote:
> On Thu, Oct 04, 2012 at 15:51:03, Philip, Avinash wrote:
> > On Thu, Oct 04, 2012 at 00:50:45, Ivan Djelic wrote:
> > > On Wed, Oct 03, 2012 at 03:29:49PM +0100, Philip, Avinash wrote:
> > > > ELM module can be used for error correction of BCH 4 & 8 bit. Also
> > > > support read & write page in one shot by adding custom read_page &
> > > > write_page methods. This helps in optimizing code.
> > > >
> > > > New structure member "is_elm_used" is added to know the status of
> > > > whether the ELM module is used for error correction or not.
> > > >
> > > > Note:
> > > > ECC layout of BCH8 uses 14 bytes for 512 byte of data to make compatible
> > > > with RBL ECC layout, even though the requirement was only 13 byte. This
> > > > results a common ecc layout across RBL, U-boot & Linux.
> > > >
> > >
> > > See a few comments below,
> > >
> > > (...)
> > > > +static int omap_elm_correct_data(struct mtd_info *mtd, u_char *dat,
> > > > + u_char *read_ecc, u_char *calc_ecc)
> > > > +{
> > > > + struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
> > > > + mtd);
> > > > + int eccsteps = info->nand.ecc.steps;
> > > > + int i , j, stat = 0;
> > > > + int eccsize, eccflag, size;
> > > > + struct elm_errorvec err_vec[ERROR_VECTOR_MAX];
> > > > + u_char *ecc_vec = calc_ecc;
> > > > + enum bch_ecc type;
> > > > + bool is_error_reported = false;
> > > > +
> > > > + /* initialize elm error vector to zero */
> > > > + memset(err_vec, 0, sizeof(err_vec));
> > > > + if (info->nand.ecc.strength == BCH8_MAX_ERROR) {
> > > > + size = BCH8_SIZE;
> > > > + eccsize = BCH8_ECC_OOB_BYTES;
> > > > + type = BCH8_ECC;
> > > > + } else {
> > > > + size = BCH4_SIZE;
> > > > + eccsize = BCH4_SIZE;
> > > > + type = BCH4_ECC;
> > > > + }
> > > > +
> > > > + for (i = 0; i < eccsteps ; i++) {
> > > > + eccflag = 0; /* initialize eccflag */
> > > > +
> > > > + for (j = 0; (j < eccsize); j++) {
> > > > + if (read_ecc[j] != 0xFF) {
> > > > + eccflag = 1; /* data area is flashed */
> > >
> > > Just a reminder: this way of checking if a page has been programmed is not robust to bitflips,
> > > so you may get into trouble with UBIFS on a fairly recent device.
>
> Sorry I missed this point.
>
> Here we were checking data in spare area (only in ecc layout 14*4 for BCH8) is 0xFF. If all data
> in spare area is 0xFF, conclude that the page is erased & no need of error correction. In case
> of bit flip present in spare area, page will be reported as uncorrectable.
> But I am not understand understand " trouble with UBIFS on a fairly recent device".
> Can you little elaborativ
There are at least 2 potential problems when reading an erased page with bitflips:
1. bitflip in data area and no bitflip in spare area (all 0xff)
Your code will not perform any ECC correction.
UBIFS does not like finding bitflips in empty pages, see for instance
http://lists.infradead.org/pipermail/linux-mtd/2012-March/040328.html.
2. bitflip in ECC bytes in spare area
Your code will report an uncorrectable error upon reading; if this happens while reading a partially programmed UBI block,
I guess you will lose data.
BR,
--
Ivan
^ permalink raw reply
* [PATCH 1/1] mtd: st fsmc_nand: pass the ale and cmd resource via resource
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-05 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb10dfKR-sAvbUar+ZsC16uLofhBXuMxfL7QtXLhNg1+Q@mail.gmail.com>
On 14:49 Fri 05 Oct , Linus Walleij wrote:
>
> On Thu, Oct 4, 2012 at 3:14 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
>
> > Do not use the platform_data to pass resource and be smart in the drivers.
> > Just pass it via resource
> >
> > Switch to devm_request_and_ioremap at the sametime
> >
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Vipin Kumar <vipin.kumar@st.com>
> > Cc: linux-mtd at lists.infradead.org
>
> This is much better. Actually I was confused by these offsets recently...
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> My patch to convert the Nomadik to the FSMC driver will collide with this,
> but I can sure fix it up as we run into it, no big deal.
ha you did it too
I'll give it a try
Best Regards,
J.
^ permalink raw reply
* alignment faults in 3.6
From: Russell King - ARM Linux @ 2012-10-05 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506ED18C.3010009@gmail.com>
On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
> On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
> > Does it matter? I'm just relaying the argument against adding __packed
> > which was used before we were forced (by the networking folk) to implement
> > the alignment fault handler.
>
> It doesn't really matter what will be accepted or not as adding __packed
> to struct iphdr doesn't fix the problem anyway. gcc still emits a ldm.
> The only way I've found to eliminate the alignment fault is adding a
> barrier between the 2 loads. That seems like a compiler issue to me if
> there is not a better fix.
Even so, please test the patch I've sent you in the sub-thread - that
needs testing whether or not GCC is at fault. Will's patch to add the
warnings _has_ uncovered a potential issue with the use of __get_user()
in some parts of the ARM specific kernel, and I really need you to test
that while you're experiencing this problem.
^ permalink raw reply
* [PATCH 07/16] ARM: OMAP: Make plat/sram.h local to plat-omap
From: Jon Hunter @ 2012-10-05 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004220449.26676.54281.stgit@muffinssi.local>
Hi Tony,
On 10/04/2012 05:04 PM, Tony Lindgren wrote:
> We can move this from plat to be local to plat-omap
> for common ARM zImage support.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap1/clock.c | 3 -
> arch/arm/mach-omap1/clock_data.c | 3 -
> arch/arm/mach-omap1/devices.c | 2
> arch/arm/mach-omap1/pm.c | 3 -
> arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 3 -
> arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 3 -
> arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 3 -
> arch/arm/mach-omap2/io.c | 3 -
> arch/arm/mach-omap2/omap4-common.c | 4 -
> arch/arm/mach-omap2/pm24xx.c | 3 -
> arch/arm/mach-omap2/pm34xx.c | 3 -
> arch/arm/mach-omap2/sdrc.c | 2
> arch/arm/mach-omap2/sdrc2xxx.c | 2
> arch/arm/mach-omap2/sleep34xx.S | 2
> arch/arm/plat-omap/common.h | 2
> arch/arm/plat-omap/include/plat/sram.h | 105 -------------------------
> arch/arm/plat-omap/sram.c | 1
> arch/arm/plat-omap/sram.h | 109 +++++++++++++++++++++++++-
> 18 files changed, 130 insertions(+), 126 deletions(-)
> delete mode 100644 arch/arm/plat-omap/include/plat/sram.h
>
> diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
> index 638f407..b15d4ee 100644
> --- a/arch/arm/mach-omap1/clock.c
> +++ b/arch/arm/mach-omap1/clock.c
> @@ -24,11 +24,12 @@
> #include <plat/cpu.h>
> #include <plat/usb.h>
> #include <plat/clock.h>
> -#include <plat/sram.h>
> #include <plat/clkdev_omap.h>
>
> #include <mach/hardware.h>
>
> +#include "../plat-omap/sram.h"
Any reason why you did not put this in
arch/arm/plat-omap/include/plat-omap/ like we were discussing for dma
and dmtimers headers? Then it can be just "#include <plat-omap/sram.h>".
Just curious ...
Cheers
Jon
^ permalink raw reply
* OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
From: Benoit Cousson @ 2012-10-05 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506EDEB3.3050003@ti.com>
On 10/05/2012 03:20 PM, Archit Taneja wrote:
> On Friday 05 October 2012 06:07 PM, Rajendra Nayak wrote:
>> On Friday 05 October 2012 05:59 PM, Archit Taneja wrote:
>>> The other not so good option to make DSS PM work would be to add
>>> OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which
>>> have the hack "dss_fck" as slave clock). I gave this approach a try,
>>> that too isn't working so well. When I disable DSS, I get
>>> CM_DSS_DSS_CLKCTRL.IDLEST as 0x1, and
>>> CM_DSS_CLKSTCTRL.CLKACTIVITY_DSS_L3_ICLK is set. I wonder why that's
>>> happening.
>>
>> I have seen DSS get stuck in transition, with just a clkdm state toggle
>> (from say HWSUP to SWWKUP) while its optional clocks are not running.
>> Thats probably whats happening now.
>
> Oh ok, I can notice that too. So in the _idle() path, the clocks are
> disabled first, and then we try to change the clkdm state. I guess that
> could be the reason why DSS doesn't sleep.
>
> But then, I don't understand why this problem isn't seen if I try the
> alternative option of removing the fake dss_fck slave clock, and tie
> modulemode to only the parent hwmod. There DSS IDLEST is 0x3 when I
> disable DSS.
>
> I think with this approach, the problem is with _disable_clocks(), in
> disable_clocks, main_clk is disabled first, and then the slave clocks.
> That translates to DSS_FCK opt clock getting disabled first, and then
> MODULEMODE bits. I think DSS doesn't transition to sleep with this
> disable sequence.
>
>>
>> Did you try keeping the modulemode enabled and see if it really gates
>> DSS/system sleep. I remember testing with Teros CORE ret/off patches
>> and I was always seeing DSS modulemode enabled but it wasn't gating
>> sleep.
>
> If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all
> set). Is this helpful? Can we just leave modulemode on all the time?
> That'll be the best :)
Well, it is true that in the case of the DSS the modulemode is only
managing the interface clock. And since the interface clock is doing
autogating, it will not prevent clockdomain transition.
But I will not recommend using that, it should not be useful assuming
the clocks are properly managed by the DSS.
I think we still have issue dur to the presence of that fake modulemode
clock node.
Regards,
Benoit
^ permalink raw reply
* alignment faults in 3.6
From: Mikael Pettersson @ 2012-10-05 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506ED18C.3010009@gmail.com>
Rob Herring writes:
> On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
> > On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
> >> On 5 October 2012 08:12, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >>> On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
> >>>> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
> >>>>> This struct is the IP header, so a struct ptr is just set to the
> >>>>> beginning of the received data. Since ethernet headers are 14 bytes,
> >>>>> often the IP header is not aligned unless the NIC can place the frame at
> >>>>> a 2 byte offset (which is something I need to investigate). So this
> >>>>> function cannot make any assumptions about the alignment. Does the ABI
> >>>>> define structs have some minimum alignment? Does the struct need to be
> >>>>> declared as packed or something?
> >>>>
> >>>> The ABI defines the alignment of structs as the maximum alignment of its
> >>>> members. Since this struct contains 32-bit members, the alignment for the
> >>>> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
> >>>> might be unaligned (in addition to removing any holes within).
> >>>
> >>> This has come up before in the past.
> >>>
> >>> The Linux network folk will _not_ allow - in any shape or form - for
> >>> this struct to be marked packed (it's the struct which needs to be
> >>> marked packed) because by doing so, it causes GCC to issue byte loads/
> >>> stores on architectures where there isn't a problem, and that decreases
> >>> the performance of the Linux IP stack unnecessarily.
> >>
> >> Which architectures? I have never seen anything like that.
> >
> > Does it matter? I'm just relaying the argument against adding __packed
> > which was used before we were forced (by the networking folk) to implement
> > the alignment fault handler.
>
> It doesn't really matter what will be accepted or not as adding __packed
> to struct iphdr doesn't fix the problem anyway. gcc still emits a ldm.
> The only way I've found to eliminate the alignment fault is adding a
> barrier between the 2 loads. That seems like a compiler issue to me if
> there is not a better fix.
If you suspect a GCC bug, please prepare a standalone user-space test case
and submit it to GCC's bugzilla (I can do the latter if you absolutely do not
want to). It wouldn't be the first alignment-related GCC bug...
^ permalink raw reply
* alignment faults in 3.6
From: Mikael Pettersson @ 2012-10-05 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG5Tg6WSRtwPkz9OEg6xS7X5uV6-U4o3GaxbTRW-jCfuMPdb=g@mail.gmail.com>
Mans Rullgard writes:
> On 5 October 2012 09:33, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Oct 05, 2012 at 09:33:04AM +0100, Mans Rullgard wrote:
> >> On 5 October 2012 09:24, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
> >> >> On 5 October 2012 08:12, Russell King - ARM Linux
> >> >> <linux@arm.linux.org.uk> wrote:
> >> >> > On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
> >> >> >> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
> >> >> >> > This struct is the IP header, so a struct ptr is just set to the
> >> >> >> > beginning of the received data. Since ethernet headers are 14 bytes,
> >> >> >> > often the IP header is not aligned unless the NIC can place the frame at
> >> >> >> > a 2 byte offset (which is something I need to investigate). So this
> >> >> >> > function cannot make any assumptions about the alignment. Does the ABI
> >> >> >> > define structs have some minimum alignment? Does the struct need to be
> >> >> >> > declared as packed or something?
> >> >> >>
> >> >> >> The ABI defines the alignment of structs as the maximum alignment of its
> >> >> >> members. Since this struct contains 32-bit members, the alignment for the
> >> >> >> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
> >> >> >> might be unaligned (in addition to removing any holes within).
> >> >> >
> >> >> > This has come up before in the past.
> >> >> >
> >> >> > The Linux network folk will _not_ allow - in any shape or form - for
> >> >> > this struct to be marked packed (it's the struct which needs to be
> >> >> > marked packed) because by doing so, it causes GCC to issue byte loads/
> >> >> > stores on architectures where there isn't a problem, and that decreases
> >> >> > the performance of the Linux IP stack unnecessarily.
> >> >>
> >> >> Which architectures? I have never seen anything like that.
> >> >
> >> > Does it matter?
> >>
> >> It matters if we want to fix it.
> >
> > I can't help you there. Ask the networking people.
>
> I'm asking anyone who is listening. Since you've (apparently) seen the claim
> being made, perhaps you can point to an email or so with more information.
> I'd hate to think you're just making up excuses.
I'm pretty sure I've seen DaveM make this statement (not allowing the packed
attribute) and also stating that alignment faults in the kernel itself MUST be
handled silently and correctly. (And DaveM is of course also the maintainer
of SPARC, another machine with strict-alignment requirements.)
^ permalink raw reply
* OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
From: Archit Taneja @ 2012-10-05 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506EE14E.4080500@ti.com>
On Friday 05 October 2012 07:01 PM, Rajendra Nayak wrote:
>> If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all
>> set). Is this helpful? Can we just leave modulemode on all the time?
>> That'll be the best :)
>
> Is everything around DSS enabled by default in omap2plus? If so, I
> haven't seen Tero (who has been working on getting OMAP4 to sleep)
> complain about DSS causing him any trouble. So you should be good
> with whats already there atleast from 'not-gating-sleep' point of
> view.
DSS is selected only as a module in omap2plus_defconfig, so the DSS
driver would never kick in with the defconfig.
The DSS hwmods would be initialised though. If I boot up linux-next with
omap2plus_defconfig, I get:
CM_DSS_CLKSTCTRL 0x3
CM_DSS_DSS_CLKCTRL 0x00060002
So the module is in standby, but IDLEST is 0x2, which says DSS is idle
only with respect to the interconnect. In the bootloader, IDLEST was
0x3. So I don't know if that's a good thing or not.
Archit
^ permalink raw reply
* OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
From: Rajendra Nayak @ 2012-10-05 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506EDEB3.3050003@ti.com>
> If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all
> set). Is this helpful? Can we just leave modulemode on all the time?
> That'll be the best :)
Is everything around DSS enabled by default in omap2plus? If so, I
haven't seen Tero (who has been working on getting OMAP4 to sleep)
complain about DSS causing him any trouble. So you should be good
with whats already there atleast from 'not-gating-sleep' point of
view.
^ permalink raw reply
* [PATCH] ARM: EXYNOS5: Remove wrongly placed usb2.0 PHY_CFG definition from PMU_REG
From: Vivek Gautam @ 2012-10-05 13:26 UTC (permalink / raw)
To: linux-arm-kernel
EXYNOS5_USB_CFG macro should actually point to USB20PHY_CFG
system register (base addr + 0x230). It's wrongly placed in regs-pmu.
Actual register at offset 0x230 in PMU is SEQ_TRANSITION4.
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
---
arch/arm/mach-exynos/include/mach/regs-pmu.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index d4e392b..70b2795 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -230,8 +230,6 @@
/* For EXYNOS5 */
-#define EXYNOS5_USB_CFG S5P_PMUREG(0x0230)
-
#define EXYNOS5_AUTO_WDTRESET_DISABLE S5P_PMUREG(0x0408)
#define EXYNOS5_MASK_WDTRESET_REQUEST S5P_PMUREG(0x040C)
--
1.7.6.5
^ permalink raw reply related
* OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
From: Archit Taneja @ 2012-10-05 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506ED492.5010709@ti.com>
On Friday 05 October 2012 06:07 PM, Rajendra Nayak wrote:
> On Friday 05 October 2012 05:59 PM, Archit Taneja wrote:
>> The other not so good option to make DSS PM work would be to add
>> OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which
>> have the hack "dss_fck" as slave clock). I gave this approach a try,
>> that too isn't working so well. When I disable DSS, I get
>> CM_DSS_DSS_CLKCTRL.IDLEST as 0x1, and
>> CM_DSS_CLKSTCTRL.CLKACTIVITY_DSS_L3_ICLK is set. I wonder why that's
>> happening.
>
> I have seen DSS get stuck in transition, with just a clkdm state toggle
> (from say HWSUP to SWWKUP) while its optional clocks are not running.
> Thats probably whats happening now.
Oh ok, I can notice that too. So in the _idle() path, the clocks are
disabled first, and then we try to change the clkdm state. I guess that
could be the reason why DSS doesn't sleep.
But then, I don't understand why this problem isn't seen if I try the
alternative option of removing the fake dss_fck slave clock, and tie
modulemode to only the parent hwmod. There DSS IDLEST is 0x3 when I
disable DSS.
I think with this approach, the problem is with _disable_clocks(), in
disable_clocks, main_clk is disabled first, and then the slave clocks.
That translates to DSS_FCK opt clock getting disabled first, and then
MODULEMODE bits. I think DSS doesn't transition to sleep with this
disable sequence.
>
> Did you try keeping the modulemode enabled and see if it really gates
> DSS/system sleep. I remember testing with Teros CORE ret/off patches
> and I was always seeing DSS modulemode enabled but it wasn't gating
> sleep.
If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all
set). Is this helpful? Can we just leave modulemode on all the time?
That'll be the best :)
Anyway, I guess it would be the best to have a custom _setup function(or
skip them all together) for DSS as Benoit suggested.
Archit
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox