From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1481AC433E0 for ; Wed, 24 Feb 2021 10:34:33 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 76A4E64ECF for ; Wed, 24 Feb 2021 10:34:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 76A4E64ECF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 86DC51675; Wed, 24 Feb 2021 11:33:39 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 86DC51675 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1614162869; bh=AbYjnRnIbu3q7j81cuRh/YenJGzIkDTCyhjZzTdTK2U=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=YvXiDay9ekB4YnQyGuw5fYX+uNQup9XsFO5RTmpS4FMzL5iIPqfyRzyckyuDmqxo6 bSGt4t6xMYKxvX+pAkvuLdtL3T/RbHqh2xx6Ql4DPWKN6gYtn+UjLbdKxHhYcJEZld AaKu2qFkQ/e7h2JLkxD/39yotFQUOlWeyFt8zE40= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 1510BF80161; Wed, 24 Feb 2021 11:33:39 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 13060F8016C; Wed, 24 Feb 2021 11:33:37 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 0D1F9F80129 for ; Wed, 24 Feb 2021 11:33:33 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 0D1F9F80129 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 01A52B03A; Wed, 24 Feb 2021 10:33:33 +0000 (UTC) Date: Wed, 24 Feb 2021 11:33:32 +0100 Message-ID: From: Takashi Iwai To: Jaroslav Kysela Subject: Re: [RFC 2/2] ASoC: rt5670: Add LED trigger support In-Reply-To: <03068e15-2157-3ae6-ffd6-7ec315bb49a3@perex.cz> References: <20210215142419.308651-1-hdegoede@redhat.com> <20210215142419.308651-3-hdegoede@redhat.com> <20210223134506.GF5116@sirena.org.uk> <578b1ee3-f426-c5b5-bc78-5a91108ebdc8@redhat.com> <20210223140930.GH5116@sirena.org.uk> <5c6a21c1-7107-3351-25be-c007b0b946d3@perex.cz> <776b4ad9-2612-b08a-cb76-c3e1ce02388a@perex.cz> <4574088a-4676-131a-0065-499a516f80ae@perex.cz> <03068e15-2157-3ae6-ffd6-7ec315bb49a3@perex.cz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Oder Chiou , alsa-devel@alsa-project.org, Liam Girdwood , Hans de Goede , Mark Brown , Bard Liao X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Wed, 24 Feb 2021 10:49:41 +0100, Jaroslav Kysela wrote: > > Dne 24. 02. 21 v 10:38 Takashi Iwai napsal(a): > > >> It seems that you misunderstood the number of issues which my code is trying > >> to resolve: > >> > >> 1) set LED based on state from multiple cards (so you cannot trigger LED > >> inside single driver / single control element); we need one arbiter; this is > >> the main argument > >> 2) unifies the audio LED interface > >> 3) reduce the hardware driver code > > > > Those purposes are all fine. But they don't need to be exposed for > > user controls that can be abused. That's the very concern. > > So, how to handle this feature for AMD ACP without PA / PipeWire modifications? > > And if we add an user space channel to the audio LED arbiter code, how it > differs from my proposed control API extension? As the early patch does, creating a kernel control (but not a generic "Capture" switch but specific to LED) and control it in UCM profile. What's the practical problem there? That's what I might have missed as the starting point of the discussion. > We have already locking > mechanism for the user control element to one task, so it's possible to create > safe user space implementation (depending on the standard task priviledges) on > demand even with my proposal. > > Could you elaborate the abuse you mean? Three bits? You can create up to 1028 user controls per card and each of them can fire the led trigger... That's an interesting experiment :) So far, a user control is merely storing the value, let read/write via the control API. That's all, and nothing wrong can happen just by that. Now if it interacts with other subsystem... A more serious concern is rather the fragility of the setup; for enabling the mute LED control, you'd have to create a new user-space control, the function of the control has to be ignored by some application and some not, etc. This has to be done on each machine when the system got updated. And, not everyone is using alsa-lib. Does tiny ALSA and other existing backend support the user control element management? Some uncertainty here. thanks, Takashi