[alsa-devel] [PATCH 21/31] ASoC: dapm: Use WARN_ON() instead of BUG_ON()

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20131106/318bf19e/attachment.sig>