From: Randy Dunlap <rdunlap@infradead.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Richard Kuo <rkuo@codeaurora.org>,
"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>,
Linux-sh list <linux-sh@vger.kernel.org>
Subject: Re: [PATCH] arch/h8300: modify ffs(), fls() etc. functions to return int
Date: Sun, 22 Jul 2018 18:02:26 +0000 [thread overview]
Message-ID: <87467b7c-d361-034f-09d4-8694f26f80e0@infradead.org> (raw)
In-Reply-To: <CAMuHMdVwY0b9S3j2MnuC59vYOuV=LXtQwnhevq227r+mec491Q@mail.gmail.com>
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
prev parent reply other threads:[~2018-07-22 18:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87467b7c-d361-034f-09d4-8694f26f80e0@infradead.org \
--to=rdunlap@infradead.org \
--cc=dalias@libc.org \
--cc=geert@linux-m68k.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=rkuo@codeaurora.org \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).