docs: document the surprising encoder num_chan=0 behavior

It means "use the default, 3".

Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
tests: test names=(1 value) of comp-generated components

This tests one "names=" argument.  This works.

Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
tests: test names=(17 values) of comp-generated components

This should be rejected (16 names is the max), and it is.  The component
fails to load.

Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
tests: test some valid counts= of comp-generated components

There is no upper limit on counts= like there is on names=.  This tests
counts=1, =16, and =17, they're all accepted.

Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
tests: test names=(16 values) of comp-generated components

This currently fails because of a bug in comp.

Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
comp: don't overrun the names[] array

Before this commit, if a comp-generated component was given the max
number of names= arguments, it would happily walk past the end of the
names[] array until it came to a NULL.

In kernels since 2.6, module_param_array() sets the number of entries
actually provided, we should probably use that.  Needs SIM support
though.

Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
tests: test names=(empty string) of comp-generated components

This is currently accepted, and results in a single component with no
name.  HAL objects like pins and functions get names like ".pin-name"
and ".func", which seems kind of bogus.

This is probably a bug, but we shouldn't change it in 2.6.  We should
probably change 2.7 to reject this.

Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>