[U-Boot-Users] [PATCH] ppc: Add u64 versions of fls64 and __ilog bitops

[Kumar Gala]

On Jun 10, 2008, at 6:51 PM, Wolfgang Denk wrote:

> Dear Kumar,
>
> in message <3F2661BD-8C86-410F-984D- 
> B887242A8AA2 at kernel.crashing.org> you wrote:
>>
>>> Comments and code do not match; you'r actually adding much more  
>>> code.
>>
>> I was just needing the u64 versions and the other stuff came along to
>> make it work :)
>
> Please make the comment match the code.

will do.

>>> Also: is fls() vs. __fls() a good way to differentiate between int  
>>> and
>>> ulong?
>>
>> I took this from the kernel source tree and didn't really pay much
>> attention to it.
>
> Maybe we can do better?

going to drop __fls()

>>>> + * fls64(value) returns 0 if value is 0 or the position of the  
>>>> last
>>>> + * set bit if value is nonzero. The last (most significant) bit is
>>>
>>> Sorry, I can't parse this.
>>
>> again taken from kernel land.
>
> No reason not to fix it.

I'm not clear on what the confusion is.

>>>> +#elif BITS_PER_LONG == 64
>>>> +static inline int fls64(__u64 x)
>>>> +{
>>>> +	if (x == 0)
>>>> +		return 0;
>>>> +	return __fls(x) + 1;
>>>
>>> Do I  have to understand where the "+1" is coming from?

It has to do w/how __fls(x) is implemented.  It might be clear in v2.

>> Nope, you can just accept it.  I can drop this for now since I don't
>> believe we support any ppc64 machines.
>
> I guess we might see support for the PA6T soon. SO please leave it
> here.
>
> And I'd appreciate if somebody could explain the code to me...
>
>>>> +static inline int ffs64(u64 x)
>>>> +{
>>>> +	return __ilog2_u64(x & -x) + 1ull;
>>>
>>> Isn't there an easier way to do this?
>>
>> Not aware of one.
>>
>> So, I've stolen this from the kernel and am not sure what you'd like
>> for me to change at this point.
>
> Please clean it up and fix at least the obvious issues.
>
> Best regards,

take a look at v2 and see what issues you have with it :)

- k