[alsa-devel] [PATCH] ALSA: ctl: allow TLV read operation for callback type of element in locked case

[Takashi Iwai]

On Tue, 24 Dec 2019 11:02:10 +0100,
Takashi Sakamoto wrote:
> 
> On Mon, Dec 23, 2019 at 04:03:53PM +0100, Takashi Iwai wrote:
> > On Mon, 23 Dec 2019 10:33:47 +0100,
> > Takashi Sakamoto wrote:
> > > 
> > > A design of ALSA control core allows applications to execute three
> > > operations for TLV feature; read, write and command. Furthermore, it
> > > allows driver developers to process the operations by two ways; allocated
> > > array or callback function. In the former, read operation is just allowed,
> > > thus developers uses the latter when device driver supports variety of
> > > models or the target model is expected to dynamically change information
> > > stored in TLV container.
> > > 
> > > The core also allows applications to lock any element so that the other
> > > applications can't perform write operation to the element for element
> > > value and TLV information. When the element is locked, write and command
> > > operation for TLV information are prohibited as well as element value.
> > > Any read operation should be allowed in the case.
> > > 
> > > At present, when an element has callback function for TLV information,
> > > TLV read operation returns EPERM if the element is locked. On the
> > > other hand, the read operation is success when an element has allocated
> > > array for TLV information. In both cases, read operation is success for
> > > element value expectedly.
> > > 
> > > This commit fixes the bug. This change can be backported to v4.14
> > > kernel or later.
> > 
> > The patch looks good but your sign-off is missing...
> 
> Oops, I was in the festive mood...
> 
> Signed-off-by: Takashi Sakamoto <o-takashi at sakamocchi.jp>
> 
> Besides, let us backport this patch to older kernels? As long as I
> investigate, this bug exists since v2.6.19 kernel, in which TLV feature
> was firstly introduced and extended[1]. When I worked for refactoring to
> control core in v4,14 kernel, the bug remains kept as is[2].
> 
> It's possible to apply this patch to the longterm v4.14.160 kernel. But
> when fixing this bug for the older kernels. we need to prepare an
> alternative patch. In my opinion, the disadvantage of the bug is not so
> critical, thus it's reasonable to abandon the older kernels.

I don't think we need a stable backport.  It's no regression, as you
pointed, and nothing leading to a serious problem like a crash.

So I merged now to for-next branch for 5.6 branch without
Cc-to-stable.  Also corrected the comment in C style as Jaroslav
suggested, too.


thanks,

Takashi

> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=8aa9b586e4209
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=450296f305f13
> 
> 
> Regards
> 
> Takashi Sakamoto
>