Dear Graeme Russ,
In message 4D88909A.80508@gmail.com you wrote:
That would be a layer higher than do_reset() (for example, in panic()).
Hmmm, but panic() is defined in lib/vsprintf.c with no possibility for it to be overridden in any arch or board specific way
I guess that could be helped.
panic() is a higher software layer. It probably results in calling reset() in the end.
Unless CONFIG_PANIC_HANG is defined...
reset():
- does not exist (as far as I can tell)
reset() is used as symbol in many arm, mips and sparc start.S files
I still like the idea of passing a 'reason' to reset() / panic() - Could we change panic() to:
...
Anywhere in the code that needed to hang has a choice - hang(reason) or panic(reason | PANIC_FLAG_HANG)
I don't think you resonably decide which to use in common code.
Most calls to panic() appear to come from proprietary flash drivers anyway - most of which should be dropped as they could use the CFI driver instead. [And if you look at the actual code, the tests for these panic()s can easily be computed at compile time, so these are stupid aniway.]
Others
Now, assume for things like this:
panic("No working SDRAM available\n");
or like handling undefined instructions or that - what would be more useful - to hang() to to reset()? ;-)
Can you please show me a specific case where you would use such different arguments to panic() in the existing code?
Default implementations of hang() and reset() would just ignore reason. Board specific code can use reason to do one last boot_progress(), set LED states etc.
That should be done at a higher software layer.
Best regards,
Wolfgang Denk