Kevin Hilman had written, on 03/18/2010 05:49 PM, the following:
Nishanth Menon <[email protected]> writes:
BUG_ON should not ideally contain a functional code. Remove it out.
True. But this code should not be using BUG_ON() in the first place.
We should not crash the whole kernel in this case, just fail
with a warning.
If you're cleaning this up, can you make it fail more gracefully.
I agree if this was a preipheral driver or a non-critical path. but in
this case:
a) we are speaking of a core description of the h/w - OPPs frequencies
and voltages which out which the functionality of the system is at
stake. I am not speaking of just having a basic kernel boot up to shell
prompt - we need the kernel to do much better than that.
b) Is there any reason why the registration could fail - if it did fail
at this point, there is something catastrophic happening - some other
driver is going beserk OR Opp layer is by itself screwed up - why
continue if we can warn the system and force a fix of the code?
c) is there a recovery mechanism to put the system back in a usable mode
with dvfs etc? I might prefer to get some ideas on it..
Kevin
Ref: http://marc.info/?l=linux-kernel&m=109391212925546&w=2
Cc: Ambresh K <[email protected]>
Cc: Benoit Cousson <[email protected]>
Cc: Eduardo Valentin <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Phil Carmody <[email protected]>
Cc: Sanjeev Premi <[email protected]>
Cc: Tero Kristo <[email protected]>
Cc: Thara Gopinath <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
---
arch/arm/mach-omap2/cpufreq34xx.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/cpufreq34xx.c
index c453ec5..f0ed3ae 100644
--- a/arch/arm/mach-omap2/cpufreq34xx.c
+++ b/arch/arm/mach-omap2/cpufreq34xx.c
@@ -111,6 +111,7 @@ static struct omap_opp_def __initdata
omap36xx_dsp_rate_table[] = {
void __init omap3_pm_init_opp_table(void)
{
+ int r;
struct omap_opp_def **omap3_opp_def_list;
struct omap_opp_def *omap34xx_opp_def_list[] = {
omap34xx_mpu_rate_table,
@@ -126,8 +127,9 @@ void __init omap3_pm_init_opp_table(void)
omap3_opp_def_list = cpu_is_omap3630() ? omap36xx_opp_def_list :
omap34xx_opp_def_list;
- BUG_ON(opp_init_list(OPP_MPU, omap3_opp_def_list[0]));
- BUG_ON(opp_init_list(OPP_L3, omap3_opp_def_list[1]));
- BUG_ON(opp_init_list(OPP_DSP, omap3_opp_def_list[2]));
+ r = opp_init_list(OPP_MPU, omap3_opp_def_list[0]);
+ r |= opp_init_list(OPP_L3, omap3_opp_def_list[1]);
+ r |= opp_init_list(OPP_DSP, omap3_opp_def_list[2]);
+ BUG_ON(r);
}
--
1.6.3.3
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
