[alsa-devel] [PATCH 1/4] ALSA: control: return payload length for TLV operation

[Takashi Sakamoto]

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/uapi/sound/asound.h?h=sound-4.8-rc4#n945
>>
>> 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/uapi/sound/tlv.h?h=sound-4.8-rc4
>> )
>>
>> 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