On 10/10/2013 02:58 PM, Alexandre Courbot wrote: > On Wed, Oct 9, 2013 at 4:47 PM, Olof Johansson <olof@xxxxxxxxx> wrote: >> On Fri, Oct 4, 2013 at 9:37 AM, Alexandre Courbot <acourbot@xxxxxxxxxx> wrote: ... >> But do we really need to panic here? It's a PITA to debug since it'll >> be a very early panic. I'd rather have the system log errors in dmesg >> but continue booting with one cpu. > > Actually the first version of this series continued on one CPU if TF > support was missing (as secondary CPUs would simply fail to boot), but > IIRC Stephen advocated for the current behavior (panic) instead. I > agree such an early panic is hard to debug, especially considering > that most devices using TF (Tegra retail devices) do not even feature > a serial port. > > On the other hand, if we continue booting in these conditions the > system freezes as soon as cpuidle kicks in, so we won't be going very > far anyway. However the console is up when it happens. > > Maybe if there is a way to disable the kernel features TF is supposed > to manage (SMP & cpuidle at the moment) when registration fails, the > system could continue more gracefully (even if on one leg) and warn > the user about this condition. Stephen, can I have your thoughts on > this? If we can disable the features that rely on TF/secure-mode when support is missing, then doing that rather than panic is fine. We do something similar for PCIe on Tegra20, where LP2 cpuidle state must be disabled or PCIe interrupts won't work. I would be inclined to merge the patch as-is right now, since it's only enabling a new feature that won't see any regressions due to this panic, and then add the disable-other-features with a separate patch/series later. Does that seem reasonable? -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
