On 06/11/2013 03:32 PM, Geert Uytterhoeven wrote:
> On Tue, Jun 11, 2013 at 12:26 AM, Tony Luck wrote:
>> > On Sat, Jun 8, 2013 at 3:08 AM, Chen Gang wrote:
>>> >> using 'unsigned int *', implicitly:
>>> >> ./ia64/include/asm/bitops.h:63:__set_bit (int nr, volatile void *addr)
>> >
>> > There i
On 06/08/2013 06:08 PM, Chen Gang wrote:
> Several architectures have different __set_bit() API to others, in
> standard API, 2nd param of __set_bit() is 'unsigned long *', but:
>
> in 'min10300', it is 'unsigned char *',
Oh, it is my fault, for 'mn10300' it is no issue, it is not 'unsigned
cha
On Tue, Jun 11, 2013 at 12:26 AM, Tony Luck wrote:
> On Sat, Jun 8, 2013 at 3:08 AM, Chen Gang wrote:
>> using 'unsigned int *', implicitly:
>> ./ia64/include/asm/bitops.h:63:__set_bit (int nr, volatile void *addr)
>
> There is some downside on ia64 to your suggestion. If "addr" is properly
>
On Sat, Jun 8, 2013 at 3:08 AM, Chen Gang wrote:
> using 'unsigned int *', implicitly:
> ./ia64/include/asm/bitops.h:63:__set_bit (int nr, volatile void *addr)
There is some downside on ia64 to your suggestion. If "addr" is properly
aligned for an "int", but misaligned for a long ... i.e. addr
Hello Maintainers:
Several architectures have different __set_bit() API to others, in
standard API, 2nd param of __set_bit() is 'unsigned long *', but:
in 'min10300', it is 'unsigned char *',
in 'ia64' and 'alpha', they are 'int' or 'unsigned int'.
If another sub-systems did not notice it,
5 matches
Mail list logo
