|
From: Seiji A. <sei...@hd...> - 2012-12-10 23:52:34
|
> Now my first reaction would be, if that is the scenario, why couldn't cpuA release the lock within one second. Because if cpuA is stuck > talking with firmware, then your patch to force the unlock is probably going to trip over the same problems. > (those problems include dealing with resetting a firmware state machine) > > IOW, your patch is just one of many minefields you will have to cross in order to be successful. I agree that I need to fix the platform driver's deadlocking as well to make an overall system workable. (I just wanted to fix the deadlocking problems step by step.) > > Without any testing to show that you have cleared all those minefields, I am leaning against your patch for now. I would rather have a > complete patchset that fixes all the problems in this path. Thanks. I will try to make the complete patchset. > > If you did have to go this route, why not take the 'reason' variable and pass it to some function 'in_panic_path(reason)' that tells you if > you are panicing or not. Then you can change the 'if in_nmi()' to 'if in_nmi() || in_panic'. > > The panic path already disables irqs for you, not sure you need to do it again. Unless you have some other path you are trying to > protect in mind. Thank you for the suggestion. I will update my patch in accordance with your comment if anyone else disagree that. > > Cheers, > Don |