Constraints and hw_params with highly configurable HW

[Uli Franke <uli.franke@weiss.ch>]

Hi everybody

We're currently working on some neat enhancements for the still
experimental snd_dice driver originally initiated by Clemens Ladisch. To
list some of the new and already working features:
 * firmware loading, backed by a user-space command line utility
 * generic ALSA control support for mostly all device specific settings
     for all our (i.e. Weiss Engineering) DICE based products
and last but not least
 * capture support
 * slave mode (external clock source support).

I'm currently debugging and fine-tuning things and that's where some
questions arose. The initial implementation of Clemens tried to fetch
all possible configurations of a device during probe in order to have
all combinations of rates and channels at hand when it comes to
formulate the constraints set within the ALSA pcm substream open
callback. That's a nice approach but will fail with a lot of devices as
their configurations can (and mostly will) be volatile. Our devices for
instance feature several switches, options and alike which have heavy
influence on the channel layout and sample rates and combination of both.

I consulted Takashi's documentation on constraints which suggests to
"use the source" but I couldn't find any similar situation within other
drivers (in case I should have missed something, just let me know of
course).

Therefore I had the idea to define some maximum constraints and let the
ALSA hw_params callback fail in case some settings or combinations are
determined to be not supported during its invocation.

Is this viable? Could this be/is this consistent with the specs? If yes,
would EINVAL an appropriate error code to return?

Regards
Uli