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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0901EC433F5 for ; Mon, 30 May 2022 09:18:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234743AbiE3JSy (ORCPT ); Mon, 30 May 2022 05:18:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234455AbiE3JSr (ORCPT ); Mon, 30 May 2022 05:18:47 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E49DC63535 for ; Mon, 30 May 2022 02:18:45 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 81CB921BC3; Mon, 30 May 2022 09:18:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1653902324; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HHYeJrPoJIhFkQeLzz1dxeXQAw88Q2P/6fQxJ0P02+4=; b=fU2upPQ2ssKfLkZM/IrpLffOLn/0R32zmbs3ILDyhU3o78MaR31vXss1k9Ux/RH/9/2jj6 XYBJxl9l/kQSTDbG1eVysLFGwQdGD80W1xSFDbtn0z11/CKYwV1ajWU18zqG7Gfj2Jne9m 2TTQjytIjp+XPqoDNFDjkGZUR+mr5sY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1653902324; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HHYeJrPoJIhFkQeLzz1dxeXQAw88Q2P/6fQxJ0P02+4=; b=jJ3i6lW7/vqleHkeJJ4+BZcEfTtQA1VkUs57Wp2GJk2stZlO75JgblzkOH69X7rL2xd9/J 0A/gBnzM0OPBCCDQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 4B21D13A84; Mon, 30 May 2022 09:18:44 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id eUisEfSLlGJVLQAAMHmgww (envelope-from ); Mon, 30 May 2022 09:18:44 +0000 Date: Mon, 30 May 2022 11:18:43 +0200 Message-ID: <87czfvxtsc.wl-tiwai@suse.de> From: Takashi Iwai To: Charles Keepax Cc: Vitaly Rodionov , Jaroslav Kysela , Takashi Iwai , Mark Brown , , , Subject: Re: [PATCH v4 00/17] ALSA: hda: cirrus: Add initial DSP support and firmware loading In-Reply-To: <20220530090846.GS38351@ediswmail.ad.cirrus.com> References: <20220525131638.5512-1-vitalyr@opensource.cirrus.com> <871qwf0x8t.wl-tiwai@suse.de> <20220530090846.GS38351@ediswmail.ad.cirrus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 30 May 2022 11:08:46 +0200, Charles Keepax wrote: > > On Fri, May 27, 2022 at 06:13:38PM +0200, Takashi Iwai wrote: > > On Wed, 25 May 2022 15:16:21 +0200, > > Vitaly Rodionov wrote: > > The idea to add / delete controls by the control element change > > doesn't sound good; as already mentioned in my reply to the previous > > patch set, the change of the control elements can be triggered too > > easily by any normal users who have the access to the sound devices. > > It means thousands of additions and removals per second could be > > attacked by any user. > > > > This I am a little less sure how we handle. I mean arn't there > already a few ways to do this? Both the existing ASoC wm_adsp > stuff, and the topology stuff (used on all new Intel platforms, > so very widely deployed) let you create controls by loading a > firmware file. Also within ALSA itself can't user-space create > user ALSA controls? Is there some rate limiting on that? How is > this issue tackled there? The creation of kctls via firmware loading would be OK, as the code path can't be triggered so frequently. Is it the case for this patch set? There was too little information about the implementation (and more importantly, how to use the controls), so it's hard to judge... And yes, a rate-limit could be implemented for the user controls. Or, even the hard upper limit for number of additions/deletions per process could be set, I suppose. (Currently only the total number of ctl elements are managed.) > > Moreover, the new controls with TLV controls don't look following the > > standard TLV syntax (type-length-value). My previous questions about > > the TLV usages are still unanswered, so I'm not sure what impact this > > would have, though. At least, alsactl behavior must be checked > > beforehand. If this is really device-specific (non-)TLV usages, it has > > to be clearly documented. > > > > The TLV stuff should be completely removed once my latest > comments have been updated. I don't think we need this for the > amps and I would also rather keep the usage to a minimum until > one of us finally gets around to resolving the large control > issues in a way that is more acceptable to everyone (likely > with a new IOCTL). It'll be great if the complexity could be reduced. thanks, Takashi