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

[Mark Brown]

On Wed, Nov 06, 2013 at 01:03:41PM +0100, Takashi Iwai wrote:
> Mark Brown wrote:

> > The ones in DAPM are mostly about memory corruption; if this stuff is
> > getting confused then there's a good chance that the data structures
> > that it's looking at aren't what they're supposed to be.

> This isn't so easy to guess.  Such a bug is often a memory corruption
> indeed, but it's not necessarily so.  The data can be modified by the
> device drivers that are calling dapm, so everything is possible.
> Driver writers can do anything unbelievable you can never imagine...

If the driver is modifying the DAPM data then it looses anyway.

> Practically seen, using BUG_ON() makes such debugging even more
> difficult.

That's not been my experience at all with these ones, it's much more
common for people to ignore soft failures and then wonder why they get
breakage further down the line.

This is also partly a function of the usage model for these drivers - if
someone is triggering an issue they will almost certainly be doing
development on the system.  There aren't the problems with random system
configurations or unknown hardware that you see with specs like HDA.

> > > Because you must not issue *_POST_* events without *_PRE_* events.
> > > *_PRE_* are skipped for these entries in the previous WARN_ON()
> > > checks.

> > No, that's not the case at all - it's very rare for devices to have both
> > events in the first place.

> Hrm, are you saying that *_POST events can be issued without the
> corresponding *_PRE events, as an official dpam design?  I didn't
> expect such a bad consistency in API design level...

They shouldn't be generated unmatched but it's extremely rare for them
both to actually be used by one widget.  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.
-------------- 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/22973fbd/attachment-0001.sig>