Re: [PATCH 1/4] ALSA: control: return payload length for TLV operation

[Takashi Iwai <tiwai@suse.de>]

On Tue, 30 Aug 2016 08:19:46 +0200,
Takashi Sakamoto wrote:
> 
> On Aug 30 2016 14:29, Takashi Iwai wrote:
> > On Tue, 30 Aug 2016 01:44:42 +0200,
> > Takashi Sakamoto wrote:
> >>
> >> TLV feature of control interface is originally introduced at
> >> commit 42750b04c5ba ("[ALSA] Control API - TLV implementation for
> >> additional information like dB scale") and commit 8aa9b586e420 ("[ALSA]
> >> Control API - more robust TLV implementation"). In this time,
> >> snd_kcontrol_tlv_rw_t is for generating and transferring information about
> >> threshold level for applications.
> >>
> >> This feature can transfer arbitrary data in a shape of an array with
> >> members of unsigned int type, therefore it can be used to deliver quite
> >> large arbitrary data from user space to in-kernel drivers via ALSA control
> >> character device. Focusing on this nature, commit 7523a271682f ("ASoC:
> >> core: add a helper for extended byte controls using TLV") introduced
> >> snd_soc_bytes_tlv_callback() just for I/O operations.
> >>
> >> In this case, typically, APIs return operated length, while TLV feature
> >> can't. This is inconvenient to applications.
> >
> > The ASoC TLV (ab)usage still takes / receives the length field of
> > TLV.  What's missing there?
> 
> I don't get exactly what you mean.
> 
> The issue in which I'm interested is that applications cannot get to
> know length of actual processed bytes. Nothing others.
> 
> When pure threshold level information is transferred, applications can
> get its length of TLV packet payload, because we have a loose protocol
> to store the length of data in second element of the payload. The size
> of 2 elements plus the length equals to the length of TLV packet
> payload.
> 
> When using TLV feature just for I/O, this protocol is not kept, as we
> can see implementation of 'soc_bytes_ext' operation. Thus, the number
> of processed bytes should be returned to applications, by any
> ways. This patchset uses 'length' field in TLV packet header.

The current way of ASoC ext ctl is intended to be a workaround to pass
a large data via ctl API.  Nothing more than that.  If it's used for
receiving arbitrary size of data from the driver, it's a buggy usage.


Takashi