[alsa-devel] [PATCH 13/31] ASoC: wm_adsp: Fix BUG_ON() and WARN_ON() usages

[Takashi Iwai]

At Thu, 7 Nov 2013 11:51:58 +0000,
Mark Brown wrote:
> 
> On Thu, Nov 07, 2013 at 12:07:39PM +0100, Takashi Iwai wrote:
> 
> > Yes, and think that this is the first step.  At least, we can refuse
> > the use of BUG*() in any of merged materials in future.  Leaving
> > BUG*() is a bad sign of lazy error handling.
> 
> Send patches to remove the definition of BUG then...

Oh no, it's not my point.

BUG*() macros are good for the right places, per se.  It's just wrong
usages in drivers.  And I'm not against anyone using the macros for
debugging or developing.  My only point is not to leave them in the
final form in the sound drivers.

> > And, actually your vendor-lock assumption doesn't look valid any
> > longer.  There are more and more ARM-based systems that can install
> > OS later relatively easily.  Most of distros (openSUSE, Ubuntu,
> 
> Practically speaking those systems are all in the same class, the
> general purpose end user ARM systems don't have audio hardware (things
> like the Chromebook are still closed boxes with a developer mode which
> isn't quite the same thing).  We certainly don't have anyone actually
> working on any of the stuff that would make such environments viable,
> the people trying are focusing on servers.

Yeah, it's still few, but who knows.

> > Fedora, etc) already provide the installation images, and I know many
> > users of Chromebooks running such.  (And I know some of them burned
> > speakers due to the incorrect UCM setup or usage :-)
> 
> Right, there's a whole bunch more stuff to do if you actually want to
> handle this stuff in production - the health and safety issues from
> excessive volume are even more of a concern for me than the issues with
> physical damage to the systems.

It's a good question how to handle such a problem in general.

The driver could give fair limits, if it can know beforehand.
OTOH, conceptually, it'd be cleaner for a driver to give the raw
accessibility of the hardware as much as possible.  Most of ASoC codec
drivers follow the latter model.  It works well with the closed system
in practice, until a box is opened... 


Takashi