[PATCH 2/2] cris: fix return type of ffs()

[Akinobu Mita]

The return type of ffs() is 'int' on all architectures except cris and
hexagon.  This unifies the return type to 'int'.

The problem I'm seeing is that the following line generates a warning
on cris and hexagon because of the mismatch between format '%u' and
return type of ffs().

	printk("bits in OOB size: %u\n",	ffs(ns->geom.oobsz) - 1);

But removing this warning by casting to 'int' looks odd, so I suggest
unifying the return type of ffs() on all architectures.

Signed-off-by: Akinobu Mita <akinobu.mita@xxxxxxxxx>
Reported-by: Fengguang Wu <fengguang.wu@xxxxxxxxx>
Cc: Mikael Starvik <starvik@xxxxxxxx>
Cc: Jesper Nilsson <jesper.nilsson@xxxxxxxx>
Cc: linux-cris-kernel@xxxxxxxx
Cc: Richard Kuo <rkuo@xxxxxxxxxxxxxx>
Cc: linux-hexagon@xxxxxxxxxxxxxxx
Cc: linux-arch@xxxxxxxxxxxxxxx
---
 arch/cris/include/arch-v10/arch/bitops.h | 2 +-
 arch/cris/include/arch-v32/arch/bitops.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/cris/include/arch-v10/arch/bitops.h b/arch/cris/include/arch-v10/arch/bitops.h
index 03d9cfd..cc37a22 100644
--- a/arch/cris/include/arch-v10/arch/bitops.h
+++ b/arch/cris/include/arch-v10/arch/bitops.h
@@ -65,7 +65,7 @@ static inline unsigned long __ffs(unsigned long word)
  * differs in spirit from the above ffz (man ffs).
  */
 
-static inline unsigned long kernel_ffs(unsigned long w)
+static inline int kernel_ffs(unsigned long w)
 {
 	return w ? cris_swapwbrlz (w) + 1 : 0;
 }
diff --git a/arch/cris/include/arch-v32/arch/bitops.h b/arch/cris/include/arch-v32/arch/bitops.h
index 147689d6..a5d0963 100644
--- a/arch/cris/include/arch-v32/arch/bitops.h
+++ b/arch/cris/include/arch-v32/arch/bitops.h
@@ -55,7 +55,7 @@ __ffs(unsigned long w)
 /*
  * Find First Bit that is set.
  */
-static inline unsigned long
+static inline int
 kernel_ffs(unsigned long w)
 {
 	return w ? cris_swapwbrlz (w) + 1 : 0;
-- 
1.8.3.1

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