* [PATCH] arch/h8300: modify ffs(), fls() etc. functions to return int
@ 2018-07-21 3:28 Randy Dunlap
2018-07-22 9:25 ` Geert Uytterhoeven
0 siblings, 1 reply; 3+ messages in thread
From: Randy Dunlap @ 2018-07-21 3:28 UTC (permalink / raw)
To: LKML, Yoshinori Sato; +Cc: Rich Felker, linux-sh
From: Randy Dunlap <rdunlap@infradead.org>
Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
printk format build warning. This is due to hexagon's ffs() being
coded as returning long instead of int.
Fix the printk format warning by changing all of hexagon's ffx() and
flx() functions to return int instead of long. The variables that
they return are already int instead of long.
../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]
There are no ffx() or flx() allmodconfig build errors after making this
change.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: linux-sh@vger.kernel.org
---
arch/hexagon/include/asm/bitops.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- linux-next-20180717.orig/arch/hexagon/include/asm/bitops.h
+++ linux-next-20180717/arch/hexagon/include/asm/bitops.h
@@ -194,7 +194,7 @@ static inline int __test_bit(int nr, con
*
* Undefined if no zero exists, so code should check against ~0UL first.
*/
-static inline long ffz(int x)
+static inline int ffz(int x)
{
int r;
@@ -211,7 +211,7 @@ static inline long ffz(int x)
* This is defined the same way as ffs.
* Note fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32.
*/
-static inline long fls(int x)
+static inline int fls(int x)
{
int r;
@@ -232,7 +232,7 @@ static inline long fls(int x)
* the libc and compiler builtin ffs routines, therefore
* differs in spirit from the above ffz (man ffs).
*/
-static inline long ffs(int x)
+static inline int ffs(int x)
{
int r;
@@ -254,7 +254,7 @@ static inline long ffs(int x)
* bits_per_long assumed to be 32
* numbering starts at 0 I think (instead of 1 like ffs)
*/
-static inline unsigned long __ffs(unsigned long word)
+static inline int __ffs(unsigned long word)
{
int num;
@@ -272,7 +272,7 @@ static inline unsigned long __ffs(unsign
* Undefined if no set bit exists, so code should check against 0 first.
* bits_per_long assumed to be 32
*/
-static inline unsigned long __fls(unsigned long word)
+static inline int __fls(unsigned long word)
{
int num;
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] arch/h8300: modify ffs(), fls() etc. functions to return int
2018-07-21 3:28 [PATCH] arch/h8300: modify ffs(), fls() etc. functions to return int Randy Dunlap
@ 2018-07-22 9:25 ` Geert Uytterhoeven
2018-07-22 18:02 ` Randy Dunlap
0 siblings, 1 reply; 3+ messages in thread
From: Geert Uytterhoeven @ 2018-07-22 9:25 UTC (permalink / raw)
To: Randy Dunlap
Cc: Richard Kuo, open list:QUALCOMM HEXAGON...,
Linux Kernel Mailing List, Yoshinori Sato, Rich Felker,
Linux-sh list
CC hexagon
hexagon != H8/300 != SuperH
On Sat, Jul 21, 2018 at 5:28 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
> printk format build warning. This is due to hexagon's ffs() being
> coded as returning long instead of int.
>
> Fix the printk format warning by changing all of hexagon's ffx() and
> flx() functions to return int instead of long. The variables that
> they return are already int instead of long.
>
> ../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
> ../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]
>
>
> There are no ffx() or flx() allmodconfig build errors after making this
> change.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: linux-sh@vger.kernel.org
> ---
> arch/hexagon/include/asm/bitops.h | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> --- linux-next-20180717.orig/arch/hexagon/include/asm/bitops.h
> +++ linux-next-20180717/arch/hexagon/include/asm/bitops.h
> @@ -194,7 +194,7 @@ static inline int __test_bit(int nr, con
> *
> * Undefined if no zero exists, so code should check against ~0UL first.
> */
> -static inline long ffz(int x)
> +static inline int ffz(int x)
> {
> int r;
>
> @@ -211,7 +211,7 @@ static inline long ffz(int x)
> * This is defined the same way as ffs.
> * Note fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32.
> */
> -static inline long fls(int x)
> +static inline int fls(int x)
> {
> int r;
>
> @@ -232,7 +232,7 @@ static inline long fls(int x)
> * the libc and compiler builtin ffs routines, therefore
> * differs in spirit from the above ffz (man ffs).
> */
> -static inline long ffs(int x)
> +static inline int ffs(int x)
> {
> int r;
>
> @@ -254,7 +254,7 @@ static inline long ffs(int x)
> * bits_per_long assumed to be 32
> * numbering starts at 0 I think (instead of 1 like ffs)
> */
> -static inline unsigned long __ffs(unsigned long word)
> +static inline int __ffs(unsigned long word)
The version in asm-generic deoes use "unsigned long".
See also "m68k/bitops: convert __ffs to match generic declaration"
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/commit/?h=for-v4.19&idK538d3dca3e590cdb0234746011a6d9c245cfa3
> {
> int num;
>
> @@ -272,7 +272,7 @@ static inline unsigned long __ffs(unsign
> * Undefined if no set bit exists, so code should check against 0 first.
> * bits_per_long assumed to be 32
> */
> -static inline unsigned long __fls(unsigned long word)
> +static inline int __fls(unsigned long word)
Same here
> {
> int num;
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] arch/h8300: modify ffs(), fls() etc. functions to return int
2018-07-22 9:25 ` Geert Uytterhoeven
@ 2018-07-22 18:02 ` Randy Dunlap
0 siblings, 0 replies; 3+ messages in thread
From: Randy Dunlap @ 2018-07-22 18:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Richard Kuo, open list:QUALCOMM HEXAGON...,
Linux Kernel Mailing List, Yoshinori Sato, Rich Felker,
Linux-sh list
On 07/22/2018 02:25 AM, Geert Uytterhoeven wrote:
> CC hexagon
>
> hexagon != H8/300 != SuperH
>
> On Sat, Jul 21, 2018 at 5:28 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
>> printk format build warning. This is due to hexagon's ffs() being
>> coded as returning long instead of int.
>>
>> Fix the printk format warning by changing all of hexagon's ffx() and
>> flx() functions to return int instead of long. The variables that
>> they return are already int instead of long.
>>
>> ../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
>> ../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]
>>
>>
>> There are no ffx() or flx() allmodconfig build errors after making this
>> change.
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
>> Cc: Rich Felker <dalias@libc.org>
>> Cc: linux-sh@vger.kernel.org
>> ---
>> arch/hexagon/include/asm/bitops.h | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> --- linux-next-20180717.orig/arch/hexagon/include/asm/bitops.h
>> +++ linux-next-20180717/arch/hexagon/include/asm/bitops.h
>> @@ -194,7 +194,7 @@ static inline int __test_bit(int nr, con
>> *
>> * Undefined if no zero exists, so code should check against ~0UL first.
>> */
>> -static inline long ffz(int x)
>> +static inline int ffz(int x)
>> {
>> int r;
>>
>> @@ -211,7 +211,7 @@ static inline long ffz(int x)
>> * This is defined the same way as ffs.
>> * Note fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32.
>> */
>> -static inline long fls(int x)
>> +static inline int fls(int x)
>> {
>> int r;
>>
>> @@ -232,7 +232,7 @@ static inline long fls(int x)
>> * the libc and compiler builtin ffs routines, therefore
>> * differs in spirit from the above ffz (man ffs).
>> */
>> -static inline long ffs(int x)
>> +static inline int ffs(int x)
>> {
>> int r;
>>
>> @@ -254,7 +254,7 @@ static inline long ffs(int x)
>> * bits_per_long assumed to be 32
>> * numbering starts at 0 I think (instead of 1 like ffs)
>> */
>> -static inline unsigned long __ffs(unsigned long word)
>> +static inline int __ffs(unsigned long word)
>
> The version in asm-generic deoes use "unsigned long".
>
> See also "m68k/bitops: convert __ffs to match generic declaration"
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/commit/?h=for-v4.19&idK538d3dca3e590cdb0234746011a6d9c245cfa3
>
>> {
>> int num;
>>
>> @@ -272,7 +272,7 @@ static inline unsigned long __ffs(unsign
>> * Undefined if no set bit exists, so code should check against 0 first.
>> * bits_per_long assumed to be 32
>> */
>> -static inline unsigned long __fls(unsigned long word)
>> +static inline int __fls(unsigned long word)
>
> Same here
Hi Geert,
Thanks for all your catches here. So ffs() and fls() return int,
while __ffs() and __fls() return unsigned long.
(hm, arch/arc/include/asm/bitops.h is a little different.)
(and unicore32)
I'll send a v2 patch (for hexagon).
That will still fix the printk format warning above.
>> {
>> int num;
--
~Randy
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-07-22 18:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-07-21 3:28 [PATCH] arch/h8300: modify ffs(), fls() etc. functions to return int Randy Dunlap
2018-07-22 9:25 ` Geert Uytterhoeven
2018-07-22 18:02 ` Randy Dunlap
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).