Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp542450pxb; Thu, 31 Mar 2022 11:08:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzG42nji7oM3XQ80hzodXjnK1lLKUFKR8uGop/WN9btiLKhSJrtHq0l5K4Em9kqFiulgYGg X-Received: by 2002:a05:6402:2747:b0:419:4817:ba22 with SMTP id z7-20020a056402274700b004194817ba22mr17311498edd.253.1648750111545; Thu, 31 Mar 2022 11:08:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648750111; cv=none; d=google.com; s=arc-20160816; b=Nrd2HswEpr+FTFVegljkfBEFlndjh2nU+/w5rK6yRUM0Q8GxkMBUNY36CRIN0h6L1B qJOXgQMEzzYJBrEY7IQmLSilwBvfFzVGVC9wa7lSziejiHJBb2YRL6pcclWxIbJjoeHT NqlwcCm4/iLMsdD5/dRvLo55a9p1SDVFhn6eIwL5W36jWqUtXL2ElJT2Rr7s/437iak2 xoxV+22JV/lsD7NOR60Y3uB7ZUP3V/zJd4beGb9u9/jOXSD7LG3WPaaDFa4x7PiykfOU MKMCMl5FCs6MO0rf4WrThGlFqjwEoTtasRc5M6fhJxvZ+tFkbJ9ysb9ACLICOd42lGQ7 Xf/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to; bh=0hazM8AzNmhekvcG/vE1j/2v9HlnOyWtfoZea7qNkoY=; b=wkCJg6Ijp6LAlRBSZaVjRxVRnB859/024XVWGXf9f2w4epgMcB5ab7bML4VQMWuErV Bs1G9b+mcBCyUfW1Dj2SsHd6kcysXNN61T1mBsCf2O+HDhjDBZPYaUNrs+Tx8c3dTFxW IA5v1zIe2tVCdmTD6AzC6k929yoGl4zJN8SHQGgjbPPOEWza0Z1F/I2dwCQOZinkHXt1 4xe7EW+qlR441yEzd4Os41RxQCYg7KTcs1M7p0JrCig7OY7P1aAs3hn/24QFp/m3dbQr olDQgB4W9fVQgidYVsJIRzWv3DMLv3tScaKc7aqNLsk4qyAY6NswBQyMgiFxYPQiRzkJ 9zmQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ec9-20020a170906b6c900b006dfe218dcccsi152965ejb.611.2022.03.31.11.08.05; Thu, 31 Mar 2022 11:08:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236825AbiCaNay (ORCPT + 99 others); Thu, 31 Mar 2022 09:30:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232708AbiCaNax (ORCPT ); Thu, 31 Mar 2022 09:30:53 -0400 Received: from mail.marcansoft.com (marcansoft.com [212.63.210.85]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6013937A24; Thu, 31 Mar 2022 06:29:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 8740941E96; Thu, 31 Mar 2022 13:28:59 +0000 (UTC) To: Mark Brown , =?UTF-8?Q?Martin_Povi=c5=a1er?= Cc: Liam Girdwood , Rob Herring , Krzysztof Kozlowski , Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Kettenis , Sven Peter References: <20220331000449.41062-1-povik+lin@cutebit.org> From: Hector Martin Subject: Re: [RFC PATCH 0/5] Apple Macs machine-level ASoC driver Message-ID: Date: Thu, 31 Mar 2022 22:28:56 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: es-ES Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31/03/2022 21.34, Mark Brown wrote: > On Thu, Mar 31, 2022 at 02:04:44AM +0200, Martin PoviĊĦer wrote: > >> I put together a machine-level ASoC driver for recent Apple Macs (the >> ones with ARM64 SoCs) and want to gauge opinions. > > This would be a bit easier to review with a description of the hardware. > >> Commit 2 adds a new ASoC card method (filter_controls) to let the card >> prevent some codec kcontrols from being visible to userspace. For example >> the TAS2770 speaker amp driver would be happy to expose TDM slot selection >> and ISENSE/VSENSE enables which is ridiculous. I am all ears on how to >> make the patch acceptable to upstream. > > The broad issue here is that what you consider ridiculous someone else > might have some bright ideas for configuring dynamically - if things are > being exposed for dynamic configuration it's probably because someone > wanted them, if the control is genuinely useless then it should just be > removed. Rather than getting in the way of people's policy arguments > about how to set things we expose them to userspace and let userspace > worry about it, usually with the help of UCM files. The general > userspace model is that people interact with their sound server more > than the hardware card. This is also helpful for people developing use > cases, it means they're not having to get the kernel rebuilt to tune > things. The problem with this model is that, in particular in the case of speaker amps, incorrect settings can cause your speakers to blow up. This has been a longstanding problem with ASoC platforms (I should know, I *melted* the speakers in a Chromebook by toggling the wrong alsamixer control once, it even warped the external case, all without making any audible noise). It's the kernel's job to ensure that broadly exposed user controls are safe and cannot be used to cause hardware damage; if that is possible, then that's a kernel security vulnerability worthy of a CVE, in my opinion. I think this idea of exposing what is effectively raw codec chip registers as ALSA controls that is so popular these days was a terrible idea from the start, and only makes some sense within the world of highly integrated vendor-controlled embedded platforms running kiosk-style software with no user control. It is completely unsuitable for a desktop Linux system, since it means users *will* destroy their hardware accidentally. So, some way or another, whatever is exposed has to be sanitized so that it can't go outside the envelope of what is safe for the hardware design. That cannot be known at the level of codec chips and speaker amp chips; it requires platform integration knowledge. That knowledge is what is (intended to be) encoded in the macaudio driver. It's supposed to know how to drive the underlying codec chips and disable access to things that don't make any sense on the platform, and expose controls to the user that are reasonable for what a user would want to do on that specific hardware platform, and no more. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub