On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote: >> A couple of questions on this: >> >> 1) I notice these spinlock functions are generally marked inline. >> >> Is that likely to happen in modules? If so, there would be a need to >> do SMP_ON_UP fixups at module load time -- I don't think that's >> currently implemented. > > No one should be using the arch_* spinlocks directly. The spinlocks > are implemented in out of line code in kernel/spinlock.c OK--- do think this is something we need a sanity-check for, or does this fall into to a category of bad driver implementation which will get thrown out during peer review? > >> 2) When building with this patch and CONFIG_SMP_ON_UP=y, I've seen >> vmlinux link errors like this: >> >> LD .tmp_vmlinux1 >> `.exit.text' referenced in section `.alt.smp.init' of >> drivers/built-in.o: defined in discarded section `.exit.text' of >> drivers/built-in.o >> make: *** [.tmp_vmlinux1] Error 1 >> >> I don't know whether this is caused by the patch directly or as a >> side-effect -- I've only noticed it in the linaro-2.6.37 tree so far. >> git bisect indentified this above patch as the first one with the >> error in that case. >> >> I don't understand the section discarding logic too well, so I'm not >> sure how to fix it for now... > > Hmm. I don't see how that could happen, unless some driver is going > behind the spinlock APIs, or using our dsb_sev() directly. > > I think you need to first track down what's responsible for inserting > architecture spinlock code into drivers. > OK, I'll try and do a bit more digging. I think I have a better idea of what to look for now, anyhow. Cheers ---Dave -- 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