>-----Original Message-----
>From: Mike Frysinger [mailto:[email protected]] 
>Sent: Wednesday, January 13, 2010 3:18 AM
>To: [email protected]
>Cc: [email protected]
>Subject: Re: [Linux-kernel-commits] [8142] 
>trunk/arch/blackfin: task [#4437], use long call for kernel XIP
>
>On Mon, Jan 11, 2010 at 22:20,  <[email protected]> wrote:
>> Revision 8142 Author bhsong Date 2010-01-11 22:20:37 -0500 
>(Mon, 11 Jan
>> 2010)
>>
>> Log Message
>>
>> task [#4437], use long call for kernel XIP
>>
>> Modified Paths
>>
>> trunk/arch/blackfin/kernel/entry.S
>> trunk/arch/blackfin/mach-common/entry.S
>> trunk/arch/blackfin/mach-common/interrupt.S
>>
>> Diff
>>
>> Modified: trunk/arch/blackfin/kernel/entry.S (8141 => 8142)
>>
>> --- trunk/arch/blackfin/kernel/entry.S       2010-01-11 
>12:35:31 UTC (rev 8141)
>> +++ trunk/arch/blackfin/kernel/entry.S       2010-01-12 
>03:20:37 UTC (rev 8142)
>> @@ -44,7 +44,13 @@
>>      sti r4;
>>  #endif /* CONFIG_IPIPE */
>>      SP += -12;
>> +#if defined(CONFIG_ROMKERNEL)
>> +        p5.l = _schedule_tail;
>> +        p5.h = _schedule_tail;
>> +        call ( p5 );
>> +#else
>>      call _schedule_tail;
>> +#endif
>
>this is exactly the kind of thing i didnt want to happen.  ignoring
>the broken whitespace in most of these commits, this should all be
>unified somewhere in an assembly macro.  ive fixed these issues in a
>commit now.
Thanks a lot!
>
>> @@ -90,7 +102,13 @@
>>      r0 += 24;
>>      [--sp] = rets;
>>      SP += -12;
>> +#if defined(CONFIG_ROMKERNEL)
>> +        p5.l = _bfin_clone;
>> +        p5.h = _bfin_clone;
>> +        call ( p5 );
>> +#else
>>      call _bfin_clone;
>> +#endif
>>      SP += 12;
>>      rets = [sp++];
>>      rts;
>> @@ -101,7 +119,13 @@
>>      r0 += 24;
>>      [--sp] = rets;
>>      SP += -12;
>> +#if defined(CONFIG_ROMKERNEL)
>> +        p5.l = _do_rt_sigreturn;
>> +        p5.h = _do_rt_sigreturn;
>> +        call ( p5 );
>> +#else
>>      call _do_rt_sigreturn;
>> +#endif
>>      SP += 12;
>>      rets = [sp++];
>>      rts;
>
>are you sure using p4/p5 in these short function calls is safe ?
>those arent scratch registers based on our ABI, they're call preserved
>which means if they are modified in a func, that func must
>save/restore them.
I am not compelety sure all cases are ok. But I have tried to avoid p
registers confliction, startup linux and run some basic tests. Things
are ok. 
If there are problems later, that can be a bug report.
>-mike
>
_______________________________________________
Linux-kernel-commits mailing list
[email protected]
https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits

Reply via email to