linux-kernel - Re: [PATCH 1/3] hexagon: fix ffz/fls/ffs return type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a0ZhHY35rDrg5m4o3fTXugAG3QipnaZQupnUafvKcH6HQ@mail.gmail.com>
Date:   Tue, 10 Apr 2018 08:31:44 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Richard Kuo <rkuo@...eaurora.org>
Cc:     "open list:QUALCOMM HEXAGON..." <linux-hexagon@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] hexagon: fix ffz/fls/ffs return type

On Sun, Apr 8, 2018 at 3:35 AM, Richard Kuo <rkuo@...eaurora.org> wrote:
> On Fri, Apr 06, 2018 at 04:28:21PM +0200, Arnd Bergmann wrote:
>> Let's use the same return type as the major architectures to
>> avoid warnings like
>>
>> drivers/ata/libahci_platform.c: In function 'ahci_platform_init_host':
>> drivers/ata/libahci_platform.c:561:12: warning: comparison of distinct pointer types lacks a cast [enabled by default]
>>
>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>> ---
>>  arch/hexagon/include/asm/bitops.h | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/hexagon/include/asm/bitops.h b/arch/hexagon/include/asm/bitops.h
>> index 5e4a59b3ec1b..8790a50b1f5e 100644
>> --- a/arch/hexagon/include/asm/bitops.h
>> +++ b/arch/hexagon/include/asm/bitops.h
>> @@ -194,7 +194,7 @@ static inline int __test_bit(int nr, const volatile unsigned long *addr)
>>   *
>>   * 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;
>>
>
>
> Isn't ffz usually long/unsigned long on other architectures?

Yes, that's right. Let's drop my patch for the moment and maybe revisit it
later. There were only a couple of warnings in an allmodconfig build from
this one, so it might be better change the generic bitops and the more
common architectures to all consistently use 'long' or maybe 'unsigned long'
as the return type for all those functions.

       Arnd