[PATCH 0/2] bitops: __fls adjustments

[PATCH 0/2] bitops: __fls adjustments

[Amadeusz Sławiński]

Apparently on few architectures __fls is defined incorrectly. Fix this
by adjusting declarations to asm-generic ones.

As far as I can tell there should be no functional changes, but I don't
have devices to test it, so it was only compile tested.

Amadeusz Sławiński (2):
  ARC: bitops: Change __fls to return unsigned long
  m68k: bitops: Change __fls to return and accept unsigned long

 arch/arc/include/asm/bitops.h  | 2 +-
 arch/m68k/include/asm/bitops.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.25.1

[PATCH 1/2] ARC: bitops: Change __fls to return unsigned long

[Amadeusz Sławiński]

As per asm-generic definition and other architectures __fls should
return unsigned long.

No functional change is expected as return value should fit in unsigned
long.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
---
 arch/arc/include/asm/bitops.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/include/asm/bitops.h b/arch/arc/include/asm/bitops.h
index bdb7e190a294..4076607e7168 100644
--- a/arch/arc/include/asm/bitops.h
+++ b/arch/arc/include/asm/bitops.h
@@ -82,7 +82,7 @@ static inline __attribute__ ((const)) int fls(unsigned int x)
 /*
  * __fls: Similar to fls, but zero based (0-31)
  */
-static inline __attribute__ ((const)) int __fls(unsigned long x)
+static inline __attribute__ ((const)) unsigned long __fls(unsigned long x)
 {
 	if (!x)
 		return 0;
-- 
2.25.1

Re: [PATCH 1/2] ARC: bitops: Change __fls to return unsigned long

[Vineet Gupta]

Hi,

On 5/25/22 07:48, Amadeusz Sławiński wrote:
> As per asm-generic definition and other architectures __fls should
> return unsigned long.
>
> No functional change is expected as return value should fit in unsigned
> long.
>
> Signed-off-by: Amadeusz Sławiński<amadeuszx.slawinski@linux.intel.com>

Applied to for-curr.

Thx,
-Vineet

Re: [PATCH 1/2] ARC: bitops: Change __fls to return unsigned long

[Amadeusz Sławiński]

On 5/26/2022 5:42 AM, Vineet Gupta wrote:
> Hi,
> 
> On 5/25/22 07:48, Amadeusz Sławiński wrote:
>> As per asm-generic definition and other architectures __fls should
>> return unsigned long.
>>
>> No functional change is expected as return value should fit in unsigned
>> long.
>>
>> Signed-off-by: Amadeusz Sławiński<amadeuszx.slawinski@linux.intel.com>
> 
> Applied to for-curr.
> 
> Thx,
> -Vineet

And apparently __fls is defined in two places in ARC header and I only 
changed one, should I send incremental patch on top of already merged 
one or v2?

[PATCH 2/2] m68k: bitops: Change __fls to return and accept unsigned long

[Amadeusz Sławiński]

As per asm-generic definition and other architectures __fls should
return and accept unsigned long as its parameter.

Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
---
 arch/m68k/include/asm/bitops.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/m68k/include/asm/bitops.h b/arch/m68k/include/asm/bitops.h
index 51283db53667..87c2cd66a9ce 100644
--- a/arch/m68k/include/asm/bitops.h
+++ b/arch/m68k/include/asm/bitops.h
@@ -510,7 +510,7 @@ static inline int fls(unsigned int x)
 	return 32 - cnt;
 }
 
-static inline int __fls(int x)
+static inline unsigned long __fls(unsigned long x)
 {
 	return fls(x) - 1;
 }
-- 
2.25.1

Re: [PATCH 0/2] bitops: __fls adjustments

[Cezary Rojewski]

On 2022-05-25 4:48 PM, Amadeusz Sławiński wrote:
> Apparently on few architectures __fls is defined incorrectly. Fix this
> by adjusting declarations to asm-generic ones.
> 
> As far as I can tell there should be no functional changes, but I don't
> have devices to test it, so it was only compile tested.
> 
> Amadeusz Sławiński (2):
>    ARC: bitops: Change __fls to return unsigned long
>    m68k: bitops: Change __fls to return and accept unsigned long
> 
>   arch/arc/include/asm/bitops.h  | 2 +-
>   arch/m68k/include/asm/bitops.h | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 

Thanks for the fixes Amadeo!

I wonder if there are more places like this to address..
Not tested but I do not see any issues with the code so:

Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>


Regards,
Czarek