| Message ID | 201108241307.21056.jkrzyszt@tis.icnet.pl (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Any plans to fix this regression before the rc cycle is over, or at least explain why it won't be fixed? Any special requirements as to the process of submitting bug fixes against arch/arm common bits? Thanks, Janusz On Wed, 24 Aug 2011 at 13:07:20, Janusz Krzysztofik wrote: > Commit be020f8618ca, "ARM: entry: abort-macro: specify registers to > be used for macros", while replacing register numbers with macro > parameter names, mismatched the parameter used for r1. For me, this > resulted in user space, built for EABI with -march=armv4t > -mtune=arm920t -mthumb- interwork -mthumb, broken on my OMAP1510 > based Amstrad Delta (old ABI with -mno-thumb still worked for me > though). > > Fix this by using correct parameter, fsr, instead of mismatched psr, > used by callers for another purpose. > > Tested on OMAP1510 Amstrad Delta > > Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> > --- > arch/arm/mm/abort-macro.S | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mm/abort-macro.S b/arch/arm/mm/abort-macro.S > index 52162d5..2cbf68e 100644 > --- a/arch/arm/mm/abort-macro.S > +++ b/arch/arm/mm/abort-macro.S > @@ -17,7 +17,7 @@ > cmp \tmp, # 0x5600 @ Is it ldrsb? > orreq \tmp, \tmp, #1 << 11 @ Set L-bit if yes > tst \tmp, #1 << 11 @ L = 0 -> write > - orreq \psr, \psr, #1 << 11 @ yes. > + orreq \fsr, \fsr, #1 << 11 @ yes. > b do_DataAbort > not_thumb: > .endm
On Wed, Sep 07, 2011 at 01:10:08PM +0200, Janusz Krzysztofik wrote: > Any plans to fix this regression before the rc cycle is over, or at > least explain why it won't be fixed? Apart from the patch being buried beneath a ton of email, and then being shuffled off into my "August 2011" mailbox which doesn't get looked at... no. > Any special requirements as to the process of submitting bug fixes > against arch/arm common bits? It needs to go into the patch system for merging so that it doesn't get buried and forgotten - as already demonstrated.
On Wed, 7 Sep 2011 at 13:47:40 Russell King - ARM Linux wrote: > On Wed, Sep 07, 2011 at 01:10:08PM +0200, Janusz Krzysztofik wrote: > > Any special requirements as to the process of submitting bug fixes > > against arch/arm common bits? > > It needs to go into the patch system for merging so that it doesn't > get buried and forgotten - as already demonstrated. Still not sure: am I suppposed to do something for the patch to go to the patch system? Or do you take care of this? Thanks, Janusz
diff --git a/arch/arm/mm/abort-macro.S b/arch/arm/mm/abort-macro.S index 52162d5..2cbf68e 100644 --- a/arch/arm/mm/abort-macro.S +++ b/arch/arm/mm/abort-macro.S @@ -17,7 +17,7 @@ cmp \tmp, # 0x5600 @ Is it ldrsb? orreq \tmp, \tmp, #1 << 11 @ Set L-bit if yes tst \tmp, #1 << 11 @ L = 0 -> write - orreq \psr, \psr, #1 << 11 @ yes. + orreq \fsr, \fsr, #1 << 11 @ yes. b do_DataAbort not_thumb: .endm
Commit be020f8618ca, "ARM: entry: abort-macro: specify registers to be used for macros", while replacing register numbers with macro parameter names, mismatched the parameter used for r1. For me, this resulted in user space, built for EABI with -march=armv4t -mtune=arm920t -mthumb- interwork -mthumb, broken on my OMAP1510 based Amstrad Delta (old ABI with -mno-thumb still worked for me though). Fix this by using correct parameter, fsr, instead of mismatched psr, used by callers for another purpose. Tested on OMAP1510 Amstrad Delta Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> --- arch/arm/mm/abort-macro.S | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)