Hello all,<br><br>and thank you for helpful comments.<br><br><div class="gmail_quote">2010/3/17 javier Martin <span dir="ltr"><<a href="mailto:javier.martin@vista-silicon.com">javier.martin@vista-silicon.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2010/3/17 Uwe Kleine-König <<a href="mailto:u.kleine-koenig@pengutronix.de">u.kleine-koenig@pengutronix.de</a>>:<br>
<div class="im">> I'm not sure this is worth it. IMHO an unbalanced clk_disable is a<br>
> severe bug that doesn't need to be handled smoothly.<br>
><br>
> But maybe move the WARN_ON before the __clk_disable(clk->parent)? This<br>
> way the disabled parent clock cannot stop the message to appear.<br>
><br>
> Other than that, please use WARN instead of printk + WARN_ON. Then the<br>
> message is printed only after the oops begin marker.<br>
<br>
</div>I agree with Uwe, I myself tried to do something similar in the past and people<br>
made me realize that we don't have to fix here what is really a problem in some<br>
driver which calls unbalanced disable/enable.<br>
<br>
However, I think using WARN would be a good idea since it allows the<br>
kernel hacker<br>
to track an error which according to my own experience is very<br>
difficult to detect.<br>
<br></blockquote><div> </div></div>I agree with all of you that this patch is not a bug fix, but definitely a<br>misfeature elimination.<br><br>WARN must be present anyway to inform about an incident of multiple<br>clk_disable() calls, no doubt. But I assume that if a board can be easily<br>
left in working condition after all, this could help the kernel hacker too.<br><br>Let me send a patch with respect to Uwe's comments firstly.<br><br>With best wishes,<br>Vladimir<br>