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 32B28C433F5 for ; Fri, 27 May 2022 16:13:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349205AbiE0QNo (ORCPT ); Fri, 27 May 2022 12:13:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235190AbiE0QNl (ORCPT ); Fri, 27 May 2022 12:13:41 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9DB0694AE for ; Fri, 27 May 2022 09:13:40 -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 86B8A21ADA; Fri, 27 May 2022 16:13:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1653668019; 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=UCBex/08JKyMBNG9+8XKAWONPejCLu/grdanStzZ9Ik=; b=hPry9gFOQJSaMDVK8/ftxw4EL2nKNKHnOvycMvmPCR9VXbPt+wMJiAxEmsXD+D4mpWO5yF dvljsKCTxXOkbPwgPAZFIX+2+czQ4li6KU32mLBg+5v8KwD4yUT5yUGOc9gu3FjA5v3/9C 2bXUPE4B57fTZHr30kmPe+T4kicqCH8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1653668019; 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=UCBex/08JKyMBNG9+8XKAWONPejCLu/grdanStzZ9Ik=; b=k3GbLAyhK3rEjaYy1Ap1hlX+2Y3DUnhuUPtQaNqp1m3wZa+Hfih61pJCESQZmQ8gQauaNf NI7IRvbsZdR+z1Cw== 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 5A5C3139C4; Fri, 27 May 2022 16:13:39 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id JkUdFbP4kGJHFgAAMHmgww (envelope-from ); Fri, 27 May 2022 16:13:39 +0000 Date: Fri, 27 May 2022 18:13:38 +0200 Message-ID: <871qwf0x8t.wl-tiwai@suse.de> From: Takashi Iwai To: Vitaly Rodionov Cc: 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: <20220525131638.5512-1-vitalyr@opensource.cirrus.com> References: <20220525131638.5512-1-vitalyr@opensource.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 Wed, 25 May 2022 15:16:21 +0200, Vitaly Rodionov wrote: > > The CS35L41 Amplifier contains a DSP, capable of running firmware. > The firmware can run algorithms such as Speaker Protection, to ensure > that playback at high gains do not harm the speakers. > Adding support for CS35L41 firmware into the CS35L41 HDA driver also > allows us to support several extra features, such as hiberation > and interrupts. > > The chain adds support in stages: > - General fixes to improve generalization and code re-use inside > the CS35L41 HDA driver. > - Add support for interrupts into the driver, which is required > for complete support of the firmware. > - Refactor ASoC CS35L41 code which deals with firmware to allow > for code re-use inside the CS35L41 HDA driver. > - Add support for loading firmware and tuning files from file system, > and creating alsa controls to control it. > - Support firmware load paths for different hardware systems. > - Support suspend/resume in the driver when using firmware. The firmware > supports hibernation, which allows the CS35L41 to drop into a low > power mode during suspend. > - Support the ability to unload firmware, swap and reload the firmware. > This is to allow different firmware to run during calibration. > > The intended use-case is to load the firmware once on boot, and the driver > autmatically tries to load the firmware after it binds to the HDA driver. > This behaviour can be switched off using a kconfig, if desired. 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. 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. I don't mean fully against such a TLV usage, *IFF* the same pattern has been already used in ASoC side. In that case, we may need to introduce some PCM info flag to indicate a non-standard TLV usage (but it's a bit different story). OTOH, the too easily triggered control addition/removal is likely no-go, as this could be a cause of DoS-like attacks. If we must to in this direction, it has to be verified and clarified. thanks, Takashi