[parisc-linux] [patch 2/2] backport of sba sg list management to ccio-dma
Joel Soete
soete.joel at scarlet.be
Thu Nov 1 11:17:51 MDT 2007
Grant,
Grant Grundler wrote:
> On Sun, Oct 28, 2007 at 02:45:24PM +0000, Joel Soete wrote:
> ...
>> e.g.
>> # more GetOrder-poc.c
> ...
>> give me well same results:
>> # ./GetOrder-poc
>> get_order(1) = 0 (0x0);
>> get_order_poc(1) = 0 (0x0).
> ...
>
> Good!
>
> ...
>> But I need to check more on a detail:
>> here is the prototype of fls():
>> static inline int fls(int x)
>>
>> so I need to be sure that the value of ((size - 1) >> (PAGE_SHIFT)) would
>> always stand in a int (not unsigned but sign) for 32bit (iirc
>> size_of(unsigned long)==32) and 64bit (size_of(unsigned long)==64)
>> implementations?
>
> Huh?
> Why do you care how (unsigned long) is handled when the function prototype
> defines the API to pass in an "int"?
>
Because I only have a theoritical knowledge of programming :<?
> FWIW, __fls could be extended to handle unsigned long the same way
> that __ffs has been...but I don't think we needed to for anything so far.
>
Ok, I could check if I can recover my stuff about this fls()?
(should be something like <http://lists.parisc-linux.org/pipermail/parisc-linux/2006-September/030209.html>, I will test more)
> ...
>>>> return (size ? fls((size - 1) >> (PAGE_SHIFT)): 0);
>>> fls is inlined already and does the same test for size.
>> Yes but here the error (well imo it's an error) came from the unsign long
>> of (-1 >> PAGE_SHIFT) <> 0
>
> Yeah, we'll have to make sure signed int values are handled correctly too.
> But something specific to the parisc version of get_order() can deal
> with sign bits and zero values then call __fls(unsigned long) instead
> of fls(signed int).
>
> grant
>
>
Tx again,
j.
More information about the parisc-linux
mailing list