Re: [PATCH RFC v2 12/70] MIPS: asm: asmmacro: Replace add instructions with "addui"

[Markos Chandras <Markos.Chandras@imgtec.com>]

On 01/19/2015 03:59 PM, Maciej W. Rozycki wrote:
> On Fri, 16 Jan 2015, Markos Chandras wrote:
> 
>> The use of "add" instruction for immediate operations can result to
>> build failures for MIPS R6. This is because, the 'add' is a macro in
>> binutils and depending on the size of the immediate it can expand to
>> an 'addi' instruction which has been removed from MIPS R6.
>> Thus, we will be using the 'addu' macro instead, which also
>> accepts immediate operands.
>>
>> Link: http://www.linux-mips.org/archives/linux-mips/2015-01/msg00121.html
>> Cc: Maciej W. Rozycki <macro@linux-mips.org>
>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
>> ---
> 
>  This needs a title fix: s/addui/addu/; I'd suggest making the use of 
> quotation marks consistent too on this occasion, e.g.:
> 
> MIPS: asm: asmmacro: Replace "add" instructions with "addu"
> 
> You might take the opportunity to decide on single or double quotes 
> throughout the description too; right now it looks a bit messy to me.
> 
>  Other than that -- this is self-contained and an actual bug fix, 
> irrelevant to R6.  I think it can and really should go in right away 
> regardless of the outcome of the discussion on the other changes in this 
> series.  Also to any stable branches where applicable; the change is so 
> obvious that it cannot do any harm.
> 
>  So please resend this change with the title fix (and any description 
> updates), and I'll give you my review acceptance tag to speed up 
> processing.
> 
>  NB it looks to me like a followup change is needed to ensure the correct 
> operation of these macros in 64-bit kernels, where a doubleword addition 
> must be used instead for address calculation.  One way would be by using 
> the PTR_ADDU preprocessor macro, but there are other possibilities as 
> well.  This is not a requirement for this change to be accepted as far as 
> I am concerned though.
> 
>  Thanks,
> 
>   Maciej
> 
sorry i might be missing something but why do you think this is an
important bug fix that should go into 3.19? the way i read the code it
seems that it can't go wrong at the moment.

-- 
markos