On Tue, Dec 8, 2015 at 4:15 PM, Bjorn Andersson
<bjorn.andersson@xxxxxxxxxxxxxx> wrote:
> On Tue 08 Dec 13:52 PST 2015, Arnd Bergmann wrote:
>
>> On Tuesday 08 December 2015 13:29:22 John Stultz wrote:
[...]
>> > +static int __init reboot_reason_init(void)
>> > +{
>> > + return platform_driver_register(&reboot_reason_driver);
>> > +}
>> > +arch_initcall(reboot_reason_init);
>>
>> Why this early? If it can be a normal device_initcall, you can use
>> module_platform_driver().
>>
>
> Not represented in this patch is that several Android vendors uses this
> mechanism to communicate a panic() to the boot loader; to let the system
> enter some sort of memory dump state.
They could also just parse pstore and look for a panic(). Or the
bootloader should set the reason to enter memory dump and the kernel
should clear it once it is up enough to handle resets. You have a
window of time already that a panic will hang. Only a watchdog will
help there and that would need a different solution.
Are panics in early boot really common outside of development?
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
