On Mon, 2010-09-06 at 17:36 +0100, Russell King - ARM Linux wrote: > On Mon, Sep 06, 2010 at 04:53:47PM +0100, Catalin Marinas wrote: > > On Mon, 2010-09-06 at 16:34 +0100, Russell King - ARM Linux wrote: > > > On Mon, Sep 06, 2010 at 12:46:34PM +0100, Catalin Marinas wrote: > > > > Would this work with Thumb-2 kernel builds? Maybe you can add a W(instr) > > > > in the SMP/UP macros to make sure that the instruction is always 32-bit > > > > wide. > > > > > > Probably not, and it's not obvious how to make it work for T2 kernel > > > builds. For the time being, I'm going to make this available only for > > > native ARM builds. We can think about how to make this work for T2 > > > sometime later. > > [...] > > > Indeed, that's only half of the problem. On T2, some of these may be > > > 16-bit values, others may be 32-bit values, and this mechanism has no > > > way to know the size of the areas. > > > > We can add the W() macro and they are guaranteed to be 32-bit wide or > > get a compilation error. Something like using "UP(W(nop))", though it's > > doesn't look as nice. > > > > The usr_ret macro is always compiled to ARM mode anyway. > > That's not the only place - here's another: > > + ALT_SMP(test_for_ipi r0, r6, r5, lr) > + ALT_UP_B(9997f) > > test_for_ipi may be thumb code, which could be 16-bit aligned. The branch can be 16-bit aligned as well but we would have to change the fixup loop for Thumb-2 to load/store 2 half-words and avoid an alignment fault. Anyway, I agree that for now we should get the ARM builds working and we can change the Thumb-2 afterwards, as time allows. It doesn't look like something fundamental would prevent this. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
