Kevin Hilman had written, on 03/18/2010 05:49 PM, the following:
Nishanth Menon <nm@xxxxxx> 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 <ambresh@xxxxxx>
Cc: Benoit Cousson <b-cousson@xxxxxx>
Cc: Eduardo Valentin <eduardo.valentin@xxxxxxxxx>
Cc: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx>
Cc: Phil Carmody <ext-phil.2.carmody@xxxxxxxxx>
Cc: Sanjeev Premi <premi@xxxxxx>
Cc: Tero Kristo <tero.kristo@xxxxxxxxx>
Cc: Thara Gopinath <thara@xxxxxx>
Signed-off-by: Nishanth Menon <nm@xxxxxx>
---
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
