Nishanth Menon <n...@ti.com> writes: > Kevin Hilman had written, on 03/18/2010 05:49 PM, the following: >> Nishanth Menon <n...@ti.com> 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.
A system can boot fine without OPPs/DVFS. OPPs will not be registered with CPUfreq, and no DVFS atempts will be made. > 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? Using WARN() will produce a nice loud message that alert users, get reported and get fixed as well. > 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.. What is to recover from? While not optimal in power/performance, a kernel can boot and work just fine without OPPs/DVFS. If this call fails, no DVFS will be available but the system is still quite usable. The bigger problem is that everyone things that their feature/subsystem is so crucial that any problems should hang the system, when things could actually continue just fine without it in most cases. IMO, Using BUG* macros usually indicates improper or incomplete error handling rather than a real catastrophic system failure. Kevin -- 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
