Hi Ingo, Thomas,
Thanks for your review!
2016-09-08 15:33 GMT+09:00 Ingo Molnar <mi...@kernel.org>:
>> static unsigned int flat_get_apic_id(unsigned long x)
>> {
>> - unsigned int id;
>> -
>> - id = (((x)>>24) & 0xFFu);
>> -
>> - return id;
>> + return ((x) >> 24) & 0xFFu;
>
> So while we are removing unnecessary things, exactly why does the 'x' need
> parentheses?
I will change it to:
return (x >> 24) & 0xFF;
>> static unsigned long set_apic_id(unsigned int id)
>> {
>> - unsigned long x;
>> -
>> - x = ((id & 0xFFu)<<24);
>> - return x;
>> + return (id & 0xFFu) << 24;
>
> 'id' is already unsigned, why does the 'u' have to be stressed in the literal?
> (Ditto for other places as well)
I will change it to:
return (id & 0xFF) << 24;
>> static unsigned long numachip1_set_apic_id(unsigned int id)
>> {
>> - unsigned long x;
>> -
>> - x = ((id & 0xffU) << 24);
>> - return x;
>> + return (id & 0xffU) << 24;
>> }
>
> Why is the spelling of the literal inconsistent here with the other patterns?
I think 0xff is more consistent than 0xFF
in arch/x86/kernel/apic/apic_numachip.c
Making the constant literals consistent across files
is a too much churn, I think.
>> +++ b/arch/x86/kernel/apic/x2apic_uv_x.c
>> @@ -533,11 +533,8 @@ static unsigned int x2apic_get_apic_id(unsigned long x)
>>
>> static unsigned long set_apic_id(unsigned int id)
>> {
>> - unsigned long x;
>> -
>> /* maskout x2apic_extra_bits ? */
>> - x = id;
>> - return x;
>> + return id;
>> }
>
> This was clearly left there to document a quirk and as a placeholder for
> future
> changes.
>
As suggested by Thomas, I will change it to:
{
/* CHECKME: Do we need to mask out the xapic extra bits? */
return id;
}
(I am adding '?' at the comment line.)
If there is no more comment, I will send v2.
--
Best Regards
Masahiro Yamada
