Dear Wolfgang,
On 04/16/2013 05:14 PM, Wolfgang Denk wrote:
Dear Andreas,
In message 516D62E1.7090306@gmail.com you wrote:
But how about other places in u-boot hang()ing the device? How can we tell the user that state without a terminal? If one plugs a uart cable he might see some cause of the hang() but this is not acceptable for some groups of users. Is it wise to completely stop a device without showing the state to the user?
If you want to tell the user, this should be done _before_ calling hang() - if you decide to hang() your board.
Well, that is my point. We have about 40 places where we may hang() a arm device:
---8<--- abiessmann@punisher % git grep "hang(" drivers/ arch/arm/ | wc -l 40 --->8---
You say (or at least I understand you so), that I have to hack all these places with some application specific stuff to inform the user of the device that we will stop processing now. Why don't we add an interface to easily change the behavior of hang application specific.
Keep in mind that you don't have to define CONFIG_PANIC_HANG.
Thats true, but in some cases we just want to hang on panic.
Also, as done in arch/powerpc/lib/board.c we usually print an error message on the console device, and we can call bootstage_error(), which could initialte such actions.
Ahhh ... I got it. So this is the interface I want! All we need is bootstage_error() in all hang() variants and thats it.
This question is a bit hypothetical cause we should eliminate the root causes for hang()s before going to market. However I would like to hear your thoughts about that.
You cannot eliminate all causes that will lead a board to run into hang(). There may be simply broken hardware, for example...
Thats true.
Best regards
Andreas Bießmann