On Thu, 17 Feb 2011 15:41:40 -0800 Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > Actually this part of code doesn't compile for CONFIG_ARCH_OMAP2 if > > > CONFIG_ARCH_OMAP3 is not set. Reason is that the buffer_size in under > > > CONFIG_ARCH_OMAP3 compilation in struct omap_mcbsp_platform_data > > > definition. > > > > > > I think it's easiest if this patch just removes that conditional > > > compilation from struct omap_mcbsp_platform_data as it really doesn't > > > save that much from non !OMAP3 builds. > > > > Thanks. Will fix it in the next version. > > Any news on updating this series? > > Note that you can now leave out the omap4 hwmod data as that has > been merged to omap-for-linus. > My impression from last round was that there is not that many changes required. Of course there must not have bisect issues like above, should not break OMAP1 (which I think was addressed already) but otherwise I think most of the issues were small. Kevin had concerns about PM testing but I would not put that much emphasis on that since the set should not make things any worse but should make possible to go forward with PM. -- Jarkko -- 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
