The omap2plus_defconfig enables OMAP2, 3, 4 and 5 features, but when booting an OMAP3 board, I am surprised to see an OMAP4 error. [ 0.690704] omap4_sram_init:Unable to allocate sram needed to handle errata I688 [ 0.690734] omap4_sram_init:Unable to get sram pool needed to handle errata I688 It doesn't make sense to me that we do checking in a bunch of places to see what kind of soc we're running before we do something, but not when we're trying to run omap4_sram_init. While the code inside omap4_sram_init() checks for the presence of "ti,omap4-mpu" in the device tree, it simply presents the warning/error message if it's absent, but it continues on. Since the sram_pool = of_gen_pool_get(np, "sram", 0) call fails we present yet another warning/error message. While it doesn't seem to be hurting anything, it seems like we should check to see if we're even on the right architecture first. Why not do a check for "ti,omap4" and if not present, then exit without warning. (or something similar) adam -- 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
