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.m...@gmail.com> Reported-by: Fengguang Wu <fengguang...@intel.com> Cc: Mikael Starvik <star...@axis.com> Cc: Jesper Nilsson <jesper.nils...@axis.com> Cc: linux-cris-ker...@axis.com Cc: Richard Kuo <r...@codeaurora.org> Cc: linux-hexa...@vger.kernel.org Cc: linux-a...@vger.kernel.org --- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/