On Wed, 8 Jan 2014, Doug Anderson wrote: > On Wed, Jan 8, 2014 at 11:20 AM, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: > > We've been through these arguments many times, you're not the first to > > raise it, and we've decided upon the policy. We want as _few_ work- > > arounds in the kernel as possible, because applying the work-arounds > > is very problematical with the mixture of secure and non-secure booting. > > OK, fair enough. If we want no workaround here then we can drop this patch. > > > I'd guess that the way forward is: > > * Land kernel workaround locally in Chromium tree > > * I'll try to land FW change locally in at least one Chromium branch. > If we were to get a new RO build ever (seems unlikely at this point) > it would be fixed for upstream kernels. If we were to get a new RW > build (seems unlikely, but at least less unlikely) it would be fixed > if someone landed a kernel patch to save/restore this register across > suspend/resume. > > * If Joe Upstream wants to run an upstream kernel on some type of > exynos5250 product (Samsung ARM Chromebook, HP Chromebook 11, Nexus 10 > are the ones I know of) then he will deal with the small number of > crashes or figure out a solution. At some point you have to realize that what you're proposing is not viable when taking into account the bigger picture. And your FW architecture is to blame. If you were running Windows instead of Linux I bet you'd have found a way to fix things differently than asking Microsoft to add a special quirk in their code. In the PC world you are required to perform a BIOS update instead. So you really need to provision the ability to update at least a portion of the firmware that is not read-only. That may be a third-stage bootloader or the like which purpose is only to install workarounds such as this before executing the kernel and which doesn't need to be updated with the kernel. And in theory you should be able to do that on top of your current RO firmware. Errata workarounds are often machine specific and they can be applied only in special conditions the kernel might not safely know about until it is too late. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |