Kevin Hilman had written, on 03/19/2010 01:42 PM, the following:
Felipe Balbi <m...@felipebalbi.com> writes:

On Fri, Mar 19, 2010 at 10:46:54AM -0700, Kevin Hilman wrote:
IMO, Using BUG* macros usually indicates improper or incomplete error
handling rather than a real catastrophic system failure.
on the other hand a kernel oops and system hang will always get
noted. Rather than a WARN() which simply sits in the log buffer.

Of course, but what I'm trying to avoid is making other people deal
with a BUG inserted by a developer when proper error checking and
recovery is what is really needed.

I respect your views. but a few moments of thoughts:
how would the recovery look like? I can think of 2 options here.. do share your views:

Option 1:
if (opp_init_list(OPP_MPU, omap3_opp_def_list[0])) {
        WARN("dsp OPP table registration failed");
        return;
}
if (opp_init_list(OPP_L3, omap3_opp_def_list[1])) {
        WARN("dsp OPP table registration failed");
        return;
}
if (opp_init_list(OPP_DSP, omap3_opp_def_list[2])) {
        WARN("dsp OPP table registration failed");
        return;
}

Option 2:
        if (opp_init_list(OPP_MPU, omap3_opp_def_list[0]))
                return;
        if (opp_init_list(OPP_L3, omap3_opp_def_list[1]))
                goto mpu_disable;
        if (opp_init_list(OPP_DSP, omap3_opp_def_list[2]))
                goto l3_disable;
        return;

l3_disable:
        freq = 0;
        while (!IS_ERR(opp = opp_find_freq_ceil(OPP_L3, &freq)) {
                opp_disable(opp);
                freq++;
        }
mpu_disable:
        freq = 0;
        while (!IS_ERR(opp = opp_find_freq_ceil(OPP_MPU, &freq)) {
                opp_disable(opp);
                freq++;
        }
        WARN("Registration of OPP tables failed!!");
        return;

Option 1 is a bad idea as it leaves the system in an invalid state
Option 2 is the better idea as we dont have a opp_delete option(not required usually).

All that code for something that will almost never happen?      
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to