On Fri, Nov 16, 2012 at 06:09:28PM +0000, Catalin Marinas wrote: > On Fri, Nov 16, 2012 at 09:59:21AM +0000, Russell King - ARM Linux wrote: > > On Thu, Nov 15, 2012 at 08:31:33AM -0600, Rob Herring wrote: > > > So we should make all these work-arounds depend on !MULTI_PLATFORM then. > > > > No, because some of the work-arounds don't require setting bits in magic > > registers. > > > > Also realise this: we test for the revision of the CPU to which they're > > applicable before attempting to set them. If you have a work-around > > enabled in the kernel, and it fails at boot, _that_ is an indicator not > > that the kernel is doing something wrong, but that you need to ensure > > that the work-around has been applied by the earlier stages. > > > > It's not about "but platform X doesn't need it" - it's about platform X > > not having the earlier stages updated to fix the errata. > > There is another aspect. Many CPUs in the field, even if they are a > certain rxpy revision, have ECO fixes applied for critical bugs and > don't require the workaround. Sometimes those undocumented bits have > considerable performance impact and vendors may apply an ECO (unless > they are very late in the tape-out process). But the ECO fix does not > change the CPU revision, hence the workaround becomes platform specific. > > That's why I think it's better if those workarounds are just pushed to > the boot-loader for multi-platform kernels. Linux could still check the > bits and warn about them rather than failing to boot. ... and that's a U-turn if ever there was one... it's ARM Ltd who've been pushing to have these work-arounds in the kernel in the first place. Should we just remove all the work-arounds, and require boot loaders, including the one on Versatile platforms, to implement this? Why should we treat secure platforms be any different from the non-secure ones in this regard? After all, this _does_ stand in the way of a single kernel image working properly on secure and non-secure platforms. The more this thread progresses, the more I think the decision to put errata into the kernel was the wrong one. -- 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
