Alsa-Devel Archive on
 help / color / Atom feed
From: Takashi Sakamoto <>
To: Takashi Iwai <>
Subject: Re: [alsa-devel] [PATCH] ALSA: ctl: allow TLV read operation for callback type of element in locked case
Date: Tue, 24 Dec 2019 19:02:10 +0900
Message-ID: <20191224100209.GA28396@workstation> (raw)
In-Reply-To: <>

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 <>

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.



Takashi Sakamoto
Alsa-devel mailing list

  reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-23  9:33 Takashi Sakamoto
2019-12-23  9:42 ` Takashi Sakamoto
2019-12-23 15:03 ` Takashi Iwai
2019-12-24 10:02   ` Takashi Sakamoto [this message]
2019-12-24 14:31     ` Takashi Iwai
2019-12-24 12:56 ` Jaroslav Kysela

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191224100209.GA28396@workstation \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Alsa-Devel Archive on

Archives are clonable:
	git clone --mirror alsa-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 alsa-devel alsa-devel/ \
	public-inbox-index alsa-devel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone