On 2/4/19 10:11 AM, Mark Brown wrote:
On Mon, Feb 04, 2019 at 09:08:41AM -0600, Pierre-Louis Bossart wrote:
Yes I thought about this but didn't know why the array was declared with an
implicit length.
It's been that way since the first commit (which predates me) so I don't
think it was a super thought through decision.
Unfortunately the zero is a legit value today, so we'd have to move all
existing values by one. Not sure if it's worth it.
It's not hard.
It's not hard indeed, I am just not hot on changing the values at the
same time as adding new definitions. I managed to screw-up the mic
values the first time, this would make the changes hard to check.
Maybe do this in a second patch, along with the array size checks?
Maybe an alternate way to fix this is to define snd_soc_dapm_max and check
if the ARRAY_SIZE of dapm_up_seq and dapm_down_seq match. That would trap
any changes in the enum that isn't reflected in the _seq look-up tables.
We could do that and another thing together for maximum robustness!
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
