On Aug 31 2016 13:20, Vinod Koul wrote:
The layout of TLV packet is: struct snd_ctl_tlv { unsigned int numid; # numerical ID of a control element unsigned int length; # length of payload unsigned int tlv[0]; # payload }; http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/uap...
In our implementaion, TLV packet payload (struct snd_ctl_tlv.tlv) is used to transfer data. For pure threshold level information, we expects applications and drivers to fill the payload with this protocol: struct snd_ctl_tlv.tlv[0]: one of SNDRV_CTL_TLVT_XXX struct snd_ctl_tlv.tlv[1]: length of data struct snd_ctl_tlv.tlv[2..]: data
(You can see SNDRV_CTL_TLVT_XXX in this header. http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/uap... )
On the other hand, ALSA SoC part performs: struct snd_ctl_tlv.tlv[0..]: arbitrary data
If your 'tlv[1]' means the 'struct snd_ctl_tlv.tlv[1]', no sense.
The issue I address is current implementation cannot correctly handle this case:
- applications request a buffer with a certain size
- drivers processes the request with smaller size
- application cannot get the size
When implementing I/O operation, in my understanding, this situation often occurs, depending on driver implementation. Fortunately, current implementation of WM-ADSP is free from this concern, but it's better for us not to expect this luck always.
Thanks for the detailed explanation,
IIUC, the fix would be to ensure that drivers or ASoC does return the length value in snd_ctl_tlv.tlv[1] per the API expectations. As I said, in ASoC we tend to move code to core, so snd_soc_bytes_tlv_callback should be updated
Instead of it, I proposed to use 'struct snd_ctl_tlv.length' for the length of TLV packet payload, because the original protocol is too rough as I/O operations. The issue I suggested for ALSA SoC part is one of actual examples. We can generate similar issues on user-defined control element set.
Regards
Takashi Sakamoto