[PATCH v2 0/8] ARM: mostly harmless gcc warnings

[PATCH v2 0/8] ARM: mostly harmless gcc warnings

[Arnd Bergmann]

Most patches from the first time this was posted have been
adopted by a subsystem maintainer or were show to be obsolete.
Here are the remaining ones again.

I'm planning to submit those patches that are still necessary
by the time we have an -rc1 through the arm-soc tree, but
my preference is still to have them go through the subsystem
maintainers.

Olof: should we add it to for-next?

	Arnd

Arnd Bergmann (8):
  SCSI: ARM: ncr5380/oak uses no interrupts
  SCSI: ARM: make fas216_dumpinfo function conditional
  mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN
  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
  spi/s3c64xx: use correct dma_transfer_direction type

 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 +-
 mm/slob.c                       |    6 +++---
 8 files changed, 10 insertions(+), 9 deletions(-)

-- 
1.7.10

Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jochen Friedrich <jochen@scram.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Pavel Machek <pavel@suse.cz>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-fbdev 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: spi-devel-general at lists.sourceforge.net
Cc: stable at vger.kernel.org

[PATCH v2 1/8] SCSI: ARM: ncr5380/oak uses no interrupts

[Arnd Bergmann]

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

[PATCH v2 2/8] SCSI: ARM: make fas216_dumpinfo function conditional

[Arnd Bergmann]

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

[PATCH v2 3/8] mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN

[Arnd Bergmann]

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>
Acked-by: 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

[PATCH v2 4/8] USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit

[Arnd Bergmann]

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>
Acked-by: 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

[PATCH v2 5/8] clk: don't mark clkdev_add_table as init

[Arnd Bergmann]

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

[PATCH v2 6/8] pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops

[Arnd Bergmann]

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.

Without this patch, building collie_defconfig results in:

drivers/pcmcia/pxa2xx_sharpsl.c:22:31: fatal error: mach-pxa/hardware.h: No such file or directory
compilation terminated.
make[3]: *** [drivers/pcmcia/pxa2xx_sharpsl.o] Error 1
make[2]: *** [drivers/pcmcia] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2

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

[PATCH v2 7/8] video: mark nuc900fb_map_video_memory as __devinit

[Arnd Bergmann]

nuc900fb_map_video_memory is called by an devinit function
that may be called at run-time, but the function itself is
marked __init and will be discarded after boot.

To avoid calling into a function that may have been overwritten,
mark nuc900fb_map_video_memory itself as __devinit.

Without this patch, building nuc950_defconfig results in:

WARNING: drivers/video/built-in.o(.devinit.text+0x26c): Section mismatch in reference from the function nuc900fb_probe() to the function .init.text:nuc900fb_map_video_memory()
The function __devinit nuc900fb_probe() references
a function __init nuc900fb_map_video_memory().
If nuc900fb_map_video_memory is only used by nuc900fb_probe then
annotate nuc900fb_map_video_memory with a matching annotation.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev at vger.kernel.org
---
 drivers/video/nuc900fb.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index e10f551..b31b12b 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -387,7 +387,7 @@ static int nuc900fb_init_registers(struct fb_info *info)
  *    The buffer should be a non-cached, non-buffered, memory region
  *    to allow palette and pixel writes without flushing the cache.
  */
-static int __init nuc900fb_map_video_memory(struct fb_info *info)
+static int __devinit nuc900fb_map_video_memory(struct fb_info *info)
 {
 	struct nuc900fb_info *fbi = info->par;
 	dma_addr_t map_dma;
-- 
1.7.10

[PATCH v2 v2 v2 8/8] spi/s3c64xx: use correct dma_transfer_direction type

[Arnd Bergmann]

There is a subtle difference between dma_transfer_direction and
dma_data_direction: the former is used by the dmaengine framework,
while the latter is used by the dma-mapping API. Although the
purpose is comparable, the actual values are different and must
not be mixed. In this case, the driver just wants to use
dma_transfer_direction.

Without this patch, building s3c6400_defconfig results in:

drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_dmacb':
drivers/spi/spi-s3c64xx.c:239:21: warning: comparison between
	'enum dma_data_direction' and 'enum dma_transfer_direction' [-Wenum-compare]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: spi-devel-general at lists.sourceforge.net
---
 drivers/spi/spi-s3c64xx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d1c8441f..2e44dd6 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -132,7 +132,7 @@
 
 struct s3c64xx_spi_dma_data {
 	unsigned		ch;
-	enum dma_data_direction direction;
+	enum dma_transfer_direction direction;
 	enum dma_ch	dmach;
 	struct property		*dma_prop;
 };
-- 
1.7.10

[PATCH v2 7/8] video: mark nuc900fb_map_video_memory as __devinit

[Wan ZongShun]

2012/10/10 Arnd Bergmann <arnd@arndb.de>:
> nuc900fb_map_video_memory is called by an devinit function
> that may be called at run-time, but the function itself is
> marked __init and will be discarded after boot.
>
> To avoid calling into a function that may have been overwritten,
> mark nuc900fb_map_video_memory itself as __devinit.
>
> Without this patch, building nuc950_defconfig results in:
>
> WARNING: drivers/video/built-in.o(.devinit.text+0x26c): Section mismatch in reference from the function nuc900fb_probe() to the function .init.text:nuc900fb_map_video_memory()
> The function __devinit nuc900fb_probe() references
> a function __init nuc900fb_map_video_memory().
> If nuc900fb_map_video_memory is only used by nuc900fb_probe then
> annotate nuc900fb_map_video_memory with a matching annotation.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Wan ZongShun <mcuos.com@gmail.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev at vger.kernel.org

Thanks for your patch.
Acked-by: Wan ZongShun <mcuos.com@gmail.com>

> ---
>  drivers/video/nuc900fb.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index e10f551..b31b12b 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -387,7 +387,7 @@ static int nuc900fb_init_registers(struct fb_info *info)
>   *    The buffer should be a non-cached, non-buffered, memory region
>   *    to allow palette and pixel writes without flushing the cache.
>   */
> -static int __init nuc900fb_map_video_memory(struct fb_info *info)
> +static int __devinit nuc900fb_map_video_memory(struct fb_info *info)
>  {
>         struct nuc900fb_info *fbi = info->par;
>         dma_addr_t map_dma;
> --
> 1.7.10
>



-- 
Wan ZongShun.
www.mcuos.com

[PATCH v2 7/8] video: mark nuc900fb_map_video_memory as __devinit

[Florian Tobias Schandinat]

On 10/09/2012 08:13 PM, Arnd Bergmann wrote:
> nuc900fb_map_video_memory is called by an devinit function
> that may be called at run-time, but the function itself is
> marked __init and will be discarded after boot.
> 
> To avoid calling into a function that may have been overwritten,
> mark nuc900fb_map_video_memory itself as __devinit.
> 
> Without this patch, building nuc950_defconfig results in:
> 
> WARNING: drivers/video/built-in.o(.devinit.text+0x26c): Section mismatch in reference from the function nuc900fb_probe() to the function .init.text:nuc900fb_map_video_memory()
> The function __devinit nuc900fb_probe() references
> a function __init nuc900fb_map_video_memory().
> If nuc900fb_map_video_memory is only used by nuc900fb_probe then
> annotate nuc900fb_map_video_memory with a matching annotation.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Wan ZongShun <mcuos.com@gmail.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev at vger.kernel.org

Applied.


Thanks,

Florian Tobias Schandinat

> ---
>  drivers/video/nuc900fb.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index e10f551..b31b12b 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -387,7 +387,7 @@ static int nuc900fb_init_registers(struct fb_info *info)
>   *    The buffer should be a non-cached, non-buffered, memory region
>   *    to allow palette and pixel writes without flushing the cache.
>   */
> -static int __init nuc900fb_map_video_memory(struct fb_info *info)
> +static int __devinit nuc900fb_map_video_memory(struct fb_info *info)
>  {
>  	struct nuc900fb_info *fbi = info->par;
>  	dma_addr_t map_dma;

[PATCH v2 5/8] clk: don't mark clkdev_add_table as init

[Russell King - ARM Linux]

On Tue, Oct 09, 2012 at 10:13:55PM +0200, Arnd Bergmann wrote:
> 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.

I'm not sure this is the right thing to do.  I suspect this comes from the
stupidly complex samsung code, and that this is actually safe - I suspect
that s3c2440_clk_add() needs to be appropriately marked, but then you end
up having to trace its call path through various structures etc.

[PATCH v2 5/8] clk: don't mark clkdev_add_table as init

[Arnd Bergmann]

On Friday 12 October 2012, Russell King - ARM Linux wrote:
> On Tue, Oct 09, 2012 at 10:13:55PM +0200, Arnd Bergmann wrote:
> > 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.
> 
> I'm not sure this is the right thing to do.  I suspect this comes from the
> stupidly complex samsung code, and that this is actually safe - I suspect
> that s3c2440_clk_add() needs to be appropriately marked, but then you end
> up having to trace its call path through various structures etc.

Yes, you are right. I have verified now that the only code path into
s3c2440_clk_add() is from "int __init s3c2440_init(void)", so 
s3c2440_clk_add can be marked __init_refok.

I'll follow up with a new patch to replace this one.

	Arnd

[PATCH v2 v2 v2 8/8] spi/s3c64xx: use correct dma_transfer_direction type

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> There is a subtle difference between dma_transfer_direction and
> dma_data_direction: the former is used by the dmaengine framework,
> while the latter is used by the dma-mapping API. Although the
> purpose is comparable, the actual values are different and must
> not be mixed. In this case, the driver just wants to use
> dma_transfer_direction.
> 
> Without this patch, building s3c6400_defconfig results in:
> 
> drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_dmacb':
> drivers/spi/spi-s3c64xx.c:239:21: warning: comparison between
> 	'enum dma_data_direction' and 'enum dma_transfer_direction' [-
> Wenum-compare]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

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

BTW, don't we need following accordingly?

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 1a81c90..a0bb55e 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1067,11 +1067,11 @@ static int __devinit s3c64xx_spi_get_dmares(

 	if (tx) {
 		dma_data = &sdd->tx_dma;
-		dma_data->direction = DMA_TO_DEVICE;
+		dma_data->direction = DMA_MEM_TO_DEV;
 		chan_str = "tx";
 	} else {
 		dma_data = &sdd->rx_dma;
-		dma_data->direction = DMA_FROM_DEVICE;
+		dma_data->direction = DMA_DEV_TO_MEM;
 		chan_str = "rx";
 	}

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: spi-devel-general at lists.sourceforge.net
> ---
>  drivers/spi/spi-s3c64xx.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index d1c8441f..2e44dd6 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -132,7 +132,7 @@
> 
>  struct s3c64xx_spi_dma_data {
>  	unsigned		ch;
> -	enum dma_data_direction direction;
> +	enum dma_transfer_direction direction;
>  	enum dma_ch	dmach;
>  	struct property		*dma_prop;
>  };
> --
> 1.7.10

[PATCH v2 v2 v2 8/8] spi/s3c64xx: use correct dma_transfer_direction type

[Arnd Bergmann]

On Wednesday 17 October 2012, Kukjin Kim wrote:
> BTW, don't we need following accordingly?
> 
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 1a81c90..a0bb55e 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -1067,11 +1067,11 @@ static int __devinit s3c64xx_spi_get_dmares(
> 
>         if (tx) {
>                 dma_data = &sdd->tx_dma;
> -               dma_data->direction = DMA_TO_DEVICE;
> +               dma_data->direction = DMA_MEM_TO_DEV;
>                 chan_str = "tx";
>         } else {
>                 dma_data = &sdd->rx_dma;
> -               dma_data->direction = DMA_FROM_DEVICE;
> +               dma_data->direction = DMA_DEV_TO_MEM;
>                 chan_str = "rx";
>         }
> 

Yes, you are absolutely right, sorry for not seeing that earlier.
New version below.

	Arnd

>From c10356b9846b13651a8a24c3a31e029ffe6eafd9 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 30 Apr 2012 16:31:27 +0000
Subject: [PATCH] spi/s3c64xx: use correct dma_transfer_direction type

There is a subtle difference between dma_transfer_direction and
dma_data_direction: the former is used by the dmaengine framework,
while the latter is used by the dma-mapping API. Although the
purpose is comparable, the actual values are different and must
not be mixed. In this case, the driver just wants to use
dma_transfer_direction.

Without this patch, building s3c6400_defconfig results in:

drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_dmacb':
drivers/spi/spi-s3c64xx.c:239:21: warning: comparison between
	'enum dma_data_direction' and 'enum dma_transfer_direction' [-Wenum-compare]

As pointed out by Kukjin Kim, this also changes the use of constants
from DMA_FROM_DEVICE/DMA_TO_DEVICE to DMA_DEV_TO_MEM/DMA_MEM_TO_DEV.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: spi-devel-general at lists.sourceforge.net

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d1c8441f..cd43b4b 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -132,7 +132,7 @@
 
 struct s3c64xx_spi_dma_data {
 	unsigned		ch;
-	enum dma_data_direction direction;
+	enum dma_transfer_direction direction;
 	enum dma_ch	dmach;
 	struct property		*dma_prop;
 };
@@ -1065,11 +1065,11 @@ static int __devinit s3c64xx_spi_get_dmares(
 
 	if (tx) {
 		dma_data = &sdd->tx_dma;
-		dma_data->direction = DMA_TO_DEVICE;
+		dma_data->direction = DMA_MEM_TO_DEV;
 		chan_str = "tx";
 	} else {
 		dma_data = &sdd->rx_dma;
-		dma_data->direction = DMA_FROM_DEVICE;
+		dma_data->direction = DMA_DEV_TO_MEM;
 		chan_str = "rx";
 	}