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