On Wed, Nov 06, 2013 at 06:21:36PM +0100, Takashi Iwai wrote:
So, basically what such lazy people would need is a knob to make WARN*() triggering panic(). But this shouldn't be done unconditionally for all DAPM usages, or better in all sound driver usages.
Sure, it's a bit nicer in some situations. My point is that you're greatly overstating the problems with asserting in practical usage. The environment and productisation process used with this stuff is different to that for PCs.
BTW, another substantial problem is that this dapm code doesn't handle any errors...
Feel free to send patches. I've never considered it a high priority to go through and add stuff there since the unwinding code is way more effort to write than it's worth and would never get tested - generally where constructive error recovery is possible the natural user reaction of stopping and restarting things is about as constructive as it gets anyway. There's always something more pressing to work on.
They shouldn't be generated unmatched but it's extremely rare for them both to actually be used by one widget.
So, the unprocessed list item must be filtered out.
I don't understand what you mean by this?
To the extent that they're used matched it's with the PRE_PMU matched with POST_PMD and vice versa, though using just one is quite common for inserting delays. It's going to cause more harm than good to actively suppress events.
It won't suppress any events that have been working. Remember that there's been BUG_ON() with the very same condition before the patch. Thus any good-working cases must not hit with this conversion.
But then we're still left with bombing out if the first half of the function ever changes. The check is there for the benefit of the register handling, the fact that it's affecting events is just a side effect rather than the intention.
Remember also that BUG() can be disabled so there is a faint chance that we'd not trigger, and of course the issue might be introduced between the two events.